On Wed, Jan 6, 2010 at 7:27 PM, Kristian Lyngstøl <[email protected]> wrote: > On Tue, Jan 5, 2010 at 6:01 AM, Sam Spilsbury <[email protected]> wrote: >> As part of a purely administrative detail, I just read this [1] >> article by the FSFE on copyright assignment and how it should be >> handled. > (... reassigning copyright) > > I applaud you for reading up on it and caring enough to write about > it. I wish more people did that. > > However, I do not reassign my copyright. This is one point where I do > not agree with the FSF.
Sure. > > If you want to know a good reason NOT to reassign it, take a look at X-Chat. >From what I can read on Wikipedia [1], here we have a situation where the current maintaining council or maintainer has taken the code of others for commercial interests. I can say that I have seen this happen in other places too (see gPSP, which was GPL'd software by Exophase, but the maintainer was then given a revenue sharing agreement by a more popular iPhone port in return for copyright assignment and a change of license to the code) I think this kind of situation is avoidable with some kind of consitution by the current developers as to what kind of licenses would be acceptable for code with copyright assigned to a 'OpenCompositing Foundation'. I also don't think that making copyright re-assignment mandatory for all contributors to the upstream project is necessarily good idea. Voluntary re-assignment leaves form of control for the sake of the future of the project to any future contributors should the original developers be out-of-contact or not able to provide legal consent to change for any reason. Implementing such a system where copyright re-assignment is voluntary should be fairly simple considering our plugin-based system. Mixed copyright in areas like core should be a little more difficult though. > > I may not contribute much any more, but I take my copyright serious, > as should everyone. The history of Compiz and licenses isn't nearly > solid and mature enough for me to believe it's sane to expect > developers to trust a council with all their copyright, specially when > our organization isn't even close to mature. With the general volatility of the project, I'll agree to this statement. However does this outweigh the consideration that developers may become out-of-contact as has happened in the past? The only option that is really left in case developers feel the need to change the licence (not just for personal interests, but perhaps to improve compatibility) is currently to rewrite the code and this has only really implicitly (license change from MIT to GPLv2) happened since Dennis rewrote core in C++. This approach seem far-from-optimal at least seeing that a complete rewrite has essentially slowed the project right down to a crawl. I don't think compiz could sustain another rewrite. The reason I brought this up, is that I have noticed that a lot of plugins seem have been touched by different maintainers over the years, who, while all maintaining the same license, have up to about 4 (and growing) copyright owners because of significant code changes. This can be problematic where there are huge amounts of legal overhead in contacting and gaining the consent from all copyright owners of a file in order to take any legal direction or action (see the recent GPL Violation suit by the SFLC on behalf of BusyBox) > > Besides, if the code is licensed under one of either "MIT" or "GPL X > or newer", it's not going to be a big deal anyway. And if somebody > chose GPL, they probably have a reason. Acknowledged. > most developers care far too little about the consequence of letting a > foundation or a commercial entity own what should've been their > copyrighted works. Agreed completely. I believe that by making a not-for-profit foundation, it is impossible for commercial interests to buy out the licence of the code - or at least this is what I read in the FSFE document. [1] http://en.wikipedia.org/wiki/XChat Kind Regards, Sam > > - Kristian > _______________________________________________ > Council mailing list > [email protected] > http://lists.compiz-fusion.org/mailman/listinfo/council > -- Sam Spilsbury _______________________________________________ Dev mailing list [email protected] http://lists.compiz-fusion.org/mailman/listinfo/dev
