Hi David, First of all I must stress again that my personal opinion in this is just that, and that I don't presume to force it upon anyone else, being open to relicense is needed be. Having said that:
On 9/18/07, David Chisnall <[EMAIL PROTECTED]> wrote: (...) > I believe you are misunderstanding the OpenBSD debate. There is no > dispute over whether you can use BSDL code in GPL'd projects. The > complete work becomes GPL'd and the BSDL components remain BSDL > individually. That was the initial debate (or the dual-licensing was, not sure). In recent days, and probably due to growing and noticible animosity between the camps, as it were, I have seen the debate surpass that point. The current confrontation has the side-effect of making people look more in depth where previously they didn't bother, and I have actually read some good reasons why BSDL code could be incompatible with the GPL in terms of using it and distributing a GPL binary with parts covered by the BSDL. > The issue there is over relicensing BSDL code under > the GPL. This can only be done with the consent of the original > author(s). The controversy began when someone sent a diff to the > LKML removing the original author's copyright notice and licenses > from the files. This was done because someone believed that Linus > would not accept BSDL code into the kernel (no idea why they thought > that; there's loads of BSD, MIT and PD code in the Linux kernel > already), and so ditched the dual license. It's not completely clear > whether changing the license of a dual-licensed piece of code to a > single license is allowed, but removing the original copyright notice > is definitely not allowed. There is, however, nothing stopping you > from using a BSDL component in a GPL'd project[1]. > That is indeed what happened, and I agree with you in general. However the debate has extended from there to other areas (Marc Espies' mail is a good indicator of the bad blood that exists presently), including the GPLv3 not being BSDL compatible due to some of the termination clauses, and the GPLv2 not being BSDL compatible due to not allowing any further restriction. Note that I didn't say this was true, but many speculations about the effects of the GPLv3 are also not provable true and that doesn't see to affect peoples opinion on it (which is normal, of course).This is all a bit unfortunate, and I don't want to be affected by it. Hopefully everything will calm down, and I have been always been suportive of non-copyleft licenses in the grand scheme of things (i.e. supportive,but not finding them prefered), but I have had enough heated discussions since the GPLv3 launch and the Atheros mess to be a bit paranoid when GPL-to-BSD discussions take place. Jesse, ------------------ > - All new code should be under the modified BSD, LGPL or more > permissive license (X11/MIT, ISC, public domain...). > - All existing code should be attempted to be relicensed to LGPL, > BSD or more a permissive license, with the author's permission. > - Any new contributions to existing projects should be under the > same license as the project, or a more permissive license. > - Any ports or forks from existing work should be under the license > of the original project, and should not be GPL if there is a more > permissively-licensed alternative. GPL code may be entered into the > project, but should be sufficiently isolated from other code (ie: via > separation of the code to a service or helper application). ------------------ Sounds reasonable. In the end people developing "third party" applications (I'm sure everyone is hoping for that) will choose whatever they want. I can live with the LGPL/BSDL choice - actually, as I said many time, I would relicense the code regardless, not conditioned by this discussion. I'm also feeling midly embarassed in the way I'm apparently raising a lot of obstacles when the main contributors have already reached a consensus. Do view my mails as a simple statement of my views and not as a way to block anything, I have no such presumption *at all*. Best regards, Frederico Muñoz _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
