Omidyar Network has an ongoing interest in open source - the investments we make, the internal code we share, and our support for the community. David Hayes from Fenwick & West stopped by our office today to explore the licensing issues of open source. I thought it might be useful to share elements of our discussion.
The basics
Open source is a type of licensing model that doesn't require explicit acceptance of a license agreement. Under open source, IP is protected by copyright rather than patent. (This being said, we also think about open source as a development methodology.) Most people are under the impression that open source software is not someone's intellectual property - but it's the IP that allows open source licensing to even exist.
Richard Stallman (the writer of GNU) is generally recognized as the poppa of open source, and started the Free Software Foundation (FSF). Stallman's philosophy of 'free software' was focused on software that all people are free to use, not software free of cost. This distinction is murky for most. Eric Raymond and Bruce Perens later coined the term 'open source' when forming the Open Source Initiative (OSI), in an effort to clarify Stallman's concepts.
Why use open source
The primary reason that developers release code as open source is because of cultural perception, or cultural benefit. The other benefit is access to a technical community at no or little cost, while activity can be supervised to drive improvements. (Of course, developers may also release open source code because they have triggered a GPL or other viral license that requires it legally.)
On the other hand (not to use Ugly Money Words), there are business model incentives to use open source. Perhaps the code is not designed to be a moneymaker, and you would enjoy the leverage of viral marketing. Open source release can also help to compete against large competitors. Or at a basic level, there may be a need to focus resources on marketing and services, and you'd like to leverage free development efforts. If you're thinking about open source licensing for business reasons, there is also the attraction of a dual licensing model that provides for a proprietary offering in addition to the free/open source offering.
Types of licenses
The most common type of open source license is viral. This conditions rights on the release of source code. GPL, LGPL, Apache 2.0, Common Public License, Mozilla are all viral. Non-viral licenses such as the Sun Community Source License (SCSL) are subject to conditions. Open-ended licenses are similar to putting content into the public domain.
Viral licenses are the most complex, and there are several levels of viral control.
- Strong viral (GPL) is infectious; it contaminates other code it
touches, and requires the release of source code for the infected code
under GPL.
- Medium viral (LGPL) does not infect other code, but it does require
the release of source/object code of derivative works under the same
license.
- Weak viral (CPL, Mozilla) does not affect other code; it requires
release of source code for derivative works, but object code can be
under a different license. For example, a modified library has to be
put back into the community. Just using a library doesn't create any
requirements.
The OSI has a number of conditions for certification. (Most open source developers want to have OSI certification because Everyone Is Doing It.)
- Royalty-free redistribution rights; you can charge for service, support, etc but not for distribution
- Source code rights; does not have to be viral, does not require distribution in source form
- Allows modifications and derivative works
- Protects the integrity of the author's source code; this allows for patches
- No discrimination against people or groups; open means open!
- No discrimination for fields of endeavor; if someone wants to use your code on a porn site, they can
- Rights must flow automatically; you can't force others to execute additional licenses
- License must not be specific to a product
- License must not restrict other software that is distributed along with the licensed software
- License may not be predicated on any particular technology platform or style of interface
Selecting an open source license
Selecting an open source license is heavily influenced by whether or not you will pursue a dual licensing model. (No changing your mind later!) MySQL is a great example of this; you can either get the 'as-is' version and turn in your contributions, or you can purchase a proprietary license that comes with a warranty and services. (And BTW, the MySQL proprietary license will not require you to turn in your development work.)
Developers should also consider whether or not they want to use an existing license. GPL has a certain culture; Berkeley Software Distribution (BSD) is well-known by the developer community; SCSL allows for you to introduce custom conditions into your license. You may get flack for a custom license, but if that's what you need, it's best to start this way rather than change later.
If your license will be viral, you have to decide whether or not you will require release of source code. This might be triggered only if you distribute the software, or you might have to release your source to the community anyway. If it's viral, is it infectious? Are there any restrictions that you want to place on the license? (e.g., reproducing notices, giving attributions, giving notice of modifications, use of complete APIs that protect backwards compatibility, prohibition on or approval of commercial use, indemnifcation of all contributors)
Patent rights also need to be addressed. Most consider the GPL to include an implicit patent right, but this is NOT true. (If you intend to have patent protection, then get an explicit patent license!) You may also want to terminate a license if patent rights are asserted by any of the licensees - this is a more recent trend that prevents licensees from claiming a patent that uses your open source. As for copyrights, if someone creates a derivative work in open source code, you own the copyright to the derivative work. Most developers assign ownership of this copyright back into the community or to the free software foundation. (Note that assignments need to be in writing in order to be valid.)
Fenwick & West performed a survey of Sourceforge and Freshmeat content over the summer, and they found that licenses were 70% GPL, 6-11% LGPL, and 5-7% BSD. In addition, very large (or popular) open source projects tended to use a custom license. Apache, BitTorrent, Perl, PHP, and Python, for example, are all based upon custom licenses.
GPL terms
The GPL provides a license to copy, distribute, and modify in both source and object form. There are many conditions for distribution of the source. There are also some conditions for modification - for example, notice of changes made and the persistent infection of works based on/containing the program. Though none of this applies for separate works or aggregated works, it does apply to collective works. Naturally, no one agrees on how aggregated works and collective works differ. ;)
The scope of infection by a viral license like GPL is subject to debate. Although static linking creates a derivative work, does a DLL do so? What about loadable modules? GPL FAQs take the position that if modules are designed to run together in a shared address space, then they have been combined (and hence, infected.) Stallman thinks that dynamic linking creates an infection, but alternate open source guru Linus Torvalds does not. Hard to choose between these guys.
The FSF takes the position that GPL grants a patent license. This "could" mean that if you use some GPL-licensed code, your patent is now free to the world. :O We reviewed many opposing viewpoints in the session, let's just say it boils down to no one knows what this will mean when it finally gets litigated.
Many people use the GPL without realizing how onerous it is; they grab it because it's at the heart of open source culture, or because they are working on code that is already subject to a GPL license.
Apache 2.0 terms
Apache 2.0 has express copyright and patent licenses. Modifications contributed back are available to all under the license, and you can also distribute modifications not contributed back under the original license.
Mozilla terms
Copyright and patent licenses are allowed. Distributed modifications are subject to the license, and source code needs to be made available. Object code, however, can be independent of the license. Nicely, Mozilla requires that you reproduce all legal notices in your license - so licensees know exactly what requirements are in the code they use.
BSD terms
Redistribution and modification in source or binary form is permitted; source code redistributions must retain copyright notices and contain the license.
Creative Commons terms
The Creative Commons license is interesting because it's used by more than just software developers. Licenses are formed from a basic deed, which users then add conditions to. Musicians, for example, may prohibit derivative works. The licensee must make the license terms clear in distribution or reuse.
Best practices
Do an open source audit, and identify the open source that you've used. Search your code text for terms like "license", "rights", "copyright", etc. (If you aren't the only developer, there is undoubtedly some open source code lurking.) Differentiate between what's for distribution use and what's for internal use. Service companies should be very careful...if they become a product company someday, they can get slammed by their use of open source code on internal tools.
Set up compliance procedures. (The FSF does have an enforcement arm!) Do whatever remedial steps are required, and be careful to get rid of contaminated code. You can also set up an intake process that includes legal review, but this is not exactly what makes engineers happy.
All this being said...if you're looking to release open source, think about why you would do so. The answers will guide the license that you select.
Tags: christine herron spacejockeys technology best practices fenwick & west Web 2.0 best practices
