An Open Source License is a legal document that defines the terms under which permission is granted by a rights holder to the recipient. Open source licenses allow software to be used, modified, and shared by anyone for any purpose with very few restrictions.

Do All Open Source Projects Have Licenses?

Yes. If a project lacks a license we can’t consider it to be open source. The rights held by the code-owner might not be licensed, thus using the code may be an infringement. Some people publish code and assume this implies a license. Some projects add the name of a license inside a configuration file. One might argue this implies a license. But there’s legal precedent to suggest that courts wish to see copyright agreements clarified in writing (“Section 204’s writing requirement [for transfer of copyright] is not unduly burdensome”). We seek to avoid ambiguity and assumptions. If you don’t see an expressed license associated with the code, we can’t assume it is open source.

For this reason we put a license in the root of all of our code projects and add a license header in all code files. This makes it clear to others. When it comes to using code, we like to see an explicit license (and will ask the project to make it clear if it was not already clear).

How Do We Pick Which License To Use?

By default we use the MIT license since it is permissive (allowing people to use the code with very few restrictions), simple, well known and broadly used in the Ruby and Javascript communities. Our intent is to be clear, grant permissions, and fit in with the community we’re operating in./

There are times we are required to, or it is ideal to, license code under other licenses. For example, if we are extending code licensed under the GPL license, we’ll license our derivative work under GPL in compliance with the terms of the license. In those cases, if someone violates the terms of our GPL licensed code, we’ll extend to them an opportunity to cure and reinstate their license. If we hold a patent relevant to open source code we publish, we’ll publish it under the Apache License 2.0 which includes an explicit patent grant.

Are All Open Source Licenses Alike?

All open source licenses grant rights that comply with the open source definition. But they differ in important ways from each other. We generally categorize licenses as being permissive or restrictive. The former are relatively easy to comply with, the latter could impose more complications under many circumstances. There will be instances where we will or will not use code based on the license. There will be instances where we will or will not contribute to a project based on the license. Situational details matter such that we’ll say yes in some cases, no in others. The SDRT’s role is in part to help educate our developers about these issues, but ultimately to determine a proper course of action for a given situation. Our consistent message to developers: please ask whenever you see something that you are not 100% sure about. We will help inform and decide what makes the most sense in a given situation.

Are Any Licenses Not Open Source?

Yes. The most common are commercial licenses that grant limited permissions in return for money. But there are others that offer openness and freedoms, but are still not technically open source.

• Source-Available licenses are neither commercial nor open source. They operate similarly to open source in that they offer many rights and comply with much of the open source definition, but they are designed with some restrictions (e.g. limiting who can use the code or for what purposes).
• There is a new category of license that is perhaps a subcategory of Source-Available but worth noting as distinct due to different motivations and applications. These are collectively being called Ethical Source Licenses and include the The Hippocratic License 2.1.
• Freeware licenses are used for applications that are free to use (i.e. no cost), but you can’t see or modify the source code.
• The Unlicense is not actually a license, but a declaration of Public Domain status.
• Mock licenses are written to mock the idea of open source licenses. These are uncommon and in most cases do not comply with OSD. Moreover, they are typically poorly drafted from a legal perspective. Beerware is a relatively old example. WTFPL comes up once in a while, shocking a unsuspecting reviewer with a curse word. The Chicken Dance License captures this category well.

As with any license questions (especially those not approved by OSI), please ask the SDRT for guidance about the license terms and how it impacts your use of or contributions to the project. We will address each question in context of the specific use case.

What About a Licence for Content?

Open source licenses are designed to be used for source code. Other content, such as images, documentation, or data sets are often better licensed using content licenses. Some examples:

• The Creative Commons Licenses provide a set of options that allow a copyright holder to share content under terms that are similar to terms found in open source licenses.
• Some data sharing projects leverage the Open Database License or other licenses that are drafted to address the specific concerns related to data.
• Some fonts are licensed under an open font license such as the SIL Open Font License 1.1.

Note: some open content licenses do not comply with the open source definition. For example the Creative Commons non-commerical licenses restrict the Fields of Endeavor clause in the OSD. Thus technically we do not call this open source since it is neither source and it falls shy of the formal definition of open with respect to open source.

Still Confused About “Free” and “Open”

Here are a few thoughts to help you out as you read about this elsewhere:

• Often companies think of intellectual property as something they don’t want to share. Whereas many software developers see value in sharing their code with peers. There are two levels of concerns (at least). One is letting someone else see what might be a secret. The other is giving up some control over an asset. The license discussions will help clarify things. Open source licensing is not an wanton abandonment of rights, it’s a method of managing trust.
• The term free is best understood as emancipation, not cost. Think of the phrase the code is free to mean it has freedom and can be used without constraints of the owner, not that it lacks cost. This is a question of liberty. Open source does not attempt to prevent people from making money, but it does change the way a company could make money. This is often misunderstood.
• The term open means more than visible, it means unrestrained. Often an entity may be willing to make some code visible, but still seeks to restrain what others can do with that code (e.g. you can see my code, but you can’t use it in a way that might cause me to lose money.) Those cases cause confusion when people use the term open but really mean something more restricted.