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 jsecurity.org 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.
s/committer/individual/
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,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
