Who writes licenses for open source software

Legal aspects of open source projects

Understand the legal implications of open source code

Sharing your creative work with the world is a stimulating and fulfilling experience. However, unexpected legal issues can also arise. Thankfully, you don't have to start from scratch when answering them. We'll cover you up here with notes, but please note our disclaimer.

Why are people so concerned about open source legal issues?

Thanks for asking! If you work on a creative work (e.g. a text, an image, or code) it falls automatically and by default under copyright law. This means that you, the author of the work, are entitled to determine what others are allowed to do with it.

In general, no one else may use, copy, distribute or modify your work without risking warnings or lawsuits.

Open source is of course different in this regard, because the author expects others to use, modify and share the work. But because the rule of law is “exclusive copyright” first, you need a license that gives clear permissions.

If you don't use an open source license, everyone who contributes to your project also receives the exclusive copyright. That would mean that nobody really could use, copy, distribute, or modify the contributions. Not even you.

Ultimately, your project may also depend on others who have licensing terms that you were not aware of. The community around your project and / or regulations of your job can also require certain open source licenses. We cover these cases below.

Are published GitHub projects open source?

If you're creating a new project on GitHub, you can public or Private to do.

Making your GitHub project public is not the same as giving out a license. Public projects are subject to GitHub's terms of service, which allow others to view and fork your project. However, this does not entail any further permits for your work.

If you want to allow others to use, distribute, modify, or contribute to your project, you must grant an open source license. For example, no one is legally allowed to use any part of your GitHub project in his / her own code (even if it is public) unless you have explicitly given the right to do so.

Just tell me how I can protect my project.

You're in luck because open source licenses are standardized and easy to use these days. You can copy an existing license directly into your project.

MIT, Apache 2.0, and GPLv3 are the most popular open source licenses, but there are others to choose from. You can find their full texts as well as instructions for their use on choosealicense.com, as well as a grouping according to license type on ifrOSS.org/licence-center.

When you create a new project on GitHub, you will be suggested to use a license.

A standard license summarizes what they can and cannot do with the software for people with no legal background. As long as it is not absolutely necessary, you should avoid your own, modified or non-standard clauses, because these hinder the re-use of the code.

A standardized license serves as a proxy for those without legal training to know precisely what they can and can't do with the software. Unless absolutely required, avoid custom, modified, or non-standard terms, which will serve as a barrier to downstream use of the agency code.

- @benbalter, "Everything a government attorney needs to know about open source software licensing"

Which open source license suits my project?

If you're starting a completely new project, you can't go wrong with the MIT license. It's short, understandable, and allows anything, as long as you keep a license copy and your copyright notice.

Otherwise, the correct choice of license depends on the goals of your project.

Most likely your project has (or will have) external dependencies. For example, if you publish a Node.js project, you will likely use libraries from the Node Package Manager (npm). Each of these libraries is a dependency on your project and has its own open source license. If each of these licenses is “permissive” (allowing the public to use, modify, and share unconditionally), you can you use any license you want. Widely used permissive licenses are e.g. MIT, Apache 2.0, ISC and BSD.

However, if any of the libraries your project depends on is “heavily copylefted” (allowing the public to use, modify, and share as well, but on the condition that they use the same license), then your project will Also use license (must). Widely used copyleft licenses are e.g. the GPLv2, GPLv3, and the AGPLv3.

You should also get the Communities that you hope to benefit from and contribute to your project.

  • Would you like to see your project used in others? It is best to use the most popular license in the context of your project. For example, the MIT license is the most popular for npm libraries.
  • Should your project also attract large companies? Large companies probably want to secure patent rights, including from all contributors. Apache 2.0 covers this case.
  • Do you want your project to attract contributors who want to keep their contributions out of closed source software?GPLv3 or (if you don't want to contribute to closed source services either) AGPLv3 would fit in with that.

Your company may have specific license requirements for their open source projects. For example, it requires a permissive license so that it can use your project in its own closed source software. Or, your company could take advantage of a strong copyleft license and additional contribution agreement (see below). Then only you and no other company can use your project in closed source software. Or, your company could have special standards of a technical nature, or related to social responsibility, or to transparency. All of this could require a specific licensing strategy. Talk to your company's legal department.

When you create a GitHub project, the license choice is suggested to you. Select one of the above licenses and “open-sourced” your project. If you want to find the right license from among other options, please take a look at choosealicense.com, even if your project is not software per se.

What if I want to change the license of my project?

Most projects never have to change their license. But sometimes other circumstances arise.

For example: As your project grows, it integrates additional external libraries or gains users. Or, your company changes strategy. All of this can (or must) lead to a different licensing decision. In addition: If you did not issue a license at the beginning, doing so is effectively the same as changing a license. There are three basic things to keep in mind when considering licensing or changing your project:

It's complicated Determine license compatibilities and compliance. Finding out who the copyright owner (s) is can quickly become complicated and confusing. Switching to a different but compatible license for a new release version and new contributions works differently than relicensing all existing contributions. Invite your colleagues in the legal department at the first hint of a request for relicensing. Even if you have or can get the permission of the copyright holder for a license change: consider the upheaval this means for your project and its users. Treat a license change as a directional decision that can be smoother if you communicate clearly with and consult with all project participants. All of these are also good reasons to choose a suitable license at the beginning of a project.

The existing license of your project. If it is compatible with the new license you want, you can simply start using the new one. This works because compatibility of license A with license B means that if you stick to license B, you will also meet the conditions of license A (however, the reverse does not necessarily apply as well). For example, if you use a permissive license (like MIT), you can switch to a license with more conditions as long as you keep the copy of the MIT license text and the associated copyright notices (i.e. meet the MIT minimum conditions). However, if your current license is non-permissive (e.g. copyleft, or if you are not using a license) and you are not the only copyright holder, you cannot simply switch your project to MIT. In essence, a permissive license also means that a copyright holder has given permission to change the license in advance.

The existing creators of your project. If you are the only contributor to your project, then either you or your company are the sole rights holder of the project. You can add or change the license that you or your company would like to have. Otherwise, there may be other copyright holders that you need approval from in order to change the licenses. Who are you? People who are involved in your project are eligible. But in some cases the exploitation rights are held by these people's employers, in other cases people have made minimal contributions, but there is no strict rule that contributions under a certain number of lines of code are not copyrighted. What to do? It depends. For a relatively small and young project, it may be possible to get all existing contributors to agree to a license change in an issue or a pull application. For large, long-lasting projects, you may need to find many contributors and even their heirs. It took Mozilla years (2001-2006) to re-license Firefox, Thunderbird, and related software.

Alternatively, you can agree on certain license changes in advance under certain conditions that go beyond those of your existing open source license. Such additional agreements, also called “contributor (license) agreements”, are further explained below. You shift the complexity of the license change a little: you need more help from your lawyers up front, and you will still want to communicate with those involved in your project when you make a license change.

Does my project need an additional contribution agreement?

Probably not. For the vast majority of open source projects, an open source license applies implicitly to both incoming contributions and outgoing contributions to other contributors and users. If your project is on GitHub, GitHub's Terms of Service make this practice called “inbound = outbound” the explicit standard.

An additional contribution agreement - often also called a Contributor License Agreement (CLA) - can create administrative work for the project supervisor. The amount of additional work depends on the project and implementation. A simple agreement requires the contributors to confirm with one click that they have the necessary rights to contribute to the project under its open source license.

By adding “paperwork” that some consider unnecessary, difficult to understand, or unfair (if the recipient (s) in the agreement gets more rights than the contributors or the public gets through the project's open source license), you can an additional contribution agreement will be perceived as unfriendly to the community of the project.

- @bcantrill, “Broadening Node.js Contributions”

Some situations in which you should consider an additional contribution agreement for your project include:

  • Your lawyers want all contributors to expressly accept the contribution terms (sign, on- or off-line), perhaps because they feel that the open source license itself is not enough (although it is enough!). If that's the only concern, a contribution agreement confirming the project's open source license should be sufficient. The jQuery Individual Contributor License Agreement is a good example of a lightweight, additional contribution agreement. For some projects, a Developer Certificate of Origin can be an alternative.
  • You or your lawyers want developers to confirm that your commits are authorized. Many projects use the Developer Certificate of Origin for this. For example, the Node.js community uses a DCO instead of their previous CLA. DCO Probot offers a simple way of automatically requesting such a DCO in your project.
  • Your project uses an open source license that does not contain an express patent grant (e.g. MIT), but which you need from all contributors. Some of them may work for companies with large patent portfolios that could be used against you or the other contributors and users of the project. The Apache Individual Contributor License Agreement is a frequently used additional contribution agreement with a patent grant corresponding to the Apache License 2.0.
  • Your project is copylefted, but you also need to distribute a proprietary version of the project. You will need to obtain a rights management agreement from all contributors that will grant you (but not the public) a permissive license. The MongoDB Contributor Agreement is an example of such an agreement.
  • You think your project will need to change its license during its lifetime and you want contributors to approve these changes in advance.

If you really need to use an additional Contribution Agreement with your project, consider using an integration like the CLA Assistant to minimize the distraction of contributors.

What does my company's legal department need to know?

When you publish an open source project as an employee of a company, the legal department should first know that you are doing an open source project.

Regardless of the pros or cons, even if it's a personal project, be sure to share it. You likely have a "transfer of rights" agreement with your company that gives you some degree of control over your projects. Especially if these are somehow related to the company's business or if you are using the company's resources to develop the project. Your business should Easily give them permission, and may already have an employee-friendly rights agreement or company policy. If not, you can negotiate (e.g. explain that your project is for the company's professional learning and development goals) or avoid working on your project until you find a better company.

If you want to open a project on behalf of your company, definitely share this. Your legal department likely already has guidelines for an open source license (and perhaps an additional contribution agreement) based on the company's business needs that will ensure your project complies with its dependencies' licenses - if not, then you have and Your legal department lucky! The latter should be eager to work with you to find out:

  • Third party material: Does your project depend on software created by others, or does it contain or otherwise use third party code? If so, and they are open source licensed, you must comply with them. This starts with choosing a license for your project that is compatible with the third-party open source licenses (see above). If your project modifies or distributes third-party open source material, your legal department will also want to be sure that you meet additional requirements of the third-party licenses, such as maintaining copyright notices. If your project uses other code that is not under an open source license, you will likely need to ask the third party vendors to add an open source license. If that doesn't succeed, you'll need to stop using their code in your project.

  • Trade secrets: Think about whether parts of your company's project should not be made available to the public. You can extract such material from your project, keep it private, and publish the rest.

  • Patents: If your company applies for a patent for which publication of your project would constitute disclosure, you may be asked to wait (or the company may reconsider whether filing a patent is worthwhile). If you expect contributions from employees of companies with large patent portfolios, your legal department might want a license with an express patent grant from contributors (e.g. Apache 2.0 or GPLv3), or an additional contribution agreement (see above).

  • Brand names and trademarks: Make sure your project name does not conflict with existing brands. If you use your own company brands in the project, make sure that they do not cause any conflicts. FOSSmarks is a practical guide to understanding brands in free and open source projects.

  • Privacy: Does your project collect data about users? Sends it back to the company server? Your legal department can help you comply with company policies and external regulations.

When you release your company's first open source project, that's more than enough to get away with (but don't worry, most projects shouldn't raise any major concerns).

In the longer term, your legal department can do more to help the company capitalize on its commitment to open source and stay safe:

  • Employee Contribution Policy: Consider developing a company policy that defines how your employees contribute to open source projects. Having a clear policy will reduce confusion among your employees and help them support open source projects in the best interests of the company, whether as part of their work or in their free time. A good example from Rackspace is their Model IP and Open Source Contribution Policy.

The issuing of the rights associated with a patch builds the knowledge base and the reputation of the employee and shows that the company invests in the development of its employees and creates a feeling of personal responsibility and autonomy. All of these benefits also translate into higher morale and better employee loyalty.

Letting out the IP associated with a patch builds the employee’s knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.

- @vanl, “A Model IP and Open Source Contribution Policy”

  • Publish what?(Almost everything?. When your legal team understands and invests in your company's open source strategy, they are best able to help you rather than hinder your efforts.
  • Compliance: Even if your company does not publish open source projects, it is still using others' open source software. Awareness and processes for avoiding headaches, product delays and lawsuits.

Organizations must have a licensing and compliance strategy in place that fits into both the permissive and copyleft categories, starting with recording the licensing terms that apply to the open source software you use - including Sub-components and dependencies.

Organizations must have a license and compliance strategy in place that fits both [“permissive” and “copyleft”] categories. This begins with keeping a record of the licensing terms that apply to the open source software you're using - including subcomponents and dependencies.

- Heather Meeker, "Open Source Software: Compliance Basics And Best Practices"