I found a great article over here: A CIO’s Quick Guide To Open Source Licenses and wanted to make note of it.
One great benefit of using Linux, Apache, and other open source software is that you can modify the code to make it perfect for your business. But open source licensing restricts how you distribute the modifications. Here’s what a CIO needs to know about open source licenses.
Most open source software licenses have two provisions in common:
No limits on personal use, unmodified redistribution, or internal re-use. You can use the software as-is on your own, redistribute it, or modify it from source for your own use. This makes most every open source application immediately useful as an in-house productivity booster: you don’t pay anything to use it, no matter how many seats you deploy it on. And as long as you restrict the software to in-house use, you can modify it freely and keep the modifications confidential.
No warranty. You use the software entirely at your own risk. This is not always a comforting thing to hear, which is why any major open source software deployment should be cared for by a consultant or a full-timer to ensure it works.
Many licenses add two other stipulations:
Restrictions on redistribution of modifications. If you modify the software and redistribute it in binary form, you have to also release the source code for your changes. This prevents the software from being incorporated into a commercial product (or a web service) without the creators’ consent.
Derived works are under the same license. Any software you create by modifying the source of an open source licensed program has to be re-released under the terms of the same license.
Provisions vary greatly between licenses. The MIT/BSD licenses, for instance, doesn’t require redistribution of modifications; the Apache license doesn’t require that derivative works be relicensed under the same terms.
Now let’s have a look at the top five most commonly-used open source licenses and their implications. I’ve derived this list from a list of top 20 open source licenses as tabulated by Black Duck Software’s Open Source Resource Center, which tracks the usage of open source in many ways. Remember that this isn’t an exhaustive overview of open source licenses generally – there are many others not listed here, but they are typically variations on these five.
GNU Public License
The GNU Public License (GPL) and its derivates are the most widely-used free/open source software licenses around. That makes them a source for a great many powerful and useful applications. But “free” doesn’t always mean “do as you please.”
The rights granted under the GPL are at their core quite simple. You can use the software as-is for any purpose, without paying anything. But if you modify the source code and publicly release a version based on those modifications — that is, if you create a derivative product for public use — you must also release the changed source code under a matching license. Any programs you create from GPL-ed source must also be released as GPL. (This restriction doesn’t apply to programs written in a GPL development environment; those can be licensed any way you see fit.)
There are other provisions, but that one premise remains consistent across versions of the GPL: you must give back to the community any changes you make that are intended for public consumption.
The GPL comes in a few different iterations. Version 2 of the GPL, or GPL v2 for short, is the most commonly-used version of the license and works essentially as described above. Version 3, or GPL v3, adds (among other things) a provision involving software as a service: you can’t take a GPLv3 product, modify it, and then only release it in the form of a web service without also releasing your changes in source code form. For a good way to understand what you can and can’t do with GPLv3 software, the law firm De Bandt Keustermans and Van den Brande has created a bullet-point rundown[PDF] of GPL v3’s restrictions.
The LGPL, or “Lesser GPL” (also now in version 3), allows software under that license to be linked to and included with any other kind of software, be it free or commercial. It’s typically used for libraries or executables where the output is passed directly to other programs, and where the creators don’t mind its proper re-use in commercial applications.
Examples of GPL software: The Linux kernel (GPLv2); the OpenOffice.org productivity suite (LGPL v3); and the VLC media player (GPLv2).
Recommendations: Any modifications intended for public re-use need to be released as source code, with additional restrictions applying for GPL v3 software.
MIT/BSD License
The MIT and BSD licenses, also known as “permissive” licenses (sometimes “three-clause” licenses), could hardly be simpler. They consist of a copyright notice, permission to use the code as long as the copyright notice is left intact, and a disclaimer of fitness (no warranty, express or implied, etc.). The BSD license spells out the terms of attribution a little more explicitly — it requires notice of copyright to be retained in the binaries as well as the source. You are not obliged to release the source code for any derivative versions, just leave the copyright notice intact.
Because the MIT/BSD licenses are almost totally unambiguous, and software written under their terms has almost no practical restrictions on its use, such software has been re-used in everything from simple web scripts to full-blown commercial software. Mac OS X and the current Windows networking stack, for instance, both use BSD-licensed code — all perfectly legit, since re-using MIT- and BSD-licensed code in commercial apps is well within the intended scope of the license.
To that end, any code released as MIT/BSD can be re-used in most any context: as part of an internal project, as part of something for commercial or noncommercial release, and so on. Just remember to give credit where it’s due.
Examples: The original X Window system for UNIX; Ruby on Rails; and the Mono development platform class libraries are all MIT-licensed. The jQuery library for JavaScript is also dual-licensed under both the MIT and GNU GPL licenses. The family of BSD operating systems (for which BSD licensing was itself named) all use the BSD license, as well as Yahoo!’s YUI library. The Python language is released under a custom license that resembles the MIT/BSD licenses in that the main restriction is that you cannot remove the copyright notice from the code.
Recommendations: You can use MIT/BSD software as-is or modified in any context, public or private.
Artistic License
Originally devised by Larry Wall as the licensing terms for the Perl programming language, the Artistic License (currently in a 2.0 release) resembles the GPL v2 license but with some slight differences in how changes must be released.
You can use and redistribute unmodified Artistic License software without restrictions. You can also modify the original from its source, but you cannot redistribute it without doing one of two things: a) publicly release the changes in source form along with the modified program, or b) give the changes to the program’s original copyright holder. This way you’re not obliged to give changes you make to everyone, just the author—who can then optionally include your work in future releases of his product.
There are a few other restrictions: for one, the derived work cannot prevent users from installing or running the original version. But the redistribution policy is the most important one.
Examples: The Perl programming language, of course.
Recommendations: Any modifications for public use need to be either released as source to the public or provided to the copyright holder of the original code.
Apache License
Another license that was originally devised for a specific piece of software (in this case, the Apache web server), the Apache license is closest in spirit to the BSD license. You can redistribute modified versions of the software under completely different license terms. The main restriction is that every licensed file must have attributions, copyrights, or other similar notices preserved intact, and changes to any files (whether binaries or not) have to be documented in the modified version.
Examples: The Apache web server; the CouchDB document-oriented database system; and the SpamAssassin email filter.
Recommendations: Modifications should be annotated when released for public use, but there are otherwise few restrictions on repurposing Apache-licensed software.
Mozilla Public License
The Mozilla Public License, or MPL, works as a hybrid of the BSD and GPL’s approaches. MPL-licensed works can be combined with other proprietary software, as long as any MPL-licensed source code files are not intermixed with proprietary code.
For instance, if you have an MPL program that consists of a single C++ file, you could modify that one file freely and re-use it in a proprietary program. But you couldn’t make it part of another C++ source code file in the proprietary work; you’d have to keep both C++ files separate, and any changes made to the MPL-licensed file would have to be released to the public.
Examples: Mozilla Firefox, Mozilla Thunderbird. The Mozilla license has also spawned a few derivatives—the Common Development and Distribution License (CDDL), for instance, which has been used for OpenSolaris and other Sun projects.
Recommendations: Keep careful control over source code licensed as MPL, but remember that it can be re-used in proprietary programs where needed.
While open source licenses have a great deal in common, there are important differences. The software produced under those licenses can almost always be used as-is – it’s when you create derivative works from them that the restrictions of the license come most into play, and require the most attention. But those restrictions shouldn’t keep you from evaluating open source as a powerful asset.
Leave a Reply