[License-discuss] Category B licenses at Apache
An Apache member wrote that this ASF license objective is firmly held: To allow our customers to redistribute with closed-source modifications. That objective remains completely and always enforceable for ALv2 code. It is not enforceable for Eclipse (ECL) components or MPLv2 components. These are two different but entirely valid ways to FOSS. Reciprocity is a license condition for some FOSS licenses. There is nothing evil in that. It is always an author's prerogative to choose her FOSS license. None of the companies in Eclipse Foundation have any objection whatsoever (that I've heard) to the inclusion of ECL and MPLv2 components into Apache aggregations. Indeed, they collectively and enthusiastically create such valuable FOSS components for that very purpose. They include them in their own products. So is the objective to redistribute with closed-source modifications intended to describe an actual Apache concern, or a religious objection to all reciprocal licenses? Certainly not the latter! According to the current Apache Third Party License Policy http://www.apache.org/legal/resolved.html, ASF doesn't really object to these reciprocal FOSS licenses; they are handled as exceptions. In the Policy this is colloquially known as the *Category B* list. But then that Policy makes the following strange explanation for Category B and its enforcement conditions at ASF: *By including only the object/binary form, there is less exposed surface area of the third-party work from which a work might be derived; this addresses the second guiding principle of this policy.* That object/binary form requirement and the reference to exposed surface area in the Policy are nonsense. I repeat three statements I made here previously: · The binary and source forms of a work are, from a copyright perspective, the exact same work subject to the exact same FOSS license. Stop wasting time trying to distinguish them legally. · Apache is committed to FOSS. For that reason, we should always publish source code. Binaries are a convenience for our customers published by our projects, but never without source code. · Our failure, or our customer's failure, to make that source code available (including of course any ALv2 code) and copies of all relevant licenses, is a probable breach of license and possible copyright infringement. All modern technology companies understand that about FOSS and copyright law. The second guiding principle referred to in the current Apache Policy is this: 2. The license must not place restrictions on the distribution of independent works that simply use or contain the covered work. This accurately and precisely refers to independent works and not derivative works. Reciprocity has nothing to do with independent works. Every FOSS license (except perhaps under the GPL static linking doctrine) satisfies this second guiding principle. See OSD. /Larry P.S. I don't know if this message will survive legal-discuss@ list moderation, so I intend to send it onto other lists. All quotations are from *public* ASF lists. Lawrence Rosen If this were legal advice it would have been accompanied by a bill. ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
[License-discuss] Category B licenses at Apache
An Apache member wrote that this ASF license objective is firmly held: To allow our customers to redistribute with closed-source modifications. That objective remains completely and always enforceable for ALv2 code. It is not enforceable for Eclipse (ECL) components or MPLv2 components. These are two different but entirely valid ways to FOSS. Reciprocity is a license condition for some FOSS licenses. There is nothing evil in that. It is always an author's prerogative to choose her FOSS license. None of the companies in Eclipse Foundation have any objection whatsoever (that I've heard) to the inclusion of ECL and MPLv2 components into Apache aggregations. Indeed, they collectively and enthusiastically create such valuable FOSS components for that very purpose. They include them in their own products. So is the objective to redistribute with closed-source modifications intended to describe an actual Apache concern, or a religious objection to all reciprocal licenses? Certainly not the latter! According to the current Apache Third Party License Policy http://www.apache.org/legal/resolved.html , ASF doesn't really object to these reciprocal FOSS licenses; they are handled as exceptions. In the Policy this is colloquially known as the Category B list. But then that Policy makes the following strange explanation for Category B and its enforcement conditions at ASF: By including only the object/binary form, there is less exposed surface area of the third-party work from which a work might be derived; this addresses the second guiding principle of this policy. That object/binary form requirement and the reference to exposed surface area in the Policy are nonsense. I repeat three statements I made here previously: * The binary and source forms of a work are, from a copyright perspective, the exact same work subject to the exact same FOSS license. Stop wasting time trying to distinguish them legally. * Apache is committed to FOSS. For that reason, we should always publish source code. Binaries are a convenience for our customers published by our projects, but never without source code. * Our failure, or our customer's failure, to make that source code available (including of course any ALv2 code) and copies of all relevant licenses, is a probable breach of license and possible copyright infringement. All modern technology companies understand that about FOSS and copyright law. The second guiding principle referred to in the current Apache Policy is this: 2. The license must not place restrictions on the distribution of independent works that simply use or contain the covered work. This accurately and precisely refers to independent works and not derivative works. Reciprocity has nothing to do with independent works. Every FOSS license (except perhaps under the GPL static linking doctrine) satisfies this second guiding principle. See OSD. /Larry P.S. I don't know if this message will survive legal-discuss@ list moderation, so I intend to send it onto other lists. All quotations are from public ASF lists. Lawrence Rosen If this were legal advice it would have been accompanied by a bill. ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
