maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: What is the top level of the source tree and what exactly is an Apache distribution?
Date Mon, 16 Sep 2013 10:48:22 GMT
On 16 September 2013 10:50, Stephen Connolly
<> wrote:
> In an effort to get to a definitive answer for
> did some searching...
> The ASF Licensing How To includes this helpful simple snippet:
> # 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]:
> If we wander over to that link:
> # 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 (
>> 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
>;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 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 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
>;a=tree as
> again that is a separate source repository from our other stuff. Our most
> recent source release of Surefire is
> if we look at that file
> $ unzip -l ~/Downloads/ */LICENSE */NOTICE
> Archive:  /Users/stephenc/Downloads/
>   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
> 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:
> The current source bundle is
> if we take a look at that file
> $ unzip -l ~/Downloads/ */LICENSE
> Archive:  /Users/stephenc/Downloads/
>   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:
> not. Again *if* SCM is an Apache distribution then the solution is
> trivial, we'd just add
> and
> 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:
> the attentive among
> you will notice the files
> and
> One plugin that we release is the Remote Resources plugin (picked because
> it has had a recent release)
> the most recent release being
> $ unzip -l ~/Downloads/
> Archive:
>  /Users/stephenc/Downloads/
>   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
> that there is no NOTICE or LICENSE file in the
> 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
> or better yet
> could we call ourselves done with some
> and
> 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
> and a
> 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:
For additional commands, e-mail:

View raw message