Sales Guide | Collaborating with GitLab Legal

Thank you for visiting! The purpose of this Handbook resource is to provide all GitLab team members with a clear path to assist in navigating any type of go-to-market Legal Commercial requests or processes. The information below is intended to help you to find and access certain information on your own, as well as clearly establish how to best connect with, and coordinate assistance from, the GitLab Commercial Legal team.

Note: All references to ‘GitLab Legal’ or ‘Legal’ within this Handbook page refers to the Commercial Legal team.

(1) Operational - How to work with and engage GitLab Legal including requirements to close a deal, general FAQ for legal ops, including some parallels to Finance and Deal Desk matters.

(2) Educational - Learning about how and why Legal and our agreements work to better serve Sales during a sales cycle including proactive advice and education to enable Sales to feel more confident when a customer has legal related questions.

The information contained on this page is organized into two distinct categories Operational and Educational as follows:

OPERATIONAL

How to Reach the Legal Commercial Team

Different situations require different approaches. In the vast majority of cases regarding revenue-related requests, the proper way to engage the Legal team is through Salesforce (SFDC) by creating a legal request per the process below.

1. Click the “Legal Request” button under the customer’s opportunity in SFDC (or at the account level if related to a partner). This enables Legal to gather more information regarding Legal Requests created and the applicable opportunity information. If an opportunity does not exist, please open a $0 opportunity and then create the Legal Request following the steps within this section.
2. Once the Legal Request is correctly created, the request is logged in a queue where the appropriate Legal team member will assign themselves to the case and will communicatewith originator as applicable.
3. Step-by-step directions on opening a Legal Request can be found below.
   • Click “Legal Request” but located at the top of Opportunity SFDC layout.
   • Choose the correct answers for each field and add details in the “Notes” Section and hit “Save”.
   • Once saved, there will be a new legal request added to the legal queue and the appropriate team member will assign the case to themselves.
   • The legal request will be reviewed, answered and the originator will be @ mentioned.
   • Once the request is addressed, the legal request will be closed by the legal team member. NOTE: If no Opportunity exists, please create a $0 to open the Legal Request.
4. Except for export compliance purposes (see process here) do not tag @Legal in SFDC as the entire team gets unnecessarily notified.
5. All agreements or documents for a customer’s particular opportunity should be attached in the same Legal Request: e.g. a customer returns redlines to both the subscription agreement and their order form, both should be uploaded to the same Legal Request.

Reminder: Only one SFDC Legal Case should be opened for each opportunity.

How do I get an Agreement Signed

1. No one in the Sales organization is authorized to sign any agreements. Only certain individuals may execute on behalf of GitLab, see Authorization Matrix here.

2. All agreements require a Legal approval stamp in order to be signed. This stamp is placed on the agreement by a Legal team member when an executable version is reached.

   NOTE - the Legal Stamp is not a signature

3. Once the Agreement has been stamped by Legal, follow the DocuSign Process to send the agreement for signature within SFDC.

4. All Sales Team Members have DocuSign access, please work with Sales Ops for any questions on how to use it. Please be sure to copy the applicable Legal team member for all fully executed agreements

Need an NDA signed? Follow the process for Team Members with DocuSign access.

How to Get a Data Processing Addendum (DPA) Signed

GitLab includes a signed version of the DPA on the Terms of Use website. As stated within the Subscription Agreement, this DPA is applicable to all customers and does not need to be countersigned. In addition, as stated within the header of the DPA, a customer’s acceptance of the Subscription Agreement shall be treated as its agreement to the DPA.

Letters of Authorization (LOA)

Visit the Partner Operations page to learn how partners can request a Letter of Authorization.

LOA Review Steps:

1. Once the Partner has executed or otherwise clicked to accept a GitLab partner agreement, credentials and access to the partner portal will be made available to allow a partner to request an LOA. When a partner initiates a request for an LOA, Partner Operations will receive the request via DocuSign at partnersupport@gitlab.com to confirm that the partner is a valid and authorized partner. Once confirmed by Partner Operations, Legal will receive an email via DocuSign to loa@gitlab.com.
2. Once the DocuSign process is initiated by the partner and Partner Operations has confirmed that the requesting partner is a valid and authorized partner, the LOA will be routed to the Legal team to add a Legal Stamp, and then to a GitLab authorized signatory for execution. Upon completion, the fully executed LOA will be distributed via DocuSign to GitLab Legal and the partner.
3. If a partner requests a non-standard LOA with custom terms, please open a Legal Request in SFDC as outlined above.

Export Review in SFDC

1. Please see the instructions under Trade Compliance in the Internal Handbook page
2. Only Legal can clear the accounts that are flagged by the export compliance tool, please do not tag any other groups for assistance with these requests.

RFP Process

With regards to completing RFPs, sometimes referred to as RFIs, RFQs or RFXs, please find information in the RFP Process handbook page on how sales team members can operate as the DRI to utilize the existing Answer Base and collect relevant information from cross-functional stakeholders.

Completing Vendor Request Forms

It is the sales team member’s responsibility to complete vendor request forms

1. Typically matters covered within these documents: (i) include some, if not a significant number of, non-legal related items and will require review by the relevant internal stakeholders at GitLab; and (ii) in some instances are publicly available (within the Company Information page, GitLab Investor Relations page GitLab Handbook or GitLab.com) and the sales team member can save significant time, or limit the scope needed for legal review, by first searching for such information prior to reaching out to Legal.

   Included on the Company Information Page are:

   • Address / information related to each GitLab entity
   • All banking information
   • ECCN Number
   • NAICS Code
   • Dun and Bradstreet Number
   • And other relevant corporate information

2. If there are answers which are not found in the Company Information Page, the Sales team member should read, understand, and determine which GitLab departments should be involved and are the owner of the remaining matters. If you are uncertain, Legal can assist in guiding you to the right department or contact.

3. W9 is located on the Finance Forms page

4. If there are Security-related questions that are not found in GitLab’s Trust Center, the Sales team member should engage the Field Security Team per their process, which can be found at GitLab’s Customer Assurance Activities Page.

5. If there are questions / elements that are not found in the Company Information Page, the Sales Rep should engage Deal Desk to organize requests of finance and tax. Information regarding contacting Deal Desk and overall process can be found at the Sales Order Process Page.

6. If there are Security related questions / elements that are not found in GitLab’s Trust Center, the Sales Rep should engage the Field Security Team per their process, which can be found at GitLab’s Customer Assurance Activities Page.

7. If there are tax related questions, the Sales team member should engage the Tax Team within the Tax Slack Channel. For Tax Certificate requests please email the Finance team at ’tax@gitlab.com’.

8. If there are finance related questions, the Sales team member should engage the Finance team within the Finance Slack channel.

ONLY OPEN A LEGAL REQUEST IF: (i) there is a specific legal question - to be called out by the sales team member; and/or (ii) a legal stamp is needed if a GitLab signature is required on the vendor form.

Requests for GitLab Financial Information and Insurance Certificates

1. For Insurance Certificate requests, demonstrating evidence of coverage, please open a Legal Request. Note that our Certificate of Insurance is GitLab’s confidential information and either an NDA or agreed to Subscription terms need to be in place prior to distribution.
2. Regarding GitLab financial information, GitLab is a public company and its public filings can be found on SEC.gov or on GitLab’s Investor Relations website

Escalation Process

If a customer or partner has requested material non-standard terms, and the transaction merits additional consideration by GitLab’s leadership, please follow the GitLab Escalation Process (the “Process”). The Process sets forth factors to consider before escalating material non-standard requests to leadership, including initial threshold considerations, ensuring the matter receives the appropriate level of review, instructions on properly documenting the escalation, etc. Note This document is only available for GitLab Team Members.

How to get a Data Processing Addendum (DPA) signed

GitLab includes a signed version of the DPA on the Terms of Service, as stated within the Subscription Agreement this DPA is applicable to all Enterprise Customer’s and does not need to be counter-signed. In addition, as stated within the header of the DPA, a Customer’s acceptance of the Subscription Agreement shall be treated as its execution of the DPA.

Request for Name Change or Change in Control

Occasionally GitLab will receive a notice from a customer or partner outlining either a change of their company’s legal name or a change in control of the company. The following steps outline the process to have the customer or partner’s account updated in SFDC.

1. Customer provides name change notice to Sales/Channels.

2. Sales/Channels opens a Legal Request in SFDC.

3. Legal confirms whether name change OR change in control:

   a. For name changes only, Customer provides financial documentation, W9 or W8BEN to Sales/Channels.

   • Sales/Channels uploads documentation to SFDC.
   • Legal closes the legal case.

   b. For change of control, Legal confirms transaction category (acquisition, divestiture, asset sale, merger, insolvency).

   • Legal will review customer/partner documentation and existing agreements.
   • Legal will either draft redlines to customer documentation or provide new documentation supporting the transfer.
   • Customer/partner provides signed consent documentation to Sales/Channels.
   • Sales/Channels uploads signed doc to customer/partner account in SFDC.
   • Legal closes the legal case.

Legal Commercial Coverage Model

1. Please review the Legal Coverage Model which provides an overview of the GitLab Legal coverage model by region & segment. NOTE: this is available to GitLab team members only
2. Even though this resource provides individual contact information, please follow the applicable steps to open a Legal Request if you have a need related to a customer.
3. Please note this model is a guide, as the specific team member assigned will take into consideration current work-flow and subject-matter expertise.

Collaborating Cross-Functionally with GitLab Issues

For matters that necessitate being handled outside of SFDC (e.g. project-based work, or topics that require input from team members w/o SFDC access) and require the Legal team’s attention, please (i) open an Issue in the Legal and Compliance Project; (ii) select the appropriate Issue Template; (iii) apply the label legal-commercial::to-do, and (iv) if you know which Legal team member you will be working with, include them as an Assignee. This will update the Commercial Legal Issue Board for the Legal team’s benefit, and allow the team to pick up and/or assign appropriately. We also use the following labels to designate status:

• legal-commercial:in progress means the Commercial Legal team is actively working on the issue.
• legal-commercial:pending requester means the Commercial Legal team has a requirement or task that must be met by the requester before the issue progresses.
• legal-commercial:done means the Commercial Legal team has finished their portion of the issue.

CLM Process

• Contract Lifecycle Management (CLM) is a tool that enables the Commercial Legal Team to capture and report data related to legal and business terms. The ultimate goal of the CLM is to make the Legal process more efficient during the CPQ / quote-to-cash process and provide more visibility into the internal request process. Steps the Commercial Legal Team follows after an Agreement has been fully executed include:
  1. Upload the fully executed version, which is to be saved in the SFDC Legal Request by the Sales Team Member, into the CLM tool via the Legal Request Case;
  2. Complete the “Upload Intake Form” with the elements / information related to the Agreement being uploaded; and
  3. Hit “Save”
• By uploading / saving the document in the CLM, the information supplied via the Intake Form will be stored in both the CLM, as well as in the Account details in SFDC. In addition, the fully executed version will be stored in the CLM Repository for ease of retrieval.

RFP Process

With regards to completing RFPs, sometimes referred to as RFIs, RFQs or RFXs, please find information in the RFP Process handbook page.

Best Practices for a Legal Call

Please review the GitLab Legal Best Practices Resource which outlines best practices when contemplating a call between Legal and customer or partner’s legal representative. NOTE: This is available to GitLab Team Members only

Request for Training (LevelUp) Certification Purchases

Training Certification Vouchers are available to purchase via Order Form and are to be redeemed in LevelUp.

Order Form Process for Sales:

• Determine which Certification(s) are being ordered by the Customer and the quantity;
• Generate the complete and accurate quote in Salesforce;
• Open a legal case in Salesforce for preparation of a modified Certification Order Form;
• Ping Deal Desk in the legal case Chatter requesting a Word Doc of the Order Form;
• Legal will modify the Order Form in accordance with written procedures based on the Certification(s) being purchased.

Request for a Trial or Evaluation Agreement

All customers that desire free access to GitLab Software should be directed to initiate a free trial for access to the GitLab Software, which is subject to and governed by GitLab’s Subscription Agreement. A free trial is typically used by a customer for internal evaluation, and, as applicable, may also support a more involved proof of value guided by GitLab.

If a customer declines the trial process and is adamant to have a separate Evaluation Agreement, the sales team member or solutions architect should open a Legal Request to request an Evaluation Agreement with Request Form. The Legal Request should first include a request for approval from the Area Sales Manager or higher and also set forth applicable details to fill out the Request Form, such as customer contact information, length of evaluation, number of users, etc.

Provided the customer has been directed to the trial process first and approvals have been received, the applicable Legal team member will then provide a Request Form, setting forth the details of the evaluation for execution by the customer and GitLab. The Request Form and free access to the GitLab Software will be subject to the terms of the Evaluation Agreement which is attached to the Request Form.

Once the Request Form is executed, the sales team member or solutions architect should save the document in the customer’s account in SFDC. Sales Support should then be tagged in SFDC to assist in activating customer’s free access to the GitLab Software for the applicable term and number of users.

Request for Non-Standard Go-To-Market and Pricing From Legal

All sales-related requests for a non-standard GTM structure, including pricing and packaging variations (e.g. OEM), will likely require Legal assistance but should begin with an Issue opened by the requestor on the Product board here to properly vet the monetization request with the appropriate cross-functional stakeholders. Please choose either the monetization-intake template or the monetization-intake-simple template. Once created, the issue will alert the appropriate stakeholders for internal review, comments, and approvals. Legal will follow the progress of the Issue, and will begin drafting the associated agreement, or non-standard language, after appropriate stakeholders have provided clear guidance on the approved structure.

EDUCATIONAL

Overview of GitLab Agreements

1. GitLab provides its software (both on-premise and SaaS) pursuant to the GitLab Subscription Agreement, and its professional services pursuant to GitLab Professional Services Agreement. You can find our online versions here.
2. GitLab provides full transparency by including historic versions of the subscription terms. These can be found within the Agreement History section.
3. The Subscription Agreement is agreed to by either: (i) customer clicking-through when purchasing (or downloading) software via the GitLab website, (ii) referenced in an order form that is signed by a customer, (iii) signing the negotiated subscription agreement, or (iv) passed through via partner if a customer is buying through an authorized partner.
4. Please note that for a net-new customer that meets the negotiation thresholds, a Legal Request may be opened to request a single agreement that covers both Subscription and Professional Service Terms.
5. GitLab has a Master Partner Agreement that can include multiple exhibits to enable partners to: (i) resell, (ii) refer, or (iii) distribute GitLab software and professional services.

When does GitLab Negotiate?

GitLab has certain thresholds when determining when, and to what extent, we will negotiate our standard terms. GitLab will consider engaging in negotiations as detailed here. NOTE: This is available to GitLab team members only

If the net ARR threshold requirements are met, a Sales team member must open a Legal Request to ask for the most current agreement template. Please do not save an agreement template to a local drive as it may not be the most current version of the agreement. It is highly recommended that the Sales team member uses discretion and discusses the approach with the assigned Legal team member to set the appropriate expectations with the customer. Please see the Subscription Agreement basics below. While negotiation may be inevitable, it is always worth considering the following implications and how best to establish the tone of potential negotiations:

1. Negotiating on GitLab’s Standard Agreement(s): GitLab’s flexibility to accommodate deviations is tied in large part to a number of factors such as the opportunity amount, Net ARR (NARR), strategic importance and Landable Addressable Market (LAM). For example, minimal changes would be expected for a $30K opportunity / NARR with immaterial future LAM.

   • Note about Channel Partners: With regard to partners, eligibility for negotiations arises from partner categorization (Open Partner or Select Partner) as only Select partners will be allowed to negotiate terms.

2. Negotiating on customer’s agreement template: Regardless of the NARR, a customer’s agreement will almost always have terms that are unrelated to, and in some cases at complete odds with, the type of software we sell, how we license our software, and, in the case of professional services, how we implement our software.

   For example, customer agreements rarely cover, (i) an open-core model, (ii) our support SLAs, (iii) correct reference to the types of product usage data that we will (or will not) collect. We sell standard software with no customization or independent development of the underlying GitLab software. If it is determined to utilize a customer’s agreement, it is best practice to work with your assigned Legal team member to pre-emptively message and set expectations with the customer to help establish a level of trust and transparency, knowing that there will likely be extensive modifications and an increased time frame to finalize terms.

   • Note about Channel Partners: GitLab’s Partner Program, and how GitLab enables its channel partners, makes utilizing a partner’s form agreement much more difficult. It will require alignment across multiple cross-functional stakeholders and an additional level of scrutiny before moving forward. Please work with your Legal team member to help guide you through any such process.

What is Open Source?

1. GitLab uses open source software as part of its open core business model. Learn more about the GitLab Open Core Business Model.
2. For a general introduction to open source, including lists of acceptable and unacceptable open source licenses for use in GitLab, see Open Source at GitLab.
3. Helpful external resources on open source software can be found at Opensource.com and the Open Source Inititiave.
4. The open source project for GitLab can be found at gitlab.com/gitlab-org/gitlab.

GitLab Subscription Agreement Basics

🎥 Watch the “Subscription Agreement Basics” Video

Note: The video above is available to GitLab team members only

Business Associate Agreements (BAAs)

Why will GitLab not sign a BAA?

• GitLab is transparent with respect to information it requires, or does not require, in order to provide our products and services.
• GitLab does not require, nor is it designed to be used to store, Protected Health Information (PHI). In addition, GitLab, as an organization, does not desire or need to receive, process, store, transact or otherwise possess PHI in order to provide our products and services. Please view Section 14.3 of the Subscription Agreement, which specifically highlights that GitLab should not receive PHI. As such, GitLab does not meet, and has no intention of meeting, the definition of a “Business Associate” as defined under the Health Insurance Portability and Accountability Act (HIPAA).
• In the event a customer questions “incidental disclosures,” please highlight the HIPAA definition itself, which states: “Business associate functions or activities on behalf of a covered entity include claims processing, data analysis, utilization review, and billing. Business associate services to a covered entity are limited to legal, actuarial, accounting, consulting, data aggregation, management, administrative, accreditation, or financial services. However, persons or organizations are not considered business associates if their functions or services do not involve the use or disclosure of protected health information, and where any access to protected health information by such persons would be incidental, if at all.”

Data Privacy, Security and the GitLab Data Processing Addendum

1. The GitLab Privacy Policy explains how GitLab collects, uses and shares customers’ personal information, and how customers may exercise their rights with repect to that personal information. Additional details on privacy compliance at GitLab, including answers to a number of frequently asked questions concerning GDPR, can be found on the GitLab Privacy Compliance handbook page.
2. The GitLab Data Processing Addendum, usually referred to as the “DPA”, can be accessed from the GitLab Terms of Use page. As stated in the GitLab Subscription Agreement, the terms of the DPA automatically apply to corporate customers.
3. When asking questions about data privacy, customers may also raise questions about security. Generally, such questions are best directed to the Field Security Team. However, the following resources may be useful prior to contacting the Field Security team: -The Security Practices handbook page gives details about GitLab’s organizational security. -GitLab’s Customer Assurance Package provides details of GitLab’s current security and compliance policies. -GitLab documentation explaining how to Secure your application, Secure your installation and the GitLab permissions guide are useful for helping customers understand steps they can take to secure the personal data processed by GitLab.

Contract Lifecycle Management (CLM) Process

1. Contract Lifecycle Management (CLM) is a tool that enables the Legal team to capture and report data related to legal and business terms in its Subscription Agreements. The ultimate goal of the CLM is to make the legal process more efficient during the CPQ / quote-to-cash process and provide more visibility into the internal request process. In order to facilitate this process please ensure that all executed agreements are sent, or otherwise copied to, the Legal team member assigned to the Legal Request.

2. Steps the Legal team follows after an agreement has been fully executed include:

   • Uploading the fully executed agreement, which should already have been saved in the SFDC account by the Sales team member;
   • Completing the Intake Form with the information related to the agreement being uploaded; and
   • Hitting “Save”

3. By uploading the agreement in the CLM, the information supplied via the Intake Form will be stored in the CLM. The fully executed version will be stored in the CLM repository in addition to its location in SFDC. NOTE: This is available to GitLab team members only.

REQUESTING CONTENT

• You are always encouraged to make requests for future content that will help you and the team. Simply complete the form here.

View page source - Edit this page - please contribute.