Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <47A4FB02.2060008@apache.org>
Date: Sun, 03 Feb 2008 00:21:38 +0100
From: Dennis Lundberg <dennisl@apache.org>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Jakarta Commons Developers List <dev@commons.apache.org>
Subject: Re: apache commons-* -sources.jar
References: <4c39e3030802010129q954f9a2n3d73a4274fd705e1@mail.gmail.com>
	 <4c39e3030802011209j2c343980rfbb462de5673211e@mail.gmail.com>
	 <95EAB197-13DB-44E3-8149-50079F42FA70@apache.org>
	 <4c39e3030802020156k6ff9a1eakd823492bfcb493da@mail.gmail.com>
	 <E3F3CF6F-E9AD-4AF0-8806-575B1B7A560B@apache.org>
	 <4c39e3030802021208k6c190f3bu97d93db52905f6bc@mail.gmail.com>
	 <83125914-F43A-4F54-A6BA-7003CFE368C8@apache.org>
	 <1201991027.6171.16.camel@simon-laptop> <47A4F23A.3020907@apache.org>
 <8a81b4af0802021509m1332f609g4dd52be9ee2f83aa@mail.gmail.com>
In-Reply-To: <8a81b4af0802021509m1332f609g4dd52be9ee2f83aa@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Phil Steitz wrote:
> On Feb 2, 2008 3:44 PM, Dennis Lundberg <dennisl@apache.org> wrote:
>> 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.
>>>
> 
> First we have to decide whether this maven repo pushing business
> constititutes a release.  If its us (i.e. ASF and not some third party
> package-maker) who is doing the publication, then I think it does.
> This means we have to VOTE before we do anything.
> 
> I will vote -1 for anything new that we release that does not include
> NOTICE and LICENSE as part of the distribution.  I view source
> distributions as equally - in fact more - important than binaries,
> which are really just a convenience for users, so re-releasing sources
> needs to be done carefully.  This is not legalese, it is appropriate
> PMC oversight and release management.

Yes, the re-packaged jar file must follow the same rules as the original 
zip file. These files must all be checked by the PMC. A vote before they 
are published seems reasonable.

> Given the hassle of doing this, committing whatever is necessary to
> reproduce the new source releases, review and vote on them, etc; might
> it be better to just publish a script or instructions somewhere on how
> to make an IDE/maven-lovable sources jars from a commons source zip or
> tarball?  That way users could create these themselves from the actual
> source distributions.  Is that unreasonable?

Yes, I think it is unreasonable. Publishing -sources jars to the central 
repository is so that users don't have to do this packaging themselves.

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


-- 
Dennis Lundberg

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