As a company, GitLab is dedicated to open source. Not only do we believe in it, but we use it, and we give back to it. Not just through GitLab, but through contributions to other open source projects.
The purpose of this page is to document how a GitLab employee can:
See Creating a new project for the instructions.
If you're contributing to an open source project on behalf of GitLab, you may be required to enter into a CLA. In accordance with the Authorization Matrix Policy, Legal approval is required to you enter into a CLA on behalf of GitLab.
If you have the choice between a Corporate and Individual CLAs, opt for the Corporate CLA.
Follow these steps to obtain legal approval and enter into a CLA on behalf of GitLab:
Licensing label to the issue.cla_managers[at] gitlab.com email address should be used. Access to this Google Group can be requested and granted via the issue if required.cla_managers[at] gitlab.com email if one is required) and begin contributing to the project.We are continuing to develop our policy and workflow around CLAs on behalf of GitLab contributors. See related issue here. For any questions in the meantime, please post to the #legal Slack channel.
In the future me might have a single place for forks. That will allow us to track various metrics about contributions made by GitLab employees.
If your GitHub account's primary email is not your @gitlab.com email, you can add it as an additional address. No need to create a separate account.
In the future me might have a single organization for forks. That will allow us to track various metrics about contributions made by GitLab employees.
Libraries with the following licenses are acceptable for use:
MIT License (the MIT Expat License specifically): The MIT License requires that the license itself is included with all copies of the source. It is a permissive (non-copyleft) license as defined by the Open Source Initiative.
These licenses may or may not be acceptable based on the usage and integration. Review with the legal team to confirm.
Libraries with the following licenses require legal approval for use:
Libraries that are not already approved and listed on the Acceptable Licenses list or that may be listed on the Unacceptable Licenses list may be submitted to the legal team for review and use on a case-by-case basis. Please contact Legal by following the instructions in the Legal Handbook to request review. Include the details of how the software will be used, whether or not it will be modified, and how it will be distributed (if at all). After a decision has been made, the original requestor is responsible for updating this document, if applicable. Not all approvals will be approved for universal use and may continue to remain on the Unacceptable License list.
All inquiries relating to patents should be directed to the Legal team.
Decisions regarding the GNU GPL licenses are based on information provided by The GNU Project, as well as the Open Source Initiative, which both state that linking GPL libraries makes the program itself GPL.
If a library uses a license which is not listed above, open an issue and ask. If a license is not included in the "acceptable" list, operate under the assumption that it is not acceptable.
Keep in mind that each license has its own restrictions (typically defined in their body text). Please make sure to comply with those restrictions at all times whenever an external library is used.
Dependencies which are only used in development or test environment are exempt from license requirements, as they're not distributed for use in production.
NOTE: This document is not legal advice, nor is it comprehensive. It should not be taken as such.
Avoid using forked code and try to contribute your change upstream.
It's typical for forks to fall far behind the upstream repository and such dependencies become a source of pain:
There may be good reasons to create a fork:
If you decide to create a fork, make sure you open an issue that:
Before filing or continuing to prosecute any legal proceeding or claim (other than a Defensive Action) arising from termination of a Covered License, GitLab commits to extend to the person or entity (“you”) accused of violating the Covered License the following provisions regarding cure and reinstatement, taken from GPL version 3. As used here, the term ‘this License’ refers to the specific Covered License being enforced.
However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.
Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.
GitLab intends this Commitment to be irrevocable, and binding and enforceable against GitLab and assignees of or successors to GitLab’s copyrights.
GitLab may modify this Commitment by publishing a new edition on this page or a successor location.
Definitions
‘Covered License’ means the GNU General Public License, version 2 (GPLv2), the GNU Lesser General Public License, version 2.1 (LGPLv2.1), or the GNU Library General Public License, version 2 (LGPLv2), all as published by the Free Software Foundation.
‘Defensive Action’ means a legal proceeding or claim that GitLab brings against you in response to a prior proceeding or claim initiated by you or your affiliate.
GitLab means GitLab Inc. and its affiliates and subsidiaries.
