Re: [License-discuss] Category B licenses at Apache
On 8/26/15, 3:14 AM, License-discuss on behalf of David Woolley license-discuss-boun...@opensource.org on behalf of for...@david-woolley.me.uk wrote: On 26/08/15 01:45, Tzeng, Nigel H. wrote: Larry, Scenario A: I¹m looking for an example in my codebase on how to do Foo (of course) and I find a code snippet to do roughly what I want. I cut and paste it into where I need it, modify it slightly and move on. Developers do this all the time. The purpose of open source is to allow them to do this legally. Coders who do this all the time on published code that doesn't have an open source type licence are continually infringing copyright. One of the main reasons for the GPL is to ensure a large pool of code that cane be re-used and re-purposed, whilst, at the same time ensuring that the resulting code goes back into the pool. Which is great except we are discussing Apache policy and not GPL. The point is that once you do this your code is now potentially subject to the terms of the weak copyleft Category B license without you being aware of this. I believe this is the reason that Apache explicitly does not include source with their Category B components. Scenario B: I am debugging some code and find a spot where an if test should be = bar rather than bar. I fix it while inside the debugger That change is going to have insufficient creative content to have any copyright associated with it. So all you have demonstrated there is that your organisation's configuration control procedures are broken and their ISO 9000 status may need revoking. In any case, typical copyleft licences permit the use of modified versions within an organisation. I think most folks will understand that if the example above is insufficient to trigger copyright the point is still clear. At some point a (more significant) change could result in an unintentional violation if the source code is present. And everyone makes mistakes ISO 9001 or not. The key is too minimize avoidable errors through policy/procedures, training and selective use of 3rd party libraries and licenses. Apache products are generally considered safe(r) and require less oversight in terms of copyright issues. A policy change at Apache to make this less true is probably not desired by many of its users. Thank you for your concern regarding our AS9100/ISO 9001:2000 status. While I am speaking only as an individual on this list and not as a representative of our organization, we do review our software development practices quite often to identify weaknesses and areas to improve. Certification is less important to us than quality development practices. Perhaps it should be general policy or a best practice suggestion not to include weak copyright source code in projects but only the compiled binaries even if it makes development and debugging slightly more annoying. I may suggest this after thinking about it more or put it up for discussion on our internal software development list. Despite my disagreement with Larry the risks ARE relatively low so perhaps sufficient training/awareness will be sufficient. But our situation is different than that of Apache. without realizing that it was in the Category B module. Since I¹m modifying the Apache product quite a bit anyway was not immediately obvious that when I checked my changes into the local repo for the Apache product that I made a change in the Category B module. Maybe I simply never knew or had forgotten that I had to be aware there was a category B module. I believe another intent of the GPL Is that people should be able to debug and repair the code that they possess. And this would be great if the discussion was about GPL but not everyone wants to use GPL, hence Apache. Was the title or topic somehow unclear? Or do you believe members of this mailing list are unaware of the advantages and disadvantages of the different types of open source licenses? Regards, Nigel ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Category B licenses at Apache
On 26/08/15 01:45, Tzeng, Nigel H. wrote: Larry, Scenario A: I’m looking for an example in my codebase on how to do Foo (of course) and I find a code snippet to do roughly what I want. I cut and paste it into where I need it, modify it slightly and move on. Developers do this all the time. The purpose of open source is to allow them to do this legally. Coders who do this all the time on published code that doesn't have an open source type licence are continually infringing copyright. One of the main reasons for the GPL is to ensure a large pool of code that cane be re-used and re-purposed, whilst, at the same time ensuring that the resulting code goes back into the pool. Scenario B: I am debugging some code and find a spot where an if test should be = bar rather than bar. I fix it while inside the debugger That change is going to have insufficient creative content to have any copyright associated with it. So all you have demonstrated there is that your organisation's configuration control procedures are broken and their ISO 9000 status may need revoking. In any case, typical copyleft licences permit the use of modified versions within an organisation. without realizing that it was in the Category B module. Since I’m modifying the Apache product quite a bit anyway was not immediately obvious that when I checked my changes into the local repo for the Apache product that I made a change in the Category B module. Maybe I simply never knew or had forgotten that I had to be aware there was a category B module. I believe another intent of the GPL Is that people should be able to debug and repair the code that they possess. ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Category B licenses at Apache
I wrote earlier and want to postscript it: A bigger change would require that someone intelligent on the PMC evaluate it as a contribution and make a comment about it in the NOTICE file. For example, a short and simple NOTICE file could say: Apache SQRT is an improved square root calculator that was created by Sally Contributor. She combined the best features of previous ALv2 and MPLv2 square root functions. This is documented in Sally's source code available at www.apache.org http://www.apache.org . This derivative work, Apache SQRT, is Copyright (C) 2015 Sally Contributor. Because this is a derivative work of an MPLv2 program, the resulting Apache SQRT module is licensed under MPLv2. Every program that invokes this Apache SQRT module retains its own license, FOSS or proprietary. /Larry From: Lawrence Rosen [mailto:lro...@rosenlaw.com] Sent: Thursday, August 20, 2015 8:25 AM To: 'Richard Eckart de Castilho' richard.eck...@gmail.com; license-discuss@opensource.org Cc: Lawrence Rosen lro...@rosenlaw.com Subject: RE: [License-discuss] Category B licenses at Apache snip ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Category B licenses at Apache
Responding to Nigel Tzeng's concerns (below) about source and object code: There is perhaps a smaller risk that someone will make a derivative work of Apache software entirely by accident from the binary alone without looking for the source code (and finding it) posted on the web. But just in case, for that reason and many others, seeking legal review first for a commercial product is a great idea before even attempting any derivative work. Important derivative works of software are not accidental. Enforcing compliance with licenses and copyright law requires legal review even for FOSS licenses that Apache lists in Category A. I know that because I wrote one of those OSI-approved and Apache-approved and FSF-approved FOSS licenses (AFL 3.0) that imposes important (non-reciprocal) conditions on both copies and derivative work. So do many other FOSS licenses in all Apache's categories. For both binaries and source code. Caveat emptor. Caveat derivator. /Larry P.S. Nigel is correct. I meant EPL not ECL. I write too fast From: Tzeng, Nigel H. [mailto:nigel.tz...@jhuapl.edu] Sent: Thursday, August 20, 2015 4:36 PM To: Lawrence Rosen lro...@rosenlaw.com; license-discuss@opensource.org Subject: Re: [License-discuss] Category B licenses at Apache Larry, Please note that ECL is an OSI approved license based on Apache and not Eclipse. Using ECL in the same sentence as MPL is mildly confusing even when you (re)define the acronym in the previous paragraph when using EPL would be more clear. As far as differentiating between source and object code I believe that the Apache statement for category B licenses is correct. The exposed surface area at risk IS much lower than if source was available inside the Apache project as a default. You are under license obligation if you cut and paste from these EPL/MPL/etc source files and since the source files are not present you can't accidentally do so without explicitly getting that source from somewhere. By making that an extra step Apache is reducing the risk of an accidental copyright violation. Without the source files you also can't easily modify the MPL/etc work for which the modified source must be provided by you instead of just pointing upstream to some place the original source can be found. Whether or not the binary and source are considered the same work under copyright is immaterial.distributing only the binary format reduces the risk of accidental violations for code licensed under some, if not all, weak copyleft licenses by eliminating/reducing some of the most common opportunities for making a mistake. It strikes me that this is a pragmatic and useful risk reduction strategy in handling weak copyleft code within ALv2 projects that helps protect both maintainers and users of the Apache product. Apache should probably provide that source separately as a matter of policy for handling category B licensed components rather than just point upstream to a source that could disappear a few years down the road. There's a bit of orphaned java code out there where the original projects and their repos have disappeared. Maybe Apache does but it's not explicitly written in the FAQ to do anything but include the URL to the product's homepage where presumably the source is available. Maybe I read that part wrong or there is a more exhaustive checklist somewhere else of what the Apache project needs to do when using Category B components. Regards, Nigel From: License-discuss license-discuss-boun...@opensource.org mailto:license-discuss-boun...@opensource.org on behalf of Lawrence Rosen lro...@rosenlaw.com mailto:lro...@rosenlaw.com Reply-To: Lawrence Rosen lro...@rosenlaw.com mailto:lro...@rosenlaw.com , License Discuss license-discuss@opensource.org mailto:license-discuss@opensource.org Date: Monday, August 17, 2015 at 3:20 PM To: License Discuss license-discuss@opensource.org mailto:license-discuss@opensource.org Subject: [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
Re: [License-discuss] Category B licenses at Apache
Richard Eckart de Castilho wrote: The problem with reciprocal licenses in the lines of EPL and MPL is not so much in being used as: a) a *library* or as b) a clearly *separate piece of code* (that resides in a repository outside the ASF) but rather in *accepting patches* for at least two reasons: 1) it is tedious to *maintain per-line license* information in a source file 2) it seriously *limits the ability to perform refactoring* of code Thanks for trying, but why did you bother to write me about something that the ASF board has already decided for you? You didn't accurately describe my proposal. I suggested that the decisions on contribution licenses should be made by each PMC based on software needs rather than an ASF-wide policy that accomplishes nothing valuable and is legally nonsense. There is no FOSS limit on refactoring. Do it freely. Who asked for a separate source repository? Furthermore, who suggested that anyone maintain per-line license information? Are you going to blame my proposal for every unreasonable suggestion by those who don't understand copyright law and FOSS license requirements? Accepting patches (if by that you mean small changes to fix bugs) is not a copyright problem. A bigger change would require that someone intelligent on the PMC evaluate it as a contribution and make a comment about it in the NOTICE file. /Larry Lawrence Rosen If this were legal advice it would have been accompanied by a bill. -Original Message- From: Richard Eckart de Castilho [mailto:richard.eck...@gmail.com] Sent: Thursday, August 20, 2015 12:14 AM To: Lawrence Rosen lro...@rosenlaw.com; license-discuss@opensource.org Subject: Re: [License-discuss] Category B licenses at Apache Hi Larry, On 17.08.2015, at 21:20, Lawrence Rosen mailto:lro...@rosenlaw.com lro...@rosenlaw.com wrote: snip 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. snip What you call nonsense makes a lot of sense from the point of view of a software developer. The problem with reciprocal licenses in the lines of EPL and MPL is not so much in being used as: a) a *library* or as b) a clearly *separate piece of code* (that resides in a repository outside the ASF) but rather in *accepting patches* for at least two reasons: 1) it is tedious to *maintain per-line license* information in a source file 2) it seriously *limits the ability to perform refactoring* of code Of course, 1 and 2 become somewhat irrelevant if a project under license X that accepts patches under EPL/MPL simply states that all source files are licensed under EPL/MPL and *contain parts licensed under X*. But then *X becomes irrelevant* because it is hard to impossible to tell which parts of the project are actually licensed under X and which parts are under EPL/MPL. Thus, if the developers of the project wish that their project remains under license X, accepting *patches* under EPL/MPL is simple *not desirable*. Cheers, -- Richard ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Category B licenses at Apache
Larry, Scenario A: I'm looking for an example in my codebase on how to do Foo (of course) and I find a code snippet to do roughly what I want. I cut and paste it into where I need it, modify it slightly and move on. Developers do this all the time. If the source code for the Category B module is not present on my system, this code snippet can never be from that module. I will never accidentally cut and paste any reciprocally licensed code into my software because it's simply not there to be copied in the first place. This is not a true statement of the Category B module source is provided as default in the Apache product. Scenario B: I am debugging some code and find a spot where an if test should be = bar rather than bar. I fix it while inside the debugger without realizing that it was in the Category B module. Since I'm modifying the Apache product quite a bit anyway was not immediately obvious that when I checked my changes into the local repo for the Apache product that I made a change in the Category B module. Maybe I simply never knew or had forgotten that I had to be aware there was a category B module. If the source code for the Category B module is not present I typically cannot do this in the debugger. What I will discover is that the problem exists in some library for which source is not available. Typically folks will then realize the source is missing for reason. I disagree that folks do not accidentally create derivative works*. These two scenarios are easily avoided by simply not packaging the source code inside the Apache product but requiring a separate download. These two mistakes are not caught by legal review of licenses and Scenario A is not easily caught without fairly rigorous code review practices. Scenario B you have a better shot that someone notices that there are undesired changes to 3rd party packages in the repo. Frankly, inclusion of the Category B source would make it sufficiently annoying that I would likely avoid using that particular Apache product from a compliance perspective. You already need to make folks aware that just because the JRE source code is available to look at it doesn't mean its okay to reuse that source in your own code. Or source code found on Stack Overflow (default licensed CC-BY-SA). You have not shown how using a separate download does not meet requirements for Category B licenses nor made a case where including the source as default is superior to the current guideline of requiring the developer explicitly download the source for Category B modules as a safety measure. Regards, Nigel * feel free to argue fair use is viable defense for re-using code snippets without complying with the license terms. From: Lawrence Rosen lro...@rosenlaw.commailto:lro...@rosenlaw.com Reply-To: Lawrence Rosen lro...@rosenlaw.commailto:lro...@rosenlaw.com Date: Saturday, August 22, 2015 at 3:11 PM To: Nigel H. Tzeng nigel.tz...@jhuapl.edumailto:nigel.tz...@jhuapl.edu, License Discuss license-discuss@opensource.orgmailto:license-discuss@opensource.org Cc: Lawrence Rosen lro...@rosenlaw.commailto:lro...@rosenlaw.com Subject: RE: [License-discuss] Category B licenses at Apache Responding to Nigel Tzeng's concerns (below) about source and object code: There is perhaps a smaller risk that someone will make a derivative work of Apache software entirely by accident from the binary alone without looking for the source code (and finding it) posted on the web. But just in case, for that reason and many others, seeking legal review first for a commercial product is a great idea before even attempting any derivative work. Important derivative works of software are not accidental. Enforcing compliance with licenses and copyright law requires legal review even for FOSS licenses that Apache lists in Category A. I know that because I wrote one of those OSI-approved and Apache-approved and FSF-approved FOSS licenses (AFL 3.0) that imposes important (non-reciprocal) conditions on both copies and derivative work. So do many other FOSS licenses in all Apache's categories. For both binaries and source code. Caveat emptor. Caveat derivator. /Larry P.S. Nigel is correct. I meant EPL not ECL. I write too fast ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Category B licenses at Apache
Hi Larry, On 17.08.2015, at 21:20, Lawrence Rosen lro...@rosenlaw.com wrote: snip 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. snip What you call nonsense makes a lot of sense from the point of view of a software developer. The problem with reciprocal licenses in the lines of EPL and MPL is not so much in being used as: a) a *library* or as b) a clearly *separate piece of code* (that resides in a repository outside the ASF) but rather in *accepting patches* for at least two reasons: 1) it is tedious to *maintain per-line license* information in a source file 2) it seriously *limits the ability to perform refactoring* of code Of course, 1 and 2 become somewhat irrelevant if a project under license X that accepts patches under EPL/MPL simply states that all source files are licensed under EPL/MPL and *contain parts licensed under X*. But then *X becomes irrelevant* because it is hard to impossible to tell which parts of the project are actually licensed under X and which parts are under EPL/MPL. Thus, if the developers of the project wish that their project remains under license X, accepting *patches* under EPL/MPL is simple *not desirable*. Cheers, -- Richard ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Category B licenses at Apache
Larry, Please note that ECL is an OSI approved license based on Apache and not Eclipse. Using ECL in the same sentence as MPL is mildly confusing even when you (re)define the acronym in the previous paragraph when using EPL would be more clear. As far as differentiating between source and object code I believe that the Apache statement for category B licenses is correct. The exposed surface area at risk IS much lower than if source was available inside the Apache project as a default. You are under license obligation if you cut and paste from these EPL/MPL/etc source files and since the source files are not present you can’t accidentally do so without explicitly getting that source from somewhere. By making that an extra step Apache is reducing the risk of an accidental copyright violation. Without the source files you also can't easily modify the MPL/etc work for which the modified source must be provided by you instead of just pointing upstream to some place the original source can be found. Whether or not the binary and source are considered the same work under copyright is immaterial…distributing only the binary format reduces the risk of accidental violations for code licensed under some, if not all, weak copyleft licenses by eliminating/reducing some of the most common opportunities for making a mistake. It strikes me that this is a pragmatic and useful risk reduction strategy in handling weak copyleft code within ALv2 projects that helps protect both maintainers and users of the Apache product. Apache should probably provide that source separately as a matter of policy for handling category B licensed components rather than just point upstream to a source that could disappear a few years down the road. There’s a bit of orphaned java code out there where the original projects and their repos have disappeared. Maybe Apache does but it’s not explicitly written in the FAQ to do anything but include the URL to the product’s homepage where presumably the source is available. Maybe I read that part wrong or there is a more exhaustive checklist somewhere else of what the Apache project needs to do when using Category B components. Regards, Nigel From: License-discuss license-discuss-boun...@opensource.orgmailto:license-discuss-boun...@opensource.org on behalf of Lawrence Rosen lro...@rosenlaw.commailto:lro...@rosenlaw.com Reply-To: Lawrence Rosen lro...@rosenlaw.commailto:lro...@rosenlaw.com, License Discuss license-discuss@opensource.orgmailto:license-discuss@opensource.org Date: Monday, August 17, 2015 at 3:20 PM To: License Discuss license-discuss@opensource.orgmailto:license-discuss@opensource.org Subject: [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 Policyhttp://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
[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
