We recently switched from a Contributor License Agreement (CLA) to a Developer's Certificate of Origin (DCO) to make it easier for everyone to contribute to GitLab. Now, we're taking our commitment to our core tenet, "everyone can contribute," a step further. We're amending our Proprietary Information and Assignment Agreement (PIAA) and putting clarifying processes in place to help our contributors maintain their ability to work on projects that are unrelated to GitLab's business, including other open source projects.
GitHub announced the Balanced Employee Intellectual Property Agreement (BEIPA), an open source intellectual property (IP) agreement which seeks to take a more balanced approach to assigning control over IP. We want to thank GitHub for taking the lead on a very important conversation. Their new approach inspired us to take a closer look at our own PIAA, make improvements to better clarify our position, and encourage our contributors to work on projects outside of GitLab if they want to.
We recently launched a Twitter poll to assess the potential risk IP agreements pose to developers in our community. We found that the majority of developers (85 percent) have a side project and nearly half (44 percent) have worried about the IP ownership of that project. Forty-four percent say they have used company resources for a side project, potentially putting them at risk of violating their workplace IP agreement.
At GitLab, we want to give our contributors confidence that their developments will not be owned by GitLab simply by virtue of their use of GitLab-issued computers, GitLab facilities, or the GitLab source code repository. Furthermore, we want to alleviate stress of not knowing whether they are in violation, given that there is necessarily some ambiguity about which projects relate to or don't relate to our business. So, we are making some changes.
One of our values is boring solutions. With this in mind we looked at either adopting the BEIPA outright or contributing to the document. After considerable thought we concluded that it wasn’t possible to make either of these approaches work. Accordingly, we focused on improving our existing PIAA.
Why the change?
The industry standard for intellectual property agreements tend to assign a broad swath of IP to the employer, making it difficult for a contributor to work on outside projects without being in violation of the agreement. The most important piece of any employee agreement is the definition of what IP is assigned from the employee to the company.
The industry standard is to define the scope of the IP definition in three buckets:
- IP that relates to the current or prospective business of the company
- IP created by the employee as part of its work for the company
- IP created using materials, facilities, funding, or confidential information of the company
We want to alleviate the unnecessary risks posed to contributors posed by buckets 1 and 3 above.
What's changing
As a result of our internal review, we are making three important changes to our PIAA and processes related to outside creations developed by our contributors:
-
We have entirely eliminated the section in our PIAA that would grant GitLab ownership in developments simply by virtue of the use of GitLab equipment, including GitLab-issued computers, GitLab facilities, or GitLab.com as a software development platform.
-
In the event there is concern on our contributor’s behalf that there may be a gray area, we have created a process whereby GitLab can confirm that the development is outside the scope of GitLab’s business.
-
We have added plain language text to our publicly viewable Handbook that clarifies when contributors should seek further assurances from GitLab and when they shouldn’t.
Our goal is to give contributors a way to gain confidence in their ability to pursue independent projects ahead of time, and reduce the risk of potential conflicts down the line.
