Licensing Terms

I have released a few small programming efforts into the public domain over the past few years, one of which is pretty much a derivative work. When I have felt the need to add specific licensing terms, I have used the GnuGeneralPublicLicense. However from what I have read, the GPL is not necessarily the best fit for all software releases.

I was hoping that we could use this page to list various concerns which have to be addressed for a particular release, and also how specific licensing terms address them.


My two main concerns at the moment are:

--DavidMcNicol

Most authors believe it is a good idea to put a generic NO WARRANTY paragraph in their code, regardless of anything in the license. MAKE SURE THE NO WARRANTY PARAGRAPH IS IN FULL CAPITAL LETTERS.

The GPL is probably the best at avoiding "unnecessary" forking. Any forks from a GPL project will at least have full source available, so they could eventually rejoin (like GCC/egcs is doing). (But see the text below for some problems with the GPL.) Some people use a dual-license (GPL and restrictive) to allow the author to make a commercial version (like MySQL and Ghostscript). A popular strategy is to release old versions of the commercial fork under the GPL. BSD-style licenses allow commercial-only forks by anyone.

The GPL clause that forces modifiers to release their changes doesn't force you to incorporate them into your branch, so you retain control over your branch.

The right to fork gives anyone the right to create their own branch, but it never forces anyone to use one release over another. Even if a fork gained greater acceptance over your branch, you would still have the right to use your branch (and to incorporate whatever changes you want to it).


The main concern with GPL licensing is that it restricts usage of non-GPLed code in the same application, even if the other license is "reasonably" free. This can be a problem when the GPLed code is used like a library--it still restricts the entire application.

The "RIPEM/GMP" situation was a clear example of this problem. RIPEM is a Privacy-Enhanced-Mail system which uses RSA encryption. RSA uses large integers, and GMP has a portable and fast implementation of the needed functions. Version 1 of the GMP library was licensed under the GPL (NOT the LGPL). RSA encryption was (and as of early 2000 still is) considered export-controlled by the US government.

The author of RIPEM made his package available at no cost, including all source code, but required that users follow the export regulations. This was pointed out as a violation of the GPL which does not allow for such distribution restrictions. The RIPEM author tried to avoid the conflict in several ways, but none of them were fully satisfactory to all parties. (At one point it appeared to many that the FSF was asserting an interface copyright, which was hotly debated.)

The issue was only generally resolved when the RIPEM author wrote a new big-integer library without GPL restrictions ("FreeMP"). The RIPEM code could then be linked with FreeMP, or users could make changes to link with GMP. More recently, version 2 of the GMP library was released under the LGPL, which allowed it to be used in restricted programs like RIPEM.

The LGPL was originally known as the "Library General Public License", but RMS now wishes to call it the "Lesser GPL" (as it does not protect as much freedom to distribute code). The LGPL is like the GPL in most respects, but it has fewer restrictions on the rest of the application. (One of the remaining restrictions is that the end user must be able to relink the application with another version of the LGPL'ed library. This is not a problem for source distributions.)

There are various groups within the free software community which disagree about the scope and reach of the GPL. The GPL does not directly address dynamic linking or plugin functionality. Some people have asserted that a GPL application (like the Gimp--a package similar to Adobe Photoshop) cannot accept GPL-incompatible plugins. Another problem is that the popular KDE package (a desktop environment for X11) is licensed as GPL, but requires the restricted QT library. The KDE situation is made more difficult by the large number of authors who would need to give permission for license changes. Finally, several authors distribute their software under the GPL and another license. When a significant patch is submitted to a GPL version, it is unclear whether that patch may be applied to the non-GPL version. (When is a patch a derivative work?)

[The KDE problem was resolved in September 2000 when a version of the QT library was released under the GPL.]

I was slightly involved in the RIPEM/GMP situation, and finally accepted that the FSF saw the GPL as more important than the availability of cryptography. (The current (early 2000) stance of the FSF with regards to cryptography seems to be that US citizens should not contaminate the GNU efforts with export-controlled software.) I disagree, but I have some respect for their views. My latest project (UseModWiki) will be distributed under the LGPL.--CliffordAdams

[After a lot of thinking, UseModWiki's license was changed to the GPL. The LGPL contains several restrictions on linking (and other library behavior) which do not apply to scripting languages like Perl. --CliffordAdams]


August 2002 Update.

Matt Asay (a student of Larry Lessig) has written an interesting essay on why he has changed from GPL is anti-innovation to believing it's pro-innovation.

http://www.linuxdevices.com/files/misc/asay-paper.pdf

According to Asay there has been a profound shift in the last year regarding GPL. Many companies, especially in embedded devices, are using the GPL Linux as the core, dynamically-linked to their proprietary code. The new belief is that dynamic-linking relieves them from having to GPL their proprietary code.

Does anyone have any information about these claims? (a) is Linux being used this way, and (b) does the GPL allow it?

--IanRae


I have an XP-related question about LicensingTerms. Suppose while developing a product for a company, you developed some really useful class X. Class X is extremely modular, but was painful to write and wouldn't exist except for the project this company asked you for. Using class X in another company's project would save you and them time and effort. Is it wrong to do this? After all, isn't the second company benefitting unfairly from the first company's effort? If the license on the first product is still being negotiated, how would one negotiate it to free class X from the final product? Would I (the developer) have to foot the bill for class X, and hope to make it up by charging slightly for its inclusion in other companies' products?

--ScottWilliams


CategoryBusiness


EditText of this page (last edited November 16, 2014) or FindPage with title or text search