On Fri, Mar 30, 2012 at 2:08 PM, sebb <[email protected]> wrote: > On 30 March 2012 17:38, Leo Simons <[email protected]> wrote: > > On Thu, Mar 29, 2012 at 8:42 PM, sebb <[email protected]> wrote: > >> On 29 March 2012 18:43, Roy T. Fielding <[email protected]> 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
