On 16 September 2013 11:48, sebb <[email protected]> wrote: > On 16 September 2013 10:50, 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. > > AIUI a distribution is not the same as a release. >
So we are agreed that the current site documentation is completely unclear. I can see both sides, the ASF does not pay me enough for me to make a decision one way or the other, however we need a decision. > > >> 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. > > AIUI a distribution is where the source is distributed to the general > public. > As such, that includes formal releases, as well as SCM. > http://www.apache.org/dev/release.html#where-do-releases-go # Where do releases go? > A release isn't 'released' until the contents are in the project's > distribution directory, which is a subdirectory of www.apache.org/dist/. > In addition to the distribution directory, project that use Maven or a > related build tool sometimes place their releases on > repository.apache.orgbeside some convenience binaries. The distribution > directory is required, > while the repository system is an optional convenience. What is "the project's distribution directory"? To me it sounds like the place where you find the Apache distributions of a project. I have seen it repeatedly stated in mailing lists that the "source repository is just a convenience" which sounds very like a policy of "source control is not an Apache distribution"... Never mind the questions like: * What is the status of https://github.com/apache/maven? I *know* that is not one of our distributions, not even on our hardware, but a lot of developers treat it as such... and we use pull requests submitted via the github tooling as a means to pick up patches (ok we may look for a JIRA issue so we can show intent to commit to Apache in order to meet with the CLA issues). The use of pull requests may actually hint at that stuff being a near-equivalent to git.apache.org. Now I for one am not advocating dropping the use of pull requests from github, they are a great collaboration tool and we will kill contributions if we ignore pull requests, hence I look for a JIRA before I consider merging a pull request in order to satisfy the "intent" part of a contribution. > > > 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) > > +1 to making website clearer. > > > 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? > > Remember that the N&L files must relate to the bits that are actually > contained in the collection, be it SCM or tarball or jar. > > The NOTICE file in particular is specific to a independent release as > it includes the component name. (e.g. Apache Maven Release Plugin) > It includes the [product name] which could simply be "Apache Maven". And previous comments along the line of "you need N&L in SCM" have all said best effort... well what if our effort in this regard is the best we can do but still crappy? Where is the iron fist that stops us and forces us to pull up our game. Either the content needs to be correct in SCM OR it doesn't need to be there for every folder and we can have a catch-all at the root. > > Different components can have different N&L requirements (not all > source is necessarily AL licensed, and binary collections may contain > 3rd party code). > For the binary releases we use tooling to ensure that the appropriate content is included in the NOTICE and LICENSE files as when we are bundling up the binary we can collect up the requirements of what is bundled. "utility" binary releases *cannot* be the NOTICE and LICENSE files from source for all but the most trivial of projects. > > > My view > > ------------ > > > > My understanding is that an Apache distribution has to be voted on by the > > PMC, otherwise it is not an Apache distribution. > > AIU, only a release has to be voted on. > > The contents of SCM are subject to ongoing vetting by the PMC to > ensure that only appropriately licensed files are committed. > [And if any problems are later found, the PMC must ensure the > offending files are dealt with appropriately] > > > 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. > > IMO, that does not follow. > Because you have already stated your opinion that not all Apache distributions are Apache releases. My view is that only Apache releases are Apache distributions. Not everything on ASF hardware is an Apache distribution... If I put some personal work up on people.apache.org... is that an Apache distribution? If we establish that being on a *.apache.org server does not a distribution make, then we establish the principle that the source control repository does not necessarily need to be considered an Apache distribution. This sounds like a more fundamental question that needs answering, as if I am right then the following is legitimate... If I am wrong people need to be very careful about what goes up on people.apache.org and there is a lot of red tape that we will be wrapping ourselves in... I would argue that the position counter to mine is one that has the very strong potential to effectively kill off the foundation. > > > 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. > > The above paragraph contains two assertions, only the first of which > is true IMO. > Based on your opinion that not all distributions are releases > > > * 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*. > > I don't believe that is true. > > Taken as a whole, I don't believe either of your postulates are true. > > > 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) > > +1 to resolving the ambiguity. > exactly... I think most pertinent question is now "What is an Apache distribution?" I see two potential answers: 1. Only a voted on release that ends up in the project's /dist directory is an Apache distribution 2. Any source code on any ASF hardware is an Apache distribution I personally reject #2 by using reductio ad absurdum whereby I conclude that each and every directory in Subversion source control is a potential expected checkout point, and hence we should put N&L files in *every* directory in Subversion (because hey! I may just want the one utility method in some sub-module)... perhaps infra could give us a post-commit hook or a pre-commit hook to assist. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
