Relicensing: what's legal and what's right

I think the BSD community - or at least Theo de Raadt - finally sees the value of a copyleft license. His interpretation that the BSDL already is a copyleft license however is severely flawed. It isn't. If OpenBSD was under MPL, it would be true, and commercial vendors still could include this code into proprietary projects - but then they would also be forced to contribute changes back (you can put MPL code into "larger works" under different licenses, but you still need to retain the MPL on the files originally under MPL, even if you have modified them - so a MPL project incorporated into a GPL project will be "dual-licensed" forever. There are many open questions about this - one is whether the GPL actually permits to be merged with MPL code without special permission by the authors - but that's the idea at least).

The moral implication however is clear: If we accept that it's ethical to share code (as both the FSF and the BSD proponent claim), then we find that it's also more ethical to make licenses compatible, because incompatible licenses prevent people to share code between projects. I fully agree with that part of Theo's diatribe.

Theo is completely wrong on his legal argument. That doesn't mean he's wrong when he says it's rude not to dual-license further changes. Rudeness is, after all, something he knows far more about than most of us.

Non-BSD people often wonder at the seeming logical loopiness in BSD license reasoning. However, there is method to be discovered there, although it took me a long time to find it. The freedom BSD people want to retain is the right to take the code they have written (and the code in which it's embedded) and use it in any employer's product, even if that product will be proprietary. If they and their colleagues release their code under GPL, then the list of employers where they can use their own code gets much smaller.

"The copyright in a compilation or derivative work extends only to the material contributed by the author of such work, as distinguished from the preexisting material employed in the work, and does not imply any exclusive right in the preexisting material. The copyright in such work is independent of, and does not affect or enlarge the scope, duration, ownership, or subsistence of, any copyright protection in the preexisting material."

So if you start with a dual licensed file, and add additional material, the dual license only necessarily extends to the pre-existing material. The additional material is copyright by the author - who may license those additions in any way he pleases, provided that distribution of the whole is consistent with the license that governs each of the copyrighted portions.

You've read that backwards. The whole point of derivative work copyright is that the first author has rights over the entire derivative work done by the second author. (A classic derivative work is a translation. The translation contains no words from the original work, but you still need the original author's permission to copy the translation).

This section says 1) you don't need the second author's permission to copy the first author's pieces; and 2) the permission you need from the first author to copy the derivative work isn't any greater than what you need to copy his original work. In particular, his clock runs out N years after the original was published, not N years after the derivative was published.

If you can't do that, then you can't distribute the combined work.

Also, according to the FSF, you can't work around this restriction simply by making two different files containing the different parts and letting the user combine them herself: even if they are not part of the same set of files, they still (legally) constitute a single derived work (again, according to the FSF--there are some who disagree with this concept either in whole or in part). Since none of this has been specifically tested in court (certainly not in the U.S. and I don't think anywhere, although other aspects of the GPL have been tested and upheld in various courts around the world) it's hard to know the detailed legalities.

However, the way in which the FSF wants the GPL interpreted for software they hold copyright to is very clear, so ethically, at least, we should obey their wishes regardless of the legal force behind them. Similarly, Linus's interpretation of the GPL as it applies to the Linux kernel, while different slightly from the FSF's I think, is also fairly clear.

As for "however when someone relicenses a BSD (or ISC) licensed work this isn't the case" - that's simple - the work was licensed under BSC (or ISC) licence in the first place, which doesn't have the above "demand", not even in the preamble, so why would anyone have to follow it? GPL's "demands" cannot apply "backwards".

The reason for being able to distribute BSD licensed code under the GPL, is the fact that all three requirements from the BSD licence are met by shipping under the GPL too. Contrary to this, the advertising requirement from the original BSD licence cannot be met, so that licence is incompatible with the GPL.

You may also check these links out:

http://www.gnu.org/licenses/gpl-faq.html#WhatIsCompatible
http://www.gnu.org/licenses/gpl-faq.html#OrigBSD

This because the meaning of "all the rights that you have" depends on the license. So GPL people in general think that the rights given by GPL should be passed along, but that doesn't automatically mean that they agree that any rights you have should be passed along, no matter what those are.

But the BSD license doesn't allow relicensing anyway:

"Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer."

So your example is moot, it can't happen.

The current mess is because someone did it anyway, which was rectified, and because everything is muddled up with another case where there was a dual license and the BSD part was dropped.

More blahblah about dual license stuff below:

Now there is another thing that makes it more complex, and that is that a work/program is the whole thing, and not a small part of it. Throw in that an author always has more rights than recipients, and it becomes murkier. If not making a special case for the original author everyone following that preamble should put his work in the public domain.

So assuming that the original author has some leeway, that we're dealing with a dual licensed work, and modifications are done and redistributed under only one of the two licenses, then no rights are withhold. Sure, the work isn't distributed by the other license, but the modifications, which are new, may not be distributed under that other license, and thus the license of the two which was chosen is the only valid one for the whole work/program.

Adding a dual license for the unmodified parts doesn't make much sense because people can better get that from the original source.

I do not understand the argument of the OpenBSD people here.

If the license does not clearly states what the OpenBSD community expects, they need to modify the license. And if they want proprietary vendors to do whatever they like with the code and not give back (even if some do), but on the other hand (morally) demand from other Open Source projects to behave different. Then they should make a new license that makes it so.

It seems the OpenBSD people love to cry foul, but whenever they err, the subject is changed and no apologies. I would respect them a lot more if they were more honest in public communication.

I am grateful for the contributions they have made, but I equally disrespect them for their public noise and propaganda. Being trigger happy does not earn you any bonus-points. Quite the opposite.

The latter is completely impractical in a project with any number of
authors. What do you do: put a comment beside every single line giving the
initials of the people who worked on it? (Putting a comment at the top of
the file isn't good enough: it doesn't say *which bits* of the file were
changed). Both of these will make the program uglier and ruin automated
merges.

I suppose you could force each author to never modify a file that anyone
else had touched, but that would result in code that had essentially
arbitrary divisions into source files: i.e., an unreadable, unmaintainable
mess. (Because most languages imbue `file scope' with semantics of some
kind, it may actually be impossible.)

In practice this data can only sanely be stored in a version control
system (which is, of course, exactly what happens already). This means you
can't look at a printout and be sure who wrote what, but that's a tiny
price to pay given the enormous costs of working the way you propose.