On Wed, Apr 21, 2004 at 02:02:20PM +0200, Leo Simons wrote:
>...
> Greg Stein wrote:
> > On Wed, Apr 21, 2004 at 02:51:37AM +0200, Stephen McConnell wrote:
> >
> >>OK - given the qualification of intent based on the posts to this thread
> >>it seems to me that the PMC is being presented with a choice:
> >>
> >> 1. Move Fortress/ECM to Codehaus
> >> 2. Keep it here at Apache
> >
> > You didn't break this one down into:
> >
> > 2a. Keep it here at Apache Avalon
> > 2b. Keep it at Apache, but as part of another project
> >
> > I think the outcomes of those two sub-options are very different, and need
> > to be examined independently (rather than as one hunk in your response).
>
> Before writing our proposal, we did consider option 2b in detail (and
> 2a, and many others). As a group, we had mixed feelings on what the
> direction should be, but the direction indicated in our letter in the
> end received consensus.
It was unclear what the "direction" was, as the original letter stated a
transfer "to us" without really specifying whether that was "us at the
ASF" or "us somewhere else."
> As for the background rationale, I can only speak for myself there. I'll
Understood.
>...
> Avalon needs to survive as a healthy ASF project. Moreover, the ASF
> needs to take steps to ensure not only Avalon, but the range of wider
> projects related to Avalon prosper too.
Agreed.
> I fear that, by letting Fortress and ECM stay at the ASF, we will be
> less successful at achieving those things.
I don't know that "stay at the ASF" follows. "Stay in Avalon", and yah:
I'd agree with you.
>...
> There is, community-wise, a complex legacy here. Keeping this codebase
Heh. I'm quite familiar with it, yes.
> at the ASF as a new project will keep around that legacy, and I
> personally dread all the communication overhead ("when the shit hits the
> fan", "with my asbesto suit on") that I know I will put in from the
> feeling of responsibility towards the ASF to make such a new project a
> success. I have run around with similar negative feelings for the better
> part of two years (those people around here that know me a little will
> know I have a "thin skin"), to the point of desparation.
I'm unclear how this follows. Staying at the ASF as a new project is quite
independent of Avalon. There wouldn't be any "overhead" with respect to
maintaining ties with Avalon -- you'd be quite free to simply not worry
about that. With regards to "ASF overhead", I tend to believe that is
rather minimal (tho I'm obviously biased).
> I have tried this path path (option 2 and its permutations) a few times
> too often, and as much as it saddens me, it really no longer is an
> option for me personally, sorry.
Hm? I could see that you pursued it as a *sub*project of Avalon, but I
know it hasn't been pursued as a competitive TLP to Avalon. That's never
come before the Board.
>...
> > Also note that moving the code to Codehaus means that it cannot use the
> > org.apache namespace. Forking the code is fine, but non-ASF code cannot
> > use our namespace
>
> Can you explain why not?
The org.apache namespace is "owned" by the ASF. Simple as that. Projects
outside of the ASF cannot use the namespace because that would defeat the
whole purpose -- naming without fear of collision. Should we allow just
any project out there to use our namespace at their leisure? Can the ASF
start implementing things as com.sun.* or java.* ? Nope. We follow the
"rules" of namespace ownership.
Even though the code may have originated at the ASF, once it gets forked
to an external project, it is *not* the ASF's code, so it cannot use the
same namespace.
[ and yes, I do recognize the problem that creates for compatibility ]
> > (or more precisely, it *can* since we certainly can't
> > control it, but we'd be extremely and vocally peeved about it :-).
>
> Why would anyone be peeved?
How about if I started writing code in the org.jicarilla.* namespace?
Wouldn't that peeve you? There are "rules" about what naming you can use
for the software "you" write.
My comment above was essentially saying, "there isn't a way to *enforce*
the naming rules -- all that is left is the court of public opinion." IOW,
if somebody "invaded" the ASF's namespace, then the best the ASF could do
would be to be quite vocal about the infraction.
> When it comes to java software, this comes down to saying "no non-ASF
> project is allowed to be binary compatible with an ASF project or at
> least we'd "be extremely and vocally peeved about it".
Well, I know what you're saying, and the short answer is "yah". But then
again, you *can* be compatible if the ASF published specific interfaces
and your external project implemented those interfaces.
>...
> This example, is, of course, not completely fictional. Apache-SSL has
> peacefully (as far as I know, at least?) existed side by side with
> Apache-HTTPD for years now, and even uses the apache name (obviously)
> and marks (the feather). Why is there no issue there, but an issue here?
It is a simple derivative of HTTPD. Some patches applied, packaged up, and
redistributed. It is not a true fork of the project. Further, the Java
namespace rules don't apply. If the derivative published libraries that
were named the same as the original ASF httpd, then we'd have issues. And
the use of the marks have been (presumably) sanctioned by the ASF Board (I
don't recall offhand and would need to check the records).
> We're not asking for anything like that. We explicitly do not want to
> use the apache name or the avalon name for anything else than providing
> binary compatibility. I can't see how this makes anyone extremely peeved.
See above for what I mean by "peeved"; I was merely referring to external
projects publishing under the name org.apache.*. The ASF would certainly
not be peeved about other projects being compat or forking ASF code. (as
long as it obeyed the license and our package namespace)
> Another analogy closer to home might be the javax.* namespace. The ASF
> distributes and is allowed to distribute several packages in the javax
> namespace, even with java being a trademark of Sun that it needs to
> aggressively protect. I'll assume that at least part of the reason to
> allow this is to allow the ASF to provide binary compatibility with
> sun-provided packages. And I'll assert that making this allowance is in
> the best interests of Sun.
I'm not entirely clear what rules Sun has imposed on the javax.*
namespace. I'd hard for me to respond to this, and whether the analogy
holds well.
> I understand that Avalon and the ASF need to protect their name and
> interests. But I sincerely believe that, in this case, our proposal is
> in the best interests of avalon and the wider apache community.
I think that splitting Excalibur/Fortress out of Avalon would be a good
thing [for Avalon]. Moving it out of the ASF would pose certain problems
which might not be in the ASF's (and its user base) best interest.
> Finally, rest assured that we will not use the org.apache namespace if
> the ASF really does not wish it. We're not trying to get anyone all
> vocally peeved about anything.
See above :-)
With regards to moving the codebases outside of Apache: the option of a
true fork is always present, but the namespace issue makes this a bit
difficult for Java. With regards to explicit permission, I don't know that
the Board would be willing to start granting external groups a waiver to
use our namespace. The ASF is also (simply) unable to transfer full rights
and ownership to external entities unless that entity is a non-profit.
Cheers,
-g
--
[EMAIL PROTECTED] ... ASF Chairman ... http://www.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
