Phil Steitz wrote:
On Feb 2, 2008 3:44 PM, Dennis Lundberg <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED],
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 [EMAIL PROTECTED]
, [EMAIL PROTECTED] and [EMAIL PROTECTED] I'm cross-
posting to [EMAIL PROTECTED], 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 [EMAIL PROTECTED], 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
[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
