You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Stephen Connolly <st...@gmail.com> on 2013/09/16 11:50:12 UTC
What is the top level of the source tree and what exactly is an
Apache distribution?
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)
Re: What is the top level of the source tree and what exactly is an
Apache distribution?
Posted by Doug Cutting <cu...@apache.org>.
On Mon, Sep 16, 2013 at 2:50 AM, Stephen Connolly
<st...@gmail.com> wrote:
> * 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 think perhaps you're looking for clear lines where things are
actually a bit fuzzy. Certainly releases are official distributions
and need LICENSE and NOTICE files. That line is clear. On the other
hand, we try to discourage folks from thinking that source control is
a distribution. Rather we wish it to be considered our shared
workspace, containing works in progress, not yet always ready for
distribution to folks outside the foundation. But, since we work in
public, folks from outside the foundation can see our shared workspace
and might occasionally mistake it for an official distribution. We'd
like them to still see a LICENSE and NOTICE file. So it's not a
hard-and-fast requirement that every tree that can possibly be checked
out have a LICENSE and NOTICE file at its root, but it's a good
practice for those trees that are likely to be checked out have them,
so that folks who might consume them are well informed.
For example, when I want to determine the license of some project, I
often don't find and download a source release, but instead browse its
source code repository and read the license there. I appreciate that
it's almost always at the top-level and assume that this is consistent
with the license in its source releases. If I were a lawyer pursuing
a case I'd be wise to actually check the source of a specific release,
but my inquiries are often of a more casual nature.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What is the top level of the source tree and what exactly is an Apache distribution?
Posted by Kevan Miller <ke...@gmail.com>.
Hi Stephen,
I'll start by giving my opinions to your "view". Let's see how close we are… Can broaden discussion to the rest of your note as needed.
On Sep 16, 2013, at 2:50 AM, Stephen Connolly <st...@gmail.com> wrote:
>
> 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.
Apache *releases* must be voted on by the PMC. Releases are the ASF's mechanism for distributing our products for general users.
However, releases are not the only *distributions* of our software. Our source code control systems also distribute our products. We can't openly develop our software without also distributing it while under development. Typically, these distributions are used by the Apache committers and contributors. Not that it necessarily matters for this discussion… But I'll note that there's nothing that prevents general users from consuming these source code distributions, also. Especially when a *distribution* exactly/closely matches a projects *release* (i.e. a tag).
>
> 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.
Yes. There is no requirement for projects to vote on these development *distributions*. But projects must vote on their *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*.
No. That is not 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)
:)
So, then there is the question of what exactly constitutes a distribution? There are many ways of organizing a project's directory structure. A common format used by many of our java projects is:
foo/trunk/
foo/branches/1.0/
foo/branches/1.1/
foo/tags/1.0
In my opinion, each of these are a "distribution". We may tell someone to checkout https://svn.apache.org/repos/asf/foo/trunk. Or that problem has been fixed in https://svn.apache.org/repos/asf/foo/branches/1.0/
Those are examples. I'm using svn. Projects may have their own preferences for organizing their software and mechanisms for handling releases. So, I don't think one size fits all.
We can discuss Maven's directory structure and release mechanisms. I know you gave examples in your email(s). But right now I'm hoping to give insomnia the rest of the night off...
--kevan
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: What is the top level of the source tree and what exactly is an
Apache distribution?
Posted by Stephen Connolly <st...@gmail.com>.
On 16 September 2013 10:50, Stephen Connolly <
stephen.alan.connolly@gmail.com> 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.
>
This statement is assuming that Source control is viewed an Apache
distribution.
We don't vote on commits to Source control (other than the PMC's veto
right, but still the commits are not subject to a 72hr window before
becoming official and the hash/revision is always there anyway).
Thus if source control is "an Apache distribution" I argue that at least
some Apache distributions do not need to be voted on (given more than 1.5
million revisions in Subversion, one could argue the vast majority of such
distributions are not voted on) thus the "Apache distribution"s that end up
in /dist don't need to be voted on by the PMC...
> * 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*.
>
The counter argument is that "an Apache distribution" has to have had a
successful vote of 3 binding +1 votes (or whatever the respective PMC
decides) certainly http://www.apache.org/dev/release.html seems to suggest
that a release is not a release until it has been voted on by the PMC and
copied to the distribution directory. Source control is "just a
convenience".
>
> 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)
>
>
There is, to me, a very clear disconnect. I have tried to frame it in terms
of two potential strawman arguments. The whole thing is less than obvious
to me, and as a PMC Chair who is legally responsible for the releases of
the TLP that I am char of, I am uncomfortable with the lack of clarity.
Related issues that I can find:
https://issues.apache.org/jira/browse/LEGAL-136
https://issues.apache.org/jira/browse/LEGAL-27
https://issues.apache.org/jira/browse/LEGAL-26
Re: What is the top level of the source tree and what exactly is an
Apache distribution?
Posted by Stephen Connolly <st...@gmail.com>.
On 16 September 2013 10:50, Stephen Connolly <
stephen.alan.connolly@gmail.com> 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.
>
This statement is assuming that Source control is viewed an Apache
distribution.
We don't vote on commits to Source control (other than the PMC's veto
right, but still the commits are not subject to a 72hr window before
becoming official and the hash/revision is always there anyway).
Thus if source control is "an Apache distribution" I argue that at least
some Apache distributions do not need to be voted on (given more than 1.5
million revisions in Subversion, one could argue the vast majority of such
distributions are not voted on) thus the "Apache distribution"s that end up
in /dist don't need to be voted on by the PMC...
> * 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*.
>
The counter argument is that "an Apache distribution" has to have had a
successful vote of 3 binding +1 votes (or whatever the respective PMC
decides) certainly http://www.apache.org/dev/release.html seems to suggest
that a release is not a release until it has been voted on by the PMC and
copied to the distribution directory. Source control is "just a
convenience".
>
> 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)
>
>
There is, to me, a very clear disconnect. I have tried to frame it in terms
of two potential strawman arguments. The whole thing is less than obvious
to me, and as a PMC Chair who is legally responsible for the releases of
the TLP that I am char of, I am uncomfortable with the lack of clarity.
Related issues that I can find:
https://issues.apache.org/jira/browse/LEGAL-136
https://issues.apache.org/jira/browse/LEGAL-27
https://issues.apache.org/jira/browse/LEGAL-26
Re: What is the top level of the source tree and what exactly is an
Apache distribution?
Posted by Doug Cutting <cu...@apache.org>.
On Mon, Sep 16, 2013 at 2:50 AM, Stephen Connolly
<st...@gmail.com> wrote:
> * 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 think perhaps you're looking for clear lines where things are
actually a bit fuzzy. Certainly releases are official distributions
and need LICENSE and NOTICE files. That line is clear. On the other
hand, we try to discourage folks from thinking that source control is
a distribution. Rather we wish it to be considered our shared
workspace, containing works in progress, not yet always ready for
distribution to folks outside the foundation. But, since we work in
public, folks from outside the foundation can see our shared workspace
and might occasionally mistake it for an official distribution. We'd
like them to still see a LICENSE and NOTICE file. So it's not a
hard-and-fast requirement that every tree that can possibly be checked
out have a LICENSE and NOTICE file at its root, but it's a good
practice for those trees that are likely to be checked out have them,
so that folks who might consume them are well informed.
For example, when I want to determine the license of some project, I
often don't find and download a source release, but instead browse its
source code repository and read the license there. I appreciate that
it's almost always at the top-level and assume that this is consistent
with the license in its source releases. If I were a lawyer pursuing
a case I'd be wise to actually check the source of a specific release,
but my inquiries are often of a more casual nature.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: What is the top level of the source tree and what exactly is an
Apache distribution?
Posted by Stephen Connolly <st...@gmail.com>.
On 16 September 2013 13:31, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
>
>
>
> On 16 September 2013 13:20, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>>
>>
>>
>> On 16 September 2013 11:48, sebb <se...@gmail.com> wrote:
>>
>>> On 16 September 2013 10:50, Stephen Connolly
>>> <st...@gmail.com> 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.
>>
>>
>>>
[snip]
> > 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.
>>
>
> I wanted to look at the HTML source of ASF legal's distribution of its
> legal guide for committers...
>
> http://www.apache.org/NOTICE
> http://www.apache.org/NOTICE.txt
> http://www.apache.org/legal/NOTICE
> http://www.apache.org/legal/NOTICE.txt
>
> The above are all 404's
>
> http://www.apache.org/legal/src-headers.html
>
> says
>
> <!-- Licensed to the Apache Software Foundation (ASF) under one or more
> contributor license agreements. See the NOTICE file distributed with this
> work for additional information regarding copyright ownership. The ASF
> licenses this file to you under the Apache License, Version 2.0 (the
> "License"); you may not use this file except in compliance with
> the License. You may obtain a copy of the License at .
> http://www.apache.org/licenses/LICENSE-2.0 . Unless required by
> applicable law or agreed to in writing, software distributed under the
> License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR
> CONDITIONS OF ANY KIND, either express or implied. See the License for the
> specific language governing permissions and limitations under the License.
> -->
>
> I cannot find the NOTICE file distributed with the
> http://www.apache.org/legal/src-headers.html file, where is the NOTICE
> file for the distribution?
>
> http://svn.apache.org/repos/asf/infrastructure/site/trunk/
> Nope, no NOTICE there
> http://svn.apache.org/repos/asf/infrastructure/site/trunk/content/
> Nope, none there either
> http://svn.apache.org/repos/asf/infrastructure/site/trunk/content/legal/
> Again none there
>
> HTML is source, the content itself has the standard license header... if
> #2 is true then WHERE IS THE NOTICE in the SCM distribution?
>
> If #2 is actually legal's position, then they need to lead by example.
>
I wanted to generate some HTML for the Apache Maven site to assist our
committers in understanding what they had to do with respect of source
headers and other legal issues. I saw on the Apache website that the legal
team have written a program in the Markdown language that drives a HTML
generator engine to create some similar content.
I decided it would be a good idea to check out your program rather than try
and invent the wheel.
I expected that if I checked out your distribution from
https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/legal/that
it would contain all the required information.
The file
http://svn.apache.org/repos/asf/infrastructure/site/trunk/content/legal/index.mdtextcontains
a header stating that I needed to consult the NOTICE file
distributed with this work in order to get the information regarding
copyright owners of the work.
I am now in a bind as I cannot find such a file in the distribution at
http://svn.apache.org/repos/asf/infrastructure/site/trunk/content/legal/
I tried other collective works which contained your work, such as
http://svn.apache.org/repos/asf/infrastructure/site/trunk/content/
http://svn.apache.org/repos/asf/infrastructure/site/trunk/
http://svn.apache.org/repos/asf/infrastructure/site/
http://svn.apache.org/repos/asf/infrastructure/
http://svn.apache.org/repos/asf/
but none of these contained the NOTICE file as one would expect at the
source root.
Further complicating the issue is that I now cannot contribute my work in
good faith to the Maven site distribution as I am unable to update our own
NOTICE file to reflect the fact that I have included the work that you are
distributing.
At this point I really do have to question whether the source control
repository where your source control happens to be stored, and happens to
have public access for the convenience of committers, is really an Apache
distribution.
Sincerely,
Stephen
>
>>
>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>
Re: What is the top level of the source tree and what exactly is an
Apache distribution?
Posted by Stephen Connolly <st...@gmail.com>.
On 16 September 2013 13:20, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
>
>
>
> On 16 September 2013 11:48, sebb <se...@gmail.com> wrote:
>
>> On 16 September 2013 10:50, Stephen Connolly
>> <st...@gmail.com> 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.org beside 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.
>
I wanted to look at the HTML source of ASF legal's distribution of its
legal guide for committers...
http://www.apache.org/NOTICE
http://www.apache.org/NOTICE.txt
http://www.apache.org/legal/NOTICE
http://www.apache.org/legal/NOTICE.txt
The above are all 404's
http://www.apache.org/legal/src-headers.html
says
<!-- Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with this
work for additional information regarding copyright ownership. The ASF
licenses this file to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at .
http://www.apache.org/licenses/LICENSE-2.0 . Unless required by applicable
law or agreed to in writing, software distributed under the License is
distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS
OF ANY KIND, either express or implied. See the License for the specific
language governing permissions and limitations under the License. -->
I cannot find the NOTICE file distributed with the
http://www.apache.org/legal/src-headers.html file, where is the NOTICE file
for the distribution?
http://svn.apache.org/repos/asf/infrastructure/site/trunk/
Nope, no NOTICE there
http://svn.apache.org/repos/asf/infrastructure/site/trunk/content/
Nope, none there either
http://svn.apache.org/repos/asf/infrastructure/site/trunk/content/legal/
Again none there
HTML is source, the content itself has the standard license header... if #2
is true then WHERE IS THE NOTICE in the SCM distribution?
If #2 is actually legal's position, then they need to lead by example.
>
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
Re: What is the top level of the source tree and what exactly is an
Apache distribution?
Posted by Stephen Connolly <st...@gmail.com>.
On 16 September 2013 11:48, sebb <se...@gmail.com> wrote:
> On 16 September 2013 10:50, Stephen Connolly
> <st...@gmail.com> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: What is the top level of the source tree and what exactly is an
Apache distribution?
Posted by sebb <se...@gmail.com>.
On 16 September 2013 10:50, Stephen Connolly
<st...@gmail.com> 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.
>> 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.
> 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)
Different components can have different N&L requirements (not all
source is necessarily AL licensed, and binary collections may contain
3rd party code).
> 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.
> 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.
> * 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What is the top level of the source tree and what exactly is an
Apache distribution?
Posted by Stephen Connolly <st...@gmail.com>.
On 16 September 2013 12:32, Chris Graham <ch...@gmail.com> wrote:
> 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?
>
Next release cycle, because they only need to be updated on a "best effort"
basis... though the PMC may have to force things along... very unclear
The other thing is that a top level NOTICE may not work given that the
NOTICE file is supposed to contain the thing's name... though again I
wonder if we could just call all our stuff "Apache Maven" and stick to a
LICENSE and NOTICE at our subversion root...
In any case, let's leave it to legal-discuss rather than postulate the
outcome here.
And for anyone complaining about LICENSE and NOTICE files not being in SCM
when we are cutting releases, my view is that this issue is parked for us
until such time as ASF legal actually rules on the question(s) asked.
>
> -Chris
>
>
> On Mon, Sep 16, 2013 at 8:46 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> 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 <ch...@gmail.com> 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 <
> > > stephen.alan.connolly@gmail.com> 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=treeas
> > > > 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: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
Re: What is the top level of the source tree and what exactly is an
Apache distribution?
Posted by Chris Graham <ch...@gmail.com>.
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 <
stephen.alan.connolly@gmail.com> 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 <ch...@gmail.com> 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 <
> > stephen.alan.connolly@gmail.com> 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: What is the top level of the source tree and what exactly is an
Apache distribution?
Posted by Stephen Connolly <st...@gmail.com>.
On 16 September 2013 11:46, Stephen Connolly <
stephen.alan.connolly@gmail.com> 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!
>
*and* in that case we'd have no more distinction between binding and
non-binding votes for our releases...
>
>
> On 16 September 2013 11:25, Chris Graham <ch...@gmail.com> 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 <
>> stephen.alan.connolly@gmail.com> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
Re: What is the top level of the source tree and what exactly is an
Apache distribution?
Posted by Stephen Connolly <st...@gmail.com>.
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 <ch...@gmail.com> 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 <
> stephen.alan.connolly@gmail.com> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: What is the top level of the source tree and what exactly is an Apache distribution?
Posted by Chris Graham <ch...@gmail.com>.
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 <st...@gmail.com> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org