While I believe there are those who is genuine when saying that, I am a bit burned by all those people who would quickly complain if someone made a patched version of their code and put it under GPL.
Snippets of BSD code have ended up in all kinds of GPLed projects. It would be kind of "rude" to just take a BSD-licensed project in its entirety and re-license it. It's legally questionable too. As someone who isn't the copyright holder, you can't really dictate the license.
In fact, incidentally, I believe that if you integrate BSD-licensed code into a proprietary product (where, say, it is manifested as a translation to machine code), you don't actually own those sections of machine code. They are derived works, governed by the BSD license: anyone can rip that out and use it accordingly. The code has not been turned proprietary at all---it just appears in a form that is difficult to modify and tightly coupled to proprietary code.
Yes, that's just silly. If you allow proprietary use of your code (Microsoft can compile it into a binary and ship it with Windows without source) how can you possibly have a fit over it being used in GPL-ed code.
What I would do is help myself to their patch, if it's worthwhile and backport it to the BSD-licensed version.
The code is my copyright, and the patch is a derived work of something of mine; therefore I own it and it falls under my license.
Not to mention that if you take someone's BSD program, and just slap a GPL on it, it doesn't actually hold. Once the users are aware that it's actually a re-labeled BSD program from another author, they can just go with that license.
>> What I would do is help myself to their patch, if it's worthwhile and backport it to the BSD-licensed version.
>> The code is my copyright, and the patch is a derived work of something of mine; therefore I own it and it falls under my license.
That is completely incorrect. You have no rights to the patch just because it is a derivative work. You have the right to prevent distribution of derivative works (not to own or distribute), but you gave that up with the BSD license which expressly allows it.
You're also wrong about the license of the patch. The author of the patch gets to chose it. For GPL licensed software the condition of redistribution is that all derived works be distributed under the GPL as well. If you don't GPL it, you lose your permission to redistribute the original code and derived works.
BSD and MIT licenses don't include this restriction, so you're shit out of luck with making any claim on that patch.
Are you sure that's correct, from a legal perspective?
If I release an MIT project, someone makes a GPL fork with a significant new feature, wouldn't pulling that feature back into my project make my project GPL?
Someone can't make a "GPL fork" of your MIT-licensed project. The new code they add can be GPL-licensed, but they cannot simply change the licensing of the existing code from MIT to GPL.
You are correct that pulling their GPL-licensed feature/additions into your code would require you to adhere to the GPL and re-license the code. The best you could do would be to ask the author of the changes to release them under the same license (MIT) as your original project so the changes could be incorporated without modifying the license.
>they cannot simply change the licensing of the existing code from MIT to GPL.
That is an issue of contention. GPL advocates believe that they are permitted to do that, and have done so in the past. The Software Freedom Law Centre (the legal arm of the FSF) advices developers that they are permitted to do it[1], as do GPL advocates on HN[2].
The only one who is talking about changing existing code from MIT to GPL is Theo de Raadt, and he has never provided any evidence to support that anyone did it or suggested it.
People can create derivative work from BSD licensed software and have any license they want to added with it. Theo has argued that some peoples bug fixing patches did not qualify for copyright, and he is perfectly free to think so. I doubt however that he would ever put money where his mouth is and test it in court. When silence can qualify for copyright, it is a hard argument to make.
> Permission is hereby granted... to deal in the Software without restriction, including without limitation the rights to... sublicense
Because you have the right to "sublicense", you can take MIT code and license it under another license (GPL) even though you are not the copyright holder.
The BSD license is less clear on this point (in fact this is one of the important differences) and whether the BSD's grant includes the right of sublicense is more debatable, but in my view the answer is "probably".
I am not a lawyer; I am not your lawyer; this is not legal advice.
The BSD license does not grant any sublicensing rights. It clearly says that the notice and disclaimers must be preserved.
The original license required copyright notices in binary code. A newer form does not, but this is for pragmatic reasons. The binary code is still copyrighted. If you decompile it into a source language, then you probably have to restore the copyright notice and disclaimers.
When a proprietary, binary-only program with a highly restrictive EULA contains BSD code, those sections of the machine language which correspond to the BSD code are not actually under the EULA. They are not sublicensed, but only used with permission, as granted by the original license.
> he has never provided any evidence to support that anyone did it or suggested it.
Which part of the patch[0] that removed the BSD license and made the file GPLv2 isn't evidence?
You'll note that the patch removed the lines that say "Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies."
In other words they removed the notice that specifically says you're not allowed to remove the notice.
Okey, someone apparently thought they could do it, but then realized better and fixed it. The source today includes the original copyright notice. That they fixed it afterward should point towards what their current believes are, and if they thought their past patch was correct.
Was that version ever distributed to anyone?
I also notice in that thread that the author of Ath5K .c code give explicit permission to "Alternatively, this software may be distributed under the terms of the GNU General Public License". Removing the old license text of the header file and replacing it with GPL might be incorrect, and people are free to argue what a judge would say about it. It just seems very far from an actually issue, any proof of current believes, or what advices FSF gives.
They only fixed it after Theo posted angry messages on the OpenBSD mailing lists about it, the story got posted to Slashdot, it became a huge controversy and the SFLC got involved.
If it was, any proprietary work which are also derivative of the BSD work could then be "pulled" back BSD. People would get really upset if that happened.
Your first sentence is right, the rest is advocating copyright infringement. You have violated the GPL if you take someone else's GPL code and publish it in a BSD program — it's irrelevant that their patch was built on your software, their work is still their copyright exclusively under the law.
> how can you possibly have a fit over it being used in GPL-ed code
Because it's tasteless. Legal, of course, but tasteless. The person doing that is exhibiting a degree of hypocrisy in their refusal to pay it back to the original developer, while demanding that those who use their code pay it back to them. It's a "rules for thee but not for me" type of thing.
> The code is my copyright, and the patch is a derived work of something of mine; therefore I own it and it falls under my license.
This is a misapprehension of how software licensing works.
Not a lawyer, but I think the standard way to do this would be to "clean room" it. You notice that the GPL'd fork made this change, and instead of changing it you write to a co-developer "Our `name` variable is too short; it should be one byte longer. Could you fix this?"
The idea that `name` is short by a byte isn't protected, just the literal code.
(It's quite likely that this particular change is too trivial to be covered by copyright, but the chilling effects reach wide enough here that it might not be worth risking it.)
No you can't. Well, due to fair use you probably could without losing a legal battle over it, but for more substantial improvements you couldn't do that. Presumably you thought about this when choosing the BSD license (or when choosing to contribute to a BSD licensed project).
I believe that any improvements which are such that a source file still has only my name and copyright notice on it fall under the original license.
The original license forbids changing the license:
"Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer."
If you want to appropriate the code as GPL, you better do most of the work in new source files, or else change the file so significantly that (according to your lawyer) you're justified in replacing or altering the original copyright notice.
Anything that has only my name and my copyright notice on it is mine, even if it was modified. Whoever modified it acknowledged that it's mine by preserving the notices. It smells a lot like copyright assignment, and I suspect that very argument would easily succeed in court. I don't see how you can argue with a straight face that A. U. Thor is making an infringing use of your work, by taking an excerpt from a file which is "Copyright 2013 A. U. Thor".
There's nothing stopping a contributor from keeping your copyright notice, and adding his own license that only covers his own modifications. The contributor does not technically need to change the license of _your_ work, but he is free to chose whatever license he likes for his own changes to your code.
You should read phkahler's comment very carefully, because I think it's especially important that people with such strong ties to non-GPL licenses as yourself fully understand these licenses.
