commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From simon <simon.kitch...@chello.at>
Subject Re: apache commons-* -sources.jar
Date Sat, 02 Feb 2008 22:23:47 GMT

On Sat, 2008-02-02 at 15:25 -0600, Curt Arnold wrote:
> On Feb 2, 2008, at 2:08 PM, nicolas de loof wrote:
> on repository@apache.org, http://mail-archives.apache.org/mod_mbox/www-repository/200802.mbox/thread
> 
> LICENSE, NOTICE and other *.txt files (release note, readme ...) have  
> been added at jar root.
> > I can rebuild the jars with those files in META-INF if required.
> >
> > The script was not designed for reproductibility but to avoid  
> > manually browse on repo, download, unzip and so on..
> >
> > Here is the code. It is not portable (based on my computer path and  
> > tools) and produces on System.out DOS commands to get executed. Some  
> > downloaded artifacts also required some folder name fix as they  
> > didn't follow other commons-* conventions.
> >
> > I'm OK to publish it under Apache license ;-)
> 
> 
> This discussion should move to the dev@commons.apache.org mailing  
> list, since the Commons PMC is responsible for whatever is released  
> for that project.  The thread has been cross-posted between repository@apache.org 
> , pmc@commons.apache.org and dev@commons.apache.org.  I'm cross- 
> posting to repository@apache.org, but this should be the last post on  
> that list until the issue is resolved in the commons PMC.
> 
> The one -sources.jar that I looked at commons-beanutil-1.6-sources.jar  
> did not have a NOTICE file anywhere in the release.  It did have a  
> LICENSE.txt in the root directory, but that was a ASL 1.1, not ASL 2.0.
> 
> In addition, the source files in that release do not adhere to the ASF  
> Source Header and Copyright Notice Policy to which all ASF releases  
> created after November 1. 2006 must comply.
> 
> As such, the sources.jar would not be acceptable in a new release.  I  
> don't think that there would be an exception for a new repackaging of  
> a prior release, but I'd like to see that checked against legal- 
> discuss or board@apache, but that is the Commons PMC's responsibility.
> 
> My take would be:
> 
> a) A sources repackaging of a commons release that adheres to the ASF  
> Source Header Policy is achievable.  I'd prefer to see it done with  
> something much more portable (Apache Ant would be my choice).  There  
> should be some automated check for proper Source Headers and presence  
> of NOTICE and LICENSE.  The artifacts should be posted (as the current  
> ones have been) and a formal vote called on the  
> dev@commons.apache.org.  After a successful conclusion of that vote  
> (72 hours elapsed, 3 +1's from PMC members, et al), then the  
> candidates could be copied to the rsync master.
> 
> b) Releases that predate or otherwise don't adhere to the ASF Source  
> Header Policy should not have retroactive sources.jar releases.  You  
> can't change the source to change the notice and still be consistent  
> with the previous release and you can't release anything new (at least  
> in my opinion) that does not conform to the current ASF release  
> policies.  If you really want to get the sources to a project that has  
> non-conforming source code, then you should do the sources.jar as part  
> of a new complete release even if the only change is the source  
> headers.  Again that should be subject to a standard release vote.

I think all this legalese stuff is rather excessive.

All these files already have binary releases that do have valid
copyright and notice statements in them. These source jars are only for
the convenience of people using IDEs.

Each source file has an appropriate header on it, and if people have any
further questions about the licensing of the source they see, then
either the binary or the svn repository has the correct answer.

Remember that in the absence of a license to redistribute, people do NOT
have the right to redistribute. So we are not turning these files into
public domain even if no license is provided at all.

The only question I see is whether the source is *right*. It would be
rather embarrassing to publish source that does not quite match the
binary, so a second check on these is probably a good idea. But even
then it isn't fatal; changing a binary once it has been published in a
maven repository is a really bad idea because it makes builds
unrepeatable. However changing the source is not such a big issue, and
could be fixed after the fact if necessary.

Nicolas is right that this would be a nice service to some Apache
software users. It's not a big thing because these releases that are
being fixed are all old ones (we have our act together now) but it's
still nice to do. Let's not make this harder than it needs to be.

And anyway, if notice/license is to be put in these source jars I would
just take it from the equivalent binary jar's META-INF directory. If the
project was originally published under ASF1.1, it seems right to me that
the same license should be attached to the source jar.

So unless there is an official statement from the board, or a qualified
lawyer says this is wrong, I'm +1 on releasing these sources jars, but
suggest that people be given a few days to check that they have the
right contents first.

Regards,

Simon


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


Mime
View raw message