Wrapper library licenses

[aerique]

I am a couple of weeks away from releasing the first versions of three Common Lisp packages which all three provide an interface to a foreign library (a 3D engine, a physics engine and an input library).

Since I do not really know much about licenses my initial thought was to release them under the same license as the libraries they're interfacing to which are the: GNU Lesser General Public License, Zlib license and the zlib/libpng license respectively.

However I'm not really sure whether that is actually the smartest thing to do. I basically want people to be free to use my code how they like as long as credit is given where credit is due and as long as they don't misrepresent their changes to my code as being the original thing. By the looks of I'm totally free to slap on the license I want on my code, but perhaps someone can elaborate or suggest otherwise.

[gugamilare]

I am a couple of weeks away from releasing the first versions of three Common Lisp packages which all three provide an interface to a foreign library (a 3D engine, a physics engine and an input library).

Since I do not really know much about licenses my initial thought was to release them under the same license as the libraries they're interfacing to which are the: GNU Lesser General Public License, Zlib license and the zlib/libpng license respectively.

However I'm not really sure whether that is actually the smartest thing to do. I basically want people to be free to use my code how they like as long as credit is given where credit is due and as long as they don't misrepresent their changes to my code as being the original thing. By the looks of I'm totally free to slap on the license I want on my code, but perhaps someone can elaborate or suggest otherwise.

Licensing a CL library in LGPL is a mistake because CL libraries can't be dynamically linked (well, ECL is the only exception I know about), so a LGPL library in Lisp is the same as a GPL library, which will make your code only be usable if other people release their code under the same license. Instead, you should either choose GPL or LLGPL.

None of these licenses you mentioned are "viral" (for dynamically linking, which is what you are going to do) so you can even make a closed library if you want to. I'd say that your options are basically these licenses:

GPL: people can only use your library to make GPL programs, which means that they always will have to release the source code.

LLGPL (Lisp LGPL): people can use your library and release their code under whatever license they want. If they distribute your library for themselves, they need to provide the source code, and, if they modify your library, the modifications should be released as well. This does not apply to the whole program, only modified parts of the library itself. (This is the equivalent to LGPL, but accepts statically linking, not only dynamically linking).

MIT / BSD-style: this is the "do whatever you like, but don't remove the credit". This means that someone can modify your library, close the source code and put your copyright notice somewhere in the documentation of his program, saying that one piece of the code was made by you, but your code would not be there, neither modified nor unmodified.

All of these options will only allow the use of your library if the copyright notice is retained, so, your credit can't be taken away in any option you make. MTI or BSD-style licenses are the most used and the ones that I would recommend, since that people would give you suggestions to your program if they have suggestions. The first option will make people avoid to use your library. I would use the second option only to a big, important and useful library.

[Jasper]

Affero GPL everything the GPL does but also if the users use it via a network. (Not saying it is better then GPL, just that it exists.)

[findinglisp]

IMO, libraries should always be MIT/BSD or LLGPL, not GPL. Personally, I prefer LLGPL because I think it forces enhancements to be openly contributed back to the library without being completely viral and thereby shutting out people who want to use the library but don't want to completely open source the application.

Another option is MPL. It allows people to make changes to the actual code that you release, sharing those changes, but doesn't prohibit even direct linking to the code in question. It's less strict than LGPL.

In short, I work at an open source company (Vyatta, http://www.vyatta.com/ ) and yet I still think that creating libraries that taint everybody's code is a real mistake (GPL). I have no problem with people asking that enhancements, etc., be made public (LGPL and LLGPL in the case of Lisp) so they can be incorporated back into the library. IMO, any user of said library who thinks they'll gain commercially by enhancing a library, without regard to the application they are writing, is missing the point, IMO. I also don't have a religious aversion to closed-source code.

So, before you start talking licenses, it's important for you to identify your philosophy and your reasons for wanting to release the code into the wild at all. Once you have done that, the correct license is usually obvious. As stated by gugamilare, just about all these licenses have restrictions that prevent somebody from either removing credit or misrepresenting changes as being the original. That said, "giving credit where credit is due" depends highly on what you mean by "credit." If you want your source code comments to be preserved, you're good to go in almost all cases. If you're looking for 36-point font attribution on the application splash screen, almost none will give you that much credit.

[findinglisp]

Affero GPL everything the GPL does but also if the users use it via a network. (Not saying it is better then GPL, just that it exists.)

I personally hate the Affero GPL. Long-term, I think you will see people running away from it because it's very unfriendly to any business that uses open source code in any manner. One of the nice things about the original GPL was that you were allowed to keep your modifications private as long as you didn't distribute your code to anybody else. In other words, you had little intellectual property exposure if you were simply consuming open source on which to run your business. Only when you started to give/sell/transact your code did you have to worry about providing source, etc.

[Jasper]

So, before you start talking licenses, it's important for you to identify your philosophy and your reasons for wanting to release the code into the wild at all.

Why wouldn't you want to release code into the wild? In many cases, i don't see it being negative any time soon. Sure, you don't want to represent little-tested code as being easy to use and good libraries, but why not let other people look at it if they want. (Although they probably won't look at it.) By having a project website code, you can allow people to work collaboratively with you.

For libraries the GPL can indeed be too restrictive. On the other hand, that can be exactly the purpose. It has made a few projects GPL (clisp being one i know of, via readline) Same for the Affero GPL. There is also a licensing model where you give it with GPL to everyone that wants it, and a different license to people that pay for it. Thought qt did this.(dual licensing) In that way, (Affero) GPL for libraries can make sense. Of course it can be a little harsh against small(honest) companies that want to use it. Also if you use it all contributors to the code in question including those in the past must agree. (Since they presumably licensed it to you under the GPL, since they modified your GPL code.)

Btw which foreign libraries are you trying to interface to?

[aerique]

Thanks for the extensive answers and suggestions so far.

In case this helps the discussion the libraries I'm writing / have written wrappers for are: Ogre3D, Bullet and OIS.

(on that note: if you're a CL programmer looking for interesting projects, a native collision / physics library and a native cross-platform input library would be very welcome (a 3D engine as well but that's a multi-year job))

MIT / BSD-style: this is the "do whatever you like, but don't remove the credit". This means that someone can modify your library, close the source code and put your copyright notice somewhere in the documentation of his program, saying that one piece of the code was made by you, but your code would not be there, neither modified nor unmodified.

I don't think I would mind if this happened.

So, before you start talking licenses, it's important for you to identify your philosophy and your reasons for wanting to release the code into the wild at all. Once you have done that, the correct license is usually obvious.

I basically want people to use the above-mentioned libraries from Common Lisp however they want, even closed-source commercial projects, as long as it is within the parameters set out by the original libraries without being bitten in the ass by any licensing restrictions that I might unknowingly introduce.

That said, "giving credit where credit is due" depends highly on what you mean by "credit." If you want your source code comments to be preserved, you're good to go in almost all cases. If you're looking for 36-point font attribution on the application splash screen, almost none will give you that much credit.

Good point about what is meant with "credit". The source code comments mainly, I don't need the splash screen A little copyright notice in a long list of credits as well perhaps, but if they don't need to mention Ogre they definitely don't need to mention my little effort.

[findinglisp]

Why wouldn't you want to release code into the wild? In many cases, i don't see it being negative any time soon. Sure, you don't want to represent little-tested code as being easy to use and good libraries, but why not let other people look at it if they want. (Although they probably won't look at it.) By having a project website code, you can allow people to work collaboratively with you.

There are many reasons you may not want to release your code. Do you release all your code, all the time? If not, why not? There is your answer.

That said, I agree with you and generally try to make my code available as soon as it's in a state where I would actually want to support it.

For libraries the GPL can indeed be too restrictive. On the other hand, that can be exactly the purpose. It has made a few projects GPL (clisp being one i know of, via readline) Same for the Affero GPL.

Yes. I don't see that as an advantage. The CLISP license is notoriously screwed up because of that.

There is also a licensing model where you give it with GPL to everyone that wants it, and a different license to people that pay for it. Thought qt did this.(dual licensing) In that way, (Affero) GPL for libraries can make sense. Of course it can be a little harsh against small(honest) companies that want to use it. Also if you use it all contributors to the code in question including those in the past must agree. (Since they presumably licensed it to you under the GPL, since they modified your GPL code.)

Yes, it's quite common to have dual license terms, actually. MySQL made most of its money before Sun bought them by selling a proprietary version of their code to anybody who wanted to avoid tainting with the GPL. It was purchased primarily by other OEM companies building larger systems where they wanted to embed MySQL but didn't want the hassle of GPL.

One thing that many people don't understand is that if you're the author of all the code, you can release it as many times, under as many different licenses as you want to. You always retain the copyright, so even if you "get it wrong" and want to change it, that's easy enough to do. Under the GPL and other licenses, you can't stop anybody from distributing the code under the license they received it under, but you can make it such that all new versions that are put out by you use a new license. People are still free to distribute the other under whatever original terms you used for as long as they would like. Note that this only applies to code you have written, not to libraries or other code that you may have acquired somewhere else, and taking an outside contribution under a GPL license may then taint your code with that contribution. If you aren't the author of all the code, you would have to get the permission of all the other authors to change the license, or you'd have to remove all the other contributions and get back to just your own code. In practice, that's nearly impossible. People have suggested that the Linux kernel can never be changed from GPLv2 because some of the authors have already died, though that's actually false if you could find the surviving relatives who have inherited the rights and get them to agree. In practice, however, there are simply too many people to coordinate it.

[findinglisp]

I basically want people to use the above-mentioned libraries from Common Lisp however they want, even closed-source commercial projects, as long as it is within the parameters set out by the original libraries without being bitten in the ass by any licensing restrictions that I might unknowingly introduce.

Then you probably want MIT/BSD if you aren't concerned about getting any changes back into the public. If you want to force somebody to expose any changes or improvements, then you'd probably want LLGPL or MPL. Note that even if you choose MIT/BSD, it doesn't prevent anybody from giving changes back, and many people will (see, for instance, FreeBSD), it just doesn't require it.

Good point about what is meant with "credit". The source code comments mainly, I don't need the splash screen A little copyright notice in a long list of credits as well perhaps, but if they don't need to mention Ogre they definitely don't need to mention my little effort.

Perfect. I just wanted you to set your expectations correctly. Some people think that they deserve top billing and are annoyed when people are "ripping them off and not giving them credit!!!" It doesn't sound like you're suffering from that delusion.