You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by "William A. Rowe Jr." <wr...@rowe-clan.net> on 2012/01/03 18:35:34 UTC
Q. Forks without concensus?; A. anytime / depends / never without
agreement
On 1/3/2012 11:14 AM, Greg Stein wrote:
> On Jan 3, 2012 11:48 AM, "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
>> ...
>>>> A PMC I am on had this exact conversation with board members several
>>>> months ago regarding a code base the project is dependent on that is housed
>>>> outside the ASF which we were considering bringing in as a subproject. We
>>>> were told that under no circumstances could we fork the code without the
>>>> "owner's" blessing, regardless of what the license allowed us to do. To me,
>>>> this answer is black and white.
>>>
>>> Not to me. :-)
>>
>> Which is the problem, isn't it? Note; hat switch, you are now speaking
>> with the authority of a Director.
>
> Euh, nope. Offering my personal opinions. A Director hat would (and does)
> mean nothing since I could not speak for the Board.
So this is a question that should be put to bed once and for all, you have
both been swinging pretty wildly at diametrically opposed answers to this
question.
If we read that the Board has charged this committee with acceptance criteria
for submitted or proposed products... then the question above should be
resolved.
Essentially, we have several choices...
[ ] Forks are accepted without judgement [Greg] [1]
[ ] [something more nuanced here]
[ ] Hostile forks are never acceptable [Roy] [2]
If the answer lies somewhere in the middle, it would help potential
contributors/forkers to know approximately where that middle sits.
[1] "I don't see it as our place to *judge* communities. If it is a fork,
or a corporate spin-out, or a move, or brand new... All Good. "
[2] "At Apache, all contributions are voluntary. We do not accept code
from copyright owners who don't want us to have it, even if we have
the legal right to adopt it for other reasons.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without
agreement
Posted by "William A. Rowe Jr." <wm...@gmail.com>.
On 1/3/2012 11:43 AM, Benson Margulies wrote:
>
> I don't understand the purpose of a vote here. Roy has stated rather
> firmly that [2] is settled foundation policy.
Pointer to where that policy was established, or it didn't happen.
It might have been a consensus relative to some specific incident
or issue that arose, but only resolutions carry weight, as Greg
rightly points out.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
Posted by Karl Wright <da...@gmail.com>.
Any time a body of code is contributed from another source, it should
go through the standard Apache procedures, including a license grant
(if it's not open-source already). But this is very different from
spinning off chunks of an existing incubator project.
For example, ManifoldCF is currently attempting to spin off three
subprojects. Each of the subprojects is more tightly related in some
way to other projects than it is to ManifoldCF itself, and in an ideal
world these other projects would incorporate the subproject code
themselves. Unfortunately, in two of the cases (plugins for two
versions of Lucene/Solr) the project has refused to include the code,
and in another case (a SharePoint plugin) the main "project" is not
open-sourced in the first place.
I would hope that there would be enough flexibility in the incubator
model to permit this kind of thing. Just my two cents, nonbinding...
Karl
On Tue, Jan 3, 2012 at 1:16 PM, Donald Whytock <dw...@gmail.com> wrote:
> It occurs to me that the ASF, in enforcing open-source licensing,
> becomes a source of free legal advice to the open-source community,
> whether it intends to or not...
>
> 1. Contribute a body of code to ASF.
>
> 2. "Is it legal for us to accept this? Better run it past legal@."
>
> 3. Use acceptance of the contribution as certification that it can be
> used by the contributor.
>
> Just sayin'. Not sure if this is a good thing or a bad thing.
>
> Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without
agreement
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 1/3/2012 12:51 PM, Sam Ruby wrote:
> On Tue, Jan 3, 2012 at 1:28 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> On Tue, Jan 3, 2012 at 9:57 AM, Leo Simons <ma...@leosimons.com> wrote:
>>> So the generic policy is there is no generic policy, and instead there
>>> is appropriate application of judgement to specific cases.
>>
>> Generic policy doesn't mean you couldn't use judgement or make
>> exceptions. In principle, if the ASF's mission is to build communities
>> around source code, we should not accept forks of open source projects
>> if that's not the (consensus) will of the original community.
>
> I agree with the first statement in the above paragraph, and believe
> that it potentially leads to a different conclusion than the final
> sentence in that same paragraph.
+1. I would suggest we would avoid encouraging forks of open source
projects if that isn't the last remaining alternative to allow both
groups of contributors to move forward.
A fork is a social artifact more than a code assembly artifact.
> We have had unfriendly forks within the ASF. We have had instances
> where the original community has disappeared later to return and
> attempt to reclaim ultimate direction for a project. We've even had
> destructive forks where both the fork and the original community ended
> up failing.
Good points.
> We can, and should, make a decision based on the specifics of the
> community in question, and informed by our past experiences -- both
> successes and failures.
Or to quote the cited logic behind "we accept voluntary contributions
only", let's look at a genesis of that statement circa 1999;
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Group and was originally based
* on public domain software written at the National Center for
* Supercomputing Applications, University of Illinois, Urbana-Champaign.
Which devolves to;
1. many individuals made voluntary contributions *on behalf of Apache*
2. this does not deny some contributions made externally (not on behalf
of Apache) were not also incorporated (I'd speculate that some were
likely adopted, say patches in BSD or similar)
3. this work is originally written somewhere else and not a voluntary
contribution on behalf of the Apache Group whatsoever, but published
as-is into the commons.
The genesis of Apache is a fork. Not a hostile fork, but a fork of an
effectively abandoned work. It's possible to read the statement above
that all contributions are directly offered to Apache, but that really
isn't what it said.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
Posted by Sam Ruby <ru...@intertwingly.net>.
On Tue, Jan 3, 2012 at 1:28 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> On Tue, Jan 3, 2012 at 9:57 AM, Leo Simons <ma...@leosimons.com> wrote:
>> So the generic policy is there is no generic policy, and instead there
>> is appropriate application of judgement to specific cases.
>
> Generic policy doesn't mean you couldn't use judgement or make
> exceptions. In principle, if the ASF's mission is to build communities
> around source code, we should not accept forks of open source projects
> if that's not the (consensus) will of the original community.
I agree with the first statement in the above paragraph, and believe
that it potentially leads to a different conclusion than the final
sentence in that same paragraph.
We have had unfriendly forks within the ASF. We have had instances
where the original community has disappeared later to return and
attempt to reclaim ultimate direction for a project. We've even had
destructive forks where both the fork and the original community ended
up failing.
We can, and should, make a decision based on the specifics of the
community in question, and informed by our past experiences -- both
successes and failures.
> Kalle
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
Posted by Kalle Korhonen <ka...@gmail.com>.
On Tue, Jan 3, 2012 at 10:33 AM, Greg Stein <gs...@gmail.com> wrote:
> On Jan 3, 2012 1:28 PM, "Kalle Korhonen" <ka...@gmail.com> wrote:
>> On Tue, Jan 3, 2012 at 9:57 AM, Leo Simons <ma...@leosimons.com> wrote:
>> > So the generic policy is there is no generic policy, and instead there
>> > is appropriate application of judgement to specific cases.
>> Generic policy doesn't mean you couldn't use judgement or make
>> exceptions. In principle, if the ASF's mission is to build communities
>> around source code, we should not accept forks of open source projects
>> if that's not the (consensus) will of the original community.
> And what happens when the arriving community has a different vision than
> the original community? Do you tell them to go pound sand? Tell them the
> two communities are not allowed to diverge or separate?
You tell the arriving community that you need to work with the
original community and that forking an existing open source project
with an existing community is your last option, not your first one. I
think it's just plain common sense that you have to be respectful of
others, just like in the real world. Specifically regarding
Bloodhound, much of the issues would likely have been avoided if the
proposal hadn't dismissed the original community and hadn't stated as
its primary intention to fork the existing Trac project (see quotes
below). If the stated goal had been to provide a packager and
installers and work closely with the existing community, I bet the
tone of all stakeholders would have been very different.
Kalle
---
>From the proposal:
"By it's own recognition, however, the development community
surrounding Trac has largely dissipated."
"As discussed earlier, the current Trac development community is small
and reluctant to accept outside contributions."
"Given the Foundation’s
reputation for building and maintaining communities, we feel a new
project, based on Trac but incubated under the Apache umbrella, would
help re-build the developer community, jump started by developer time
donated by WANdisco."
"The initial goals for Bloodhound primarily revolve around migrating
the existing code base and integrating external features to make the
project easy to deploy."
"Some of the initial goals include:
* Migrate the existing BSD-licensed Trac code base to the ASF."
>
> Cheers,
> -g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
Posted by Greg Stein <gs...@gmail.com>.
On Jan 3, 2012 1:28 PM, "Kalle Korhonen" <ka...@gmail.com> wrote:
>
> On Tue, Jan 3, 2012 at 9:57 AM, Leo Simons <ma...@leosimons.com> wrote:
> > So the generic policy is there is no generic policy, and instead there
> > is appropriate application of judgement to specific cases.
>
> Generic policy doesn't mean you couldn't use judgement or make
> exceptions. In principle, if the ASF's mission is to build communities
> around source code, we should not accept forks of open source projects
> if that's not the (consensus) will of the original community.
And what happens when the arriving community has a different vision than
the original community? Do you tell them to go pound sand? Tell them the
two communities are not allowed to diverge or separate?
Cheers,
-g
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
Posted by Kalle Korhonen <ka...@gmail.com>.
On Tue, Jan 3, 2012 at 9:57 AM, Leo Simons <ma...@leosimons.com> wrote:
> So the generic policy is there is no generic policy, and instead there
> is appropriate application of judgement to specific cases.
Generic policy doesn't mean you couldn't use judgement or make
exceptions. In principle, if the ASF's mission is to build communities
around source code, we should not accept forks of open source projects
if that's not the (consensus) will of the original community.
Kalle
On Tue, Jan 3, 2012 at 10:16 AM, Donald Whytock <dw...@gmail.com> wrote:
> It occurs to me that the ASF, in enforcing open-source licensing,
> becomes a source of free legal advice to the open-source community,
> whether it intends to or not...
>
> 1. Contribute a body of code to ASF.
>
> 2. "Is it legal for us to accept this? Better run it past legal@."
>
> 3. Use acceptance of the contribution as certification that it can be
> used by the contributor.
>
> Just sayin'. Not sure if this is a good thing or a bad thing.
>
> Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
Posted by Donald Whytock <dw...@gmail.com>.
It occurs to me that the ASF, in enforcing open-source licensing,
becomes a source of free legal advice to the open-source community,
whether it intends to or not...
1. Contribute a body of code to ASF.
2. "Is it legal for us to accept this? Better run it past legal@."
3. Use acceptance of the contribution as certification that it can be
used by the contributor.
Just sayin'. Not sure if this is a good thing or a bad thing.
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without
agreement
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 1/3/2012 11:43 AM, Benson Margulies wrote:
>
> Would some please clarify is this is *truly* a hostile fork?
Wrong thread, see Subject: above. Thx.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
Posted by Benson Margulies <bi...@gmail.com>.
> [ ] Forks are accepted without judgement [Greg] [1]
>
> [ ] [something more nuanced here]
>
> [X ] Hostile forks are never acceptable [Roy] [2]
I don't understand the purpose of a vote here. Roy has stated rather
firmly that [2] is settled foundation policy. So, if someone wants to
reopen that question, don't we need to go to the board for a vote?
It's not an incubator issue, it's a contribution issue. Someone is
proposing to check into svn code that fails the 'voluntary' test.
Would some please clarify is this is *truly* a hostile fork? Is the
copyright holder willing to grant, or not? That is, I claimed, a
different question from 'there is a lack of consensus in the
development community for a fork at Apache.'
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Jan 3, 2012 at 15:13, ralph.goers @dslextreme.com
<ra...@dslextreme.com> wrote:
> On Tue, Jan 3, 2012 at 11:46 AM, Doug Cutting <cu...@apache.org> wrote:
>
>> On 01/03/2012 07:35 AM, William A. Rowe Jr. wrote:
>> > [1] "I don't see it as our place to *judge* communities. If it is a fork,
>> > or a corporate spin-out, or a move, or brand new... All Good. "
>> >
>> > [2] "At Apache, all contributions are voluntary. We do not accept code
>> > from copyright owners who don't want us to have it, even if we have
>> > the legal right to adopt it for other reasons.
>>
>> These aren't necessarily contradictory. At least part of what Roy's
>> saying is that if someone doesn't intend to distribute their software
>> under the Apache license then we should not take it. But I think if
>> someone's clearly established their intent to publish a body of software
>> under the Apache license and a new community forms around that software
>> that's distinct from its original authors, then we can consider housing
>> that community.
>
>
> In the case Roy made the comment I quoted on, the code had been distributed
> under the Apache License. The license was being changed to Eclipse. We
> asked whether the Apache Licensed version could be brought into the ASF.
> The answer was effectively, not without the owner's permission. I don't
> have a problem with that answer. I also don't have a problem with your
> answer above. I do have a problem giving a different answer based on who
> the involved parties are.
I doubt that it depends on where/what the software is coming from.
You're just getting different answers from different people :-P
(for the record: I'd have no problem if an Apache community grabbed a
copy of software before it changed its license; of course, also
assuming the community was willing to take on the development,
maintenance, etc of that software)
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
Posted by "ralph.goers @dslextreme.com" <ra...@dslextreme.com>.
On Tue, Jan 3, 2012 at 11:46 AM, Doug Cutting <cu...@apache.org> wrote:
> On 01/03/2012 07:35 AM, William A. Rowe Jr. wrote:
> > [1] "I don't see it as our place to *judge* communities. If it is a fork,
> > or a corporate spin-out, or a move, or brand new... All Good. "
> >
> > [2] "At Apache, all contributions are voluntary. We do not accept code
> > from copyright owners who don't want us to have it, even if we have
> > the legal right to adopt it for other reasons.
>
> These aren't necessarily contradictory. At least part of what Roy's
> saying is that if someone doesn't intend to distribute their software
> under the Apache license then we should not take it. But I think if
> someone's clearly established their intent to publish a body of software
> under the Apache license and a new community forms around that software
> that's distinct from its original authors, then we can consider housing
> that community.
In the case Roy made the comment I quoted on, the code had been distributed
under the Apache License. The license was being changed to Eclipse. We
asked whether the Apache Licensed version could be brought into the ASF.
The answer was effectively, not without the owner's permission. I don't
have a problem with that answer. I also don't have a problem with your
answer above. I do have a problem giving a different answer based on who
the involved parties are.
Ralph
Re: Q. Forks without concensus?; A. anytime / depends / never without
agreement
Posted by Doug Cutting <cu...@apache.org>.
On 01/03/2012 07:35 AM, William A. Rowe Jr. wrote:
> [1] "I don't see it as our place to *judge* communities. If it is a fork,
> or a corporate spin-out, or a move, or brand new... All Good. "
>
> [2] "At Apache, all contributions are voluntary. We do not accept code
> from copyright owners who don't want us to have it, even if we have
> the legal right to adopt it for other reasons.
These aren't necessarily contradictory. At least part of what Roy's
saying is that if someone doesn't intend to distribute their software
under the Apache license then we should not take it. But I think if
someone's clearly established their intent to publish a body of software
under the Apache license and a new community forms around that software
that's distinct from its original authors, then we can consider housing
that community.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
Posted by Leo Simons <ma...@leosimons.com>.
On Sat, Jan 7, 2012 at 10:24 PM, Roy T. Fielding <fi...@gbiv.com> wrote:
> If there is a community
> and that community doesn't want Apache to fork the code that they created,
> then we will not fork that code at Apache. If the original developers of the
> code do not want their license changed, then we will not fork the code at Apache.
> We only accept voluntary contributions (contributions == the stuff we take on as
> change-controller and managed as such by one of our collaborative projects).
> We use other open source code and include that other code in our own releases,
> but we don't take change-control over it without the blessing of the original authors.
[Citation Needed]
While I agree with the general idea, the closest I can find to it
being written down is
http://incubator.apache.org/guides/proposal.html#template-community
which is not very close at all.
Did the subject actually come up before or is this the first time you
wrote this down?
Also, we should consider that the modus operandi of open source is
changing. The default behavior on github for example is to put a "fork
me on github" button on your project website, which doesn't mean a
"community fork", but for the healthier projects it does mean
"community chaos" as forks and pull requests simply happen all over
the place. So the relationship between "take change-control" and
"community fork" is a bit different in those instances. You could say
that the "fork me on github" (or just using github) is in fact
inviting everyone to take as much change control as they want.
cheers,
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
Posted by ant elder <an...@gmail.com>.
On Sat, Jan 7, 2012 at 9:24 PM, Roy T. Fielding <fi...@gbiv.com> wrote:
> The VOTE was based on misleading information. The Incubator PMC should declare it
> void and request a new proposal. The existing Bloodhound podling should be
> placed on hold until this is sorted out.
What is the status of the Bloodhound proposal? Roy has asked for an
updated proposal and re-vote, would that be acceptable?
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jan 11, 2012, at 8:33 PM, Noel J. Bergman wrote:
> Roy T. Fielding wrote:
>
>> Noel J. Bergman wrote:
>>> The ASF is not about code; it is about community. If a community forks,
> or otherwise emerges around a codebase, we are not accepting the CODE: we
> are accepting the COMMUNITY.
>
>> One company is not a community.
>
> As you've otherwise acknowledged, I was talking in the general case, and
> you're addressing a specific instance.
>
>>> And it seems to me that if we are to say that a COMMUNITZY is not
> permitted
>>> to participate despite use of code that is perfectly proper according to
> the
>>> license, then we are beggaring out own license, the whole point of which
> is
>>> to permit forks, and to prevent a sole copyright holder from assuming
> control
>>> over the community.
>
>> If there is no community for the original codebase, yes.
>
> Agreed.
>
>> If there is a community and that community doesn't want Apache to fork the
> code that they created,
>> then we will not fork that code at Apache.
>
> Why not, *IF* there is an active second community that wants to fork?
> Again, in the hypothetical, not in the specific, case, which you say is a
> single vendor, not a community.
Because it is rude to do so.
The second community is welcome to fork their own code and contribute that here.
In some cases, an open community will have joint copyright and some of those
folks can split off and contribute the whole here even if the others don't like it.
But that is a rare case, and I'd suggest we would have to look at it carefully
to avoid being used as someone else's pawn.
>> If the original developers of the code do not want their license changed,
> then we
>> will not fork the code at Apache.
>
> I kind of take that as a given, since how could we fork it if we can't
> relicense it?
We could fork BSD variants without relicensing the files. By forking them
here, we relicense the end product (our releases). We choose to do so as
an Apache fork only when it is desired by the current maintainers of that code.
Otherwise, we make it clear that we are only distributing a copy of their code,
under their original license, and place it in a location for third-party
code (srclib) or have the user download it separately at build time.
>> We only accept voluntary contributions
>
> The presence of a community that wants to work here implies voluntary, and
> not everyone has to agree with the fork. Don't you remember the origins of
> Apache Felix?
By community, I mean the people who have contributed to the work and thus
have a vested interest in its future. Such community members are welcome to
contribute here any work products that they have personally developed or own
copyright to, and any code for which they have an expressed permission from
the copyright owner that it is okay to contribute it here. We also accept,
at face value, files under a compatible license for which the author is no
longer responding to communication, or small subsets of code for which
copying them here has no negative impact on some other community, such as
copying routines out of FreeBSD for use in httpd.
Yes, open source licenses give permission to fork. We try to do no harm
when we fork. It's a philosophy thing that is fairly unique to Apache
because we are so community-centric, but it is not difficult to explain
to others and many open source developers just assume it as a given.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Q. Forks without concensus?; A. anytime / depends / never without agreement
Posted by "Noel J. Bergman" <no...@devtech.com>.
Roy T. Fielding wrote:
> Noel J. Bergman wrote:
> > The ASF is not about code; it is about community. If a community forks,
or otherwise emerges around a codebase, we are not accepting the CODE: we
are accepting the COMMUNITY.
> One company is not a community.
As you've otherwise acknowledged, I was talking in the general case, and
you're addressing a specific instance.
> > And it seems to me that if we are to say that a COMMUNITZY is not
permitted
> > to participate despite use of code that is perfectly proper according to
the
> > license, then we are beggaring out own license, the whole point of which
is
> > to permit forks, and to prevent a sole copyright holder from assuming
control
> > over the community.
> If there is no community for the original codebase, yes.
Agreed.
> If there is a community and that community doesn't want Apache to fork the
code that they created,
> then we will not fork that code at Apache.
Why not, *IF* there is an active second community that wants to fork?
Again, in the hypothetical, not in the specific, case, which you say is a
single vendor, not a community.
> If the original developers of the code do not want their license changed,
then we
> will not fork the code at Apache.
I kind of take that as a given, since how could we fork it if we can't
relicense it?
> We only accept voluntary contributions
The presence of a community that wants to work here implies voluntary, and
not everyone has to agree with the fork. Don't you remember the origins of
Apache Felix?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jan 6, 2012, at 8:17 PM, Noel J. Bergman wrote:
> The ASF is not about code; it is about community. If a community forks, or otherwise emerges around a codebase, we are not accepting the CODE: we are accepting the COMMUNITY.
One company is not a community.
> And it seems to me that if we are to say that a COMMUNITZY is not permitted to participate despite use of code that is perfectly proper according to the license, then we are beggaring out own license, the whole point of which is to permit forks, and to prevent a sole copyright holder from assuming control over the community.
If there is no community for the original codebase, yes. If there is a community
and that community doesn't want Apache to fork the code that they created,
then we will not fork that code at Apache. If the original developers of the
code do not want their license changed, then we will not fork the code at Apache.
We only accept voluntary contributions (contributions == the stuff we take on as
change-controller and managed as such by one of our collaborative projects).
We use other open source code and include that other code in our own releases,
but we don't take change-control over it without the blessing of the original authors.
That does not stop people from forking the code elsewhere, perhaps in-house or at
google code, growing a community over time, and attracting their own community.
> If a corporation were to create an ASF-licensed codebase, and later decide to "take back" control, would we refuse a COMMUNITY-based project based on that codebase?
It depends on where the community wanted to take it.
In this case, which is far more interesting than a theoretical case, a company
with long ties at Apache has decided to fork an existing, community-supported
open source project that is currently under the BSD license, without having
made any significant contributions to that project in the past, and is using
Apache's reputation as an excuse to place themselves in control over this new
"community" at Apache. That is wrong.
The original developers are not ambivalent to this fork. What they told
WANdisco is the same that we would tell them -- the license allows you to
fork the code if you desire to do so. They did not want a fork -- what they
want is for WANdisco to participate in their own community *first* and then
everyone can see whether the existing community wishes to adopt their
changes (or not).
The VOTE was based on misleading information. The Incubator PMC should declare it
void and request a new proposal. The existing Bloodhound podling should be
placed on hold until this is sorted out. If WANdisco wishes to fork trac for
their own commercial reasons, they are free to do so under their own name and
their own responsibility, not ours. If the existing TRAC community wants to
join the ASF, then their community can be asked to put together a joint proposal
to that effect -- not one dominated by a sole corporation that has not even
been a part of that community.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Jan 7, 2012 at 7:01 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> On Jan 7, 2012, at 8:05 AM, Sam Ruby wrote:
>
>> On Fri, Jan 6, 2012 at 11:53 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>>
>>> On Jan 6, 2012, at 8:17 PM, Noel J. Bergman wrote:
>>>
>>>> The ASF is not about code; it is about community. If a community forks, or otherwise emerges around a codebase, we are not accepting the CODE: we are accepting the COMMUNITY.
>>>>
>>>> And it seems to me that if we are to say that a COMMUNITZY is not permitted to participate despite use of code that is perfectly proper according to the license, then we are beggaring out own license, the whole point of which is to permit forks, and to prevent a sole copyright holder from assuming control over the community.
>>>>
>>>> If a corporation were to create an ASF-licensed codebase, and later decide to "take back" control, would we refuse a COMMUNITY-based project based on that codebase?
>>>
>>> The answer to that is yes. It has happened.
>>
>> As always, the answer is a bit more subtle than that.
>>
>> More typically, what happens is somebody asks a few questions.
>>
>> Then the people who were pushing the idea realize that that they don't
>> have answers.
>>
>> A bit of time passes.
>>
>> Then those who were originally pushing the idea state that they
>> weren't allowed because some unnamed "they" wouldn't let them.
>
> It isn't my intention to drag in a different set of parties, which is why I haven't linked to messages on other lists.
>
> However, what you say above isn't my recollection at all. As always, Roy gave a refreshingly clear answer which I quoted several days ago. You then more or less backed that up by saying the i's had to be dotted, the t's crossed and to document what was being done. Then be prepared to answer hard questions. You finished with
>
> "Matters of law are non-negotiable. Matters of policy are. However
> you had better have a solid reason and a d**n good plan before you
> challenge an established policy like everything here is a voluntary
> contribution. Search the archives. For example, look at earlier
> versions of the Apache License. It is a part of our DNA and who we
> are at this point. It is not something we are going to change
> lightly."
>
> While your answer was not as crystal clear as Roy's you said multiple times - go get a software grant. Our response was, "We aren't going to bother because we know we won't get one".
>
> I am not sure why you are backing off from this now. I have no problem with this policy. I just wish it was written down on the "How it works" page and then applied uniformly. To see current directors who have all been members of the foundation for a long, long time rendering different opinions on what the policy is isn't helpful.
Clearly we are seeing the same events from different perspectives.
>From my perspective, I said the policy is negotiable (I didn't say it
would be easy, but I did say negotiable). I asked a few (admittedly
hard) questions. You decided not to pursue it. Some time passed.
Now you are saying that the ASF refused.
If you want to bring code to the ASF you need to establish provenance.
We even have a short form for that:
http://incubator.apache.org/ip-clearance/index.html
> Ralph
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
Posted by Ralph Goers <ra...@dslextreme.com>.
On Jan 7, 2012, at 8:05 AM, Sam Ruby wrote:
> On Fri, Jan 6, 2012 at 11:53 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>> On Jan 6, 2012, at 8:17 PM, Noel J. Bergman wrote:
>>
>>> The ASF is not about code; it is about community. If a community forks, or otherwise emerges around a codebase, we are not accepting the CODE: we are accepting the COMMUNITY.
>>>
>>> And it seems to me that if we are to say that a COMMUNITZY is not permitted to participate despite use of code that is perfectly proper according to the license, then we are beggaring out own license, the whole point of which is to permit forks, and to prevent a sole copyright holder from assuming control over the community.
>>>
>>> If a corporation were to create an ASF-licensed codebase, and later decide to "take back" control, would we refuse a COMMUNITY-based project based on that codebase?
>>
>> The answer to that is yes. It has happened.
>
> As always, the answer is a bit more subtle than that.
>
> More typically, what happens is somebody asks a few questions.
>
> Then the people who were pushing the idea realize that that they don't
> have answers.
>
> A bit of time passes.
>
> Then those who were originally pushing the idea state that they
> weren't allowed because some unnamed "they" wouldn't let them.
It isn't my intention to drag in a different set of parties, which is why I haven't linked to messages on other lists.
However, what you say above isn't my recollection at all. As always, Roy gave a refreshingly clear answer which I quoted several days ago. You then more or less backed that up by saying the i's had to be dotted, the t's crossed and to document what was being done. Then be prepared to answer hard questions. You finished with
"Matters of law are non-negotiable. Matters of policy are. However
you had better have a solid reason and a d**n good plan before you
challenge an established policy like everything here is a voluntary
contribution. Search the archives. For example, look at earlier
versions of the Apache License. It is a part of our DNA and who we
are at this point. It is not something we are going to change
lightly."
While your answer was not as crystal clear as Roy's you said multiple times - go get a software grant. Our response was, "We aren't going to bother because we know we won't get one".
I am not sure why you are backing off from this now. I have no problem with this policy. I just wish it was written down on the "How it works" page and then applied uniformly. To see current directors who have all been members of the foundation for a long, long time rendering different opinions on what the policy is isn't helpful.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
Posted by Sam Ruby <ru...@intertwingly.net>.
On Fri, Jan 6, 2012 at 11:53 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> On Jan 6, 2012, at 8:17 PM, Noel J. Bergman wrote:
>
>> The ASF is not about code; it is about community. If a community forks, or otherwise emerges around a codebase, we are not accepting the CODE: we are accepting the COMMUNITY.
>>
>> And it seems to me that if we are to say that a COMMUNITZY is not permitted to participate despite use of code that is perfectly proper according to the license, then we are beggaring out own license, the whole point of which is to permit forks, and to prevent a sole copyright holder from assuming control over the community.
>>
>> If a corporation were to create an ASF-licensed codebase, and later decide to "take back" control, would we refuse a COMMUNITY-based project based on that codebase?
>
> The answer to that is yes. It has happened.
As always, the answer is a bit more subtle than that.
More typically, what happens is somebody asks a few questions.
Then the people who were pushing the idea realize that that they don't
have answers.
A bit of time passes.
Then those who were originally pushing the idea state that they
weren't allowed because some unnamed "they" wouldn't let them.
> Ralph
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
Posted by Ralph Goers <ra...@dslextreme.com>.
On Jan 6, 2012, at 8:17 PM, Noel J. Bergman wrote:
> The ASF is not about code; it is about community. If a community forks, or otherwise emerges around a codebase, we are not accepting the CODE: we are accepting the COMMUNITY.
>
> And it seems to me that if we are to say that a COMMUNITZY is not permitted to participate despite use of code that is perfectly proper according to the license, then we are beggaring out own license, the whole point of which is to permit forks, and to prevent a sole copyright holder from assuming control over the community.
>
> If a corporation were to create an ASF-licensed codebase, and later decide to "take back" control, would we refuse a COMMUNITY-based project based on that codebase?
The answer to that is yes. It has happened.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Q. Forks without concensus?; A. anytime / depends / never without agreement
Posted by "Noel J. Bergman" <no...@devtech.com>.
The ASF is not about code; it is about community. If a community forks, or otherwise emerges around a codebase, we are not accepting the CODE: we are accepting the COMMUNITY.
And it seems to me that if we are to say that a COMMUNITZY is not permitted to participate despite use of code that is perfectly proper according to the license, then we are beggaring out own license, the whole point of which is to permit forks, and to prevent a sole copyright holder from assuming control over the community.
If a corporation were to create an ASF-licensed codebase, and later decide to "take back" control, would we refuse a COMMUNITY-based project based on that codebase?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org