Open source is considered a computer software that is released and granted under a license in which the licensor grants users the right to use, study, distribute and change the software’s source code and its effects for the benefit of third parties, contributors or generally a user who would otherwise be prohibited.

The legal implications of open source 

Sharing your creative work within the legal umbrella of intellectual property can be both an exciting and rewarding experience. On the other hand, it can also mean a bunch of legal things you were not familiar with and didn’t worry about previously. The following are some of the legal disclaimers that a person must be cognizant of in relation to this article:

  1. Legal Disclaimers

Legal disclaimers enable the open source projects to be able to be used due to the license granted by the author of the source code that enables and facilitates the protection of contributors and removes the possibilities of arising warranties and disclaiming liability for damages resulting from the usage of the projects. 

Operating an open source project, like any other human endeavor, involves uncertainty and tradeoffs. The legal questions arising may differ in its own uniqueness and therefore, you should seek help from legal experts and consult your retained or your own legal counsel to address this. The same applies to companies. 

  1. Licenses

License is a permission granted by a qualified authority permitting a licensee to do something that would otherwise be prohibited by law. This also includes a permit. 

  1. Permissions

This is an authorization or formal consent from someone in authority. With regards to this article of open source, some projects are used with the permission of Django Software Foundation and individual contributors.

The importance of legal framework of open source

Any work that falls under intellectual property including creative works such as writing, code or graphics is under copyright laws by default. The law protects you as an author of the work by making you have a say or a stake in what third parties can do with it.

In a general sense, this means that nobody else can use, distribute, copy or modify your work without being at risk of take-downs, shake-downs or even litigation in some cases if all attempts of depositions and alternative dispute resolution mechanisms fail including arbitration.

As stated earlier, permissions are important aspects in open source. This is because open source being an unusual situation, the author expects that others will use, modify and even share the work. But because the legal default is still exclusive copyright, you need a license that explicitly provides for these permissions aforementioned.

It is also noteworthy that if you don’t apply for an open source license, everyone who is a party to your project in terms of contribution becomes an exclusive copyright holder of their work. This in simpler terms means that nobody can use, copy, distribute or even modify their own contributions and it is not only limited to them but includes you too.

Your project may also have dependencies with license requirements that you were not cognizant of or aware of. Your project’s community or in some instance your employer’s policies, may require your project to use specific open source licenses. Some of the latest versions of these licenses includes the General Public License (GPL), version 3 of this provides for a clause that forbids the payments of royalties on copies of the open source software. Another type of license is the Berkley Software Distribution (BSD), which has an important source of Unix development. Unix is an operating system which is analogous to DOS and Windows that supports multiple concurrent users. 

The question of whether public GitHub is an open source

It is important for you to note that GitHub is not a law firm and as such does not provide legal advice. When you want to create a new project on the GitHub platform, you are provided with options to make the repository public or private.

Making your GitHub projects differs from licensing your projects. This is so because public projects are covered within the purview of GitHub’s terms of service, which allows others to view and fork your project, but does not have permissions. In other words, your work comes with no permissions.

If it is your desire that others should use, distribute, modify or generally contribute back to your project, you need to include an open source license for this to be feasible. For instance, a person cannot legally use any part of your project in GitHub in their own code, even if your code is public unless and until you explicitly give them the right to proceed to do so. Failure to acquire gives a person this right and they proceed to use your code, they will be held liable in law and you will be compensated damages.

Licenses that protect your projects

Currently, open source licenses are standardized and easy to use. It is as easy as just copy pasting an existing license directly into your project. 

The most popular open source licenses include;

  1. MIT License

This is a short and simple permissive license with conditions that only permits preservation of copyright and license notices. 

  1. Permissions 
  • Private use 
  • Modification purposes
  • For commercial use
  • Distribution purposes
  1. Conditions
  • Must include license and copyright notice
  1. Limitations
  • Liability
  • Warranty
  1. Apache License 2.0

This is a permissive license whose main conditions require preservation of copyright and license notices. The contributors must provide an express grant of patent rights. With relation to modifications, licensed works and larger works, it may be distributed under different terms and without a source code.

  1. Permissions
  • For patent use
  • Private use
  • Commercial use and distribution
  • Modification use
  1. Conditions
  • State changes
  • License and copyright notice
  1. Limitations
  • Warranty
  • Trademark use
  • Liability
  1. GNU General Public License v3.0

Permissions of this license are conditioned on making available source codes of licensed work and modifications by including larger works using licensed work under the same license. Just like Apache 2.0, contributors must provide an express grant of patent rights.

  1. Permissions
  • Commercial and distribution use
  • Modification use
  • Patent use
  • Private use
  1. Conditions
  • Same license
  • Disclose source
  • License and copyright notice must be provided
  • State changes
  1. Limitations
  • Warranty
  • Liability

Any project created on GitHub will require the author to add a license. This does not necessarily mean that you’re under an obligation to choose a license. However, without one as such, copyright laws will apply and you will retain managing rights to your source code. That is, no one may reproduce, distribute or create derivative works from your source code.

Choosing a suitable license for your project and examples of appropriate project licenses.

MIT License is usually the best license to go for based on its applicability and usability. It allows any person to undertake anything within it as long as you retain a copy of the license, including copyright notice.

Picking the right open source license usually depends upon the author’s objectives. Your project will most likely have dependencies. For instance, if your intent is open sourcing a Node.js project, there is a high probability library use from the Node Package Manager (nvm). Each library depended on will have their own open source license. If the licenses are permissive in nature that is they give the members of the general public permission to use, modify, and share, without any condition for down streaming licensing, a person can therefore use any licensing they wish to applicable in their work. The most common permissive licenses include MIT, Apache 2.0 and Berkley Software Distribution (BSD).

Contrary, if your dependencies are of a strong copyleft; (these are permissions given to the public subject to condition of using the same downstream license), then your project must use the same license throughout. An example of a strong copyleft license is General Public License v3 (GPLv3).

It is also prudent to consider the communities that will use and contribute to your project. The following are questions for your own undertaking with regards to your project:

  • Whether you want your project to be used as a dependency by other projects
  • Whether you want your project to appeal to large businesses
  • Whether you want your project to appeal to contributors who do not want their contributions to be used in closed sourced software

Furthermore, companies differ with their specificity of licensing requirements for its open source projects. Some companies may require permissive license, another company may require a strong copyleft license or another may require a particular licensing strategy that addresses certain needs related to standards, transparency or even social responsibility. 

Circumstances that may make you to change project licenses

It is anticipated, expected and foreseeable that circumstances change sometimes hence prompting projects to change their licenses.

This may arise out of the possibility that as your project grows so will the dependencies or the users, or your company may review the strategies any of which could require an application of a different license. There are three factors that are considered when adding or changing the project’s license as provided down below:

  1. Complications

The compatibility and compliance of who holds copyright usually gets complicated. This is because switching to a foreign but compatible license for new contributions is different from relicensing an already existing contribution. This again will need you to involve your company’s legal team.

  1. Project’s existing license

if the current existing license is compatible with the new license you intend to apply, then you can start using the new license. This is because compliance with terms of the old license will be compatible with terms of the new license. For example, if a permissive license is in use, a similar license with more conditions can be applied so long as you retain a copy of the original permissive license and any associated copyright notices.

  1. Project’s existing copyright holders

In an instance whereby you are the sole contributor, you are held as the project’s sole copyright holder. Therefore, you can change to your preferable license you or your company desires. If there are many copyright holders, you need agreement from everyone with a stake in order to change the licenses

Additional contributor agreements

There are vast majority of open source projects and an open source license is flexible to cater for both inbound that is contributors and outbound that is contributors and users license. Therefore, it will not be necessary for an additional contributor agreement.

An additional contributor agreement also known as Contributor License Agreement (CLA) creates administrative work for the project maintainers. The amount of work to be added usually depends on the project and implementation. Some of the situations whereby a person may consider an additional contributor agreement includes:

  • In a situation whereby your legal team want all the contributors to expressly accept to contribution terms by signing online or offline because they may be of the view that the open source license is not enough. An example of an easy additional contributor agreement is the JQuery individual contributor license agreement. An Open JS Foundation comprises of 32 open source JavaScript projects inter alia, Appium, JQuery, Node.js, webpack.
  • When you or your legal team want developers to represent that every commit they make is authorized. 
  • The project incorporates an open source license not including an express patent grant and you need it from all the contributors in existence some of whom may be attached to companies with large patent portfolios that may be used to target both you and the project’s contributors and users. The Apache Individual Contributor License Agreement may be used as an additional contributor agreement to counter this.
  • When your project is under a copyleft license and you want to distribute a proprietary version of the project. The MongoDB Contributor Agreement may aid in this instance. It is a short form that allows you to easily pull requests against GitHub usernames that already signed the agreement.
  • When your project might need to change licenses in its lifetime but you want the contributors to agree to this in advance.

A CLA assistant minimizes contributor distraction as it performs functions such as commenting on each opened pull requests, updates the status of a pull request when the contributors agree and automatically asking users to re-sign the CLA for each new pull request.

Company legal team scope, powers, framework and functionality

Before sourcing any project, your company’s legal team should be aware of this. This applies to personal projects as well. For personal projects an employee IP agreement with your company should be in place as this them oversight over your projects if they are related to the company’s business or you intend to use the company’s resources. The company grants you permission through the employee IP agreement or in some instances a company policy.

In a situation whereby you are open sourcing a project for your company, it is mandatory that you let them know. This is because your legal team will need to review the policies for what open source license and additional contributor agreement will be preferable based on the company’s business operations and expertise that ensure your project is in compliance with the licenses of its dependencies. Some of the things in consideration are:

  • Third party material. Choose a license that is compatible with 3rd party open source licenses. If it is not compatible due to contrasts between parties, ask the third party maintainers to add an open source license.
  • Trade secrets- Is there information not to be disclosed to the public?
  • Patents. With relations to public disclosure.
  • Trademarks. The project’s name should not conflict with any existing trademarks.
  • Privacy. Does the project involve data collection on users?
  • Employee contribution policies. Consider a policy that species how employees contribute to open source projects.
  • Compliance. Awareness and process can aid to avoid lawsuits.
  • Patents. Open Invention Network provides a shared defensive patent pool to protect members and enables them to explore other alternative patent licensing.

Conclusion

Open source provides control, training, security, stability and community that inspires users and developers to from and grow their companies. The legal aspect protects everyone involved in the open source process and procedures as discussed by the above article. Therefore, it is encouraged to carry out open sourcing as the law provides a path, shield and justice to all persons.