Re: Multi-licensed dependencies
On Fri, Mar 30, 2012 at 2:08 PM, sebb seb...@gmail.com wrote: On 30 March 2012 17:38, Leo Simons m...@leosimons.com wrote: On Thu, Mar 29, 2012 at 8:42 PM, sebb seb...@gmail.com wrote: On 29 March 2012 18:43, Roy T. Fielding field...@gbiv.com wrote: On Mar 29, 2012, at 6:17 PM, Marvin Humphrey wrote: Personally, I agree with Roy. Perhaps it might seem a little odd to include the text of e.g. the GPLv2 in one of our LICENSE files (alongside a more permissive license), but the key here is that it is both legally OK for us to distribute a product bundling such a dependency without explicitly justifying our usage, and legally OK for a downstream consumer to distribute a product bundling ours which asserts usage of the dependency under a different rationale. I prefer to put our license in the file and then, at the bottom, refer to a list of other licenses per dependency (if included in this package), wherein the dependency licenses are in separate files near the dependency. However, this does not agree with the following [1]: ... When an artifact contains code under several licenses, the LICENSE file should contain details of all these licenses. For each component which is not Apache licensed, details of the component and the license under which the component is distributed should be appended to the LICENSE file. [1] http://www.apache.org/dev/release.html#distributing-code-under-several-licenses ...the license file SHOULD contain ... I believe at least some of these how-to-put-the-license(s)-into-the-file(s) statements are not necessarily backed up by it must be this way legally or this is unambiguously always the best way kind of thoughts, but more by this is a good standard way to do it, that is easy to do and (automatically) verify. So Roy saying I prefer does not necessarily conflict with the SHOULD in the policy. I very much like the approach where the Incubator teaches the documented policies that have been defined by Legal. While it's probably good to have Roy's preferences (which I trust are good ones) reflected in our policy docs, that should happen via legal-discuss in this case, and even after that, we should not change what we teach our podlings This is precisely the issue - there is no single unified message at present. The approach depends a lot on who happens to be mentoring/reviewing releases. until the docs have changed. It gets way too confusing way too quickly, otherwise. It's already confusing. Nor do the documents have a single - or even consistent - approach. I think a lot of this stems from the fact that the documents tend to describe processes and procedures without providing the underlying rationale. +1 That is the key observation. We need more principles, agreed on and documented, than we need more policies and rules. For example, the core licensing criteria makes a simple but solid statement that has allowed us to adapt to the changing licensing landscape by applying these principles to new situations: http://www.apache.org/legal/resolved.html#criteria It would be great if we had similar compact statement on the intent of LICENSE and NOTICE. -Rob The statement from Roy about open source and the ASF incorporation was very useful in understanding the existing doumentation. I think the foundation assumptions need to be clearly documented so the derived processes and rules can be better understood. cheerio, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Multi-licensed dependencies
On Thu, Mar 29, 2012 at 8:42 PM, sebb seb...@gmail.com wrote: On 29 March 2012 18:43, Roy T. Fielding field...@gbiv.com wrote: On Mar 29, 2012, at 6:17 PM, Marvin Humphrey wrote: Personally, I agree with Roy. Perhaps it might seem a little odd to include the text of e.g. the GPLv2 in one of our LICENSE files (alongside a more permissive license), but the key here is that it is both legally OK for us to distribute a product bundling such a dependency without explicitly justifying our usage, and legally OK for a downstream consumer to distribute a product bundling ours which asserts usage of the dependency under a different rationale. I prefer to put our license in the file and then, at the bottom, refer to a list of other licenses per dependency (if included in this package), wherein the dependency licenses are in separate files near the dependency. However, this does not agree with the following [1]: ... When an artifact contains code under several licenses, the LICENSE file should contain details of all these licenses. For each component which is not Apache licensed, details of the component and the license under which the component is distributed should be appended to the LICENSE file. [1] http://www.apache.org/dev/release.html#distributing-code-under-several-licenses ...the license file SHOULD contain ... I believe at least some of these how-to-put-the-license(s)-into-the-file(s) statements are not necessarily backed up by it must be this way legally or this is unambiguously always the best way kind of thoughts, but more by this is a good standard way to do it, that is easy to do and (automatically) verify. So Roy saying I prefer does not necessarily conflict with the SHOULD in the policy. I very much like the approach where the Incubator teaches the documented policies that have been defined by Legal. While it's probably good to have Roy's preferences (which I trust are good ones) reflected in our policy docs, that should happen via legal-discuss in this case, and even after that, we should not change what we teach our podlings until the docs have changed. It gets way too confusing way too quickly, otherwise. cheerio, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Multi-licensed dependencies
On 30 March 2012 17:38, Leo Simons m...@leosimons.com wrote: On Thu, Mar 29, 2012 at 8:42 PM, sebb seb...@gmail.com wrote: On 29 March 2012 18:43, Roy T. Fielding field...@gbiv.com wrote: On Mar 29, 2012, at 6:17 PM, Marvin Humphrey wrote: Personally, I agree with Roy. Perhaps it might seem a little odd to include the text of e.g. the GPLv2 in one of our LICENSE files (alongside a more permissive license), but the key here is that it is both legally OK for us to distribute a product bundling such a dependency without explicitly justifying our usage, and legally OK for a downstream consumer to distribute a product bundling ours which asserts usage of the dependency under a different rationale. I prefer to put our license in the file and then, at the bottom, refer to a list of other licenses per dependency (if included in this package), wherein the dependency licenses are in separate files near the dependency. However, this does not agree with the following [1]: ... When an artifact contains code under several licenses, the LICENSE file should contain details of all these licenses. For each component which is not Apache licensed, details of the component and the license under which the component is distributed should be appended to the LICENSE file. [1] http://www.apache.org/dev/release.html#distributing-code-under-several-licenses ...the license file SHOULD contain ... I believe at least some of these how-to-put-the-license(s)-into-the-file(s) statements are not necessarily backed up by it must be this way legally or this is unambiguously always the best way kind of thoughts, but more by this is a good standard way to do it, that is easy to do and (automatically) verify. So Roy saying I prefer does not necessarily conflict with the SHOULD in the policy. I very much like the approach where the Incubator teaches the documented policies that have been defined by Legal. While it's probably good to have Roy's preferences (which I trust are good ones) reflected in our policy docs, that should happen via legal-discuss in this case, and even after that, we should not change what we teach our podlings This is precisely the issue - there is no single unified message at present. The approach depends a lot on who happens to be mentoring/reviewing releases. until the docs have changed. It gets way too confusing way too quickly, otherwise. It's already confusing. Nor do the documents have a single - or even consistent - approach. I think a lot of this stems from the fact that the documents tend to describe processes and procedures without providing the underlying rationale. The statement from Roy about open source and the ASF incorporation was very useful in understanding the existing doumentation. I think the foundation assumptions need to be clearly documented so the derived processes and rules can be better understood. cheerio, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Multi-licensed dependencies
On Thu, Mar 29, 2012 at 7:07 AM, Fabian Christ christ.fab...@googlemail.com wrote: Am 26. März 2012 17:20 schrieb Roy T. Fielding field...@gbiv.com: On Mar 26, 2012, at 4:41 PM, Karl Wright wrote: On Mon, Mar 26, 2012 at 10:24 AM, sebb seb...@gmail.com wrote: On 26 March 2012 02:38, Shinichiro Abe shinichiro.ab...@gmail.com wrote: The LICENSE file includes references to lots of jars that are dual licensed under CDDL v1.0 and GPL v2. However, there is no indication which license has been chosen by the project. I think this is a blocker. A project does not choose a license. The license is provided by the copyright owner. We do not change that license, nor do we reduce the number of the available licenses to choose from, for downstream recipients. Therefore, it doesn't make any sense to indicate which one is chosen. I am following all these discussions for doing a first release of Apache Stanbol (incubating) but get totally confused. According to http://apache.org/legal/resolved.html#mutually-exclusive you have to choose the license and include only the license that you have chosen. Hi, Fabian, With Roy objecting to the practice codified in that documentation, it seems as though we no longer have consensus in either the Incubator PMC or the ASF at large as to what you ought to do. For the time being, I suggest you do either one. :) If an Incubator PMC member feels strongly enough about this issue -- either way -- and believes that it should block all future affected releases, please speak up on this thread. Otherwise, we should accept that in the absence of consensus, we can advise but should not vote -1 on a given release candidate until the matter is resolved. Personally, I agree with Roy. Perhaps it might seem a little odd to include the text of e.g. the GPLv2 in one of our LICENSE files (alongside a more permissive license), but the key here is that it is both legally OK for us to distribute a product bundling such a dependency without explicitly justifying our usage, and legally OK for a downstream consumer to distribute a product bundling ours which asserts usage of the dependency under a different rationale. Regarding the current documented recommendation, though, I don't think it is actively harmful, because I don't believe we are doing anything which violates the terms under which multi-licensed products are typically made available. Therefore, in my opinion we can put this controversy in a queue for legal-discuss@a.o, to be dealt with after the more pressing matter of bundled jar files. :) Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Multi-licensed dependencies
On Mar 29, 2012, at 6:17 PM, Marvin Humphrey wrote: Personally, I agree with Roy. Perhaps it might seem a little odd to include the text of e.g. the GPLv2 in one of our LICENSE files (alongside a more permissive license), but the key here is that it is both legally OK for us to distribute a product bundling such a dependency without explicitly justifying our usage, and legally OK for a downstream consumer to distribute a product bundling ours which asserts usage of the dependency under a different rationale. I prefer to put our license in the file and then, at the bottom, refer to a list of other licenses per dependency (if included in this package), wherein the dependency licenses are in separate files near the dependency. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Multi-licensed dependencies
On 29 March 2012 18:43, Roy T. Fielding field...@gbiv.com wrote: On Mar 29, 2012, at 6:17 PM, Marvin Humphrey wrote: Personally, I agree with Roy. Perhaps it might seem a little odd to include the text of e.g. the GPLv2 in one of our LICENSE files (alongside a more permissive license), but the key here is that it is both legally OK for us to distribute a product bundling such a dependency without explicitly justifying our usage, and legally OK for a downstream consumer to distribute a product bundling ours which asserts usage of the dependency under a different rationale. I prefer to put our license in the file and then, at the bottom, refer to a list of other licenses per dependency (if included in this package), wherein the dependency licenses are in separate files near the dependency. However, this does not agree with the following [1]: ... When an artifact contains code under several licenses, the LICENSE file should contain details of all these licenses. For each component which is not Apache licensed, details of the component and the license under which the component is distributed should be appended to the LICENSE file. [1] http://www.apache.org/dev/release.html#distributing-code-under-several-licenses Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Multi-licensed dependencies
On Thu, Mar 29, 2012 at 11:42 AM, sebb seb...@gmail.com wrote: On 29 March 2012 18:43, Roy T. Fielding field...@gbiv.com wrote: I prefer to put our license in the file and then, at the bottom, refer to a list of other licenses per dependency (if included in this package), wherein the dependency licenses are in separate files near the dependency. However, this does not agree with the following [1]: ... When an artifact contains code under several licenses, the LICENSE file should contain details of all these licenses. For each component which is not Apache licensed, details of the component and the license under which the component is distributed should be appended to the LICENSE file. [1] http://www.apache.org/dev/release.html#distributing-code-under-several-licenses It is also at odds with the Apache HTTPD LICENSE file we've been treating as a canonical sample. The documentation on www.apache.org/dev may have been contaminated by well-meaning volunteers and changed from Roy's original meaning, but I assume that the HTTPD LICENSE and NOTICE files haven't gotten away from him and are still 100% consonant with both the letter and the intent of the ALv2. While Roy's suggestion of referencing licenses spread over multiple files seems like a perfectly sane alternative, I'd argue against documenting it as best practice unless HTTPD changes their LICENSE file to match. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
More on multi-licensed dependencies
On Thu, Mar 29, 2012 at 10:39 AM, Roy T. Fielding field...@gbiv.com wrote: On Mar 29, 2012, at 4:07 PM, Fabian Christ wrote: I am following all these discussions for doing a first release of Apache Stanbol (incubating) but get totally confused. According to http://apache.org/legal/resolved.html#mutually-exclusive you have to choose the license and include only the license that you have chosen. The answer in that document is wrong. I believe what they meant to say is that we only include one of the licenses in the text/pointers of our product-wide LICENSE file. Mainly for dual-licensed GPL. Wait, wait... If we only put the permissive license of a dual-licensed dependency into LICENSE, aren't we doing what you warned against earlier? A project does not choose a license. The license is provided by the copyright owner. We do not change that license, nor do we reduce the number of the available licenses to choose from, for downstream recipients. Therefore, it doesn't make any sense to indicate which one is chosen. This is what makes sense to me, as it is consistent with both our dev documentation and the HTTPD LICENSE file: * The ASF releases packages consisting primarily of IP licensed to the Foundation by contributors and available under the ALv2. * These packages may bundle dependencies under various licenses whose terms do not conflict with the ALv2. * The top-level LICENSE file communicates *all* licensing information for the complete, heterogenously-licensed package, including the licenses for all dependencies, no matter how deeply nested. With that definition for LICENSE in mind, and with the new admonition that we must not choose between the licenses of multi-licensed dependencies, here is some proposed sample text: Apache Foo bundles the CommonWidgets library in extras/common_widgets, which is available both under the MIT license and the GPLv2: [Full text of MIT license, including embedded copyright notice.] [Full text of GPLv2] Embedding complete license texts in LICENSE may be verbose, but that is how it is done right now. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Multi-licensed dependencies
On Mar 29, 2012, at 9:37 PM, Marvin Humphrey wrote: On Thu, Mar 29, 2012 at 11:42 AM, sebb seb...@gmail.com wrote: On 29 March 2012 18:43, Roy T. Fielding field...@gbiv.com wrote: I prefer to put our license in the file and then, at the bottom, refer to a list of other licenses per dependency (if included in this package), wherein the dependency licenses are in separate files near the dependency. However, this does not agree with the following [1]: ... When an artifact contains code under several licenses, the LICENSE file should contain details of all these licenses. For each component which is not Apache licensed, details of the component and the license under which the component is distributed should be appended to the LICENSE file. [1] http://www.apache.org/dev/release.html#distributing-code-under-several-licenses Pointers are sufficient. It is also at odds with the Apache HTTPD LICENSE file we've been treating as a canonical sample. The documentation on www.apache.org/dev may have been contaminated by well-meaning volunteers and changed from Roy's original meaning, but I assume that the HTTPD LICENSE and NOTICE files haven't gotten away from him and are still 100% consonant with both the letter and the intent of the ALv2. I know more about the letter and intent of the ASF's license and licensing policy than anyone else at the foundation. This was discussed and approved on the licensing list some time ago. While Roy's suggestion of referencing licenses spread over multiple files seems like a perfectly sane alternative, I'd argue against documenting it as best practice unless HTTPD changes their LICENSE file to match. httpd's license refers to small snippets of code all over the tree; all of the licenses are fairly close to BSD. It is simply more convenient to list all of those in one place. Inclusion of entire jar files is different. As is including huge and nasty license files, like the GPL. You do not want to mix all those licenses together, particularly since most of those licenses won't be included in your source distributions. Also, you cannot mix the GPL license in with the others. We are not shipping a combined work as GPL. We can ship an aggregated work, wherein the aggregation consists of separate components in separate directories with their own license files, or we can ship an overlayed work -- where the GPL distribution is unpacked on top of an Apache-licensed distribution. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
