incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <>
Subject Re: SVN move
Date Sat, 26 Jul 2008 17:55:19 GMT
Hi Alan,

see my 0.02€ below...

Alan D. Cabrera wrote:
> On Jul 25, 2008, at 8:50 PM, William A. Rowe, Jr. wrote:
>> Alan D. Cabrera wrote:
>>> On Jul 25, 2008, at 7:38 PM, Craig L Russell wrote:
>>>> Hi Alan,
>>>> On Jul 25, 2008, at 3:31 PM, Alan D. Cabrera wrote:
>>>>> Some things to consider in this discussion:
>>>>> - The 0.9.0 release cannot be performed off of the copy in ASF
>>>>> - The 0.9.0 or earlier releases cannot be supported off of the copy 
>>>>> in ASF
>>>>> Maybe that's what everyone is thinking.  I just want to make sure 
>>>>> that it's clear.
>>>> I don't agree with either of the above opinions. We don't restrict 
>>>> what people do with Apache code.

+1, except for the minimal restrictions stated in the AL 2.0.

>>>> I don't see anything wrong with publishing a release off the 
>>>> artifacts stored in Apache. It cannot be called "an Apache 
>>>> incubating release" but it can certainly be called JSecurity 0.9 
>>>> whatever.
>>>> Follow-on releases can similarly be built from code checked into the 
>>>> Apache repository. They just cannot be called "Apache anything". And 
>>>> if they're published in the download area they can be 
>>>> maintained in the Apache repository.

The last sentence confused me a bit. Whether or not a code branch
is maintained in the Apache repo does not depend on where exactly
releases are published. Non-Apache releases are not published from
Apache servers. Code can be maintained in the Apache repo without
being Apache-released: sandboxes, experimental branches,...

>> Understand that it's not Apache Foo x.x.x, and that the ASF
>> doesn't publish or take account for the contents of such an external
>> package.
>> Which effectively means the committer (or their employer if they are
>> acting on the behalf of such) is assuming all responsibilities for such
>> a package.  This is usually not the sort of personal responsibility an
>> individual desires, so it would probably make more sense to resolve the
>> issues at the project and vote on an ASF release.

It's not an Apache release, so it doesn't matter what
Apache hats the individual(s) could wear around here.

>> The act of a tag-tar-vote-release at the ASF is an act of the foundation
>> (as long as the RM/PMC follows the whole process) so it is a shield, of
>> sorts.  If the RM and project acts in good faith, the ASF backs the
>> release and is a much more public face to settle any later disputes.
> Not that I believe that it will happen in the case of the JSecurity 
> project but, does this not mean that the "original" project can continue 
> for a potentially long time to develop their own releases off of the ASF 
> repo?  That's ok?

Yes, and why shouldn't it be? Anybody can pull Apache sources from
our public SVN repo and make releases with or without modifications
under any license that is compatible with the AL 2.0. As long as they
don't claim to do an Apache release. "Anybody" includes individuals
that happen to be ASF committers.

> What if the license for those releases was incompatible w/ AL2.0?

That would be a show stopper. The code pulled from the ASF repo
is licensed as AL 2.0 (with few exceptions), even if there are
pre-Apache copies available under an incompatible license.

It is the responsibility of the people making the release to
ensure that they obey all licensing requirements of the code
they put into their release packages. The ASF has established
processes to do that for Apache releases. How non-Apache
releases are done is not our concern. If we learn about
licensing violations, we will contact the responsible people
to resolve the issue in good faith.

> What if there was absolutely no community involvement for those branches 
> and their releases?

Only Apache committers can create branches in the Apache repo.
This is typically done for Apache releases and not for anybody
outside who wants to do a non-Apache release. But in the end,
it is the decision of the (P)PMC whether to branch code or not.
In your real case, I don't see a problem. In your hypothetical
case, I'd say that the PMC shouldn't allow a new branch.
That doesn't prevent anyone from pulling a specific revision
out of the Apache repo and making a non-Apache release off that.

hope that helps,

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

View raw message