james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject NOTICE/LICENSE, apache- prefix and other ASF best practices (Re: [mime4j] release plan for 0.3) [LONG]
Date Tue, 15 May 2007 00:40:43 GMT
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.

>> 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 :-) I
only found the last activemq release following this best practice inside
ASF. httpd for one is named httpd-2.2.4.tar.gz, 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>

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

> unless apache is included within the name of an artifact then
> trademark law cannot be used to prevent distribution of look-alike
> jars. IIRC this issue cropped up years ago (so there may be a board
> resolution) but i don't recall anything any policy being written down.

On this topic I'm on your side! The only difference between our "views"
is the definition of the "source distribution", but I think we can both
live with this difference :-)

>> >> Please note that this is not to mean that I don't believe you, but
>> >> simply to tell to someone that I think this thing is important and
>> this
>> >> should be documented and more widely communicated to newcomers.
>> >
>> > not sure apache has a solution for this. i find that writing
>> > documentation is tough and takes a lot of time. there are only a
>> > limited number of other people who find any time for documentation.
>> >
>> > it's easier (and usually quicker) to create technical solutions. when
>> > infra moves to using a proper release upload mechanism, the releases
>> > can be verified and any which don't meet policy can be rejected.
>>
>> This would be cool, but this would increase the requirement of a policy
>> to be written :-)
>> E.g: maybe that if the maven2 guys was aware of this "prefix"/"trademark
>> " issue they could have decided to include the groupId in the name of
>> the resulting artifacts in the m2 repository.
>>
>> I will try to do my homework and to post a message about this issue to
>> repository@apache list so to ping them about the issue and spread the
>> word!
> 
> probably too late to change now: the advice should have be given when
> maven changed to use groupId and artifactId

I agree. But I also know that maven/ant/ivy/osgi teams are still
discussing about repositories and so I guess there is no anything
definitive yet and we can do of our best to let them know our concerns!
I posted to repository with this in mind: if they ignore my email, well,
at least I tried :-)

>> [..]
>> It is exactly the svn export with the only addition of NOTICE and
>> LICENSE that I think are required (by policies) to redistribute a
>> package. Also the "package concept" is not part of svn ;-)
> 
> if the root of project included NOTICE and LICENSE files then adding
> them would be unnecessary. for people in some jurisdictions not
> including them means that a checkout from svn does not provide the
> necessary copyright documentation.

My question is mainly legal-related: I don't care of a LICENSE/NOTICE
file and I would only add them so that ASF can take care of the legal
issues. So I will simply do what the ASF tell me. E.g.: if ASF suggest
me to place a NOTICE file in every folder of our svn repository I will
do that, but If I can avoid such thing I will be more happy :-)

>> >> Imho it is important to understand if the svn root tree is a requisite
>> >> or not because currently our NOTICE and LICENSE is generated by
>> metadata
>> >> included in the POM and having also a non-automatically generated
>> >> artifact in the source tree will lead to duplication and much more
>> easy
>> >> desynchronization.
>> >
>> > the maven NOTICE generation stuff seems to be working much better now
>>
>> In the same message I posted to legal-discuss I also asked other
>> questions about the content of NOTICE and LICENSE as my knowledge about
>> what to put in NOTICE and LICENSE was different by the knowledge of the
>> m2 committer that created the remote resources plugin (that generates
>> the NOTICE and LICENSE). The weird thing is that our knowledge has been
>> generated by discussions with Cliff, for both of us..
> 
> the policy is covered in http://apache.org/legal/src-headers.html
> 
> apache policy tends to be a set of principles that projects are free
> to implement in their own way. i'll try to add some comments to aid
> understanding

I read that webpage many times :-)
But it is not consistent with what we have done in james LICENSE after a
bunch of mails between us and Cliff... that's why I've asked again ;-)

>> 1) What is the correct approach?
> <snip>

Thank you for the explanation!

>> >> I don't understand why this should be asked to INFRA and not LEGAL,
>> >
>> > legal discuss is about points of law and not about points of policy.
>> > yes, policy is informed by law but release policy is set by the
>> > infrastructure team. the policy is that every artifact released must
>> > have LICENSE and NOTICE documents. (the convention for source
>> > distributions is to have them at top level.)
>>
>> I exactly followed that policy. The only "detail" is that in zips I
>> always included a folder with the same name of the artifact and the
>> LICENSE/NOTICE are placed inside this folder with everything else.
>> Is this OK?
> 
> i'm not sure i understand
> 
> the policy is that every release artifact distributed must include
> appropriate LICENSE and NOTICE documents

Ok, this is already done in mime4j.

>> > therefore to produce a proper source release through a svn export,
>> > LICENSE and NOTICE files need to be at top level. however, if you
>> > aren't going to be shipping a proper source release then they aren't
>> > necessary.
>>
>> Can I guess that "proper" is your own opinion and not an ASF policy? ;-)
> 
> this is a definition and so not something which could be policy (but
> it is widely shared amongst the infrastructure team)
> 
> <snip>

If you compare the source zip generated by mime4j and an svn export you
will find that the only difference is the lack of LICENSE and NOTICE in
the svn export: this is because they are generated files and we don't
include generated files in the source tree (unless we are not required
to do this because of some non-technical reason).

>> >> >> If they will reply that NOTICE and LICENSE are needed also in
>> 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 source
>> >> 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.
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.
</core>

> 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

> 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 :-)

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.

>> >> Every other package we release is created by a build script: why
>> should
>> >> we use svn export for the source release?
>> >
>> > because it's the source and are an open source project :-)
>>
>> My understanding was that LICENSE and NOTICE are required for
>> redistribution. You can do everything else with the svn export ;-)
> 
> if LICENSE and NOTICE documents are in the top of the root then the
> export will produce a compliant distribution

The export does not zip and does not take care of the prefix. A folder
in my filesystem is not a distribution.

Btw I hope you understood that we may have different opinion on the fact
that "svn export" is the tool for creating source distributions.

>> IMHO LICENSE and NOTICE are not part of the sources: in fact they are
>> not involved in the build process ;-) .
> 
> no - these documents are the most important sources of all

I don't agree.

>> 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.

>> IMHO "svn export" is not intended to create redistributables (does this
>> word exists?).
> 
> creating releases is a primary use case for svn export

I don't agree: IMHO it is only a part of the process.

>> 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>

>> PS: I don't want to convince you of anything but I ask you a personal
>> favor: I found it difficult to understand what of your sentences are
>> personal ideas and what are ASF policies. As described here:
>> http://www.apache.org/foundation/how-it-works.html#management (hats)
>> I always consider your sentences as personal ideas if not otherwise
>> specified, but if you have knowledge of ASF policies that already
>> defined what we have to do then it does not worth discussing our
>> personal ideas.
> 
> apache has very little formal policy. this can be found by reading the
> documentation.

ok. I read most of it multiple times :-)
May also be I know *written* ASF policies/documentations much better
than any ASF member ;-)

> most of what i say is advice though i try to indicate (using IMHO) any
> advice that i don't think is a reasonable consensus infrastructure
> position
> 
> - robert

Ok. You used only 1 imho and it was about the "source release"
definition. As it seems it is also the only thing we "in our humbling
opinion" disagree upon I'm fine with it.


Stefano


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


Mime
View raw message