http://www.apache.org/dev/licensing-howto.html#source-tree-location
bq.
LICENSE and NOTICE belong at the top level of the source tree. They may be named LICENSE.txt and NOTICE.txt, but the bare names are preferred.

http://www.apache.org/dev/licensing-howto.html#binary
bq.
What applies to canonical source distributions also applies to all redistributions, including binary redistributions:
Any redistribution must obey the licensing requirements of the contents.
The best way to do that will likely depend on the binary packaging form.
When assembling binary distributions, it is common to pull in and bundle additional dependencies which are not bundled with the source distribution. These additional dependencies must be accounted for in LICENSE and NOTICE. As a result, the LICENSE and NOTICE files for a binary distribution may well differ from those in the source distribution it was built from. In any case, the principle remains the same: LICENSE and NOTICE must exactly represent the contents of the distribution they reside in.

As I read it: we could put the LICENSE and NOTICE template files in every release root, override them during distribution.

Robert

On Tue, 17 Jan 2017 08:14:09 +0100, Stephen Connolly <[email protected]> wrote:

Yep

My personal opinion is that these files in scm is silly.

I didn't want to bias you before you had a chance to state your own opinion

W.r.t notice files for binaries.

Because the binary *includes* dependent jar files, whereas the source in
general does not, there will typically be different NOTICE files for each.

As we have relicensed resolver pure, it should be just: ALv2 for source.

It would get more complex if we actually had forked some code under a
license that requires a NOTICE.

But where all code in source is ALv2 and "clean" we probably don't even
need to Notice file in the scm from the notice file strict interpretation
legal heads

On Tue 17 Jan 2017 at 03:30, Hervé BOUTEMY <[email protected]> wrote:

Le lundi 16 janvier 2017, 08:10:58 CET Stephen Connolly a écrit :

> There is a divergence of opinion from legal.

>

> Some view even SCM as a distribution so we'd need the files at the root
of

> every git repo and in every SVN checkout "root"

>

> Others view this as madness and argue that we don't need these files in
SCM

> (except for *source* NOTICE files or binary NOTICE files where we use
those

> to generate the binary distribution)

I don't understand the exception



>

> I filed some LEGAL issues when I was chair to try and resolve the issue.

> Last time I checked there had been no resolution

ok, I see (even if I don't find precisely the JIRA issue)



then if we look at our current Maven practice: in our ~100 release roots,
we

don't have such files in general in scm but just in build process



and:

- there are a few LICENSE.txt or NOTICE.txt, which cause strange release

source distribution result: see maven-archetype for example

- generated NOTICE contains accurate date, where date in manually
maintained

NOTICE.txt in scm is not up to date

- I'm not clear on when to add more information in manual NOTICE than what
is

just generated (ie. This product includes software developed at The Apache

Software Foundation: when does a release contain more than software
developed

at ASF?)



I'm not in favour of adding these files one after the other.



I won't do it myself in Maven Artifact Resolver: staying with our current

general practice



Regards,



Hervé



>

> On Mon 16 Jan 2017 at 07:36, Hervé BOUTEMY <[email protected]>
wrote:

> > back to a discussion we had some time ago, and I'm not clear on the

> > definitive

> >

> > conclusion.

> >

> >

> >

> > Here is the question:

> >

> > since NOTICE and LICENSE files are automatically added to the source

> >

> > distribution archive (through
apache-source-release-assembly-descriptor),

> > do

> >

> > we need to manually maintain a copy of these files in scm?

> >

> >

> >

> > When I look at current scm content, for the vast majority of
components,

> > we

> >

> > didn't copy files and rely on
apache-source-release-assembly-descriptor.

> >

> >

> >

> > Personnally, I don't see the interest in copying files in scm.

> >

> >

> >

> > Regards,

> >

> >

> >

> > Hervé

> >

> > Le lundi 16 janvier 2017, 04:02:42 CET Christian Schulte a écrit :

> > > Am 01/15/17 um 20:34 schrieb Hervé BOUTEMY:

> > > > Hi,

> > > >

> > > >

> > > >

> > > > I reworked history, starting from 1.0.3-SNAPSHOT, and applying only

> > > >

> > > > renaming but absolutely no code change.

> >

> > > > Please review and confirm that this branch is ok to merge to
master:

> > then

> >

> > > > I'll launch the release process for Maven Artifact Resolver 1.0.3.

> > >

> > > <

> >

> >
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND

> > %

> >

> >

> >
20fixVersion%20%3D%20%22Maven%20Artifact%20Resolver%201.2.0%22%20ORDER%20B

> > Y%>

> > > 20key%20ASC%2C%20priority%20DESC>

> > >

> > >

> > >

> > > Maybe MRESOLVER-1 needs to be updated to 1.0.3?

> > >

> > >

> > >

> > > Regards,

> >

> > ---------------------------------------------------------------------

> >

> > To unsubscribe, e-mail: [email protected]

> >

> > For additional commands, e-mail: [email protected]

> >

> >

> >

> > --

>

> Sent from my phone







---------------------------------------------------------------------

To unsubscribe, e-mail: [email protected]

For additional commands, e-mail: [email protected]



--
Sent from my phone

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to