Why do they feel obliged to remove the BSD license from the Linux port of the driver? If they just keep it dual-licensed, there isn't a problem.
Or did someone issue an edict that Linux kernel code can't be dual-licensed, at some point when I wasn't paying attention?
Or did someone issue an edict that Linux kernel code can't be dual-licensed, at some point when I wasn't paying attention?
I think the point of the story is the following: 1. Developer A writes some code for OpenBSD (or whatever) 2. Developer B says "that's cool, I wish Linux had that" 3. Developer B ports developer A's code to Linux 4. Developer B then starts improving on A's code
However, developer B doesn't want to release his changes under the BSD license, so the improved version goes out GPL-only. Developer A says "hey, wait, that sucks", because now he can't incorporate those changes back into OpenBSD, which does (I assume) have a policy that all code must be BSD-licensed.
One one hand, it's unfortunate, because OpenBSD loses out. On the other hand, the original author wrote the code knowing that someone could take it and not release changes (for instance, incorporate it into Windows or Mac OS X or SunOS or something like that), and this really isn't all that much different.
I agree completely, this comes to show the BSD weakness not the GPL weakness, it seem that BSD people who bitch about it would want their BSD code to behave like GPL in some respects while still behaving like BSD in others (we still want to let people to use it who don't want to give back improvements to the code) -- I still don't see how you can eat the cake and still have it.
I am considering choosing the BSDL for any future large projects on the idea that one cannot compete with Free (both senses). However, if someone started usng my code in GPL projects and not giving back, (if we wanted it back) I would see if anyone in the community was willing to do an analysis of those changes so we could implement them ourselves. This would probably have two impacts: 1) Force those using our code to either give back or fork, and 2) Driving up the costs of code maintenance for those who
>> 1. Developer A writes some code for OpenBSD (or whatever) 2. Developer B says "that's cool, I wish Linux had that" 3. Developer B ports developer A's code to Linux 4. Developer B then starts improving on A's code >> I think it's ABCBA, or ABCAB -- writing the code, implementing it and code review means 3 parties.
>>However, developer B doesn't want to release his changes under the BSD license, so the improved version goes out GPL-only. Developer A says "hey, wait, that sucks", because now he c
Porting a wireless driver from OpenBSD to Windows is just like copying code;-) Note however that nothing prevents the OpenBSD driver developer from reading the code, thinking about it, coming back, and ading his own versions of the improvements. Or safer yet, askign someone *else* to read the code, provide a specification of the algorythm, an then reimplementing it since the algorythm itself is not subject to copyright protection (IANAL, but read the basic analysis in Gates v. Bando as to what is subject t
The dual licensing thing works fine, but the GNU people never get all of what they want. The GPL lets the driver not taint the kernel. You can put non-GPL code in the Linux kernel, but you really can't distribute it once you do that.
The *BSD people can't put GPL-only code in their kernel for a similar reason: the GPL code could be included by the end user but not distributed unless it followed the GPL, which some BSD distributors likely don't.
Simple solution (Score:2)
Re:Simple solution (Score:5, Interesting)
I think the point of the story is the following:
1. Developer A writes some code for OpenBSD (or whatever)
2. Developer B says "that's cool, I wish Linux had that"
3. Developer B ports developer A's code to Linux
4. Developer B then starts improving on A's code
However, developer B doesn't want to release his changes under the BSD license, so the improved version goes out GPL-only. Developer A says "hey, wait, that sucks", because now he can't incorporate those changes back into OpenBSD, which does (I assume) have a policy that all code must be BSD-licensed.
One one hand, it's unfortunate, because OpenBSD loses out. On the other hand, the original author wrote the code knowing that someone could take it and not release changes (for instance, incorporate it into Windows or Mac OS X or SunOS or something like that), and this really isn't all that much different.
Re: (Score:2)
What should one be required to share? (Score:2)
1) Force those using our code to either give back or fork, and
2) Driving up the costs of code maintenance for those who
Re:A simple solution (Score:1)
1. Developer A writes some code for OpenBSD (or whatever)
2. Developer B says "that's cool, I wish Linux had that"
3. Developer B ports developer A's code to Linux
4. Developer B then starts improving on A's code
>>
I think it's ABCBA, or ABCAB -- writing the code, implementing it and code review means 3 parties.
>>However, developer B doesn't want to release his changes under the BSD license, so the improved version goes out GPL-only. Developer A says "hey, wait, that sucks", because now he c
Right, because (Score:2)
Note however that nothing prevents the OpenBSD driver developer from reading the code, thinking about it, coming back, and ading his own versions of the improvements. Or safer yet, askign someone *else* to read the code, provide a specification of the algorythm, an then reimplementing it since the algorythm itself is not subject to copyright protection (IANAL, but read the basic analysis in Gates v. Bando as to what is subject t
Re: (Score:1)
The *BSD people can't put GPL-only code in their kernel for a similar reason: the GPL code could be included by the end user but not distributed unless it followed the GPL, which some BSD distributors likely don't.