commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <>
Subject Re: apache commons-* -sources.jar
Date Sat, 02 Feb 2008 23:21:38 GMT
Phil Steitz wrote:
> On Feb 2, 2008 3:44 PM, Dennis Lundberg <> 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,
>>>> 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 mailing
>>>> list, since the Commons PMC is responsible for whatever is released
>>>> for that project.  The thread has been cross-posted between
>>>> , and  I'm cross-
>>>> posting to, 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
>>>>  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:
> For additional commands, e-mail:

Dennis Lundberg

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message