[mime4j] release plan for 0.3

[Stefano Bagnara <ap...@bago.org>]

Hi all,

I just deployed snapshot builds for mime4j here:
http://people.apache.org/~bago/mime4j/

I took care to update the james-project project and mime4j poms to have
LICENSE/NOTICE correctly included in every artifact (META-INF for jars,
root folder for other packages) and to remove any file with doubt
licensing or unknown copyright holder (thank to Bernd for having noticed
this).

I also changed a bit the resulting packages for the mime4j project:

%.jar: main "library only" binary distribution.

%-src.zip and %-src.tar.gz: source distribution. Contains the svn source
tree.

%-bin.zip and %-bin.tar.gz: binary distribution. Contains the main jar
in the root, the runtime dependencies jar in the lib folder, the example
"source" folder and the generated javadocs.

%-source.jar: contains source and generated sources java files (this may
be used in IDEs to attach sources to library for debugging purposes).

%-javadoc.jar: contains javadocs for the library (same consideration
about the IDE usage of this artifact).

jar and pom files are intended to be deployed to public maven repositories.

Please review.

If no one raises his voice I will ask Norman to prepare/tag/sign a
release the next week and to start a vote for official release of JAMES
Mime4J 0.3 and JAMES Project 1.1 artifacts
(james-parent/james-project/maven-skin).

Stefano


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

Re: NOTICE/LICENSE, apache- prefix and other ASF best practices (Re: [mime4j] release plan for 0.3) [LONG]

[Stefano Bagnara <ap...@bago.org>]

robert burrell donkin ha scritto:
> On 5/15/07, Stefano Bagnara <ap...@bago.org> wrote:
>>
>> AFAIK the NOTICE we are generating in MIME4J is compliant, and it is
>> generated. What's the problem, then?
> 
> there is no problem if they are compliant
> 
> i haven't checked the NOTICE and i know of weaknesses in the current
> plugin. so it needs to be checked rather than just assumed to be
> correct. in particular, check that there are no documents without ALv2
> headers in the source.

I checked it, and it is correct (at least for my understanding of what
NOTICE/LICENSE should contain).

Bernd checked mime4j with RAT, we decided to leave 3 poms without
headers as is. They are copies of files released by jakarta-commons, so
we preffered to leave them "as is" (and they are really small files).

>> That said I think I just completed my duties on mime4j. IMHO everything
>> is ready for a release and our generated artifacts seems to be compliant
>> with any policy I heard of. If anyone wants a release just ask Norman to
>> take care of this (I don't have a signed gpg key so even if I wanted I
>> could not do the last missing step).
> 
> a key with a strong web of trust is not required by policy: just a
> signature
> 
> it's best practice to use a key with a strong web of trust but it's
> more important that the release is signed by the release manager who
> cut the release. the signature is primarily to allow infrastructure
> and the release manager to verify that an artifact was create by the
> release manager. all that requires is that the private key is kept
> safe and secure.
> 
> - robert

Good to know! I think Norman is happy to take care of releasing and
Norman is even better fit for the task as he already worked with mime4j
code (maybe he can also test it on real applications) and he already
created a lot of official ASF releases. I've worked for many of them,
but never cut down one to the last step (even if I almost often assisted
the process).

Stefano


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

Re: NOTICE/LICENSE, apache- prefix and other ASF best practices (Re: [mime4j] release plan for 0.3) [LONG]

[Norman Maurer <no...@apache.org>]

<SNIP>
>
> a key with a strong web of trust is not required by policy: just a
> signature
>
> it's best practice to use a key with a strong web of trust but it's
> more important that the release is signed by the release manager who
> cut the release. the signature is primarily to allow infrastructure
> and the release manager to verify that an artifact was create by the
> release manager. all that requires is that the private key is kept
> safe and secure.
>
> - robert 

Like I said before. I will step in and try to get the release stuff done ;-)

bye
Norman

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

Re: NOTICE/LICENSE, apache- prefix and other ASF best practices (Re: [mime4j] release plan for 0.3) [LONG]

[robert burrell donkin <ro...@gmail.com>]

On 5/15/07, Stefano Bagnara <ap...@bago.org> wrote:
> robert burrell donkin ha scritto:

<snip>

> >> 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
> > meta-data)
>
> AFAIK the NOTICE we are generating in MIME4J is compliant, and it is
> generated. What's the problem, then?

there is no problem if they are compliant

i haven't checked the NOTICE and i know of weaknesses in the current
plugin. so it needs to be checked rather than just assumed to be
correct. in particular, check that there are no documents without ALv2
headers in the source.

> >> >> 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
>
> I don't share your missing trust for the maven-assembly-plugin: I don't
> see why I should trust svn/zip and not the maven-assembly-plugin.
> Either way, I checked the resulting package with a compare tool, and it
> worked fine.

good

> As you wrote "I prefer" I think you are only telling your own preference
> and you're perfectly fine with what differently I do.

yes

> Otherwise if
> you'll take the responsibility to release mime4j here is my +1 to use
> whatever build tool you like and whatever NOTICE generator and svn
> implementation ;-). "I don't trust maven to accurately create source
> releases" IMHO is not an acceptable justification to prevent us from
> working out a release.

i agree

> IMHO you should simply check the generated result independently on how
> we generated it: IMHO the tools should be a choice of the worker.

i agree

> That said I think I just completed my duties on mime4j. IMHO everything
> is ready for a release and our generated artifacts seems to be compliant
> with any policy I heard of. If anyone wants a release just ask Norman to
> take care of this (I don't have a signed gpg key so even if I wanted I
> could not do the last missing step).

a key with a strong web of trust is not required by policy: just a signature

it's best practice to use a key with a strong web of trust but it's
more important that the release is signed by the release manager who
cut the release. the signature is primarily to allow infrastructure
and the release manager to verify that an artifact was create by the
release manager. all that requires is that the private key is kept
safe and secure.

- robert

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

Re: NOTICE/LICENSE, apache- prefix and other ASF best practices (Re: [mime4j] release plan for 0.3) [LONG]

[Stefano Bagnara <ap...@bago.org>]

robert burrell donkin ha scritto:
>> 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

I know, I hope they will consider introducing "our" suggestion too!

>> <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 really understand this! And when I understand why something should be
done someway I am the first one trying to spread the practice :-)

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

This is a pity: we "ASF newbies" often refer to what other projects do
when we can't find documentation about what to do. ASF members often
spread different (sometimes opposite) words in the name of ASF policies,
so we have to do much work to learn using our mind.

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

Well, at least "ant" includes the jars in maven repositories and this
way redistribute jars. I don't know the facts for tomcat, and maybe this
is going to much off topic: I think it is clear to both of us that the
"apache-" prefix is a good thing and that most ASF projects currently
don't make use of this good practice.

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

Ok, then we could be the first of the new cycle, the next generation ;-)
(In practice we could only be the second as activemq seems to have done
this properly, but second is cool anyway ;-) ).

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

IANAL but I really have doubt that any jurisdiction define how to
identify a root of collective work inside an svn repository.
I download a random file from svn, the header tell me that I have to
"see the NOTICE file distributed with this work".. what does it means
"distributed with this work" for a file downloaded via HTTP from a
random URL?.. Italian laws do not add anything to help me finding this
NOTICE file.

BTW I can't afford discussing this: if we can find an answer from a
lawyer I will be happy to increase my knowledge on this issue.

FWIW seeing this "requirement" listed
http://www.apache.org/legal/src-headers.html
or
http://www.apache.org/dev/apply-license.html
would be enough for me to avoid ad all similar discussions about
personal interpretation/preferences (devil's advocate playing) in favor
of a written rule (acknowledged at least by people that do oversight on
www.apache.org content).

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

You should anyway verify the result of a build: we vote and are
responsible for what we have in released packages and not for the way
this package has been generated.

If we keep a copy of generated LICENSE/NOTICE files in svn and we
instead generate other files we would suffer desynchronization for sure,
soon.

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

I don't agree: you have to oversight anyway. The autogeneration of the
NOTICE increase the probability to keep NOTICE informations synchronized
with real dependencies. Otherwise you always depend on manual
synchronization.

>> 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
> meta-data)

AFAIK the NOTICE we are generating in MIME4J is compliant, and it is
generated. What's the problem, then?

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

I don't agree again: the tool is a tool. We still have the
responsibility for the resulting NOTICE file. As long as Maven will
generate a compliant NOTICE it should be an option of the developer to
decide how to generate this.

>> 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
> followed).
> 
> the NOTICE is a modern replacement for the (infamous) advertising clause

I agree: but I still think of it as something separated from the source
files. Imho the NOTICE and the LICENSE are documents that tells you what
you can do with that files, but changing the NOTICE imho does not
constitute a change of the sources. Of course all of this is more a
philosophical issue.

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

I don't share your missing trust for the maven-assembly-plugin: I don't
see why I should trust svn/zip and not the maven-assembly-plugin.
Either way, I checked the resulting package with a compare tool, and it
worked fine.

As you wrote "I prefer" I think you are only telling your own preference
and you're perfectly fine with what differently I do. Otherwise if
you'll take the responsibility to release mime4j here is my +1 to use
whatever build tool you like and whatever NOTICE generator and svn
implementation ;-). "I don't trust maven to accurately create source
releases" IMHO is not an acceptable justification to prevent us from
working out a release.

IMHO you should simply check the generated result independently on how
we generated it: IMHO the tools should be a choice of the worker.

That said I think I just completed my duties on mime4j. IMHO everything
is ready for a release and our generated artifacts seems to be compliant
with any policy I heard of. If anyone wants a release just ask Norman to
take care of this (I don't have a signed gpg key so even if I wanted I
could not do the last missing step).

No further steps will come from me on mime4j-0.3. My time for this
product (I don't even use) is expired with this message :-)

Stefano

PS: I enjoyed and found interesting the discussion until the last reply.
IMHO this is becoming too long, too religious and time wasting now (and
I'm the first to be guilty, of course). To keep placing emphasis on our
known diversities won't help anyone. Thank you for your patience :-)


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

Re: NOTICE/LICENSE, apache- prefix and other ASF best practices (Re: [mime4j] release plan for 0.3) [LONG]

[robert burrell donkin <ro...@gmail.com>]

On 5/15/07, Stefano Bagnara <ap...@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 <ap...@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
managers

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

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

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

> > 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
meta-data)

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.

<snip>

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

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

NOTICE/LICENSE, apache- prefix and other ASF best practices (Re: [mime4j] release plan for 0.3) [LONG]

[Stefano Bagnara <ap...@bago.org>]

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

Re: [mime4j] release plan for 0.3

[robert burrell donkin <ro...@gmail.com>]

On 5/13/07, Stefano Bagnara <ap...@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/<46...@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

Re: [mime4j] release plan for 0.3

[Stefano Bagnara <ap...@bago.org>]

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

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

>> >> 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/<46...@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 ;-)

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

>> So I'd like to know what is the legal requirement and then to be able to
>> decide how to better accomplish it technically ;-)
> 
> it's a consequence of a policy requirement (not a legal one)

Thank you for explaining: I often merge the issues, because I classify
anything not technical as "legal". ASF policies are my "laws" as a
committer at the same level as "real" legal issues.

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

> 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? ;-)

>> but I will do this too.
> 
> not sure that there's much point asking on infra: you'll probably get
> a quicker answer by asking infrastructure questions on this list.
> hopefully, i've been reasonably comprehensive. please ask more
> questions if i haven't been clear on any points.

Can you check the thread I linked before? In that message I was asking
few things about LICENSE/NOTICE and related stuff. It would be cool to
have a reply.

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

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

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

IMHO LICENSE and NOTICE are not part of the sources: in fact they are
not involved in the build process ;-) . LICENSE and NOTICE are
policy/legal disclaimers needed to protect the ASF and to enforce the
licensing.

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

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

Stefano

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.


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

Re: [mime4j] release plan for 0.3

[robert burrell donkin <ro...@gmail.com>]

On 5/13/07, Stefano Bagnara <ap...@bago.org> wrote:
> robert burrell donkin ha scritto:

<snip>

> >> None of the jars distributed by ASF via Maven repositories (*MANY*
> >> products) have the apache name in the jar !?! (well maybe a couple of
> >> them have this prefix.. but a couple vs thousands)
> >
> > i've taken a quick look and the maven 2 repository is much worse than
> > the old one used to be
> >
> > jar names should include 'apache'. unless jar names include 'apache'
> > we have no ability to ensure that others do not produce jars with the
> > same name. probably need to go and remind them that they still have it
> > very wrong.
>
> There should be a "priority" list where every committer should receive
> such informations: they are critical to the ASF community and I ensure
> you that even if I read a lot of documentaiton and I make a lot of
> questions on how to do stuff I never head the prefix thing before!

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

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

<snip>

> >> 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/<46...@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...

> 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

> So I'd like to know what is the legal requirement and then to be able to
> decide how to better accomplish it technically ;-)

it's a consequence of a policy requirement (not a legal one)

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

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.

> but I will do this too.

not sure that there's much point asking on infra: you'll probably get
a quicker answer by asking infrastructure questions on this list.
hopefully, i've been reasonably comprehensive. please ask more
questions if i haven't been clear on any points.

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

the latest maven code does the signing reliably but does not use an
agent so i'm not sure that i'd trust it with my code signing key

(FWIW i do all my signing on an isolate machine by switching hard discs)

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

a source release should consist of the source exported directly from
the repository and compressed for delivery. everything else is just
window dressing.

- robert

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

Re: [mime4j] release plan for 0.3

[Stefano Bagnara <ap...@bago.org>]

robert burrell donkin ha scritto:
>> > it's best to prefix the jar names with 'apache' (eg
>> > apache-james-mime4j-0.3-SNAPSHOT-bin.tar.gz) since this allows
>> > trademark law to be used against anyone passing off bad jars
>>
>> I see your point, but shouldn't this be discussed with the whole Maven2
>> community?
> 
> not really: there are quite a lot of areas where work is needed before
> maven will produce compliant releases. AIUI the maven team are have
> been working hard on a lot of these areas and it's a lot better now.

I never read this on Maven2 lists/docs: we should spread the word :-)
I will start applying this rule to our projects.

>> None of the jars distributed by ASF via Maven repositories (*MANY*
>> products) have the apache name in the jar !?! (well maybe a couple of
>> them have this prefix.. but a couple vs thousands)
> 
> i've taken a quick look and the maven 2 repository is much worse than
> the old one used to be
> 
> jar names should include 'apache'. unless jar names include 'apache'
> we have no ability to ensure that others do not produce jars with the
> same name. probably need to go and remind them that they still have it
> very wrong.

There should be a "priority" list where every committer should receive
such informations: they are critical to the ASF community and I ensure
you that even if I read a lot of documentaiton and I make a lot of
questions on how to do stuff I never head the prefix thing before!
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.

>> Should we change every of our artifactId to include "apache-" ? We have
>> org.apache.james in the groupId for every artifact, but we don't have
>> "apache" for the artifactId (as I said before I'm not aware of any other
>> project using "apache" in the artifactId apart the
>> apache-jar-resource-bundle-1.2.jar I just added to the local stage
>> folder).
> 
> every artifact id should include 'apache'

Ok. Added to todo.

>> > taken a quick look and the basics seem ok (haven't run RAT)
>> >
>> > mvn doesn't work for me when running against trunk
>>
>> maven 2.0.6 > mvn -U -Plocal package
>>
>> What's the error you get?
>>
>> if it was the missing "apache-jar-resource-bundle" artifact I just added
>> it to the local repository (having it in the james-project local
>> repository hidden this problem to me).
>> Please tell me if this fixed your issue.
> 
> mvn -U -Plocal package works for me now
> 
> i recommend adding a top level BUILDING.txt file giving building
> instructions

Added to todo.

> <snip>
> 
>> > the root source lacks NOTICE and LICENSE
>>
>> Do you mean the source tree in svn or the source package?
> 
> best to have them at the top of the source tree in svn
> 
>> 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/<46...@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.

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.

So I'd like to know what is the legal requirement and then to be able to
decide how to better accomplish it technically ;-)

I don't understand why this should be asked to INFRA and not LEGAL, but
I will do this too. (added to todo ;-) ).

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

Every other package we release is created by a build script: why should
we use svn export for the source release?

This is my opinion, of course.

Thank you for following me in this mime4j task,
Stefano


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

Re: [mime4j] release plan for 0.3

[robert burrell donkin <ro...@gmail.com>]

On 5/13/07, Stefano Bagnara <ap...@bago.org> wrote:
> robert burrell donkin ha scritto:
> > On 5/11/07, Stefano Bagnara <ap...@bago.org> wrote:
> >> Hi all,
> >>
> >> I just deployed snapshot builds for mime4j here:
> >> http://people.apache.org/~bago/mime4j/
> >
> > it's best to prefix the jar names with 'apache' (eg
> > apache-james-mime4j-0.3-SNAPSHOT-bin.tar.gz) since this allows
> > trademark law to be used against anyone passing off bad jars
>
> I see your point, but shouldn't this be discussed with the whole Maven2
> community?

not really: there are quite a lot of areas where work is needed before
maven will produce compliant releases. AIUI the maven team are have
been working hard on a lot of these areas and it's a lot better now.

> None of the jars distributed by ASF via Maven repositories (*MANY*
> products) have the apache name in the jar !?! (well maybe a couple of
> them have this prefix.. but a couple vs thousands)

i've taken a quick look and the maven 2 repository is much worse than
the old one used to be

jar names should include 'apache'. unless jar names include 'apache'
we have no ability to ensure that others do not produce jars with the
same name. probably need to go and remind them that they still have it
very wrong.

> Should we change every of our artifactId to include "apache-" ? We have
> org.apache.james in the groupId for every artifact, but we don't have
> "apache" for the artifactId (as I said before I'm not aware of any other
> project using "apache" in the artifactId apart the
> apache-jar-resource-bundle-1.2.jar I just added to the local stage folder).

every artifact id should include 'apache'

> > taken a quick look and the basics seem ok (haven't run RAT)
> >
> > mvn doesn't work for me when running against trunk
>
> maven 2.0.6 > mvn -U -Plocal package
>
> What's the error you get?
>
> if it was the missing "apache-jar-resource-bundle" artifact I just added
> it to the local repository (having it in the james-project local
> repository hidden this problem to me).
> Please tell me if this fixed your issue.

mvn -U -Plocal package works for me now

i recommend adding a top level BUILDING.txt file giving building instructions

<snip>

> > the root source lacks NOTICE and LICENSE
>
> Do you mean the source tree in svn or the source package?

best to have them at the top of the source tree in svn

> 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/<46...@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.

> 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

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

Re: [mime4j] release plan for 0.3

[Stefano Bagnara <ap...@bago.org>]

robert burrell donkin ha scritto:
> On 5/11/07, Stefano Bagnara <ap...@bago.org> wrote:
>> Hi all,
>>
>> I just deployed snapshot builds for mime4j here:
>> http://people.apache.org/~bago/mime4j/
> 
> it's best to prefix the jar names with 'apache' (eg
> apache-james-mime4j-0.3-SNAPSHOT-bin.tar.gz) since this allows
> trademark law to be used against anyone passing off bad jars

I see your point, but shouldn't this be discussed with the whole Maven2
community?

None of the jars distributed by ASF via Maven repositories (*MANY*
products) have the apache name in the jar !?! (well maybe a couple of
them have this prefix.. but a couple vs thousands)

Should we change every of our artifactId to include "apache-" ? We have
org.apache.james in the groupId for every artifact, but we don't have
"apache" for the artifactId (as I said before I'm not aware of any other
project using "apache" in the artifactId apart the
apache-jar-resource-bundle-1.2.jar I just added to the local stage folder).

> taken a quick look and the basics seem ok (haven't run RAT)
> 
> mvn doesn't work for me when running against trunk

maven 2.0.6 > mvn -U -Plocal package

What's the error you get?

if it was the missing "apache-jar-resource-bundle" artifact I just added
it to the local repository (having it in the james-project local
repository hidden this problem to me).
Please tell me if this fixed your issue.

> the MANIFEST is very basic. i think that it looks better to include
> the implementation and specification stuff.

ok. added to the TODOs.

> the root source lacks NOTICE and LICENSE

Do you mean the source tree in svn or the source package? 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/<46...@apache.org>

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.

Stefano


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

Re: [mime4j] release plan for 0.3

[Stefano Bagnara <ap...@bago.org>]

Update on this issue.

robert burrell donkin ha scritto:
> On 5/11/07, Stefano Bagnara <ap...@bago.org> wrote:
>> Hi all,
>>
>> I just deployed snapshot builds for mime4j here:
>> http://people.apache.org/~bago/mime4j/
> 
> it's best to prefix the jar names with 'apache' (eg
> apache-james-mime4j-0.3-SNAPSHOT-bin.tar.gz) since this allows
> trademark law to be used against anyone passing off bad jars

DONE

> taken a quick look and the basics seem ok (haven't run RAT)
> 
> mvn doesn't work for me when running against trunk

FIXED

> the MANIFEST is very basic. i think that it looks better to include
> the implementation and specification stuff.

DONE

> the root source lacks NOTICE and LICENSE

The distribution include them.
About the james/mime4j/trunk svn folder there is a LONG message living
in this list ;-)

I published updated artifacts to the same location.

Stefano


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

Re: [mime4j] release plan for 0.3

[robert burrell donkin <ro...@gmail.com>]

On 5/11/07, Stefano Bagnara <ap...@bago.org> wrote:
> Hi all,
>
> I just deployed snapshot builds for mime4j here:
> http://people.apache.org/~bago/mime4j/

it's best to prefix the jar names with 'apache' (eg
apache-james-mime4j-0.3-SNAPSHOT-bin.tar.gz) since this allows
trademark law to be used against anyone passing off bad jars

taken a quick look and the basics seem ok (haven't run RAT)

mvn doesn't work for me when running against trunk

the MANIFEST is very basic. i think that it looks better to include
the implementation and specification stuff.

the root source lacks NOTICE and LICENSE

- robert

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

Re: [mime4j] release plan for 0.3

[Norman Maurer <no...@apache.org>]

Hi Stefano,

I just did some quick review and all seems to be fine .

I whould be proud todo the release stuff ;-)

bye
Norman

Stefano Bagnara schrieb:
> Hi all,
>
> I just deployed snapshot builds for mime4j here:
> http://people.apache.org/~bago/mime4j/
>
> I took care to update the james-project project and mime4j poms to have
> LICENSE/NOTICE correctly included in every artifact (META-INF for jars,
> root folder for other packages) and to remove any file with doubt
> licensing or unknown copyright holder (thank to Bernd for having noticed
> this).
>
> I also changed a bit the resulting packages for the mime4j project:
>
> %.jar: main "library only" binary distribution.
>
> %-src.zip and %-src.tar.gz: source distribution. Contains the svn source
> tree.
>
> %-bin.zip and %-bin.tar.gz: binary distribution. Contains the main jar
> in the root, the runtime dependencies jar in the lib folder, the example
> "source" folder and the generated javadocs.
>
> %-source.jar: contains source and generated sources java files (this may
> be used in IDEs to attach sources to library for debugging purposes).
>
> %-javadoc.jar: contains javadocs for the library (same consideration
> about the IDE usage of this artifact).
>
> jar and pom files are intended to be deployed to public maven repositories.
>
> Please review.
>
> If no one raises his voice I will ask Norman to prepare/tag/sign a
> release the next week and to start a vote for official release of JAMES
> Mime4J 0.3 and JAMES Project 1.1 artifacts
> (james-parent/james-project/maven-skin).
>
> Stefano
>
>   


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