You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by Ate Douma <at...@douma.nu> on 2011/06/28 14:17:41 UTC
Rules for determining the required content of NOTICE and LICENSE
files
As a follow up and discussion point for the RAVE-63 issue, I'd like to summarize
my view on what the rules for NOTICE and LICENSE files within a Apache
distribution are.
Using these rules, it should become relatively easy to determine what the
*legally* required 3rd party attributions are and thereby what should be in the
NOTICE and LICENSE files, and what *not*.
The rules for the NOTICE and LICENSE file contents have been debated a lot
within Apache and IMO there still isn't a single location where they have been
described fully, in detail and/or extensively.
Furthermore, the requirements have become more strict over the last few years
but not all (or not even a lot) Apache projects are yet following all these
requirements. This makes it very confusing and difficult to compare against what
other projects as some are doing too little while others are doing too much.
For established (TLP) Apache projects the responsibility for validating and
ensuring the correct legal attributions are met falls under their own PMCs.
For Incubator projects, it is the IPMC who has the final responsibility on this,
but expects the PPMC to do the hard work and "learn" the Apache way and rules on
this matter. As such, we are (and should) be under much higher scrutiny and can
expect our release distributions to be painstakingly checked against the legal
"rules" concerning LICENSE and NOTICE files.
Again, what I describe below is just how I interpret the current state and
requirements. As I am not a lawyer (AINAL), please don't take my view on this as
"the" requirements, but as just a best shot at interpretation :)
Other mentors and those feeling experienced in this area: please chime in and
provide your feedback. Getting this stuff "right" should be(come) easy over
time, but for that we need to get the "rules" straight first.
As IMO this isn't properly or extensively documented enough yet elsewhere (to my
knowledge), my intend is to get this somewhere put into the public Apache
Incubator and/or legal documentation so other projects will not have to hunting
for this again (and again, and again, ...).
The primary documentation I've been looking at for this are:
[1]
http://incubator.apache.org/guides/releasemanagement.html#best-practice-license
[2] http://www.apache.org/legal/resolved.html
[3] http://wiki.apache.org/legal/3party/notice
[4] http://wiki.apache.org/legal/3party/notice/discuss
A very important rule which is critical for understanding the NOTICE and LICENSE
requirements comes from [2] Software License Criteria #2:
"The license must not place restrictions on the distribution of independent
works that simply use or contain the covered work."
Based on this rule, an ASF based distribution may not contain anything which
license would place a restriction on merely the use of such a 3rd party product.
My interpretation of this is: if we for example include a test-case (under our
own copyright) which only *uses* xmlunit, but do not distribute xmlunit itself,
there is no (legal) requirement to put a NOTICE or LICENSE for xmlunit in that
distribution.
Please note that this Software License Criteria #2 (and #3 even more) *prohibit*
using Copy-Left based licenses like (L)GPL as those *would* require us to obey
to their requirements, even if we don't distribute the 3rd party product itself.
Another important "rule" is that the LICENSE and NOTICE files serve *only* a
legal purpose. Which means they *must* cover what is required, but not more.
Otherwise said: we should keep the content of these files to the minimum.
Adding unneeded notices and/or licenses therefore is "bad practice".
The result of this is that every distribution might require different content
for their N&L files.
What is a (release) distribution:
a) the (ASF obligatory) release source archive
b) the ASF svn repository (for the release, e.g. the release tag root folder)
c) all other downloadable/hosted release "artifacts" like:
- each published individual Maven artifact (Maven Central)
- binary distributions provided from the project dist area
Note that the svn repository itself also should be regarded as a "distribution"
(see [4]), which makes it required to have appropriate N&L files in the root
folder (of a release tag).
The a) and b) distributions mostly can be regarded as equal, although under some
conditions b) might contain some additional "sources" which are only used for
producing a), but not included in a). In that case b) can have higher
requirements for the svn repository N&L not needed for the source distribution
itself.
The N&L requirements for a a/b distribution are often very minimal as they only
cover the sources themselves. Only when 3rd party copyright/license covered
sources are included (checked in) then those need separate N&L attribution on
a/b level.
The N&L requirements for a c) type distributions however usually need to cover
much more as often 3rd party artifacts are packaged together during the build of
such distribution.
Any other "usage" or dependency not packaged within the distribution but which
are required (or optionally needed) at runtime can (should) be mentioned in the
accompanying README within the distribution, but there is no *legal* obligation
for this, as long as we stick to external usages which fall within the license
criteria as specified in [2]. The README is intended to support the end-users
(only). An example of this could be mentioning that the rave-portal uses
(depends on) jquery at runtime. As we currently don't package jquery ourselves
but let it be dynamically resolved by the browser at runtime, we have no legal
obligation to attribute jquery in the N&L files, but it might be appropriate to
mention it in the README for the end-users.
Finally, the ASF itself has the specific requirement to include (append) *all*
covered 3rd party licenses within the LICENSE file. While a 3rd party product
might only require attribution and possible linking to a online license URL, we
nonetheless should copy and merge that license within our ASF provided LICENSE file.
Concerning the current state of our N&L files: I think we still need to append a
few more 3rd party licenses to our war/dist packaged LICENSE files.
Furthermore, the NOTICE attribution for JUnit probably shouldn't needed and I'm
not sure but likely neither for JSMin and OpenAjax (yet).
And I noticed a license attribution for the "OpenSocial Javascript API" in the
main Shindig LICENSE file ([5]) which maybe we should include as well.
[5]
http://svn.apache.org/repos/asf/shindig/tags/shindig-project-3.0.0-beta2/LICENSE
Regrettably I don't have time left right now to actually fix the above remaining
tasks (if everyone agrees with the above that is), so I have to un-assign myself
from RAVE-63 for now.
I expect not to be able to pick it up again before end of tomorrow, so if anyone
else feels to jump in, please do :)
Ate
Re: Rules for determining the required content of NOTICE and LICENSE
files
Posted by Marlon Pierce <mp...@cs.indiana.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
+1
>
> I will do it, but would like to suggest a new "rule" for Rave developers:
>
> "If you add a new runtime dependency to the POM while working on Rave,
> it is your responsibility to update the LICENSE and NOTICE files
> appropriately"
>
> These tasks, while not fun (unless you are a lawyer), are necessary. As
> good citizens of the Rave community, taking the responsibility to update
> the LICENSE & NOTICE files as we go saves a bunch of effort and time as we
> approach release.
>
>>
>> Ate
>>
>>
>>
>>
>>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOCc0mAAoJEEfVXEODPFIDdKkH/32ygCTUUuvQEXA6ainc94Gn
clbQuUbfPcWBCtnk+7vS7nWIcyUjN1vM5Fvvsom3tWYSODVRae9xUCkxiI/kGsnl
nubGHYkb5WP9+zjivSeDGeBtm0HOwW3Zw10qqy6HMLXNJsSKRxxvBq+HJ4+gg15C
2h5w2X3XMpAtHMJIJxDGEFZyorOsTmVuikGUam5f+MglKPvmP63C80APeeZg6qL3
jOJeLBw6qHm/mmN5JztaygN+/Mb021XsmzWM4qVsHrH1mhK8QZr5igDp2/fKr1Lk
1G0c7pe2gImesnN2Mrks6nG/pZqeQhWVe3trFNafmSslDQuL6Rj/4ZavXQew9EM=
=dpVV
-----END PGP SIGNATURE-----
Re: Rules for determining the required content of NOTICE and
LICENSE files
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
On 6/28/11 8:17 AM, "Ate Douma" <at...@douma.nu> wrote:
>As a follow up and discussion point for the RAVE-63 issue, I'd like to
>summarize
>my view on what the rules for NOTICE and LICENSE files within a Apache
>distribution are.
>
>Using these rules, it should become relatively easy to determine what the
>*legally* required 3rd party attributions are and thereby what should be
>in the
>NOTICE and LICENSE files, and what *not*.
>
>The rules for the NOTICE and LICENSE file contents have been debated a
>lot
>within Apache and IMO there still isn't a single location where they have
>been
>described fully, in detail and/or extensively.
>Furthermore, the requirements have become more strict over the last few
>years
>but not all (or not even a lot) Apache projects are yet following all
>these
>requirements. This makes it very confusing and difficult to compare
>against what
>other projects as some are doing too little while others are doing too
>much.
>
>For established (TLP) Apache projects the responsibility for validating
>and
>ensuring the correct legal attributions are met falls under their own
>PMCs.
>
>For Incubator projects, it is the IPMC who has the final responsibility
>on this,
>but expects the PPMC to do the hard work and "learn" the Apache way and
>rules on
>this matter. As such, we are (and should) be under much higher scrutiny
>and can
>expect our release distributions to be painstakingly checked against the
>legal
>"rules" concerning LICENSE and NOTICE files.
>
>Again, what I describe below is just how I interpret the current state
>and
>requirements. As I am not a lawyer (AINAL), please don't take my view on
>this as
>"the" requirements, but as just a best shot at interpretation :)
>
>Other mentors and those feeling experienced in this area: please chime in
>and
>provide your feedback. Getting this stuff "right" should be(come) easy
>over
>time, but for that we need to get the "rules" straight first.
>As IMO this isn't properly or extensively documented enough yet elsewhere
>(to my
>knowledge), my intend is to get this somewhere put into the public Apache
>Incubator and/or legal documentation so other projects will not have to
>hunting
>for this again (and again, and again, ...).
>
>The primary documentation I've been looking at for this are:
> [1]
>http://incubator.apache.org/guides/releasemanagement.html#best-practice-li
>cense
> [2] http://www.apache.org/legal/resolved.html
> [3] http://wiki.apache.org/legal/3party/notice
> [4] http://wiki.apache.org/legal/3party/notice/discuss
>
>A very important rule which is critical for understanding the NOTICE and
>LICENSE
>requirements comes from [2] Software License Criteria #2:
>"The license must not place restrictions on the distribution of
>independent
>works that simply use or contain the covered work."
>
>Based on this rule, an ASF based distribution may not contain anything
>which
>license would place a restriction on merely the use of such a 3rd party
>product.
>My interpretation of this is: if we for example include a test-case
>(under our
>own copyright) which only *uses* xmlunit, but do not distribute xmlunit
>itself,
>there is no (legal) requirement to put a NOTICE or LICENSE for xmlunit in
>that
>distribution.
>Please note that this Software License Criteria #2 (and #3 even more)
>*prohibit*
>using Copy-Left based licenses like (L)GPL as those *would* require us to
>obey
>to their requirements, even if we don't distribute the 3rd party product
>itself.
>
>Another important "rule" is that the LICENSE and NOTICE files serve
>*only* a
>legal purpose. Which means they *must* cover what is required, but not
>more.
>Otherwise said: we should keep the content of these files to the minimum.
>Adding unneeded notices and/or licenses therefore is "bad practice".
>The result of this is that every distribution might require different
>content
>for their N&L files.
>
>What is a (release) distribution:
> a) the (ASF obligatory) release source archive
> b) the ASF svn repository (for the release, e.g. the release tag root
>folder)
> c) all other downloadable/hosted release "artifacts" like:
> - each published individual Maven artifact (Maven Central)
> - binary distributions provided from the project dist area
>
>Note that the svn repository itself also should be regarded as a
>"distribution"
>(see [4]), which makes it required to have appropriate N&L files in the
>root
>folder (of a release tag).
>
>The a) and b) distributions mostly can be regarded as equal, although
>under some
>conditions b) might contain some additional "sources" which are only used
>for
>producing a), but not included in a). In that case b) can have higher
>requirements for the svn repository N&L not needed for the source
>distribution
>itself.
>
>The N&L requirements for a a/b distribution are often very minimal as
>they only
>cover the sources themselves. Only when 3rd party copyright/license
>covered
>sources are included (checked in) then those need separate N&L
>attribution on
>a/b level.
>
>The N&L requirements for a c) type distributions however usually need to
>cover
>much more as often 3rd party artifacts are packaged together during the
>build of
>such distribution.
>
>Any other "usage" or dependency not packaged within the distribution but
>which
>are required (or optionally needed) at runtime can (should) be mentioned
>in the
>accompanying README within the distribution, but there is no *legal*
>obligation
>for this, as long as we stick to external usages which fall within the
>license
>criteria as specified in [2]. The README is intended to support the
>end-users
>(only). An example of this could be mentioning that the rave-portal uses
>(depends on) jquery at runtime. As we currently don't package jquery
>ourselves
>but let it be dynamically resolved by the browser at runtime, we have no
>legal
>obligation to attribute jquery in the N&L files, but it might be
>appropriate to
>mention it in the README for the end-users.
+1 to all above.
>
>Finally, the ASF itself has the specific requirement to include (append)
>*all*
>covered 3rd party licenses within the LICENSE file. While a 3rd party
>product
>might only require attribution and possible linking to a online license
>URL, we
>nonetheless should copy and merge that license within our ASF provided
>LICENSE file.
I will add the additional ones. Since I linked to the online ones in the
NOTICE file, I figured we didn't need to distribute them, but I can change
that.
>
>Concerning the current state of our N&L files: I think we still need to
>append a
>few more 3rd party licenses to our war/dist packaged LICENSE files.
>Furthermore, the NOTICE attribution for JUnit probably shouldn't needed
>and I'm
>not sure but likely neither for JSMin and OpenAjax (yet).
I think OpenAjax is bundled in Shindig's WAR. I will remove JSMin and
Junit. I agree that they shouldn't be there (just copied from Shindig's
NOTICE).
>And I noticed a license attribution for the "OpenSocial Javascript API"
>in the
>main Shindig LICENSE file ([5]) which maybe we should include as well.
I thought I added OpenSocial APIs to the NOTICE....
>
> [5]
>http://svn.apache.org/repos/asf/shindig/tags/shindig-project-3.0.0-beta2/L
>ICENSE
>
>
>Regrettably I don't have time left right now to actually fix the above
>remaining
>tasks (if everyone agrees with the above that is), so I have to un-assign
>myself
>from RAVE-63 for now.
>I expect not to be able to pick it up again before end of tomorrow, so if
>anyone
>else feels to jump in, please do :)
I will do it, but would like to suggest a new "rule" for Rave developers:
"If you add a new runtime dependency to the POM while working on Rave,
it is your responsibility to update the LICENSE and NOTICE files
appropriately"
These tasks, while not fun (unless you are a lawyer), are necessary. As
good citizens of the Rave community, taking the responsibility to update
the LICENSE & NOTICE files as we go saves a bunch of effort and time as we
approach release.
>
>Ate
>
>
>
>
>