Robert Burrell Donkin ha scritto:
On Wed, Mar 26, 2008 at 10:07 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Robert Burrell Donkin ha scritto:
> looks good
>
> only possible issue are those PITA poms without license headers in the
> stage directory :-/
IIRC the issue has been raised [1] in legal-discuss and in repository
lists but we had no solution to the fact that most poms in the maven
repository have no license headers.
the real problem is the complete lack of auditable process involved:
there's no way to track down who did what when
Hi Robert, you are right. Here are the details:
files in stage\org.apache.james have been created by us. poms include
the ALv2 header while xmls dont because of maven issues during deploying
to the repository (and we used the deployed ones).
stage\org.jvyaml\poms\jvyaml-0.2.1.pom has been created by me.
stage\uk.nominet\poms\dnsjnio-0.9.9.pom has been created by me.
stage\commons-cli\poms\commons-cli-1.1.pom has been downloaded from central.
stage\dnsjava\poms\dnsjava-2.0.5.pom has been created by me
stage\junit\poms\junit-3.8.1.pom has been downloaded from central.
stage\log4j\poms\log4j-1.2.14.pom has been downloaded from central.
I think we can assume that log4j and commmons-cli have been created by
ASF committers and even if they don't include a license header they are
intended under the ALv2 by their respective projects, but this is not clear.
The main issue is the junit pom: it doesn't contain a license header and
is not from ASF, and AFAIK there is nothing in the process to upload a
file to central that make it clear that the file will have to be
redistributable and compatible with given licenses. Once it is clear
this we will also know whether we can include it in our distribution or
we can only use it via remote download by maven or we can't do anything
with it.
For jSieve you found that we had false dependencies and worked out a
good solution that allowed us to remove the whole stage folder (that I
repeat we simply introduced to satisfy a request by Noel to not use
remote repositories to retrieve dependencies during a build). I'm not
sure this can be done for jSPF.
I can raise the issue again on legal discuss but I don't think it is
good to stop releasing because of this issue while all of other PMC are
releasing.
the members delegate supervision of each project to it's PMC. the
JAMES PPMC is responsible for it's releases. in addition, i'm unaware
of any other projects that ship staging repositories in the way that
JAMES does.
I thought the problem is the unknown license for poms in the central
repository for maven. MOST m2 based ASF projects declare dependencies on
poms that have no license on central and during the build this very poms
are automatically download (without user notice) and used for the
building process. I thought that this is not allowed if you don't know
what the license/copyright for that files is and because there is no
policy declared by "central" on what people can do with what they
download from that server.
We also include them in the package, but I think this is a secondary
issue: first it should be made clear what people can do with that files,
don't you think?
Given the current answers we have on the topic I'm not even
sure that the jSieve solution is ok: is it ok for an ASF product to
require remote inclusion of artifacts (POM/metadata) under an unknown
license?
distributing documents of unknown provenance within a release is
clearly and simply unacceptable
jsieve does not do this. a user may download temporary POMs without
licenses but maven does this all the time anyway. jsieve has an ant
build and anyone who wants to avoid this problem can use that instead.
You are right on jSieve. But I'm interested in the generic maven
solution: most ASF projects make use of poms from central. MANY poms in
central have unknown procenance. I think this is an issue the board
should take care of, because PPMCs don't seem to give enough importance
to this, RIGHT?
I don't understand why most policy/legal issues are raised when JAMES
PMC makes a release (and we only do 1 release per year) while other PMCs
release daily under the "same rules" and they are not vetoed.
Either the ASF board take a position on the maven repository poms/xmls
or IMHO we can *temporarily* ignore the issue as everyone else is doing.
i'm on the legal committee so that's hard for me to ignore the issue
This is very good that you are in the legal committee. Please help us
having a definitive answer (and publish them in some ASF policy page) on
the questions:
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200710.mbox/[EMAIL
PROTECTED]
This will help a lot.
Maybe you, Noel, Danny or other more experienced ASF members are more
entitled in understanding the entity of this issue and ask the Board to
take this issue into consideration and give us an answer about what to do.
no experience is requried to take this to the board, anyone on the
PPMC can do ot. indeed, it would probably be better if you did it.
I did this with repository and legal-discuss and I had no answer. I
understood that the PMC Chair is the best candidate to bring issues to
the Board. I'll make sure (by pinging Danny) that this issue is included
in our next report. OK?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
