Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Sat, Jan 7, 2012 at 10:24 PM, Roy T. Fielding field...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Q. Forks without concensus?; A. anytime / depends / never without agreement
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Jan 9, 2012, at 9:11 PM, Greg Stein wrote: On Jan 9, 2012 10:03 PM, Roy T. Fielding field...@gbiv.com wrote: ... And, no, the discussion has not been with the Trac community -- it was in private with a few individuals; as far as Apache is concerned, it never happened. And Oracle's private conversations, and their decisions regarding OOo contrary to the community, were somehow acceptable? Acceptable to whom? Oracle owned the copyright on the code. LibreOffice is not the community for Oracle's codebase -- it is just the most public and successful of the earlier forks. Oracle made the choice of where they wanted to contribute their own code, long before they contacted the ASF. I am damn sure that we didn't have any significant private discussion with Oracle before their proposal was submitted to the incubator. IBM did, I presume, and maybe a few others acting as individuals, but not the ASF. As far as Apache is concerned, those private discussions didn't happen. The Apache work began with a public proposal, and it wasn't until then that Oracle could be said to have discussed it with the Apache community. Is the result acceptable to us? Yes. Acceptable to the LibreOffice community? Probably not, but it wasn't their's to contribute even if they had wanted to do so. Oracle was the only entity with the ability to relicense that code to the ASF. ... There is no fork in the current plan, so this discussion is moot anyways. I believe the point was to settle the issue so that we don't have to deal with this situation again. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Tue, Jan 10, 2012 at 5:11 AM, Greg Stein gst...@gmail.com wrote: There is no fork in the current plan, so this discussion is moot anyways. There have been tons of long emails on this proposal and i haven't read them all so am a little lost on whats going on, but http://wiki.apache.org/incubator/BloodhoundProposal in the section on Initial Source says: The original Trac code base has been under development for more than 8 years, though development has become minimal over the past 2 years. We have sync'd the existing Trac repository, including history, and are using it as the basis for Bloodhound. Isn't that a fork? ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Sat, Jan 7, 2012 at 9:24 PM, Roy T. Fielding field...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Jan 10, 2012 9:30 AM, ant elder ant.el...@gmail.com wrote: On Tue, Jan 10, 2012 at 5:11 AM, Greg Stein gst...@gmail.com wrote: There is no fork in the current plan, so this discussion is moot anyways. There have been tons of long emails on this proposal and i haven't read them all so am a little lost on whats going on, but http://wiki.apache.org/incubator/BloodhoundProposal in the section on Initial Source says: Ignore the proposal. It is out of date, since the podling has already started. The Bloodhound and Trac communities already have a new non-fork plan and are executing on that now, on the bloodhound-dev mailing list. Cheers, -g
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Tue, Jan 10, 2012 at 5:04 PM, Greg Stein gst...@gmail.com wrote: ...Ignore the proposal. It is out of date, since the podling has already started. The Bloodhound and Trac communities already have a new non-fork plan and are executing on that now, on the bloodhound-dev mailing list For completeness, could you mention that in the proposal, and link to the relevant threads? -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Tue, Jan 10, 2012 at 11:16 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Jan 10, 2012 at 5:04 PM, Greg Stein gst...@gmail.com wrote: ...Ignore the proposal. It is out of date, since the podling has already started. The Bloodhound and Trac communities already have a new non-fork plan and are executing on that now, on the bloodhound-dev mailing list For completeness, could you mention that in the proposal, and link to the relevant threads? I agree. The proposal sits out there where people are prone to read it. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Tue, Jan 10, 2012 at 11:20, Benson Margulies bimargul...@gmail.com wrote: On Tue, Jan 10, 2012 at 11:16 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Jan 10, 2012 at 5:04 PM, Greg Stein gst...@gmail.com wrote: ...Ignore the proposal. It is out of date, since the podling has already started. The Bloodhound and Trac communities already have a new non-fork plan and are executing on that now, on the bloodhound-dev mailing list For completeness, could you mention that in the proposal, and link to the relevant threads? I agree. The proposal sits out there where people are prone to read it. Done: http://wiki.apache.org/incubator/BloodhoundProposal Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On 1/10/2012 6:40 AM, Roy T. Fielding wrote: On Jan 9, 2012, at 9:11 PM, Greg Stein wrote: There is no fork in the current plan, so this discussion is moot anyways. I believe the point was to settle the issue so that we don't have to deal with this situation again. Roy That was the point of my choice of subject lines, yes ;-) It is not helpful to have a number of directors contradicting each other on general@, never coming to consensus. In fact, its maddening. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Tue, Jan 10, 2012 at 2:49 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: It is not helpful to have a number of directors contradicting each other on general@, never coming to consensus. In fact, its maddening. I'm actually not seeing much in the way of contradiction in discussion of the policy. The letter seems to be: Apache projects don't import and incorporate code without the owners' consent. License to use is not synonymous with consent to import. The spirit seems to be: It is terminally rude to try to form an Apache project by ripping up an existing community without its consent. Most of the Apache people commenting here seem to agree on these things. Most of the argument on this thread seems to have been about whether or not they apply to Bloodhound. Bloodhound notwithstanding, there's probably enough practical clarification here to put up on a page somewhere, with a link from the main policy page saying, For a discussion of the issues, click here. But perhaps I'm naive. Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On 1/10/2012 2:20 PM, Donald Whytock wrote: I'm actually not seeing much in the way of contradiction in discussion of the policy. The letter seems to be: Apache projects don't import and incorporate code without the owners' consent. License to use is not synonymous with consent to import. The spirit seems to be: It is terminally rude to try to form an Apache project by ripping up an existing community without its consent. Most of the Apache people commenting here seem to agree on these things. Most of the argument on this thread seems to have been about whether or not they apply to Bloodhound. Bloodhound notwithstanding, there's probably enough practical clarification here to put up on a page somewhere, with a link from the main policy page saying, For a discussion of the issues, click here. But perhaps I'm naive. No, that's exactly what I've interpreted. Perhaps it is a bit more nuanced; if there were two sets of 'copyright holders' who could no longer tolerate collaborating together, perhaps the ASF would raise the issue again. More likely, go off and work your project elsewhere and come to the ASF demonstrating you already operate with appropriate community dynamics (fork'ers being presumptively suspect of problematic community dynamics ;-) So A. above appears to be Almost never without agreement. And let there be one heck of a detailed justification in the exception case. It would be good for the board to issue an explicit policy to this effect. But the discussion was sufficient to move on. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
Hi, On Tue, Jan 10, 2012 at 8:49 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: It is not helpful to have a number of directors contradicting each other on general@, never coming to consensus. In fact, its maddening. I see no indication of this escalating into a board issue, so I don't see why the voices of directors should carry any more weight than those of other experienced members of our community. Or why they for some reason should agree more with each other than the rest of us do. Instead I'd find it odd if the directors came here with a common voice, implying that the board has already collectively decided what we should do. The IPMC is perfectly capable (in its own sometimes messy way) to deal with this issue. In fact the board has explicitly delegated the responsibility of acceptance and oversight of new products submitted or proposed to become part of the Foundation to the IPMC. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Tue, Jan 10, 2012 at 4:50 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Tue, Jan 10, 2012 at 8:49 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: It is not helpful to have a number of directors contradicting each other on general@, never coming to consensus. In fact, its maddening. I see no indication of this escalating into a board issue, so I don't see why the voices of directors should carry any more weight than those of other experienced members of our community. Or why they for some reason should agree more with each other than the rest of us do. Instead I'd find it odd if the directors came here with a common voice, implying that the board has already collectively decided what we should do. The IPMC is perfectly capable (in its own sometimes messy way) to deal with this issue. In fact the board has explicitly delegated the responsibility of acceptance and oversight of new products submitted or proposed to become part of the Foundation to the IPMC. The IPMC accepted this podling on terms that at least one director though were wrong. The fact that a subsequent discussion led to a better plan is good, but not quite the same. Greg both acquiesced in picking another plan while at the same time he did not retreat from the position that there is no set Foundation policy here. Roy takes a strong and continuing line that there is one. So I personally wish that the board put this on its agenda, and pass a resolution one way or another stating the board-level invariants. I'm sure that there will remain plenty of IPMC-level interpretation for evaluating particular situations. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On 1/10/2012 4:04 PM, Benson Margulies wrote: Greg both acquiesced in picking another plan while at the same time he did not retreat from the position that there is no set Foundation policy here. Roy takes a strong and continuing line that there is one. So I personally wish that the board put this on its agenda, and pass a resolution one way or another stating the board-level invariants. I'm sure that there will remain plenty of IPMC-level interpretation for evaluating particular situations. +1 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On 1/10/2012 3:50 PM, Jukka Zitting wrote: The IPMC is perfectly capable (in its own sometimes messy way) to deal with this issue. In fact the board has explicitly delegated the responsibility of acceptance and oversight of new products submitted or proposed to become part of the Foundation to the IPMC. Not if there is a foundation-wide policy, we aren't. The IPMC can no more violate our rules on accepting forks than it can accept GPL'ed projects, without the board revisiting policy. This is not G v. R arguing we should or shouldn't accept forks, this is G v. R arguing that a foundation-wide policy already exists. Let the board square it up. If the answer is 'depends', then you are right, incubator would have been the committee to weight those conditions. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Tue, Jan 10, 2012 at 22:59, Niclas Hedhman nic...@hedhman.org wrote: ... This sounds more and more like an example of Fascination of the Apache brand, as a lever for commercial interest. I agree with Roy that this is bad taste, and I wish WANdisco simply makes a commercial derivative, OR even a commercially backed, open source licensed derivative on GitHub, which may build traction with a larger community and we can discuss it again... To understand why WANdisco wants Bloodhound to be an Apache project, rather than their own, please read their CEO's message: https://groups.google.com/group/trac-dev/msg/5bc628afdd5a4ff3 They approach some things wrong, but I agree with David's sentiment in that message: the ASF is the best way to create a long-lived, healthy, and vendor-neutral project. There is a strong assumption that a community will evolve around Apache Bloodhound, and that is what the Incubator is for. Most podlings arrive with the hope and assumption that a community is out there, just waiting to be discovered. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Sat, Jan 7, 2012 at 4:10 PM, Roy T. Fielding field...@gbiv.com wrote: On Jan 7, 2012, at 1:49 PM, Greg Stein wrote: On Jan 7, 2012 4:24 PM, Roy T. Fielding field...@gbiv.com wrote: ... The original developers are not ambivalent to this fork. Untrue. Christian and Remy are, and always have been, supportive. They were the ones to suggest the fork, rather than trying to make the changes in trunk. I read the trac-dev mailing list. To say that they are supportive is a huge stretch of the imagination. They are sadly resigned to see a potential contributor decide to fork the code instead of working with them directly. And the rest of the community (which is far larger than the core) thinks the idea stinks. If you read trac-dev, you will also notice that the discussion about the so-called fork has more responses than all other threads in the last three months *combined*. Lots of navel gazing, not much work. (Though surprisingly, discussion *has* picked up in the past couple of weeks, so maybe this is a Good Thing all around.) What you have is a vocal minority that disagree. Ethan is not even a core committer, as far as I can tell. Edgewall, the copyright holder, is a defunct shell. That is a primary reason WANdisco wanted to move to the ASF: a home with actual backing and longevity. Then we should be able to convince Christian and Remy to join the initial committers list and bring the rest of the TRAC community with them. Why has that not been done? It has been. They have essentially said we've moved on, best of luck. WANdisco has definite problems in how they approach and work with open source communities. They discussed this stuff with the Trac principals privately, rather than with the broader community. But my read is that the Trac leads are supportive of Bloodhound. They are supportive of people doing work on Trac. They did not support a fork at the ASF. What they told WANdisco was that, rather than come to some artificial agreement on how they should work together before WANdisco had contributed anything, that WANdisco should fork the code and start by making contributions. That's it. The only reason that Christian has not directly opposed Bloodhound is because he believes the BSD license gives permission to fork the code. My interest here is seeing Trac revitalized, improved, and delivered as an awesome open source issue tracker. I'm tired of Bugzilla and (non-OSS) Jira. I like the Google Code tracker, but I'm biased there :-P There is no evidence to suggest that cannot be done on trac-dev. I'm not sure I agree with this statement. Trac has a singular and well-defined philosophy built around a small core and an environment of plugins. This isn't the place to debate the merits of that architecture, but suffice it to say that such a system can often require a lot of work to get to a usable state. The goals of Bloodhound are separate from that: create a full-featured issue tracker which is easy to deploy and use for end users and administrators both. Honestly, Trac is a good product, and is an excellent choice as the core for Bloodhound, but the community goals differ. Significantly. Bloodhound won't happen on trac-dev because the Trac community is philosophically opposed to the direction the nascent Bloodhound community wants to take. That's okay: people are allowed to have different goals. And the great part about open source is we all don't have to reinvent the wheel to implement those different views of the world. Bloodhound can be a derivative of Trac with its own community and goals [1]. There's room enough in the world for them both. I think the Trac community sees this as a zero-sum game: if people are contributing to Bloodhound, they *aren't* contributing to Trac. Instead, we should try to convince the Bloodhound people that our philosophy is best, and they should just come over here. Resolving such philosophical differences and technical goals is difficult at best, and I don't see it happening soon. But that's okay, there isn't a globally optimal solution to issue tracking, and we can agree to experiment with different paths. But I've probably said too much already. There isn't much more I can add here, and the last think I want to do at this point is prolong the agony of this discussion. -Hyrum [1] Indeed, I know of at least one private proprietary derivative of Trac, but since it's proprietary, nobody knows about it and nobody complains. It's the fact that Bloodhound is proposed as open source which is causing the hullaballoo in the first place. -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Mon, Jan 9, 2012 at 9:42 AM, Hyrum K Wright hyrum.wri...@wandisco.com wrote: I think the Trac community sees this as a zero-sum game: if people are contributing to Bloodhound, they *aren't* contributing to Trac. Instead, we should try to convince the Bloodhound people that our philosophy is best, and they should just come over here. Resolving such philosophical differences and technical goals is difficult at best, and I don't see it happening soon. But that's okay, there isn't a globally optimal solution to issue tracking, and we can agree to experiment with different paths. But I've probably said too much already. There isn't much more I can add here, and the last think I want to do at this point is prolong the agony of this discussion. Where's the agony? I see the general discussion about forks without consensus as very healthy, and I think it should continue to be discussed till all voices are heard. [1] Indeed, I know of at least one private proprietary derivative of Trac, but since it's proprietary, nobody knows about it and nobody complains. It's the fact that Bloodhound is proposed as open source which is causing the hullaballoo in the first place. But dear Sir, I don't believe that to be true if I may say so. Had the original proposal been worded as a derivative intended to keep Trac as the foundation, rather than a take-over there wouldn't have been any hullaballoo. I still don't understand why Bloodhound needs to start by forking Trac, without a single line written yet. The architecture with a small core and many plugins versus a complete installable package are not contradicting in any way. Kalle - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Jan 9, 2012, at 9:42 AM, Hyrum K Wright wrote: On Sat, Jan 7, 2012 at 4:10 PM, Roy T. Fielding field...@gbiv.com wrote: On Jan 7, 2012, at 1:49 PM, Greg Stein wrote: On Jan 7, 2012 4:24 PM, Roy T. Fielding field...@gbiv.com wrote: ... The original developers are not ambivalent to this fork. Untrue. Christian and Remy are, and always have been, supportive. They were the ones to suggest the fork, rather than trying to make the changes in trunk. I read the trac-dev mailing list. To say that they are supportive is a huge stretch of the imagination. They are sadly resigned to see a potential contributor decide to fork the code instead of working with them directly. And the rest of the community (which is far larger than the core) thinks the idea stinks. If you read trac-dev, you will also notice that the discussion about the so-called fork has more responses than all other threads in the last three months *combined*. Lots of navel gazing, not much work. (Though surprisingly, discussion *has* picked up in the past couple of weeks, so maybe this is a Good Thing all around.) Yes, that is a common side-effect of introducing a sense of awareness to a project that is otherwise in stasis. I have no doubt that Trac needs new blood and a driving force capable of energizing the community that developed on top of it. What you have is a vocal minority that disagree. Ethan is not even a core committer, as far as I can tell. It isn't a vocal minority. Not a single person outside of WANdisco considered it a good idea. Not one. Yes, most of the people commenting were the implementers of plug-ins, but they are also supposed to be part of the Bloodhound proposal. Edgewall, the copyright holder, is a defunct shell. That is a primary reason WANdisco wanted to move to the ASF: a home with actual backing and longevity. Then we should be able to convince Christian and Remy to join the initial committers list and bring the rest of the TRAC community with them. Why has that not been done? It has been. They have essentially said we've moved on, best of luck. I don't follow that. Is Edgewall still a formal organization capable of owning copyright? If not, who owns the copyright? Have Christian and Remy stopped all work on Trac, or are they just busy with their $jobs? And, no, the discussion has not been with the Trac community -- it was in private with a few individuals; as far as Apache is concerned, it never happened. Yes, there are many reasons to prefer that it is under the ASF. Many, many, many reasons. That doesn't change the fact that Apache only accepts voluntary contributions. Before you import code to the ASF, you have to get some indication from the authors that they either *want* us to maintain that code or that they have completely abandoned it. Not just a sigh and a statement that the BSD license is forkable -- they have to want Apache to build a community for maintaining that code. Otherwise, we don't, for social reasons that have little to do with licensing. WANdisco has definite problems in how they approach and work with open source communities. They discussed this stuff with the Trac principals privately, rather than with the broader community. But my read is that the Trac leads are supportive of Bloodhound. They are supportive of people doing work on Trac. They did not support a fork at the ASF. What they told WANdisco was that, rather than come to some artificial agreement on how they should work together before WANdisco had contributed anything, that WANdisco should fork the code and start by making contributions. That's it. The only reason that Christian has not directly opposed Bloodhound is because he believes the BSD license gives permission to fork the code. My interest here is seeing Trac revitalized, improved, and delivered as an awesome open source issue tracker. I'm tired of Bugzilla and (non-OSS) Jira. I like the Google Code tracker, but I'm biased there :-P There is no evidence to suggest that cannot be done on trac-dev. I'm not sure I agree with this statement. Trac has a singular and well-defined philosophy built around a small core and an environment of plugins. This isn't the place to debate the merits of that architecture, but suffice it to say that such a system can often require a lot of work to get to a usable state. The goals of Bloodhound are separate from that: create a full-featured issue tracker which is easy to deploy and use for end users and administrators both. Honestly, Trac is a good product, and is an excellent choice as the core for Bloodhound, but the community goals differ. Significantly. Those sound like the goals for a commercial distribution of an open source project. In any case, there is no evidence that it cannot be done on trac-dev because it wasn't attempted. Bloodhound won't happen on trac-dev because the Trac community is philosophically opposed to the
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Mon, Jan 9, 2012 at 10:02 PM, Roy T. Fielding field...@gbiv.com wrote: I don't follow that. Is Edgewall still a formal organization capable of owning copyright? If not, who owns the copyright? Have Christian and Remy stopped all work on Trac, or are they just busy with their $jobs? Yes, Edgewall is still a formal organization capable of owning copyright. (Aside: it's not entirely clear to me at the moment how much copyright Edgewall owns over the Trac codebase, vs. whether individual Trac contributors retain the copyright to their own contributions[1].) Christian and Remy have not stopped all work on Trac. They are still, at least, reviewing and merging patches. Other core committers (newer contributors, and contributors with partial repository access) are also committing changes[2]. Separately, I do want to point out that the most recent statements from WANdisco's David Richards and Gary Martin on trac-dev and bloodhound-dev are encouraging, and clearly indicate an interest in developing Bloodhound as a downstream Trac distribution with patches maintained separately (presumably without official Apache copyright and licensing) and submitted upstream. As far as I've seen, everybody in the Trac community is fully supportive of this, as well as appreciative. That said, it would probably be best if the official Bloodhound proposal were modified to correct the mischaracterizations about the Trac community, and to replace the explicit plans for a Trac fork (Migrate the existing BSD-licensed Trac code base to the ASF etc) with a clear description of the new approach including how the upstream patches, plus their copyright and licensing, will be managed. (As an Apache newcomer I have no idea whether this would require or merit a new VOTE.) I think that if/when these details are clearly ironed out, all the fundamental short-term issues will be resolved. Longer-term concerns expressed by WANdisco (copyright protection, non-conflicting visions, a core velocity that does not impede downstream development) and the Trac community (upstream contributions, symbiotic communities, increased burdens of knowledge management for core devs // plugin authors // users) can then hopefully be tackled and reevaluated during the incubation process. -Ethan [1] https://groups.google.com/group/trac-dev/msg/cfbf54981ad64138 [2] http://trac.edgewall.org/timeline?from=Jan+10%2C+2012daysback=30authors=changeset=onupdate=Update
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Jan 9, 2012 10:03 PM, Roy T. Fielding field...@gbiv.com wrote: ... And, no, the discussion has not been with the Trac community -- it was in private with a few individuals; as far as Apache is concerned, it never happened. And Oracle's private conversations, and their decisions regarding OOo contrary to the community, were somehow acceptable? ... There is no fork in the current plan, so this discussion is moot anyways. -g
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Fri, Jan 6, 2012 at 11:53 PM, Ralph Goers ralph.go...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Jan 7, 2012 4:24 PM, Roy T. Fielding field...@gbiv.com wrote: ... The original developers are not ambivalent to this fork. Untrue. Christian and Remy are, and always have been, supportive. They were the ones to suggest the fork, rather than trying to make the changes in trunk. What you have is a vocal minority that disagree. Ethan is not even a core committer, as far as I can tell. Edgewall, the copyright holder, is a defunct shell. That is a primary reason WANdisco wanted to move to the ASF: a home with actual backing and longevity. ... WANdisco has definite problems in how they approach and work with open source communities. They discussed this stuff with the Trac principals privately, rather than with the broader community. But my read is that the Trac leads are supportive of Bloodhound. My interest here is seeing Trac revitalized, improved, and delivered as an awesome open source issue tracker. I'm tired of Bugzilla and (non-OSS) Jira. I like the Google Code tracker, but I'm biased there :-P Cheers, -g (*) on my tablet right now, so it is hard for me to look up details/history; the above is based on my recollection
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Sat, Jan 7, 2012 at 10:49 PM, Greg Stein gst...@gmail.com wrote: ...WANdisco has definite problems in how they approach and work with open source communities. They discussed this stuff with the Trac principals privately, rather than with the broader community. But my read is that the Trac leads are supportive of Bloodhound Can we have this support documented at a public URL by those Trac leads? That would solve this issue, IMO. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Jan 7, 2012, at 2:10 PM, Roy T. Fielding wrote: On Jan 7, 2012, at 1:49 PM, Greg Stein wrote: On Jan 7, 2012 4:24 PM, Roy T. Fielding field...@gbiv.com wrote: ... The original developers are not ambivalent to this fork. Untrue. Christian and Remy are, and always have been, supportive. They were the ones to suggest the fork, rather than trying to make the changes in trunk. I read the trac-dev mailing list. To say that they are supportive is a huge stretch of the imagination. They are sadly resigned to see a potential contributor decide to fork the code instead of working with them directly. And the rest of the community (which is far larger than the core) thinks the idea stinks. http://groups.google.com/group/trac-dev/msg/96c8e39fa1c8e401 Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Jan 7, 2012, at 8:05 AM, Sam Ruby wrote: On Fri, Jan 6, 2012 at 11:53 PM, Ralph Goers ralph.go...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Sat, Jan 7, 2012 at 7:01 PM, Ralph Goers ralph.go...@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 ralph.go...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Q. Forks without concensus?; A. anytime / depends / never without agreement
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
[ ] 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
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 dwhyt...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Jan 3, 2012 1:28 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: On Tue, Jan 3, 2012 at 9:57 AM, Leo Simons m...@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
On Tue, Jan 3, 2012 at 1:28 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: On Tue, Jan 3, 2012 at 9:57 AM, Leo Simons m...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Tue, Jan 3, 2012 at 11:46 AM, Doug Cutting cutt...@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
On Tue, Jan 3, 2012 at 15:13, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: On Tue, Jan 3, 2012 at 11:46 AM, Doug Cutting cutt...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Tue, Jan 3, 2012 at 10:33 AM, Greg Stein gst...@gmail.com wrote: On Jan 3, 2012 1:28 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: On Tue, Jan 3, 2012 at 9:57 AM, Leo Simons m...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On 1/3/2012 12:51 PM, Sam Ruby wrote: On Tue, Jan 3, 2012 at 1:28 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: On Tue, Jan 3, 2012 at 9:57 AM, Leo Simons m...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
