Sorry, you need to enable JavaScript to visit this website.


BY jim curry ON Oct 19, 2017

Open Source Hacks: Open source software licenses 

This blog series aims to share simple philosophies, insights, tips, and tricks that can have a positive impact on your open source adventures. Each blog will feature a guest expert providing their thoughts on one open source question.  Today’s expert, Jessica Marz, answers this question:

“Which open source software license should I use for my project?”

I get asked that a lot. Or this variation, “What are your preferred open source licenses?” My answer: It depends.

I’m not trying to be flip; really, IT DEPENDS! No single open source license is appropriate for every use case or objective. And I have no “preferred” open source licenses—sure, there are some I find myself using or recommending more frequently, but as long as it has been approved as an open source license by the Open Source Initiative (OSI) or a free license by the Free Software Foundation (FSF), there is no license that I *wouldn’t* use, given the right scenario.

The choice comes down to what is most appropriate for a particular situation. How do you determine which license(s) might be appropriate for a given project? There are multiple factors to weigh.

If you are contributing to an existing project, the community expects you will make contributions under the existing project license, or a compatible license—the important thing is to understand and follow that community’s norms.

A project maintainer might reject contributions made under any license other than the one they’ve specified, even if from a legal and practical perspective the licenses have no incompatibilities. “Know your audience” and “go with the flow” are two maxims to keep in mind when you’re making upstream contributions.

What license to choose becomes more interesting when the project is your own. Assuming you have a choice (you haven’t used or incorporated any code licensed under terms that require the same license for derivative work), think about what you want recipients to be able to do (or not do) with your code.

By that I mean is it important that your code *not* be permitted to be incorporated into proprietary (“closed”) works? If so, a lax, permissive or “academic” license is not the right choice; you want to select some sort of reciprocal license. There are a number of possibilities, so how to choose? Once again, consider the likely uptake by your target audience. If you are entering a domain where one or two well-known licenses are popular, your project might not be wildly embraced if you apply an obscure or less-well-known license, even if OSI-/FSF-approved and functionally identical to the more popular license.

Also think about how your project fits the existing ecosystem, and make sure you choose a license that is compatible with the licenses of adjacent projects or dependencies. If your project needs to mix with proprietary code to get wide market adoption, you should probably consider a lax, permissive license.

Within that category, you can further refine your choice based on factors like whether you want to make an explicit patent grant, or if you need a license as widely-compatible as possible with other open source licenses. Or even both: the OSI recently approved a new lax, permissive license that both includes a patent grant *and* is compatible with the GPLv2.

Lengthy commentary and debate on the perceived merits or disadvantages of pretty much every open source or free software license can be found online. I won’t wade into that fray. The “right” open source license for your project will be the one that has terms that support your objectives, is compatible with other licenses in the relevant ecosystem, and is acceptable to your users.

Getting that equation right doesn’t guarantee your project success, of course, but getting it wrong is almost certain to ensure failure. 

One of the best ways to learn about open source licensing is to keep up to date with discussions in the open source legal and licensing community, either by joining a mailing list or browsing a mailing list’s archives. Two of my favorites are the Apache Software Foundation’s legal-discuss@ and the OSI’s license-discuss, and I’ve always been a fan of the FSF’s ‘Various Licenses and Comments about Them’ page. Happy reading!

If you liked this blog, checkout some of the others in the series;

Naming your open source project

Promoting diversity

Building community

Organizing meet-ups

About the Author

Jessica Marz works for Intel Corporation's Open Source Technology Center and has been involved in software legal compliance since becoming licensed to practice law. In her current role, she is responsible for defining and managing Intel’s corporate Open Source Software policies and practices. She explains legal stuff to software developers, and software development stuff to lawyers.