james-server-dev mailing list archives

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

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

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


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

View raw message