Bardbarian on Steam - coming s…
A Meandering Path to an Evolvi…Quick as a FlashThings Every ActionScript Deve…Making Money with Adobe AIRUsing Flash for 3D Game MMO UIUtilizing Flash for Game UI De…Why I (Still) Love FlashMy Favourite Things
Posted on July 1, 2008 by Grant Skinner
Source Code Licenses
I think there is a critical lack of understanding about the implications of different source code licenses in the Flash and Flex world. As my company has grown, and we have tackled more critical projects for larger clients, I have had to educate myself and my team on this topic.
I think this is a hugely important topic, so I’ve devoted quite a lot of time and energy to research and synthesize information on some of the most popular source code licenses being used in the Flash community today. I would also encourage you to spread this information around, either by linking to this article from your blog, or by sharing its contents with your colleagues. Hopefully it helps developers sharing their code to choose appropriate licenses (I’m getting sick of seeing LGPL source code), and also help the community to use shared source code legally and appropriately.
While I have worked hard to research everything in this article, I am not a lawyer, or an expert on this topic, so I make no claims that it is accurate or correct. It is also written from the perspective of someone who releases free code, and runs a service oriented development shop. Implications may vary for product development.
Below you will find an overview of some of the most common open source licenses. I have tried to list them in order from most restrictive to most permissive.
Implicit Copyright (no license specified)
There is a general misunderstanding that any source code released without an explicit license is in the public domain (see below) and is free and clear to use. In fact, quite the opposite is true – any source code released without a license is afforded implicit protection under copyright law. This applies even if there is no copyright notice.
Without specific permission from the author, you cannot legally utilize unlicensed code in your projects. The enforceability of the publisher’s rights is somewhat unclear with regards to source code (especially you have significantly modified the source code prior to distribution), but it is better to be safe than sorry.
If you want to use publicly released code that does not have a license explicitly specified, I would encourage you to contact the developer and ask them to re-release the code under an MIT license.
GPL GNU General Public License
The GNU General Public License is a “viral” license, meaning that it must be applied to any source code that interacts with GPL libraries. According to the Free Software Foundation (FSF), this includes dynamically linked libraries.
You are free to use GPL libraries in commercial projects. However, if you do so ALL of the source code for your project must be made available under GPL to anyone “who comes into possession of a copy” of your project. This means that your client’s competitors could potentially take the code, and legally deploy it for themselves. Very few clients are going to agree to that.
Note that server-side code is an exception because the application is never in the possession of the end user. Exactly how GPL applies to web application built in Flash, which execute on the client machine, but aren’t installed software is a subject for much debate.
You are also required to display conspicuous copyright notices in your program, and provide the full text of the license with it. Exactly how this applies to web applications is unclear, but putting the notices and a link to the license text in the application’s about box would probably suffice.
LGPL GNU Lesser General Public License
LGPL is very similar to GPL, with one major difference: It specifically allows you to dynamically link LGPL libraries into your project without having to release your source code under LGPL. Direct derivatives of the LGPL code, including modified versions or subclasses, must be released under LGPL.
Another requirement is that any LGPL libraries in your project must allow reverse engineering for reverse engineering, and you must allow the user to swap those libraries for newer versions.
While it is technically possible to dynamically link libraries in AS3, there is no easy mechanism to do it. Loading classes at runtime is easy, but compiling against a library without compiling it into your binary still requires some messing around.
Further, it is unclear how you would satisfy the requirement that a user be able to replace LGPL libraries in a web application.
You also have to be careful when subclassing any code covered by LGPL. Subclasses are considered direct derivatives and subject to LGPL, which means they must be dynamically linked in your project (otherwise your whole project will be subject to LGPL).
LGPL has effectively the same attribution implications as GPL. You must provide copyright notices and the text of the license, as well as information on obtaining the source code for the LGPL libraries.
MPL Mozilla Public License
MPL is a very permissive license. It allows commercial use and derivative works, and is very lenient in its definition of covered code. Only files that were modified in the original MPL libraries, or that contain code copied from such a library are required to be re-released under MPL. Unlike LGPL, there is no requirement for dynamic linking – libraries can be compiled into your project.
Besides releasing any modifications you make to the MPL libraries, the only important requirement is that you must include advice on where to get any MPL libraries in the project (in the about screen, for instance). As long as your client is okay with this condition, it should be no problem to utilize MPL code in a project.
BSD 3 & 4 clause versions
The BSD license is a very simple, permissive license. It allows you to use the source code however you’d like, requiring only that you include the copyright notice and license text in the covered source code files and in the documentation for your program.
An older 4 clause version of the license required all marketing materials for a program to include credit for the author of the BSD licensed libraries. This has since been rescinded, and it is unlikely you will find modern code libraries using the 4 clause version.
The attribution requirements are the only real implication of using source code covered under the BSD license. As long as it is the 3 clause version of the license, and your client is okay with the copyright notice and license text appearing in the covered source code, and in their documentation (this could probably be a document linked from the application’s about box), you should be fine.
You should be very careful using any libraries licensed under the 4 clause BSD license in commercial projects. Clients are unlikely to be happy if they need to include attribution in every banner ad or radio spot they run.
Apache License version 2.0
The Apache License version 2.0 has similar conditions to the BSD license, but is more verbose and specific, covering a broader range of intellectual property issues. Source code under AL2 can be used for virtually any purpose, but you must retain all relevant IP, licensing, and attribution notices in the source code. You may also be required to display these notices in either a “NOTICE” file or in an appropriate location in your binary.
ASL2 is a popular license with the Cold Fusion community.
As with the BSD license, the implications of using AL2 libraries are mainly limited to the attribution requirements. You must retain the notices in the source code, and you may also have to display notices in either an accompanying NOTICE file, or in the about screen of your application. The latter is required only if a NOTICE text file has been included in the original distribution.
The MIT license is very simple and very permissive. It allows you to do whatever you want with the licensed code, except remove the license and copyright information.
Because the only requirement of the MIT license is to retain the header in the source code, there is generally no problem using MIT licensed code in commercial projects.
I release most of our publicly available libraries under MIT, and I encourage other developers to do the same.
In order for a work to enter the public domain, the owner must explicitly dedicate the work to the public domain. Once they have done so, they release all rights to the work.
Work in the public domain is theoretically completely free of encumbrances. This is potentially qualified by the specific wording of the public domain dedication that the owner uses.
Creative Commons offers modular licenses that allow a developer to select the conditions that meet their needs. For example, I could create a license that allowed commercial use, derivative works, and did not require attribution. Or, I could create one that did not allow any commercial use or modifications, and required attribution. They also offer versions of GPL, LGPL, and BSD licenses, as well as a Public Domain Dedication.
One of the really nice things about Creative Commons licenses is that they include a human readable summary of each license in addition to the full legal text.
It is important to note that the “modular” Creative Commons licenses are not intended for use with software.
Dependent on the license used.
If “shared” source code does not have a license, it is covered by copyright law, and is very risky to use in commercial projects.
The GPL and LGPL licenses are quite restrictive, and it can be difficult or impossible to utilize code covered by these licenses in commercial projects. The former due to its viral terms, and the latter due to technical difficulties meeting its requirements.
The other licenses listed here are more permissive, and libraries covered by them should be usable in most situations. It mainly depends on your client’s tolerance for including copyright and license information in their source code, documentation, or compiled application.
The most important thing to remember is that regardless of the type of license public source code is released under, you have a responsibility to clear its use with your client prior to implementing it in a project. Hopefully this guide helps you to explain the implications of doing so to your client in a concise, easily understood manner.
Another thing to keep in mind is that it is always a good idea to carry out due diligence, and attempt to verify that whoever is releasing the source code under license has the right to do so. It is a little unclear what the exact implications are if you incorporate source code that was incorrectly released under one of the above licenses, but it’s unlikely to be good.
I would strongly encourage developers to release shared code under the MIT license. When I release source code, it’s generally to help other developers with their day to day work, not to impose painful restrictions or requirements. My goal is to encourage the free sharing of helpful code, not force it (as the GPL does). I always appreciate attribution, but understand it’s simply not possible on some projects.
I would also encourage developers to petition the owners of their favourite shared libraries to change their licensing to MIT, if they haven’t already.
Did I get something wrong? Do you have more information to add? Please let me know in the comments. I will happily update this article with more accurate information as it comes in.
Follow @gskinner on Twitter for more news and views on interactive media.