Theo de Raadt On Relicensing BSD Code

iBSD writes "KernelTrap has an interesting article in which Theo de Raadt discusses the legal implications of the recent relicensing of OpenBSD's BSD-licensed Atheros driver under the GPL. De Raadt says, 'it has been like pulling teeth since (most) Linux wireless guys and the SFLC do not wish to admit fault. I think that the Linux wireless guys should really think hard about this problem, how they look, and the legal risks they place upon the future of their source code bodies.' He stressed that the theory that BSD code can simply be relicensed to the GPL without making significant changes to the code is false, adding, 'in their zeal to get the code under their own license, some of these Linux wireless developers have broken copyright law repeatedly. But to even get to the point where they broke copyright law, they had to bypass a whole series of ethical considerations too.'"

Comments

Still confused

[Kelson]

For the last decade+, people have been claiming that the BSD licenses are more free than the GPL, because they effectively place no restrictions on what you can do with the code. Now we're being told that there are restrictions on what you can do with the code.

Re:Sure, but

[Anonymous Coward]

The GPLers didn't strip the licence. The code was available under either licence. What gets me is that Theo De Raadt is arguing that both licences apply so they couldnt remove one. He seems to not realise that if both licences applied then they couldn't use the code in FreeBSD anyway because they would be bound by the GPL parts of the licence. Funny that they kicked him off the NetBSD team for being so hard to work with. I wonder why ...

IANAL, but I actually agree with Theo

[einhverfr]

BTW, I am an avid Linux user, and I think that the Linux kernel developers who made the error made an honest mistake. Let us treat it as such.

Unfortunately, the more I do my own research, the more worried I am about Theo's main complaint-- that the SFLC may be giving out advice that seems questionable to me.

While IANAL, I say so based on my own understanding that it is nearly impossible to sue lawyers for malpractice and so we *all* need to develop a basic understanding of the law in areas which are relevant. Here are specific points I would make:

1) While the BSDL and related licenses clearly do not have the intent to force sharing of code, they clearly *do* have the intent to provide the downstream recipients of the original elements of that code with the rights listed in the license. So Theo is right that you cannot simply wrap the BSDL in the GPL.

This is particularly relevant to the GPL3 because it introduces potential license incompatibilities between BSDL-code and GPL3 code (see section 7 on removing additional permissions *without* asserting copyright).

2) Copyright law seems even in the US holds that nonexclusive licenses are clearly indivisible and do not automatically grant sublicense rights (a sublicense being a new license issued by a licensee). Some BSD-like licenses (like the MIT License) explicitly allow sublicensing the code and in this case, wrapping it in the GPL would be allowed. Otherwise, it seems difficult to make this case. Whether exclusive licenses are divisible is not yet a settle matter of law as far as I can tell (you have the Gardner v. Nike case which suggests that they exclusive licenses are indivisible, but that is the only case I can find).

BTW, Mr Moglen dismisses the above issue without providing any substantive argument against it.

3) Some BSD-like licenses seem to be addressed to all downstream users and do not include the right to sublicense. The ICU licnese, for example, and the X.Org licenses start out "Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files..." and does not specifically state a sublicensing right.

Thus I am not sure that the advice that these can be automatically sublicensed under the GPL is advice that is sound.

For these reasons, I have been suggesting that open source project leaders should seek unbiased legal advice from people outside the community.