james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "robert burrell donkin" <robertburrelldon...@gmail.com>
Subject Re: NOTICE/LICENSE, apache- prefix and other ASF best practices (Re: [mime4j] release plan for 0.3) [LONG]
Date Tue, 15 May 2007 18:30:41 GMT
On 5/15/07, Stefano Bagnara <apache@bago.org> wrote:
> if you have 10 minutes to waste feel free to read all, otherwise search
> for "<core>" ;-)
> robert burrell donkin ha scritto:
> > On 5/13/07, Stefano Bagnara <apache@bago.org> wrote:
> >> robert burrell donkin ha scritto:
> >> > not sure how critical it really is. apache tends to be loathed to take
> >> > legal action. IIRC this arose around 5 years ago but i can't remember
> >> > why. it can't have been that important or it would have been more
> >> > widely known.
> >> >
> >> > but it is good practice and worth adopting
> >>
> >> Maven is all about spreading good practice and sharing a standard way to
> >> do releases. So such a policy should be transmitted to the maven guys
> >> first of all.
> >
> > there has historically been a conflict between maven implementing
> > general best practices, and apache specific policy and practice
> I know, but the best solution is when we can do stuff in the parent pom
> for apache projects!
> In the mail I sent yesterday to the repository@apache list I suggested
> (as an example) the use of a plugin that put a big warning when the
> artifact does not start with "apache-". This plugin should be added to
> the parent pom for apache (not the m2 super pom) and every ASF project
> should be suggested to use that parent pom.

AIUI a release checking plugin is already under development

> >> If ASF committers could read somewhere "it is suggested by
> >> ASF policies to include "apache-" as a prefix of every artifactId I
> >> guess we would have much more "policy compliant" packages.
> >
> > AFAIK this isn't policy - just advice about best practice
> <provoking>"best practices" should be used by someone at least :-)

at one time, nearly all jakarta releases had jakarta in the title.
these should have been changed to use apache (for trademark reasons)
but it seems in the move by maven to use groupId/artifactId most of
these were ported wrongly.

this is a good example of issues that have cropped up from time to
time at apache with maven: the practice they enforce is not always the
best one for apache

> I only found the last activemq release following this best practice inside
> ASF. httpd for one is named httpd-2.2.4.tar.gz,

ironically enough, most best practice originated in httpd but anything
which wasn't written down tends to be forgotten by later release

> even product having main
> zip distribution named with the prefix (apache-ant and apache-tomcat)
> contains non prefixed jars (catalina.jar, tomcat-api.jar,
> ant.jar)</provoking>

what matters are the artifacts distributed: if a project does not
intend to distribute jars then it doesn't need to take care over

> <seriously>I'm happy we are the *best* (first/fastest) at least in this
> *practice* issue, now!</seriously>

not the first: there was a period where there was a drive to ensure
that everything we released had apache in the title. we've just had
regression over time...


> >> >> >> If they will reply that NOTICE and LICENSE are needed also
> >> the svn
> >> >> >> source tree then we should coordinate the Maven2 guys to avoid
> >> pushing
> >> >> >> the use of the
> >> >> >> "apache-jar-resource-bundler"+"maven-remote-resources-plugin"
> >> >> >> combination because this leads to no LICENSE/NOTICE in the
> >> >> tree.
> >> >> >
> >> >> > seems wrong to me that maven actively conflicts with the use of
> >> an svn
> >> >> > export to create a proper source release
> >> >> >
> >> >> > - robert
> >> >>
> >> >> I don't agree on the fact that svn export should be used to create
> >> >> source releases. svn export does not create a package, does not
> >> sign it,
> >> >> does not ensure any rule.
> >> >
> >> > maven doesn't really enforce rules yet (but it is coming)
> >>
> >> Not maven alone, but a properly configured pom.xml results in maven
> >> creating the LICENSE/NOTICE. (you just need to declare the parent apache
> >> pom, even if we don't use this solution for JAMES products).
> >> The parent apache pom include this LICENSE/NOTICE "rule".
> >
> > this didn't used to work very well but it's a lot better now
> >
> > there are downsides with generating LICENSE and NOTICE documents
> >
> > 1 it is unfortunate that users no longer receive the permissions they
> > require when they checkout a mavenised project. in some jurisdictions,
> > this may make checking out the source a criminal offense.
> <core>
> That's exactly the point of my question: but I have doubts about the
> validity of the doubt and that's why I keep asking.

this concern only applies to jurisdictions where an actual copy of the
license is required

> If I do svn export of the src subfolder of mime4j I don't receive a
> NOTICE and LICENSE anyway and there is no descriptor that tell me what
> folder level in svn is a product parent folder ant what is not.
> If we can get a lawyer position about this specific issue it would be
> really useful to give much more sense to this (anyway interesting, but
> otherwise more appropriate for a bar) conversation.

the LICENSE and NOTICE apply only to the collective work which is why
they are located in the root directory for that work. individual
documents each have their own particular license.   under most sane
copyright laws (including the US) users checking this out should be

> > 2 it is no longer possible for to check that the NOTICE and LICENSE
> > documents are correct just by checking out the source.
> They are included in the stage folder, inside a jar named
> apache-jar-resource-bundle-1.2.jar

that means that i have to do a build before i can verify that these
documents are accurate

> > there's quite a lot more work required before maven will generate
> > correct NOTICE documents under all circumstances but hopefully this
> > will happen within the year
> We don't need maven to generate correct documents under all
> circumstances: we just need it to generate correct documents in our
> circumstances and we oversight on the generated files :-)

it's harder to provide oversight when i need to create a full build in
order to check whether a NOTICE is up to date

> If you add a dependency in maven MAYBE maven will automatically take
> care of the NOTICE changes, otherwise you can do it manually. If you
> don't use that generated license then you are SURE that you have to do
> it manually for sure.

this algorithm is not sufficient to create a compliant NOTICE (it
would be possible to do it properly but it will take a while to write
the software and instrument the code bases with the required

it's easy to maintain a NOTICE if you understand what's required and
it's not possible to check a NOTICE unless you understand what's
required. so, if maven generates this file it's very important that it
does it correctly.


> >> LICENSE and NOTICE are
> >> policy/legal disclaimers needed to protect the ASF and to enforce the
> >> licensing.
> >
> > no: these documents are not required to enforce licensing
> >
> > the work is not public domain and so a license is required before it
> > can be lawfully copied. these documents permit people to checkout and
> > develop the source. apache is user friendly when it comes to
> > licensing. this is policy
> > (http://apache.org/legal/src-headers.html#notice). policy exists to
> > make things as easy and clear as possible for users from a legal
> > perspective.
> I don't understand this. I always thought that NOTICE and LICENSE are
> needed to tell people what they can do with the software (and this is a
> legal thing): they don't change the behavior of the software.

(under most modern copyright laws) without a license, you have no
right to create a copy of the work. this means that it cannot be
downloaded or the document loaded into memory. the LICENSE grants the
right to create copies (providing that certain conditions are

the NOTICE is a modern replacement for the (infamous) advertising clause

> >> IMHO they are not compressed for delivery, but packaged in a
> >> redistributable artifact.
> >
> > just use a compression application
> <provoking>Why do you use ant? you could just execute a sequence of the
> command you need, instead..</provoking>

creating and using any script is a trade-off

creating source releases is quick and easy. few ever need to create
releases. i prefer to use the traditional way of creating releases. i
don't trust maven to accurately create source releases.

- robert

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message