Re: [License-discuss] [Non-DoD Source] Re: OSI definition

+1 to David's interpretation. Otherwise you end up on slippery slope territory. Thanks, Cem Karan From: License-discuss [license-discuss-boun...@lists.opensource.org] on behalf of David Woolley [for...@david-woolley.me.uk] Sent: Sunday, January 17, 2021

Re: [License-discuss] [Non-DoD Source] Re: Certifying MIT-0

How about the mashup at https://github.com/USArmyResearchLab/ARL-Open-Source-Guidance-and-Instructions/blob/rewrite_for_2.0/LICENSE.txt ? Would that work in all parts of the EU? Thanks, Cem Karan 1 (301) 394-0667 1 (240) 309-5216 From: License-discuss

Re: [License-discuss] [Non-DoD Source] A new USG License

McCoy, if you're willing to talk with Diane, I'd appreciate it! I did talk with her quite a while ago about the USG's issues, but nothing much came of the interaction (she seemed very, very busy at the time). If you're able to continue the discussions, I would be very interested in seeing wher

Re: [License-discuss] Generic process for removing approved licenses. Re: REMOVE AAL from list of approved licenses

(Comment below, I've heavily edited to focus in, please read earlier portions of the thread for context) On Sunday, March 29, 2020 2:06 PM, Henrik Ingo wrote: On Fri, Mar 27, 2020 at 10:22 PM Josh Berkus mailto:j...@berkus.org > > wrote: 1. license does not in fact conform to the OSD (was erro

Re: [License-discuss] [Non-DoD Source] Re: Resources to discourage governments from bespoke licenses?

> -Original Message- > From: Richard Fontana > Sent: Saturday, February 29, 2020 2:07 PM > To: mc...@lexpan.law; license-discuss@lists.opensource.org > Cc: Karan, Cem F CIV USARMY CCDC ARL (USA) > Subject: Re: [License-discuss] [Non-DoD Source] Re: Resources to discourage > governments f

Re: [License-discuss] [Non-DoD Source] Re: Resources to discourage governments from bespoke licenses?

NOSA 3.0 was a NASA effort to address the complaints of 2.0. It wasn’t submitted, just worked on. I’m sorry about causing confusion. Thanks, Cem Karan —- Other than quoted laws, regulations or officially published policies, the views expressed herein are not intended to be used as an authorit

Re: [License-discuss] [Non-DoD Source] Re: Resources to discourage governments from bespoke licenses?

> >>> [There also were some concerns about non-reciprocity, IIRC, to which the > >>> response was the same as above] > > >>THAT would be a serious concern! I don't recall there being such a > >>problem, can you find it in the archives? If it does exist, then it > needs to be addressed. > > He

Re: [License-discuss] [Non-DoD Source] Re: Resources to discourage governments from bespoke licenses?

> >>The US Government has a lot of money, and with money can come lawsuits. > >>These are not only expensive to fight, they can also have a > chilling effect on both the use of, and publication of, Open Source software > by the US Government. I personally want to avoid that kind of > problem.

Re: [License-discuss] [Non-DoD Source] Re: Resources to discourage governments from bespoke licenses?

On Friday, February 28, 2020 12:37 PM Thorsten Glaser wrote: > To: Karan, Cem F CIV USARMY CCDC ARL (USA) via License-discuss > > Karan, Cem F CIV USARMY CCDC ARL (USA) via License-discuss dixit: > >But as it currently stands, I don’t know if I’m exposing both the USG > >*

Re: [License-discuss] [Non-DoD Source] Re: Resources to discourage governments from bespoke licenses?

On Friday, February 28, 2020 1:28 PM McCoy Smith wrote: >>As one of those people who keep trying to get recognition of how the US >>Government (USG) **really is** different, I’d like to point out the following >>issues: >>Also as far as I know, none of the major Open Source licenses have a >>

Re: [License-discuss] [Non-DoD Source] Re: Resources to discourage governments from bespoke licenses?

As one of those people who keep trying to get recognition of how the US Government (USG) **really is** different, I’d like to point out the following issues: 1) As far as I know, all of the major Open Source licenses rely on copyright for protection in some form. 2) Also as far as I

Re: [License-discuss] [Non-DoD Source] Re: "Fairness" vs. mission objectives

What about NOSA 3.0? Thanks, Cem Karan —- Other than quoted laws, regulations or officially published policies, the views expressed herein are not intended to be used as an authoritative state of law nor do they reflect official positions of the U.S. Army, Department of Defense or U.S. Govern

Re: [License-discuss] [Non-DoD Source] Re: "Fairness" vs. mission objectives

Eric S. Raymond wrote on Monday, February 24, 2020 2:10 PM > > Simon Phipps : > > What I'd propose here is that we explore a process for deprecation of > > licenses by someone other than the license steward. Maybe it would > > start with a substantiated request endorsed by several regular list >

Re: [License-discuss] Storing source artifacts in ELF files

Howard Chu wrote on Monday, October 7, 2019 7:42 PM: > Karan, Cem F CIV USARMY CCDC ARL (USA) via License-discuss wrote: > > Thorsten Glaser wrote on Monday, October 7, 2019 5:14 PM: > >> To: license-discuss@lists.opensource.org > >>> SEAs require you to trust tha

Re: [License-discuss] [Non-DoD Source] Re: Storing source artifacts in ELF files

Thorsten Glaser wrote on Monday, October 7, 2019 5:14 PM: > To: license-discuss@lists.opensource.org > Subject: [Non-DoD Source] Re: [License-discuss] Storing source artifacts in > ELF files > > Karan, Cem F CIV USARMY CCDC ARL (USA) via License-discuss dixit: > > >Ye

Re: [License-discuss] Storing source artifacts in ELF files (was: RE: [Non-DoD Source] Re: Discussion: AGPL and Open Source Definition conflict)

I get what you're saying, and I see your point. My thought is that the tools would be shipped with distros (which I strongly suspect is what 99% of the people out there will use, rather than roll their own). The tools may actually be simple bash scripts that do exactly what you're saying, or t

Re: [License-discuss] Storing source artifacts in ELF files (was: RE: [Non-DoD Source] Re: Discussion: AGPL and Open Source Definition conflict)

Bruce Perens wrote on Monday, October 7, 2019 3:52 PM: > Rather than do this, why not just make an existing > archive format executable? Just sticking #! and the > interpreter name at the front should be sufficient. > If you execute it, it extracts and runs a native > executable for your archi

Re: [License-discuss] Storing source artifacts in ELF files (was: RE: [Non-DoD Source] Re: Discussion: AGPL and Open Source Definition conflict)

Thorsten Glaser wrote on Monday, October 7, 2019 11:22 AM: > Karan, Cem F CIV USARMY CCDC ARL (USA) via License-discuss dixit: > > >If it were to be done seriously, then a great deal more thought would > >need to go into it. In one of the messages I sent out (see > > W

Re: [License-discuss] [Non-DoD Source] Re: Discussion: AGPL and Open Source Definition conflict

Thorsten Glaser wrote on Sunday, October 6, 2019 3:24 PM > Florian Weimer dixit: > > >for shipping corresponding source code that was actually compiled, and > >not just upstream tarballs plus downstream patches. > > upstream tarballs plus downstream patches is preferred form of modification, > t

Re: [License-discuss] [Non-DoD Source] Re: Discussion: AGPL and Open Source Definition conflict

On Sep 24, 2019, at 10:23 PM, Howard Chu wrote: > > All active links contained in this email were disabled. Please verify the > identity of the sender, and confirm the authenticity of all links contained > within the message prior to copying and pasting the address to a Web browser. > > >

Re: [License-discuss] [Non-DoD Source] Re: Discussion: AGPL and Open Source Definition conflict

>From: John Cowan >Sent: Tuesday, September 24, 2019 3:32 PM > >>On Tue, Sep 24, 2019 at 2:46 PM Florian Weimer >Caution-mailto:f...@deneb.enyo.de > > wrote: >> >>A useful implementation for C and C++ looks rather involved due to the >>preprocessor.  > >I was think

Re: [License-discuss] [Non-DoD Source] Re: Discussion: AGPL and Open Source Definition conflict

Florian Weimer wrote on Tuesday, September 24, 2019 1:55 PM > * Cem F. Karan: <> > > That said, I for one would find it *highly* amusing if gcc/clang added > > a switch to embed the complete project into the binary (or even a git > > bundle, so you can do a pull from an executable). > > It's not

Re: [License-discuss] [Non-DoD Source] Re: Discussion: AGPL and Open Source Definition conflict

Florian Weimer wrote on Tuesday, September 24, 2019 6:42 AM > * Howard Chu: > > > That sounds like a fair summary, yes. Also, simply adding a > > non-standard extension to our server to meet this license requirement > > doesn't solve anything, if all LDAP clients aren't also modified to > > recog

Re: [License-discuss] [Non-DoD Source] Re: Government licenses

For what it's worth, this is essentially the stance that the US Army Research Policy (ARL) makes in its own policy (disclaimer: I co-wrote ARL's policy); see https://github.com/USArmyResearchLab/ARL-Open-Source-Guidance-and-Instructions (note that ARL is in the process of reviewing and updating