These days, many companies are struggling with their ever-expanding software codebases. What to do with that set of homegrown libraries or data processing application? Maintaining it may be costly and requires engineers that could be working on new and innovative things. There’s an interesting option that is attracting more and more interest: open source it.
Open source software is freely available software which is licensed for use and modification, including commercial activities. Anyone may copy, distribute or embed the software as they see fit, without the requirement to pay royalties or even to negotiate a license agreement.
When code is available as open source, others can use and build upon it in ways that you might not have thought of. Instead of spending time and effort on the code on your own, a company can share these efforts with others and thus free capacity to work on new projects. And at the same time, the code remains available and even improves as third parties provide contributions.
However, open sourcing code isn’t as easy as putting up a zipfile with the code somewhere. Open sourcing is a long-term commitment that requires significant investments. A lot of open source is written by individuals or volunteer organizations, who tend to be critical towards companies that go this route. A company thus needs to actively contribute to the code and stimulate others to do the same. If the project is perceived as “something thrown over the fence” or as “offloading work onto the community”, few people will bother contributing. Only through hard work and patience can you build a community around your now open codebase.
Perhaps the most difficult issue when setting up the project is which license to choose. There are over 50 different licenses that are certified as open source by the Open Source Initiative, each with their own advantages and peculiarities. Some careful pruning will reveal that many are actually copies of others, but still a choice needs to be made.
The most important decisive factor is the requirement that the license puts upon derivative works: extensions and changes made by others to the code. There are basically three kinds of requirements, each with their own implications:
1. Free-for-all licenses: these licenses only require licensees to give credit to the original authors. Derivative works can be kept proprietary. Sometimes these licenses are referred to as “academic licenses”. Examples are the so-called BSD and MIT licenses as well as the license used for the Apache Web server.
2. Keep-open licenses: modifications to software under these licenses have to be made available as open source as well. Larger works incorporating such software can be kept proprietary. The GNU Lesser GPL (used for Linux system libraries) and the Mozilla Public License (used for the Firefox Web browser) are Keep-open licenses.
3. Share-alike licenses: when software under such a license is modified or extended, the result as a whole has to be made available as open source. The term copyleft is sometimes used to characterize this kind of license. The most famous example is the GNU GPL, which applies e.g. to the Linux operating system. Another example is the Open Software License (OSL).
Each of these three options can positively or negatively influence the growth of your community. With a free-for-all license, anyone can use your code for any purpose. The FreeBSD operating system, available under the BSD license, was for example used by Apple as the basis for its Mach operating system.
However, free-for-all licenses do not require others to share code, which means a competitor can “take” the code and build a proprietary, improved version of it. Whether this is a problem depends on how you expect your code to be used. The Ogg Vorbis project for example releases reference code for its audio and video codecs under such a license in the hopes that everyone will use it and so these codecs will become de facto standards. The risk that someone will create a slightly different, incompatible codec is small, so the potential for worldwide standardization outweighs the risk.
If you do want to prevent this kind of free riding, the logical choice is a share-alike license such as the GPL. The requirement of having to share extended or modified code prevents competitors from building proprietary versions. Put differently, if they do release an extension, you get to benefit from their contributions. In the consumer electronics sphere, several major companies got together in 2003 and decided to work together on adapting Linux for their respective CE platforms. In such a situation the license acts as neutral ground: no one party would be able to benefit without having to share back its own contributions. This ensured fair play between the CE Linux Forum members.
(Of course, the CE Linux Forum had little choice in the matter. The Linux kernel itself is GPL, and so any adaptations had to be GPL no matter what. But it did influence the choice of Linux over the FreeBSD operating system.)
The downside of share-alike is that not everyone wants to share – or at least to be /forced/ to share. There could also be concerns about how much needs to be shared. For example, if the software is intended for embedded platforms, using a share-alike license may require release of the entire embedded software stack as open source. Thus, you discourage some others from contributing to your open source project by going this route.
A compromise is to use a keep-open license, which requires sharing of modifications to the code but not other code. This allows a company to integrate the code in its own products without fear that the entire codebase has to be open sourced. However, it does open room for trickery to avoid having to share anything.
Of course, other factors may also play a role. Certain communities are heavily attached to ‘their’ licenses. If you contribute Perl code, you will have to use the Perl license (which is a keep-open license somewhat similar to the Mozilla license). In the Linux community, the GPL is strongly encouraged – but in the BSD community contributing GPL code is a big no-no.
Another factor could be that you want to benefit from existing open source, for example existing libraries or frameworks. These come with their own license, which may well be a keep-open or share-alike license. This limits your options, as now you’ll have to license modifications or even extensions of that existing code under the applicable licenses. For example, if the code heavily relies on third-party GPL code, you will be obliged to license at least many parts of the code as GPL. It may then be easiest to just license the whole project under the GPL.
After you have chosen the license, decide how to treat third-party contributions. This may sound strange: the whole point of open source is to get third parties to contribute. However, third-party contributions come with their own copyrights. Now, you can of course use them in the project, as the contributions are under the same license as the project itself. But if in the future you want to change the direction of the project, you’ll need permission from all contributors to relicense their contributions.
In many cases, this is a good idea, as it assures contributors that you won’t take their work and then turn the project into a proprietary royalty-bearing solution. But there are cases where more control is desirable – if only to make it easier to sue when people violate the open source licenses. In those cases, ask for a written copyright assignment.
In the end, the choice boils down to acceptance versus contributions. If you want to stimulate acceptance, use a free-for-all license. If you want to ensure you gain access to contributions by others, use a share-alike license.
That having said, an open source license is not a guarantee for success. No one will contribute code just because it is GPL or BSD. But with the wrong license your chances of a successful open source release will be slim.
This article apeared earlier in IEEE Explore.
