commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <denn...@apache.org>
Subject Re: apache commons-* -sources.jar
Date Sat, 02 Feb 2008 22:44:10 GMT
simon wrote:
> 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.

I agree. These are not *new* releases. The -sources jars should follow 
the policy and license that were current when the original release was made.

> 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

-- 
Dennis Lundberg

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


Mime
View raw message