Vincent Untz <vu...@gnome.org> writes: > Overall, I think there are three main approaches to the issue, and I'd > like to hear what people think is best.
Thanks for soliciting community input. > a) Live with it. > The Software Center is not a dead project, and development is > ongoing (see https://launchpad.net/software-center). It is nevertheless community-hostile for Canonical to insist on a one-sided agreement: as a condition for contributing, Canonical insist on special exclusive rights to distribute the work under proprietary terms. Projects for which Canonical insist on such extra rights are not community projects. <URL:http://blogs.computerworlduk.com/simon-says/2010/08/on-contributor-agreements/> <URL:http://www.fsf.org/blogs/rms/assigning-copyright> I think that's not a situation with which we should live, but one which should be actively resisted and loudly protested. So I think a fork of some kind is necessary. > b) Maintain a "light" fork. > c) Completely fork. I think the difference between these two is partly determined by how intractable the upstream's community-hostile position is. Though the Go-OO project was a hopeful effort conducted well, it turned out to be somewhat wasted effort since OpenOffice.org just moldered upstream. It is now eclipsed by the complete fork that is LibreOffice, which I think is so rapidly successful only because it makes a complete break with the clearly community-hostile Oracle. Of course, for such a full fork to work, the surviving fork must have a strong core development team; preferably the majority of active developers from the original project. So treading carefully is also necessary, in order to convince the developers to join willingly. In the case of Canonical, their insistence on special proprietary rights in the work is a matter of long-defended public policy, so we should not hold out much hope that they will agree to a level playing field. A complete fork will be painful, but will make the contribution terms clearly level for everyone, and I expect it to be less painful than trying to work long-term across the divide imposed by Canonical's terms. > Of course, there can be a mix of those. For instance: > - light fork at first, and if Harmony takes off and everybody is > happy with it, merge everything back. This might be a reasonable option *if* Canonical showed signs of actually wanting a level playing field for contributions. As it is, though, I think it's clear current Canonical policy rules out their agreeing to terms which don't leave them in a privileged position on “their” projects. For example, Mark Shuttleworth is well aware of the advice from RMS to drop the community-hostile requirements, but chooses to misinterpret <URL:http://www.markshuttleworth.com/archives/671#comment-352309> as though RMS's advice endorsed Canonical's behaviour. (Note, please, that I'm not resting my position on RMS as some kind of authority; it's his arguments in this issue that I support.) > - light fork at first, and slowly move to full fork. If that's less painful than a full fork, I'm not against it; so long as it's clear the goal of achieving a full fork as soon as feasible. > Btw, it's not my intention to discuss whether Canonical is right or > wrong to require a copyright assigment for this project, or whether > Harmony will provide a good framework for that or not, so please do not > focus too much on this in the thread :-) Well, my position on which route to take is driven in large part by that argument, so I hope it's acceptable to discuss it to that extent. > Let's try to stay on-topic, and the topic is: which path do we choose? Thanks again for kick-starting this discussion. -- \ “One of the most important things you learn from the internet | `\ is that there is no ‘them’ out there. It's just an awful lot of | _o__) ‘us’.” —Douglas Adams | Ben Finney _______________________________________________ Distributions mailing list Distributions@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/distributions