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: pass (athena.apache.org: domain of phil.steitz@gmail.com
 designates 64.233.166.183 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=GvNxxCKVb9VF1HDEDbmBRl7iUf2duZYcY03KyDLnjZ7RsZsHtzRskA7i2bsEagpXHFuFoQahrZCHYHomoI4jjxxaKmF8VCr60tInWuEbs+w7jgOvt6PAGlcD606+AI0ilPfJHuSmruuK+EKT3Duh0ejxKKBtBZ89JEIKRXtwaWw=
Message-ID: <8a81b4af0802021509m1332f609g4dd52be9ee2f83aa@mail.gmail.com>
Date: Sat, 2 Feb 2008 16:09:44 -0700
From: "Phil Steitz" <phil.steitz@gmail.com>
To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Subject: Re: apache commons-* -sources.jar
In-Reply-To: <47A4F23A.3020907@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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>

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.

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?

Phil

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