Le mardi 17 janvier 2017, 11:28:59 CET Robert Scholte a écrit : > http://www.apache.org/dev/licensing-howto.html#source-tree-location thanks for the pointer: it's useful
> 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. my point is that since our apache-source-release-assembly-descriptor provides default LICENSE and NOTICE files to source distribution package, adding LICENSE.txt or NOTICE.txt file in scm will just cause the source distribution package to contain both files, with and without .txt: it's a bug Then, given our release procedure with apache-source-release-assembly- descriptor, the only option we have in scm is LICENSE and NOTICE: any LICENSE.txt or NOTICE.txt is just a bug that should be fixed (and that we should have noticed when voting on previous releases) > > 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. the question is about scm source and source distribution: not about binary distribution (this question may happen later). Since in general we just need the default Apache LICENSE and NOTICE, as they are provided by apache-source-release-assembly-descriptor for the common case when they are not in scm, adding default files to scm is counter productive (and not required by any procedure I read) I'll do the release with no LICENSE nor NOTICE is scm, but default files in source districtuion package. Regards, Hervé > > 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%20AN > >> D > >> > >> > > % > >> > >> 20fixVersion%20%3D%20%22Maven%20Artifact%20Resolver%201.2.0%22%20ORDER%20 > >> B > >> > >> > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
