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

Florian Weimer wrote: > * Cem F. Karan: > >> The ELF idea sounds interesting, but what about other binary >> containers, e.g. mach-o? > > I don't know anything about mach-o, sorry. Well, I know that some of > the files share their magic number with Java class files, but that's > it. > >> That s

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] Discussion: AGPL and Open Source Definition conflict

On the side of the person needing to comply, one need only make sure the source code is carefully published. On the side of the person wishing to access the source code, the only alternative is to turn on logging or use a hacked client. I don't think it would be permissible to emit no notice regard

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

On Tue, Sep 24, 2019 at 2:46 PM Florian Weimer wrote: A useful implementation for C and C++ looks rather involved due to the > preprocessor. I was thinking of something much simpler, like putting one of these, or something like them, in the Makefile immediately after the link step: elftar r $@

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

* John Cowan: > ELF format is divided into sections, and NOTE sections contain arbitrary > key-value pairs, where the value can be up to 2 GB. There seems to be no > utility for adding and removing these, but there is no problem in > principle: the ELF format is well documented, and a tool (calle

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

* Cem F. Karan: > This is actually starting to sound like an interesting/good idea. For > GPL compliance, you can't get much better than having the source > artifacts stored with the binary itself. It's not always possible to meet license notification requirements this way, unfortunately. > So,

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

On Tue, Sep 24, 2019 at 2:14 PM Karan, Cem F CIV USARMY CCDC ARL (USA) via License-discuss wrote: This is actually starting to sound like an interesting/good idea. For GPL > compliance, you can't get much better than having the source artifacts > stored with the binary itself. So, the question

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

* Cem F. Karan: > The ELF idea sounds interesting, but what about other binary > containers, e.g. mach-o? I don't know anything about mach-o, sorry. Well, I know that some of the files share their magic number with Java class files, but that's it. > That said, I for one would find it *highly* a

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

On Tue, 24 Sep 2019, 13:50 Florian Weimer, wrote > My impression is that AGPL has gained a reputation of a GPL version > that enables “open core” business models, and this is why most people > choose it. The FUD it creates for non-networked AGPL code appears to > be a welcome side effect, one th

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

On Tue, Sep 24, 2019 at 11:34 AM Florian Weimer wrote: > My impression is that AGPL has gained a reputation of a GPL version > that enables “open core” business models, and this is why most people > choose it. The FUD it creates for non-networked AGPL code appears to > be a welcome side effect,

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] Discussion: AGPL and Open Source Definition conflict

* 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 recognize the extension, and that in particular seems an > unrealistic task.

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

* Howard Chu: > Clause #10 of the definition https://opensource.org/docs/osd > > 10. License Must Be Technology-Neutral > > No provision of the license may be predicated on any individual > technology or style of interface. > > I note that the Affero GPL > https://www.gnu.org/licenses/agpl-3.0.en.

Re: [License-discuss] Fair Use

* Lawrence Rosen: > I wrote the following article for Linux Journal in 2002. Perhaps it > will help you? At least my article refers to some court cases where > legal opinions about fair use were expressed. > https://www.linuxjournal.com/article/6080 This article does not explicitly mention that

Re: [License-discuss] Coordinated release of security vulnerability information.

* VanL: > What would everyone here think of the following exception to the CAL's > requirement to provide source code: > > 4.1.3. Coordinated Disclosure of Security Vulnerabilities > > You may delay providing the Source Code corresponding to a particular > modification to the Work for up to ninety