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]
