And an update nightmare. Which begs the question, is the N/L text should need to be changed, would they all have to be updated and another release triggered, or just at the next release cycle?
-Chris On Mon, Sep 16, 2013 at 8:46 PM, Stephen Connolly < [email protected]> wrote: > Let's see what legal concludes... my postulate is that people advocating > for the files in SCM have not fully considered what that implies and that > the "PMC must vote on releases so that legal indemnity of committers is in > place" will remove the suggested requirement to keep NOTICE and LICENSE > files (which are potentially out of date - and allowed to be so by people > advocating their presence in SCM - see the use of the phrase "best effort") > from the table... but if it falls the other way, so be it... we'll just > have several hundred of these files scattered all over the place! > > > On 16 September 2013 11:25, Chris Graham <[email protected]> wrote: > > > My take: Given we vote on a source bundle, and that includes the required > > files, I think we're good. > > > > If it is ruled that this is not the case, do we have to change on what > and > > how we vote (we I think you've covered)? > > > > -Chris > > > > Sent from my iPhone > > > > On 16/09/2013, at 7:50 PM, Stephen Connolly < > > [email protected]> wrote: > > > > > In an effort to get to a definitive answer for > > > > > > http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201309.mbox/%3CCA%2BnPnMwUvmaoOuBJ7dpVj9qAmwVnbfcxTid7UZgc6EdEL7%2BOpg%40mail.gmail.com%3EI > > > did some searching... > > > > > > The ASF Licensing How To includes this helpful simple snippet: > > > > > > http://www.apache.org/dev/licensing-howto.html#source-tree-location > > > > > > # Location Within the Source Tree > > >> > > > > > > > > > LICENSE and NOTICE belong at the [top level of the source tree][1]. > They > > >> may be named LICENSE.txt and NOTICE.txt, but the bare names are > > preferred. > > > > > > > > >> [1]: http://www.apache.org/legal/src-headers.html#notice > > > > > > > > > If we wander over to that link: > > > > > > http://www.apache.org/legal/src-headers.html#notice > > > > > > # NOTICE file > > >> > > > > > > > > > 0. Every Apache distribution should include a NOTICE file in the top > > >> directory, along with the standard LICENSE file. > > >> 1. The top of each NOTICE file should include the following text, > > suitably > > >> modified to reflect the product name and year(s) of distribution of > the > > >> current and past versions of the product: > > >> Apache [PRODUCT_NAME] > > >> Copyright [yyyy] The Apache Software Foundation > > >> This product includes software developed at > > >> The Apache Software Foundation (http://www.apache.org/). > > >> 2. The remainder of the NOTICE file is to be used for required > > third-party > > >> notices. > > >> 3. The NOTICE file may also include copyright notices moved from > source > > >> files submitted to the ASF. > > >> 4. See also Modifications to NOTICE > > > > > > > > > Now that is mostly OK.... but it does beg the following questions: > > > > > > 1. What exactly is "the top level of the source tree"? Is it the tree > in > > > SCM or is it the tree in the .zip or .tar.gz files that end up in the > > /dist > > > directory. The text I have seen would seep to imply that the phrase > > refers > > > to the top level of the source tree in an Apache distribution... which > > > brings us to.. > > > > > > 2. What exactly is "an Apache distribution"? To the best of my > knowledge > > > this is just the .zip or .tar.gz files that end up in the /dist > > directory. > > > I know that other people have opinions that things like SCM also are > > Apache > > > distributions, but it would seem to me that the two links I cited above > > > would be *very clear* in stating that SCM is viewed as a distribution > if > > it > > > was the official view of the ASF (and perhaps it is... in which case > > please > > > fix the website) > > > > > > By way of some concrete examples, and because real world examples are > > much > > > much better than abstract hypotheticals. > > > > > > Consider the Apache Maven project. We are a top level project with many > > > things that we release. We have Maven Core itself and we have many > > plugins > > > and other shared components that have their own release lifecycles... > we > > > also have some components in our Subversion repository and others in > GIT > > > repositories. > > > > > > Case 1 > > > ---------- > > > > > > For technical reasons, i.e. given the way GIT works, it is easiest to > put > > > any group of things that get released as an atomic unit into a single > GIT > > > repository. Thus we have Maven Core (with the 12 modules that are used > to > > > build Maven Core) at > > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=tree Now as it > > > happens the top level of that group of 12 modules is the root of that > GIT > > > repository and we have LICENSE and NOTICE files there. As part of our > > > release process we produce a source distribution of that tree and hence > > the > > > LICENSE and NOTICE files will be at the root of the > > > apache-maven-x.y.x-src.tar.gz and apache-maven-x.y.x-src.zip files that > > end > > > up in the /dist directory. So in this case it does not matter whether > an > > > Apache distribution is only the apache-maven-x.y.x-src.tar.gz files or > > also > > > includes the https://git-wip-us.apache.org/repos/asf?p=maven.git GIT > > > repository. In this case we have the files at the root of both source > > trees. > > > > > > Case 2 > > > ---------- > > > > > > Now let us consider a different set of atomically released modules. > > > Surefire consists of again 12 modules that all get released at the same > > > time. The source tree in SCM is > > > https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=tree as > > > again that is a separate source repository from our other stuff. Our > most > > > recent source release of Surefire is > > > > > > http://www.apache.org/dist/maven/surefire/surefire-2.16-source-release.zipand > > > if we look at that file > > > > > > $ unzip -l ~/Downloads/surefire-2.16-source-release.zip */LICENSE > > */NOTICE > > > Archive: /Users/stephenc/Downloads/surefire-2.16-source-release.zip > > > Length Date Time Name > > > -------- ---- ---- ---- > > > 108 08-11-13 16:57 > > > surefire-2.16/surefire-api/src/main/appended-resources/META-INF/NOTICE > > > 11358 08-11-13 16:57 surefire-2.16/LICENSE > > > 178 08-11-13 16:57 surefire-2.16/NOTICE > > > -------- ------- > > > 11644 3 files > > > > > > So in that Apache distribution we have the LICENSE and NOTICE files. > But > > > *if* SCM is also an Apache distribution, then there is an issue as the > > > corresponding tag > > > > > > https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=tree;hb=6ba4e42610237302a83e5246a61a974aa5a6d60ddoes > > > not have the LICENSE and NOTICE files. > > > > > > So there is a potential issue with Surefire *if* SCM is considered an > > > Apache distribution... but since this is a set of things in GIT the > > > resolution of the *potential* issue is trivial, we can just add the two > > > files and be done. > > > > > > The first two were intentionally picked to show the easy cases. > > > > > > Case 3 > > > ---------- > > > > > > The Maven Release plugin consists of two modules that get released at > the > > > same time. Source control is in Subversion: > > > http://svn.apache.org/repos/asf/maven/release/trunk/ > > > > > > The current source bundle is > > > > > > http://www.apache.org/dist/maven/release/maven-release-2.4.1-source-release.zip > > , > > > if we take a look at that file > > > > > > $ unzip -l ~/Downloads/maven-release-2.4.1-source-release.zip */LICENSE > > > */NOTICE > > > Archive: > > /Users/stephenc/Downloads/maven-release-2.4.1-source-release.zip > > > Length Date Time Name > > > -------- ---- ---- ---- > > > 11358 03-22-13 19:58 maven-release-2.4.1/LICENSE > > > 170 03-22-13 19:58 maven-release-2.4.1/NOTICE > > > -------- ------- > > > 11528 2 files > > > > > > So again in that Apache distribution we have the LICENSE and NOTICE > > > files... the tag: > > > > > > http://svn.apache.org/repos/asf/maven/release/tags/maven-release-2.4.1/does > > > not. Again *if* SCM is an Apache distribution then the solution is > > > trivial, we'd just add > > > http://svn.apache.org/repos/asf/maven/release/trunk/LICENSE and > > > http://svn.apache.org/repos/asf/maven/release/trunk/NOTICE and > > > presto-chango we are done. > > > > > > Case 4 > > > ---------- > > > > > > We have a lot of plugins and shared components that have their own > > release > > > cadence, for example there are currently 42 things that we release in > our > > > "plugins" category. The source tree is hosted in Subversion because we > > > don't want to have 42 GIT repositories, one for each plugin. Here is > the > > > root of the "plugins" category: > > > http://svn.apache.org/repos/asf/maven/plugins/trunk/ the attentive > among > > > you will notice the files > > > http://svn.apache.org/repos/asf/maven/plugins/trunk/NOTICE.txt and > > > http://svn.apache.org/repos/asf/maven/plugins/trunk/LICENSE.txt > > > > > > One plugin that we release is the Remote Resources plugin (picked > because > > > it has had a recent release) > > > > > > http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-remote-resources-plugin/with > > > the most recent release being > > > > > > http://www.apache.org/dist/maven/plugins/maven-remote-resources-plugin-1.5-source-release.zip > > > > > > $ unzip -l > > ~/Downloads/maven-remote-resources-plugin-1.5-source-release.zip > > > */LICENSE */NOTICE > > > Archive: > > > > > > /Users/stephenc/Downloads/maven-remote-resources-plugin-1.5-source-release.zip > > > Length Date Time Name > > > -------- ---- ---- ---- > > > 11358 08-14-13 08:25 maven-remote-resources-plugin-1.5/LICENSE > > > 193 08-14-13 08:25 maven-remote-resources-plugin-1.5/NOTICE > > > -------- ------- > > > 11551 2 files > > > > > > And the corresponding tag is > > > > > > http://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote-resources-plugin-1.5/(notice > > > that there is no NOTICE or LICENSE file in the > > > http://svn.apache.org/repos/asf/maven/plugins/tags/ directory) > > > > > > It would be a pain, and seem incredibly stupid to me that we would have > > to > > > add LICENSE and NOTICE files to the 100+ independent release roots that > > we > > > have between our plugins, site skins, shared components, etc... plus > the > > > top of our tree could technically be considered > > > http://svn.apache.org/repos/asf/maven/ or better yet > > > http://svn.apache.org/repos/asf/ could we call ourselves done with > some > > > http://svn.apache.org/repos/asf/maven/NOTICE and > > > http://svn.apache.org/repos/asf/maven/LICENSE file in place? > > > > > > My view > > > ------------ > > > > > > My understanding is that an Apache distribution has to be voted on by > the > > > PMC, otherwise it is not an Apache distribution. If anything in source > > > control is an Apache distribution then running a CTR SCM policy for an > > > Apache TLP would be impossible and RTC would require 3x+1 binding votes > > for > > > every commit rendering the "convenience" of a commit bit on a TLP > > anything > > > but. > > > > > > So then I make the argument that only one of the following two > postulates > > > are true: > > > > > > * There is no requirement for the PMC to vote on Apache distributions > and > > > we can just let committers throw out releases without having PMC vote > > > threads. > > > * Source control is not an Apache distribution and hence we do not need > > to > > > have LICENSE and NOTICE files in source control, it can be a nice > > > convenience, but there is no *requirement*. > > > > > > Can the foundation please resolve which of the above two statements is > > > actually true (or maybe someone could check in a > > > http://svn.apache.org/repos/asf/LICENSE and a > > > http://svn.apache.org/repos/asf/NOTICE so that all TLPs using > Subversion > > > would be absolved of having to worry about what they have in their > source > > > trees) > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
