Managing dependencies in any project presents challenges, but open source adds its own constraints. In the wake of the release by Microsoft of new and useful libraries that are unfortunately encumbered by unacceptable licensing restrictions, I thought it would be a good time to summarize how we do things here in the Orchard project, both to get feedback and to give ideas to others facing similar challenges.
Early in the development of your project, you’ll have to choose a license. There are roughly four typical categories of licenses, and then some minor variations:
- Proprietary: no derivative work or redistribution is allowed without authorization. An example of that is Microsoft Office or Windows EULAs.
- Dual open-source and commercial: usage is allowed in open source projects, but commercial applications fall under a proprietary license. An example of that is RavenDB.
- Copyleft: derivative work and redistribution is allowed and encouraged, but only under a similarly copyleft license. An example of that is Gnu Linux. The restrictions are an explanation for the controversial claim by Ballmer that GPL is “viral”: if you choose to use a GPL project, any derivative work must be done under GPL or an equivalent. Copyleft licenses are often used as the open-source half of a dual-license, as they are efficient at forcing commercial applications to not use the free version, lest they become free themselves.
- Permissive: derivative work and redistribution is allowed and encouraged, even for commercial projects. An example of this is Orchard.
Orchard is under BSD, which is a permissive license. This means that you may use Orchard in pretty much any way you want, including to build commercial proprietary platforms. We wanted anyone but the most obtusely opposed to open source firms to be able to use our platform in any possible way, without restrictions.
The main consequence of our license choice is that downstream restrictions are non-existing. Upstream restrictions do exist, however. We’ve basically taken the constraints for ourselves so that you don’t have any as an Orchard user. It’s a very user-friendly strategy.
By upstream restrictions, I mean that if we want the end product to be so permissive, we can’t include any components that would force a change in the final licensing terms. Specifically, we can’t include anything that isn’t under a permissive license, because only permissive licenses lack any “viral” characteristic.
In particular, we rejected RavenDB as a possible data store because of its dual license. It would be no problem at all for us to include it, as we are open-source, but downstream commercial users would then be forced to buy a license.
Similarly, we rejected and replaced several GPL-licensed components because they would have imposed unacceptable constraints on our commercial users, in addition to forcing us into a copyleft license.
Proprietary could be an option, if free redistribution is allowed, even without the source code, because we take dependencies as binaries and are not particularly ideologically-driven. It has not been the case so far however, as proprietary software usually comes with many caveats.
The choice of a license for an open-source project is an important step, not just because it will affect your users, but also, and this is often overlooked, because it will affect the range of acceptable choices of dependencies. Choose wisely, knowing if you want to impose the necessary constraints on yourself or on your users.