I would like us to figure out our licensing policy. So far the policy has been:
- If we’re building on some other code base, use the existing license.
- If we’re building our own code, make something up.
So, sometimes people will ask about some piece of code and its licensing, and I’m forced to kind of pull an answer out of thin air, obviously without a great deal of thought. It’s nice that we make everything open source — and honestly that’s pretty much all I care about — but we need to be a little more clear about what that means for other people.
So: what licensing should we use? I wrote a post about my own thoughts on licensing. In summary, I think the most practical choice is a permissive license on libraries (MIT, BSD, etc), and perhaps the GPL (v3?) on applications. Though if applications have functionality extracted into libraries then that involves license switching — fine to do internally, but if there’s external contributions it can become complicated.
Ideally, I would like as an end product a document that makes it pretty clear to someone when they start a project (of any size) what how that should be licensed. I’d rather it not document licensing in terms of options, as I honestly don’t think it’s worth the time to put a lot of thought into licensing on a per-project basis.
I like applications based on GPL, and libraries based on LGPL. I mostly like LGPL for its easy compatibility with GPL, and haven’t run in to any of the problems you wrote about in your blog. But any permissive licensing I think is fine for libraries.
In terms of extracting functionality to libraries, we more or less have a policy that GeoTools, the LGPL library that the GPL GeoServer is based on, can have pretty much any code they want from us. Since we generally start with most all library code in GeoTools anyways we haven’t had much of a problem with extracting app functionality in to libraries. I imagine that one way to work around that problem is to get people to assign copyright to us on applications. That gives us the right to chance license, but we should obviously be up front about our norms, that their code may be turned in to a more permissive license.
Comment by cholmes on May 6, 2008 at 5:19 pm
Any permissive license is also GPL-compatible.
I have in the past gotten some pushback about LGPL, but very little. Most people are fine with it, and the one’s who aren’t are mostly being pedantic. It is pretty vague, though, for any non-C library. To me it feels like a somewhat sloppy choice, and if you are going to be lax about licensing a permissive license seems like at least you are admitting it.
Someone did bring up a success story about WebKit, which Apple released properly because of the LGPL. I suspect this is a case where Apple would have otherwise simply been too lazy to release it. Apple seems like a very lazy open source participant.
If we do copyright assignment we could relicense however we see fit. But that’s a lot of overhead. We could also ask that any contributions are done under a more permissive license (LGPL or BSDish), and then we don’t need permission to include those in GPL work. Then the expectation is that the only GPL code is stuff we wrote and own, and thus stuff we can relicense freely.
Comment by ianb on May 7, 2008 at 1:27 pm
I’ve read your musings about the various licenses and I wanted to say something, but because some of it was on your blog, and not here, I was lazy and held off. I almost didn’t respond here, but since I just finished writing a plugin for Xinha, I was thinking about these issues, because I had to choose a license for the plugin.
Most of the Xinha code is published under the ‘htmlArea’ license, which is a slightly modified BSD license, kept mainly I think because the original source was htmlArea. Some of it, however, is CC shareAlike, and some of it LGPL. I think this is relevant, being that this is javascript code…
I, too, like the LGPL, because I can see the balance it strikes, but I don’t think there should be any confusion as to how it applies to javascript code. The LGPL does two things for software licensed under it. 1) Users receiving LGPL’ed software must receive the source for that LGPL’ed software so that they will be able to modify it. 2) They must be able to modify that software, even if it has been integrated into software that they are unable to modify.
The reason, I think, that people have C code in their mind when it comes to the LGPL is because of the clarifications it makes with regards to number two and compiled code. It clearly states that statically linked binary code doesn’t satisfy number two unless the original object files are provided; If they are, then the user can compile their own version of the LGPL’ed software, and relink to create a new whole using their modifications.
When it comes to Javascript (or any dynamic language for that matter), the first freedom seems to be the more obvious of the two, but the second freedom still ensures that a distributor won’t use an obfuscator to prevent modification of the LGPL’ed software.
The GPL is an even stronger license, because it guarantees a third freedom to end users. They will be able to modify and use any software that is made up of software that is any part GPL software. I understand that this freedom is frightening to proprietary software shops, because it affects their business model, and that is why some software is licensed under the LGPL, because the author would like to allow their software to be distributed more than would happen if the third freedom was ensured.
This is also the case for permissive licenses. If you care more about greater distribution of your software, and less about the rights of the users of your software, you can license your software under BSD, Apache, or MIT licenses, among others. Take the case of sqlite: It’s not licensed at all, it’s been released into the public domain*. The authors only cared about the quality of software in general, and preferred giving their code away to ensure that developers would stop using often buggy proprietary databases or file stores and instead use a database of higher quality. As an end user, I’m happy that sqlite is getting more and more use, as I’ve seen some of the truly poor persistent storage used by software developers.
Back to licensing, though, I think the (L)GPL is especially relevant to the web, since every time a user browses a page with javascript, their browser downloads and executes a piece of software. This is distribution of software on a massive scale, and the more that end users will benefit from open source software, the better.
Finally, I wanted to address talk of stealing code as being a motivation for open source software. While I know that I have much less open source code available, I AM worried about people stealing my software, just not from me. Each time someone writes a bugfix, or adds functionality to open source software that they don’t contribute, they aren’t stealing from me or the author, but from every other user of that software.
*I’d like to point out that the public domain doesn’t exist in Germany (and possibly other countries?) and so the best German users can hope for is that the authors won’t pursue them in German courts for use of the software. This is one case where a license would actually make it easier to distribute the code, than having it under the public domain.
Comment by douglas on May 7, 2008 at 4:18 pm
Javascript is in some ways easy, because all the source is out there by default. Except, of course, for obfuscation and compression, which I suppose has become fairly common these days. And in that, I suppose quite a few people are violating the GPL (without malice) by providing the compressed source without a link to the proper source.
But the LGPL is particularly difficult to interpret. All Javascript code is executed in the same namespace. Monkeypatching is fairly common. Is subclassing allowed with the LGPL? What if you make changes to facilitate your own proprietary extensions? If people in the Javascript world cared much about licensing (and they don’t seem to on the whole) then I suspect they’d be bothered by this ambiguity. But then what? If we’re using a license that is fine for people who don’t care about licensing, who typically don’t even pay attention to licensing, is there any point to a license that asserts anything?
“Finally, I wanted to address talk of stealing code as being a motivation for open source software. While I know that I have much less open source code available, I AM worried about people stealing my software, just not from me. Each time someone writes a bugfix, or adds functionality to open source software that they don’t contribute, they aren’t stealing from me or the author, but from every other user of that software.”
This is an important problem for which there is no licensing solution. No (DFSG-compatible) license compels developers to actively and usefully share their improvements and fixes.
Comment by ianb on May 7, 2008 at 4:48 pm
I wonder whether this will work with vacuum enabled and me logged in when commenting.
Comment by ejucovy on May 22, 2008 at 2:56 pm
Well that was stupid of me, of course I meant to enable vacuum first.
Sorry about the spam, Ian and planetdev.
Comment by ejucovy on May 22, 2008 at 3:28 pm