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: [mime4j] release plan for 0.3
Date Mon, 14 May 2007 17:49:29 GMT
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

> 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

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.

> >> 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 believe the
> >> >> source package containes the NOTICE/LICENSE.
> >> >> About the svn source tree I posted a question on legal-discuss but
I
> >> >> received no answer about this:
> >> >>
> >> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200705.mbox/<463EFEEF.4080201@apache.org>
> >>
> >> >
> >> > it's not a legal question but an infra question
> >> >
> >> > all apache releases require LICENSE and NOTICE. source releases should
> >> > be the primary form of release for apache projects. source releases
> >> > are formed by svn export. if the source lacks top level LICENSE and
> >> > NOTICE files then it's hard to create compliant releases.
> >>
> >> the source package is generated via an mvn assembly (package) command
> >> and it make sure to include an up-to-date NOTICE/LICENSE.
> >
> > in that case, policy will be satisfied
> >
> > IMHO it's not a real source release though, since it does not actually
> > corresponding to anything that i can check out of svn. i sometimes
> > worry about the reconstructability of maven source releases...
>
> 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.

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

> 1) What is the correct approach?

it depends: quite possibly both. policy is set in terms of principles
so any approach that satisfies them is correct (though some approaches
will be better than others).

many licenses require a form of attribution which includes a copyright
statement. so, for these licenses the NOTICE requires a copyright
notice

when a copyright notice is relocated from original source to the
NOTICE then this will include a copyright statement

what maven seems to be (rightly) doing is assembling an appropriate
NOTICE composed of the required fragments

there is also the requirement to include licenses for all documents
included in the distribution. there are various ways to do this. IIRC
maven tends to include licenses by reference in the NOTICE document.

> 2) do we need a LICENSE/NOTICE also in the root of each svn repository
> product tree or is it ok to generate them while building artifacts?

policy is silent on this point

my advice about best practice is that LICENSE and NOTICE should be
included in the project root (see earlier for reasons) but a project
is free to work this one out for themselves

> 3) do we need a LICENSE/NOTICE file also for 'artifact-javadoc.jar's ?

all released artifacts should include these documents

> 4) If the project contains crypto code we have to add a README in the
> root of our redistributable: in case of a jar to be deployed to the
> maven repository, do we place it in the META-INF together with
> NOTICE/LICENSE?

i think so (but i'm not certain)

<snip>

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

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

2 it is no longer possible for to check that the NOTICE and LICENSE
documents are correct just by checking out the source.

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

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

> > a source release should consist of the source exported directly from
> > the repository and compressed for delivery. everything else is just
> > window dressing.
> >
> > - robert
>
> Add also that you can add LICENSE/NOTICE for redistribution policies and
> maybe you name the package apache-something and I agree with you.

not sure i understand this

> 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

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

> IMHO "svn export" is not intended to create redistributables (does this
> word exists?).

creating releases is a primary use case for svn export

> IMHO they are not compressed for delivery, but packaged in a
> redistributable artifact.

just use a compression application

maven arose from efforts to unify the jakarta way of creating
releases. the original export, compress and sign is the process which
maven automated.

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

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

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