How Orchard deals with dependency licenses

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.


  • Thank you Bertrand.

    As a commercial start-up, my company takes licensing very seriously (as it should). Our commercial vision would not see the light of day without some use of open-source; we just don't have the resources to reinvent the wheel. The permissive license is the only open-source license that gives us the freedom we need at the cost we can currently afford without violating our use of 3rd-party proprietary licensing on which part of commercial offering is built.

    When it came to choosing a CMS platform, it was Orchard's ascendency, technology stack, features, and licensing that set it apart from the alternatives we considered. We are very grateful for this and to the Orchard community. For our gratitude, we give feedback, encourage others to consider Orchard as their platform of choice, and sincerely hope to contribute useful modules in future.

    Best wishes,

  • Thanks for explaining a topic I have found very difficult to understand and thanks for doing your part to keep Orchard "Permissive".

  • That's a really good article!

    One caveat that the GPL is a commercial license, i.e.: you can charge money for code licensed under it. What it doesn't do is allow PROPRIETARY derivatives. I have to correct myself often on proprietary and commercial not being synonyms.

Comments have been disabled for this content.