www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: POM licensing
Date Tue, 02 Oct 2007 08:12:08 GMT
Daniel Kulp ha scritto:
> Well, I'm not so sure a "released" pom is considered source.   There was 
> a discussion about something similar in Geronimo in regards to the Sun 
> schemas.   Are they source or more of a binary "contract" and not source 
> that a user would/should be interested in modifying.   
> 
> In the poms case, the release plugin does modify them.  Thus, are they 
> considered "generated artifacts"?   Generated artifacts could fall into 
> Category B.

Some of the poms submitted have been written from scratch by the
submitter and not generated, so (at least in this case) they are sources.

>> - What do we do with non-ASL projects? e.g: javamail is distributed
>> under the CDDL, on the java.net repository they publish their own
>> artifacts and their own poms. The poms do not include any header, so
>> we cannot simply take it and publish it in central and we cannot use
>> it directly because it does not contains license header.
> 
> Well.   Technically we COULD write our own poms from scratch and submit 
> them (and the jar) to central.   The CDDL does permit that.   (The older 
> BCL would not)   Definitely a pain to do though.

We definitely have to deal with this some way: having a repository is
cool, but if we don't fix the legal issue it will only be a big flop.

>> Should we 
>> write our own descriptors for this artifacts? Wouldn't be a source of
>> confusion if we publish on central poms declaring the same
>> artifactId/groupid of the one published on java.net but including
>> different informations?
> 
> That has already happened.   :-(
> http://repo1.maven.org/maven2/javax/xml/soap/saaj-api/1.3/
> http://download.java.net/maven/1/javax.xml.soap/poms/
> 
> The one on central is more useful for remote-resources (has the license 
> information, name, url, etc....) but has a dependency to an artifact not 
> at central.   The one at java.net has resolvable dependencies, but not 
> any of the rest of the useful info.

So if I checkout and build a maven project that does not include a
reference to java.net my installed saaj-api will require
activation:activation:1.0.2 also when I will try to build the project
having java.net in the repositories (the first I checkout and build will
change the behaviour of the other). Very bad :-(

Stefano


Mime
View raw message