dual-licensed mole mountain

As is popping up in various places in my blog roll..

Someone proposed a patch on LKML that removes some BSD license headers and replaces them with GPLv2 headers. I've previously hinted at my licensing preferences, but they don't even come into play here, oddly enough.

I'll start with what I believe to be the logic of the people in favour of the patch. In code that is "dual-licensed" GPL/BSD, you must satisfy both licenses. Since the GPL is by far the most restrictive, the BSD license becomes moot and the code is essentially only licensed under the GPL because it's requirements are stronger. So removing the BSD license headers is basically like removing dead code.

The main opposition for this seems to be a bunch of BSD fan boys (as in a subset of BSD users) - and by that I mean they're the ones that are yelling loudest. This is probably how and why it spread so far, which is unfortunate.

From what I can see, there are some actual issues behind this though.

First of all, the word "relicensing" is really a bit of a misnomer in this context. Unless another individual is granted the right, through licensing, then only the original author can release their work under an alternative license. All of these licenses have one thing in common: they grant limited rights to the user of the code. Some think the BSD license is unrestricted, but the fact that you must include the copyright notice is actually a restriction. And contrary to some opinions, it doesn't give you the right to relicense the code.

Secondly, "dual-license" has different meanings in different contexts.

On the one hand, you have Qt and MySQL. Both projects are "dual-licensed" as proprietary code and under the GPL. In this case, "dual-licnesed" means that the original copyright holder (Trolltech and MySQL AB, respectively) offer their product under two distinct distribution models. You can use their product under the terms of the GPL, requiring all of your work be "infected" by that license, OR you can pay them a licensing fee so that you can use their product under the terms of their commercial licence, allowing you to do whatever you want with your source code without restriction.

On the other hand, you have code that was originally released under a BSD license by the author. This code is then extended by someone else. This second developer happens to like the GPL, so they tack the GPL on to the header, to cover their modifications. This code is now "dual-licensed" because it is covered by two different licenses. To use the code as it stands, you must satisfy the GPL AND the BSD licensing requirements, leading to my suspected logic described above. What really happens here is that the code becomes useless to a broad set of people because it is hard to separate the differently licensed code. You can't come along and relicense the whole thing as GPL without the permission of the original author who released under a BSD license.

And then on the third hand (yes, we're dealing with mutants), there is code that is explicitly "dual-licensed", where the file header has wording to the effect of "this code may be redistributed under the terms of the GPL OR the BSD license". This is the form of dual-licensing that actually works as people expect. You take the code, you modify it, and you release the derived work under your pick of the two licenses (or continue the dual-license trend), and everyone is happy. The copyright holder has granted you the right to do this.

In the end, the real problem is that the code in question is actually in two parts. One part falls solely under a BSD license, which can't be relicensed except by the author. Modifying this part in the Linux kernel and added a GPL header results in the second form above. The second part of that driver, however, falls under the 3rd variety (explicitly dual-licensed), and can therefore actually be relicensed as proposed.

In the end, what should have happened was something along the lines of:

"here's a patch to make some dual-licensed code GPLv2 only"
"hey, only some of that code is dual-licensed"
"oh? hey, you're right. my bad. fixed."
"cool. wanna grab a beer?"

Instead we got:

"here's a patch to make some dual-licensed code GPLv2 only"
"hey, that's not allowed! I'm telling!"
"oh? hey, you're right. my bad. fixed."
"too late, I've already told everyone on the internet and they're gonna come beat you up"

It even hit digg, so now we have a real party!

Assuming my post doesn't fuel the "debate", this should be over soon. As far as I'm concerned, the only result that matters is that it motivated me to write about it.

So go now and have non-discussions about this with your peers.

Have you cake and run windows too!

Some people are for porting Linux apps to Windows, some people are against. Pretty straight forward, right? Well I can't tell anymore. Take a look at Nikolaj's "rant", and then take a look at Aaron's rebuttal. I think they're both right, and I don't think that's a conflict. For anyone not following along, Nikolaj thinks porting Amarok to windows is good because of X and Aaron thinks he should be more concerned with Y.

I'm a Linux geek, and proud of it, but for some reason, I'm posting this from windows. Granted, I've got putty and an X server running, so I've actually got access to all of my linux/KDE stuff on my other workstation. I'll also ignore the part about me really wanting to use OpenBSD instead, but not having the guts to go all the way. There are a couple things I need windows for here at work, and they're non-negotiable and like a pizza special, there are no substitutions allowed (believe me, I tried). Damn I love pizza.. with mushrooms, and ham, and green peppers.. oh and the cheese all over the place.. wait, where was I?

Right, so what I'm trying to say here is that I want to be able to run KDE natively on windows because I can't run it natively in Linux, and X forwarding (especially across platforms) isn't perfect. This is a very practical reason to port Linux only apps to windows. Of course, Aaron is somewhat sidestepping (or maybe de-emphasizing is a better word?) the practicallity issue by taking the higher road and bringing ethics into the picture.

Finally, a chance to use one of my favourite movie quotes...

"Yeah, but your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should."

I think that makes Aaron's point pretty well (and if I'm lucky, he'll confirm or deny that..).

Should people port Linux apps to windows to make my personal life better? Sure, why not? (hey, isn't that both Nikolaj's point, and Aaron's question?)

Should they do so at the cost of the whole open source movement? Ok, that's a bit dramatic, but it makes the point I think.

There sure seems to be more at stake here than just the apps. My question is this: are Linux and other free(dom) platforms really at risk as a result of this? Worst case, it stays the way it is - which some elitists would love. Well, I guess it could be worse than that, but the elitists would still love it. Of course, without money on the line, all we'll ever have is anecdotal evidence for or against that opinion. (And of course, with money on the line, we get skewed results.. damn)

To put it plainly, I don't think having all of KDE available to windows users will hurt Linux or any other free(dom) OS.

Personally, I prefer a vision of a future where the OS is a commodity, and what people really care about are the apps, or even better, the functionality of the apps. Give people the freedom to choose their OS with no strings attached (unless you're counting financial cost, in the case of windows). THAT is a noble cause, in my mind.

To put this in terms of popular licenses (disclaimer: I'm not trying to imply their license preferences).. Nikolaj puts forth a practical commercial license, and then Aaron rebuts with the GPL.. and now I raise them both, with BSD. As I've hinted at in a previous post, I tend to favour imperfect total freedom over perfect partial freedom. Especially in this case, where we're talking about either doing something, or debating at length why not to do something (while everyone sits around looking funny). I say just do it. If nothing else, it'll make for a great movie one day ;-)

And finally, to directly respond to Aaron's challenge to Nikolaj, "...provide some sort of game plan for how it won't." How about somebody good at planning come up with this plan, while someone good at programming comes up with a port. First one to finish wins.

If this is all too heady and philosophical for you (and because I have no other logical reason to point out this link), I suggest you do as Steve Yegge suggests, and go write your own compiler. According to him, it should take you a life time to finish. And in his usual style, it'll take you a while too read too. Sounds like a perfect distraction from "big questions" like these. ;-)

That's what I call freedom

SQLite. I've known about it for a while, but never really looked into it or at it in any detail.

It's small, efficient, widely used, comes with gobs of automated tests, written in C.. a true thing of beauty. Oh, and apparently it's been public domain all this while, and I just didn't notice.

Very refreshing, especially in light of recent licensing "debates" between FSF members, Linus, and even Theo. From an idealistic point of view, I think I like the idea of public domain the most. From a more pragmatic point of view (as in something I'd use for my own code), I prefer the BSD style licenses. If I managed to make something so cool I just had to share it, I'd want to have my name all over it, as a matter of pride. Of course, the trick with licensing is you can only move to increasingly restrictive licenses unless you have permission from all of the contributors. And even then, it's really more of a fork.. anyway, not important.

I'll have to remember to make an effort to include SQLite in my projects.

Possible future topics in the same vain of praise for coolness: Open{BSD, SSH, BGP, CVS, etc.}, suckless.org, KDE, Qt, and many others I can't think of off the top of my head.