GitLab is committed to serving our customers and employing individuals with personal standards consistent with that of our values. This Code is designed to deter wrongdoing and to promote:
Our Code applies to all directors, officers, employees, and contractors of GitLab and its affiliates and subsidiaries. Agents and vendors of GitLab are also expected to read, understand, and abide by this Code.
This Code should help guide your conduct in the course of our business. Many of the principles described in this Code are general in nature, and the Code does not cover every situation that may arise. Use common sense and good judgment in applying this Code. If you have any questions about applying the Code, please seek guidance. Not all information regarding the conduct of our business is found in this Code. Please review the applicable policies and procedures in specific areas as they apply as found in our Team Handbook.
The Code of Conduct will be reviewed on an annual basis to ensure compliance with applicable laws and industry standards.
To maintain the highest standards of integrity, we must dedicate ourselves to complying with this Code, company policies and procedures, and applicable laws and regulations. Violations of this Code not only damage our company’s standing in the communities we serve, they may also be illegal. Team members involved in violating this Code will likely face negative consequences. GitLab will take the appropriate disciplinary action in response to each case, up to and including termination. In addition, team members involved may be subject to government fines, or criminal or civil liability.
If you think this Code or any GitLab policy is being violated, or if you have an ethics question, you have several options:
All reports (formal or informal) made to a GitLab supervisor, manager or executive should be promptly escalated to the People Business Partners or to the Chief People Officer (CPO). GitLab will then review the report promptly and thoroughly to determine if an investigation is warranted.
If the People Group has determined it appropriate, GitLab will promptly initiate an appropriate investigation into all possible violations of law and/or GitLab policy. The People Business Partner assigned to the business department will investigate all reports unless:
If the complaint involves a member of the executive team that has direct oversight for the Legal department or involves a member of the Legal department, then the CPO will work with outside counsel to conduct the investigation. If the complaint involves a member of the executive team that has direct oversight for the People Group or involves a member of the People Group, then Legal will work with outside counsel to conduct the investigation.
GitLab expects all employees and contractors to cooperate fully and candidly in investigations.
GitLab will make all reasonable efforts to initiate an investigation into the allegation(s) and conclude the investigation in a timely fashion. Depending on the type of investigation the steps and timeline for each investigation will vary.
The investigation findings will be reported back to the CPO. Based on the investigation findings, the CPO will make a determination as to whether the allegation(s) were founded, unfounded or inconclusive. This determination will be documented in writing and made part of the investigation report. The determinations are as follows:
GitLab has engaged Lighthouse Services to provide an anonymous ethics and compliance hotline for all team members. The purpose of the service is to insure that any team member wishing to submit a report anonymously can do so without the fear of retribution.
Reports may cover but are not limited to the following topics: ethical violations, wrongful discharge, unsafe working conditions, internal controls, quality of service, vandalism and sabotage, sexual harassment, theft, discrimination, conduct violations, alcohol and substance abuse, threats, fraud, bribery and kickbacks, conflict of interest, improper conduct, theft and embezzlement, violation of company policy, violation of the law, misuse of company property, falsification of contract, reports or records.
Please note that the information provided by you may be the basis for an internal and/or external investigation into the issue you are reporting and your anonymity will be protected by Lighthouse to the extent possible by law. However, your identity may become known during the course of the investigation because of the information you have provided. Reports are submitted by Lighthouse to a company designee for investigation according to our company policies.
Lighthouse Services toll free number and other methods of reporting are available 24 hours a day, 7 days a week for use by team members.
Any employee or contractor who reports a violation will be treated with dignity and respect and will not be subjected to any form of discipline or retaliation for reporting in good faith. Retaliation against anyone who provides information or otherwise assists in an investigation or proceeding will be treated as a violation of this Code.
We encourage maximum communication between team members at all levels of the organization. This is an important part of our culture. Whenever problems or concerns arise, it is expected that they will be addressed as quickly as possible. Your immediate manager is the person on the management team who is closest to you and your work. When you need help or have questions, complaints, problems or suggestions, please contact your manager first. It is your manager's responsibility to assist you - so please ask, and be willing to work the issue out with your manager. They are interested in your success, the success of every team member in their department, and the overall success of GitLab.
If your manager cannot help you or answer your questions, your questions will be referred to someone who can. If you feel your particular question, concern or suggestion cannot be discussed with your manager, you are encouraged to contact your manager's manager, your assigned People Business Partner, the Chief People Officer or the CEO. It is important to remember that a team member who takes these steps will not be reproached. You can expect to be treated fairly and with respect.
Having a diverse workforce, made up of team members who bring a wide variety of skills, abilities, experiences and perspectives, is essential to our success. We are committed to the principles of equal opportunity, inclusion, and respect. All employment-related decisions must be based on company needs, job requirements, and individual qualifications. Always take full advantage of what our team members have to offer; listen and be inclusive.
Report suspected discrimination right away and never retaliate against anyone who raises a good faith belief that unlawful discrimination has occurred. Employees and contractors should refer to the GitLab Anti-Harassment Policy for more information.
Every employee or contractor has a right to a work environment free from harassment, regardless of whether the harasser is a co-worker, supervisor, manager, customer, vendor, or visitor. Please refer to the GitLab Anti-Harassment Policy for more information. As is the case with any violation of the Code, you have a responsibility to report any harassing behavior or condition, whether you are directly involved or just a witness.
Our company is committed to following all applicable wage and working hours laws and regulations. To help ensure that all work performed for GitLab is compensated correctly, team members compensated on the basis of hours worked must report and record time accurately. For more information on compensation, please refer to our Compensation Principles.
GitLab strives to maintain a workplace that is free from illegal use, possession, sale, or distribution of alcohol or controlled substances. Legal or illegal substances shall not be used in a manner that impairs a person’s performance of assigned tasks. This will help to maintain the efficient and effective operation of the business, and to ensure customers receive the proper service. GitLab team members must also adhere to the local laws of where they reside and where they travel to, including the GitLab Contribute.
GitLab respects the confidentiality of the personal information of employees and contractors. This includes employee and contractor medical and personnel records. All team member records are kept in BambooHR. Team members have self service access to their profile. Where available, documents and information are shared with the team member within the platform. If a team member would like to view their entire profile from the admin view, please schedule a call with People Operations Specialists to walk through a screen share or request screenshots to be sent to your personal email address. Access to personal information is only authorized when there is a legitimate and lawful reason, and access is only granted to appropriate personnel. Requests for confidential employee or contractor information from anyone outside our company under any circumstances must be approved in accordance with applicable laws. It is important to remember, however, that employees and contractors should have no expectation of privacy with regard to normal workplace communication or any personal property used for GitLab business.
If there is no requirement within someone's job description to be public-facing, then team members can opt-out of any public exposure. Team members can opt-out of being added to the team page or what content about them is shown on the team page and can use either only their initials or an alias if desired. Since GitLab publishes much of our content, including video calls and meetings, the only way to ensure no unwanted exposure from these videos is to have video turned off and initials or an alias added to the Zoom profile name whenever a call is being recorded. Zoom shows whether a call is being recorded at the top right of the video screen, and team members are always encouraged to ask if a video will be shared or not. For any GitLab livestreams through YouTube, a team member can watch and comment through YouTube instead of through the internal video call. Any questions can be sent directly to our People Business Partners or CPO.
In the event you feel that you have not received proper attention to your data concern, or if you have any other legal/law enforcement concern - please contact GitLab's Legal Department at Legal@gitlab.com.
GitLab, Inc. is a global company with its headquarters in the U.S. This means that personal information may be used, processed, and transferred to the United States and other countries or territories and those countries or territories may not offer the same level of data protection as the country where you reside, including the European Economic Area. However, GitLab will ensure that appropriate or suitable safeguards are in place to protect your personal information and that transfer of your personal information complies with applicable data protection laws. Where required by applicable data protection laws, GitLab has ensured that service providers (including other GitLab affiliates) sign standard contractual clauses as approved by the European Commission or other supervisory authority with jurisdiction over the relevant GitLab data exporter (which typically will be your employer).
Who is collecting your personal data (who is the data controller)?
The GitLab entity that is a party to your employment contract or contract for services or otherwise employees you will be the data controller of your personal data. The following are the GitLab entities that act as controller: GitLab, Inc., GitLab, LLC., GitLab BV, GitLab GmbH, GitLab, LTD, GitLab PTY Ltd, GitLab Canada Corp, GitLab IT BV, and other GitLab subsidiaries throughout the globe ("collectively "GitLab").
GitLab affiliates may act as processors on behalf of other GitLab affiliates and/ or controllers. Furthermore, the GitLab its affiliates and subsidiaries participate in group-wide IT system in order to harmonize GitLab’s IT infrastructure and its use (the “System”). The System also may hold data on all employees, workers, individual contractors and contingent workers ("Staff"). Insofar the System serves to improve and harmonize most of the human resources (“HR”) processes within GitLab. GitLab, Inc. in the US is responsible for the System.
Applicability of Other GitLab Privacy Policies
Third Party Services
In some cases, you may provide personal information to third parties that GitLab works with or that provide services to GitLab. This includes, those parties identified in the Tech Stack Application document (“Third Parties”).
What is Personal Information?
Examples of personal information include:
What is Sensitive Personal Information?
Sensitive personal information is a subset of personal information that may be more sensitive in nature for the individual concerned.
Examples of sensitive personal information include:
What Personal Information Do We Collect?
We collect and maintain different types of personal information about you in accordance with applicable law. This includes the following:
Physical limitations and special needs in order to provide accommodations.
Where permitted by law and applicable we may collect the results of credit and criminal background checks, screening, health certifications, driving license number, vehicle registration, and driving history.
Information required for us to comply with laws, the requests and directions of law enforcement authorities or court orders (e.g., child support and debt payment information).
Acknowledgements regarding our policies, including employee handbooks, ethics and/or conflicts of interest policies, and computer and other corporate resource usage policies.
Information captured on security systems and key card entry systems.
Voicemails, e-mails, correspondence, documents, and other work product and communications created, stored or transmitted using our networks, applications, devices, computers, or communications equipment.
Date of resignation or termination, reason for resignation or termination, information relating to administering termination of employment (e.g. references).
Letters of offer and acceptance of employment.
Your resume or CV, cover letter, previous and/or relevant work experience or other experience, education, transcripts, or other information you provide to us in support of an application and/or the application and recruitment process.
References and interview notes.
Information relating to any previous applications you may have made to GitLab and/or any previous employment history with GitLab.
For specifics about what information is collected by third party applications, please refer to the Tech Stack Applications.
How is Data Collected?
Generally, we collect personal information directly from you in circumstances where you provide personal information (during the onboarding process, for example). However, in some instances, the personal information we collect has been inferred about you based on other information you provide us, through your interactions with us, or from third parties. When we collect your personal information from third parties it is either because you have given us express consent to do so, your consent was implied by your actions (e.g., your use of a Third-Party employee service made available to you by us), or because you provided explicit consent to the Third-Party to provide the personal information to us. Where permitted or required by applicable law or regulatory requirements, we may collect personal information about you without your knowledge or consent.
We reserve the right to monitor the use of our equipment, devices, computers, network, applications, software, and similar assets and resources for the safety and protection of employees and intellectual property. In the event such monitoring occurs, it may result in the collection of personal information about you. If required by applicable law, we will notify you of such monitoring and obtain your consent.
How We Process and Use Your Personal Information
We may collect and process your personal information in the Systems for various purposes subject to local laws and any applicable collective bargaining agreements and works council agreements, including:
Recruitment, training, development, promotion, career, and succession planning
Appropriate vetting for recruitment and team allocation including, where relevant and appropriate, credit checks, right to work verification, identity fraud checks, relevant employment history, relevant regulatory status and professional qualifications
Providing and administering remuneration, salary, benefits, and incentive schemes and providing relevant information to payroll
Allocating and managing duties and responsibilities and the business activities to which they relate
Identifying and communicating effectively with other employees and management
Managing and operating conduct, performance, capability, absence, and grievance related reviews, allegations, complaints, investigations, and processes and other informal and formal HR processes and making related management decisions
Consultations or negotiations with representatives of the workforce
Conducting surveys for benchmarking and identifying improved ways of working employee relations and engagement at work (these will often be anonymous but may include profiling data such as age to support analysis of results)
Processing information about absence or medical information regarding physical or mental health or condition in order to assess eligibility for incapacity or permanent disability related remuneration or benefits, determine fitness for work, facilitate a return to work, make adjustments or accommodations to duties or the workplace and make management decisions regarding employment or engagement or continued employment or engagement or redeployment and conduct related management processes
For planning, managing and carrying out restructuring or redundancies or other change programs including appropriate consultation, selection, alternative employment searches and related management decisions
Operating email, IT, Internet, intranet, social media, HR related and other company policies and procedures. The company carries out monitoring of GitLab's IT systems to protect and maintain the systems, to ensure compliance with GitLab policies and to locate information through searches where needed for a legitimate business purpose
Complying with applicable laws and regulation (for example maternity or parental leave legislation, working time and health and safety legislation, taxation rules, worker consultation requirements, other employment laws and regulation to which GitLab is subject in the conduct of its business)
Monitoring programs to ensure equality of opportunity and diversity with regard to personal characteristics protected under local anti-discrimination laws
Planning, due diligence and implementation in relation to a commercial transaction or service transfer involving GitLab that impacts on your relationship with GitLab (for example mergers and acquisitions or a transfer of your employment under automatic transfer rules)
For business operational and reporting documentation such as the preparation of annual reports or tenders for work or client team records including the use of your personal photo
In order to operate the relationship with Third-Party customer and suppliers including the disclosure of relevant vetting information in line with the appropriate requirements of regulated customers to those customers, contact or professional CV details or resume, or your personal photo for identification to clients or disclosure of information to data processors for the provision of services to GitLab
Where relevant for publishing appropriate internal or external communications or publicity material including via social media in appropriate circumstances, provided that privacy rights are preserved
To support HR administration and management and maintaining and processing general records necessary to manage the employment or worker relationship and operate the contract of employment or engagement
To centralize HR administration and management processing operations in an efficient manner for the benefit of our employees and to change access permissions
To provide support and maintenance for the System
To enforce our legal rights and obligations, and for any purposes in connection with any legal claims made by, against or otherwise involving you
To comply with lawful requests by public authorities (including without limitation to meet national security or law enforcement requirements), discovery requests, or where otherwise required or permitted by applicable laws, court orders, government regulations, or regulatory authorities (including without limitation data protection, tax and employment), whether within or outside your country
Other purposes permitted by applicable privacy and data protection legislation including where applicable, legitimate interests pursued by GitLab where this is not overridden by the interests or fundamental rights and freedoms of employees.
Additional information regarding specific processing of personal data may be notified to you by locally.
Legal Basis for processing
Where applicable data protection laws require us to process your personal data on the basis of a specific lawful justification, we generally process your personal data under one of the following bases:
Compliance with a legal obligation to which GitLab is subject; Entering into at-will employment (for US only) or performance under an employment contract with GitLab; For GitLab's legitimate interests being those purposes described in the section above headed "How We Process and Use Your Personal Information"; Your consent where required and a legitimate legal basis under applicable local laws.
We may on occasion process your personal data for the purpose of the legitimate interests of a Third-Party where this is not overridden by your interests.
Processing of Special Categories of Personal Data
“Special Categories of Personal Data” includes information revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, health, sex life or sexual orientation, as well as genetic and biometric data.
From time to time you may provide us with information which constitutes Special Categories of Personal Data or information from which Special Categories of Personal Data may be deduced. In such cases, where required by law, we will obtain your express written consent to our processing of Special Categories of Personal Data. If separate consent is not required by local law, by providing this information to GitLab, you give your freely given, informed, explicit consent for us to process those Special Categories of Personal Data for the purposes set out in How We Process and Use Your Personal Information section above.
You may withdraw your consent at any time by contacting your Local HR Department or DPO. Where you have withdrawn consent but GitLab retains the personal data we will only continue to process that Special Category Personal Data where necessary for those purposes where we have another appropriate legal basis such as processing necessary to comply with legal obligations related to employment or social security. However, this may mean that we cannot (for example) administer certain benefits or contact your next-of-kin in an emergency or provide support to you above and beyond our legal obligations. You give your knowledgeable, freely given, express consent to GitLab for GitLab to use, disclose and otherwise process any personal health information about you that is provided to GitLab by any of your personal health information custodians, for the purposes set out in the How We Process and Use Your Personal Information section above.
Sharing Personal Information
Your personal information may be shared, including to our affiliates, subsidiaries, and other third parties, as follows:
Where you request us or provide your consent to us.
We may buy or sell businesses and other assets. In such transactions, employee information is generally one of the transferred business assets and we reserve the right to include your personal information as an asset in any such transfer. Also, in the event that we, or substantially all of our assets, are acquired, your personal information may be one of the transferred assets.
Where required by law, by order or requirement of a court, administrative agency, or government tribunal, which includes in response to a lawful request by public authorities, including to meet national security or law enforcement requirements or in response to legal process.
If we determine it is necessary or desirable to comply with the law or to protect or defend our rights or property.
As necessary to protect the rights, privacy, safety, or property of an identifiable person or group or to detect, prevent or otherwise address fraud, security or technical issues, or to protect against harm to the rights, property or safety of GitLab, our users, applicants, candidates, employees or the public or as otherwise required by law.
Where the personal information is public and exempted from coverage under applicable data protection laws.
To seek advice from our lawyers and other professional advisors.
To professional advisors (e.g. bankers, lawyers, accountants) and potential buyers and vendors in connection with the sale, disposal or acquisition by use of a business or assets.
Access to Personal Information We Collect
To the extent access is required by applicable law, you can ask to see the personal information that we hold about you. If you want to review, verify or correct your personal information, please submit a request to the HR Department or DPO.
When requesting access to your personal information, please note that we may request specific information from you to enable us to confirm your identity and right to access, as well as to search for and provide you with the personal information that we hold about you. We may, in limited circumstances, charge you a fee to access your personal information; however, we will advise you of any fee in advance.
We reserve the right not to grant access to personal information that we hold about you if access is not required by applicable law. There are also instances where applicable law or regulatory requirements allow or require us to refuse to provide some or all of the personal information that we hold about you. In addition, the personal information may have been destroyed, erased or made anonymous. In the event that we cannot provide you with access to your personal information, we will inform you of the reasons why, subject to any legal or regulatory restrictions.
Correction of Collected Personal Information
We endeavor to ensure that personal information in our possession is accurate, current and complete. If an individual believes that the personal information about him or her is incorrect, incomplete or outdated, he or she may request the revision or correction of that information. We reserve the right not to change any personal information we consider to be accurate or if such correction is not required by applicable law.
Retention of Collected Information
Except as otherwise permitted or required by applicable law or regulatory requirements, we may retain your personal information only for as long as we believe it is necessary to fulfill the purposes for which the personal information was collected (including, for the purpose of meeting any legal, accounting or other reporting requirements or obligations) and for IT archival purposes.
Personal data for data subjects in the European Union is by default erased by GitLab after termination of your employment, with the exception of certain types of personal data, which may be stored for an extended period of time due to administrative purposes, e.g. for payment of retirement income or for giving references to other employers, or where such personal data must be retained to comply with regulatory requirements.
You may request that we delete the personal information about you that we hold, provided that we reserve the right not to grant such request if we are not required to delete personal information under applicable law. There are instances where applicable law or regulatory requirements allow or require us to refuse to delete this personal information. In the event that we cannot delete your personal information, we will inform you of the reasons why, subject to any legal or regulatory restrictions.
Requests to Access, Delete, or Correct Information
Please send requests to access, delete, or correct your personal information to your DPO.
Any request by you to us to delete your personal information will not result in deletion of any information submitted by you to a Third-Party provider. If you require the Third-Party to delete any of your personal information, you must contact the Third-Party directly to request such deletion.
As stated previously, there are instances where applicable law or regulatory requirements allow or require us to refuse to delete this personal information. In the event that we cannot delete your personal information, we will inform you of the reasons why, subject to any legal or regulatory restrictions.
If you have questions or concerns regarding the handling of your personal information, please contact your local HR Department or DPO. Alternatively, you may report concerns or complaints to the Legal Department.
You may also anonymously report violations of policy or law using our Third-Party managed Compliance & Fraud Prevention Hotline. You can access the Hotline by going to How to Contact GitLab's 24 Hour Hotline
Security of Collected Information
We are committed to protecting the security of the personal information collected, and we take reasonable physical, electronic, and administrative safeguards to help protect the information from unauthorized or inappropriate access or use.
Additional Rights You may also have the following additional rights, subject to certain exceptions and limitations as specified in applicable law:
Where we are relying upon your consent or the fact that the processing is necessary for the performance of a contract to which you are party as the legal basis for processing, and that personal information is processed by automatic means, to the extent provided under applicable law, you have the right to receive all such personal information which you have provided to GitLab in a structured, commonly used and machine-readable format, and also to require us to transmit it to another controller where this is technically feasible;
Right to restriction of processing
You have the right to restrict our processing of your personal information where:
To the extent required by applicable law, where personal information is subjected to restriction in this way we will only process it with your consent or for the establishment, exercise or defense of legal claims.
Right to withdraw consent
Where we are relying upon your consent to process data, you have the right to withdraw such consent at any time. You can do this by contacting your local HR Department or DPO.
Right to object to processing justified on legitimate interest grounds
Where we are relying upon legitimate interest to process data, then you have the right to object to such processing, and we must stop such processing unless we can either demonstrate compelling legitimate grounds for the processing that override your interests, rights and freedoms or where we need to process the data for the establishment, exercise or defense of legal claims. Normally, where we rely upon legitimate interest as a basis for processing we believe that we can demonstrate such compelling legitimate grounds, but we will consider each case on an individual basis.
You also have the right to lodge a complaint with a supervisory authority, in particular in your country of residence, if you consider that the processing of your personal data infringes this regulation.
In carrying out GitLab’s business, team members often learn confidential or proprietary information about our company, its customers, prospective customers, or other third parties. Team members must maintain the confidentiality of all information entrusted to them, except when disclosure is authorized or legally mandated.
Confidential or proprietary information includes:
GitLab’s confidentiality provisions can be found in the employee and contractor templates, but these may vary from what you agreed to at the time of your contract. For specific information about your obligations regarding confidentiality, please reference your contract.
In addition to confidentiality obligations owed to third parties, we also have obligations to protect the personal and sensitive information of our fellow team members. Therefore, you may not access and/or disseminate any team member's personal information (i.e. address, personal phone number, salary, etc.) that the team member has not made publicly available, unless the team member has provided written permission to share the information. An exception to this restriction would be when access is a necessary function of your job duties. A violation of this obligation is considered severe and could result in disciplinary action, up to and including termination.
Employees know that they have to protect Confidential Information. But did you know that employees also cannot use Confidential Information? Employees are not permitted to use or share Confidential Information for purposes of trading securities, illegal activities or for any other purpose except to conduct GitLab business. Insider trading (or dealing) laws and regulations globally prohibit buying or selling a company’s securities while in possession of Confidential Information about that company that is Nonpublic and Material.
Employees can also violate these laws by disclosing Material Nonpublic Confidential Information to another person if, as a result, that person – or any other person – buys or sells a security while aware of that information. If you make such a disclosure or use such information, there can be stiff penalties, even if you yourself stand to make no financial gain.
Clarity on whether information is “Nonpublic” or “Material” or what restrictions exist on the use or distribution of such information is provided below. Further questions should be directed to the Legal or Compliance Department.
Definitions Nonpublic Information is Confidential Information that is maintained or otherwise handled by GitLab that may be harmful to GitLab, it’s employees or others with whom GitLab does business as defined in the Data Classification policy, including, but not limited to, any of the following: Information used for, or obtained from, a rated entity or its agent for the purpose of determining a rating or pending rating; Major personnel changes; Lawsuits that may trigger heavy damages; Mergers, acquisitions; Substantial contracts not in the ordinary course of business; Information concerning the rating committee process, including, but not limited to, the voting breakdown in the committee, the fact that a member of the rating committee disagreed with the ultimate committee decision, and the names or titles of members of the committee; Nonpublic Information relating to GitLab’s customers and information provided by GitLab’s customers, including internal risk assessment models, information concerning the performance of those models, historical default data for loan portfolios, customer-specific loan pricing information and information concerning portfolio composition and concentration; GitLab’s nonpublic financial information and sales projections; or Information regarding GitLab’s business plans, strategies, proprietary systems, algorithms, formulas, methodologies, product designs, processes, research and development information and trade secrets; or Special Personal Information.
Material Information has no precise definition and is subject to a variety of interpretations. Accordingly, for the purposes of this Policy, “Material Information” refers to any information that: (i) might have an effect on the market for a security generally; or (ii) might affect an investment decision of a reasonable investor.
Examples of Material Information may include, but are not limited to: sales results earnings or estimates (including reaffirmations or changes to previously released earnings information) dividend actions strategic plans new products, discoveries or services major personnel changes Merger, acquisition and divestiture plans Financing plans Proposed securities offerings Government actions Substance of major litigation or potential claims Negotiation or termination of major contracts Rating or pending rating actions
If you are not sure whether or not a particular piece of information is Material Information, you should err on the side of caution and assume that it is Material Information. In other jurisdictions, Material Information may be referred to as “inside information” or “price-sensitive information”.
Material Nonpublic Information refers to information that is both Material and Non-Public Confidential Information.
All employees and contractors must protect our company assets, such as equipment, inventory, supplies, cash, and information. Treat company assets with the same care you would if they were your own. No employee or contractor may commit theft, fraud or embezzlement, or misuse company property.
The Gitlab Internal Acceptable Use Policy specifies requirements related to the use of GitLab computing resources and data assets by GitLab team-members so as to protect our customers, team members, contractors, company, and other partners from harm caused by both deliberate and inadvertent misuse. Our intention in publishing this policy is not to impose restrictions but outline information security guidelines intended to protect GitLab assets.
Our company uses global electronic communications and resources as routine parts of our business activities. It is essential that electronic resources used to perform company business are protected to ensure that these resources are accessible for business purposes and operated in a cost-effective manner, that our company’s reputation is protected, and that we minimize the potential for legal risk.
In addition to following the Social Media Guidelines, when utilizing social media think about the effects of statements that you make. Keep in mind that these transmissions are permanent and easily transferable, and can affect our company’s reputation and relationships with team members and customers. When using social media tools like blogs, Facebook, Twitter or wikis, ensure that you do not make comments on behalf of GitLab without proper authorization. Also, you must not disclose our company’s confidential or proprietary information about our business, our suppliers, or our customers.
We take the protection of privacy for our customer’s, consumer’s, and other third parties that have entrusted us with information very seriously. Customer or third party information includes any information about a specific customer/third party, including such things as name, address, phone numbers, financial information, etc. Specifically, note that:
If you do not have a business reason to access this information, you should not do so. If you do, you must also take steps to protect the information against unauthorized use or release in line with our Security Best Practices.
Our intellectual property is among our most valuable assets. Intellectual property refers to creations of the human mind that are protected by various national laws and international treaties. Intellectual property includes copyrights, patents, trademarks, trade secrets, design rights, logos, expertise, and other intangible industrial or commercial property. We must protect and, when appropriate, enforce our intellectual property rights. We also respect the intellectual property belonging to third parties. It is our policy to not knowingly infringe upon the intellectual property rights of others.
Assignment of intellectual property is addressed in the employee and contractor templates, but these may vary from what you agreed to at the time of your contract. For specific information about your obligations regarding intellectual property rights and obligations, please reference your contract.
All directors, officers, employees, and contractors must comply with antitrust and competition laws which prohibit collusive or unfair business behavior that restricts free competition. These laws are quite complicated, and failure to adhere to these laws could result in significant penalties imposed on both GitLab and the employees and/or contractors who violated the law.
Unlawful behavior examples:
Such laws prohibit efforts and actions to restrain or limit competition between companies that otherwise would be competing for business in the marketplace. You must be particularly careful when you interact with any employees, contractors or representatives of GitLab’s competitors, especially at trade association meetings or other industry or trade events where competitors may interact. Under no circumstances should you discuss customers, prospects, pricing, or other business terms with any employees or contractors or representatives of our competitors.
If you are not careful, you could find that you have violated antitrust and competition laws if you discuss or make an agreement with a competitor regarding:
Depending on business justification and effect on competition, other practices not involving competitors may also result in civil violations of the antitrust and competition laws. These practices include:
We engage in open and fair procurement activities regardless of nationality or the size of the transaction. Suppliers are selected on a competitive basis based on total value, which includes quality, suitability, performance, service, technology, and price. We strive toward establishing mutually beneficial relationships with our suppliers based on close cooperation and open communication. Terms and conditions defining our relationship with suppliers are communicated early in the supplier selection process. Any agreements to such terms and conditions, or any acceptable modifications, are reached before work begins.
It is our responsibility to accurately represent GitLab and our products in our marketing, advertising, and sales materials. Deliberately misleading messages, omissions of important facts or false claims about our products, individuals, competitors or their products, services, or employees or contractors are inconsistent with our values. Sometimes it is necessary to make comparisons between our products and our competitors. When we do, we will make factual and accurate statements that can be easily verified or reasonably relied upon.
Gathering information about our competitors, often called competitive intelligence, is a legitimate business practice. Doing so helps us stay competitive in the marketplace; however, we must never use any illegal or unethical means to get information about other companies.
Legitimate sources of competitive information include:
When working with consultants, vendors, and other partners, ensure that they understand and follow GitLab policy on gathering competitive information.
Money laundering is a global problem with far-reaching and serious consequences. Money laundering is defined as the process of converting illegal proceeds so that funds are made to appear legitimate, and it is not limited to cash transactions.
Complex commercial transactions may hide financing for criminal activity such as terrorism, illegal narcotics trade, bribery, and fraud. Involvement in such activities undermines our integrity, damages our reputation and can expose GitLab and individuals to severe sanctions.
Our company forbids knowingly engaging in transactions that facilitate money laundering or result in unlawful diversion. Anti-money laundering laws require transparency of payments and the identity of all parties to transactions. We are committed to full compliance with anti-money laundering laws throughout the world and will conduct business only with reputable customers involved in legitimate business activities and transactions.
We believe in doing business with third parties that embrace and demonstrate high principles of ethical business behavior. We rely on suppliers, contractors, and consultants to help us accomplish our goals. They are part of the GitLab team and should be treated according to our values. To create an environment where our suppliers and consultants have an incentive to work with GitLab, they must be confident that they will be treated in an ethical manner. We offer fair opportunities for prospective third parties to compete for our business. The manner in which we select our suppliers and the character of the suppliers we select reflect on the way we conduct business.
Globally, many countries have laws that prohibit bribery, kickbacks, and other improper payments. No GitLab employee, contractor, officer, agent, or vendor acting on our behalf may offer or provide bribes or other improper benefits in order to obtain business or an unfair advantage. You must avoid participating in commercial bribery and kickbacks, or even the appearance of it, in all of our business dealings. Even in locations where such activity may not technically be illegal, it is absolutely prohibited by our company policy.
Modest gifts, favors, and entertainment are often used to strengthen business relationships. However, no gift, favor, or entertainment should be accepted or given if it obligates, or appears to obligate, the recipient, or if it might be perceived as an attempt to influence fair judgment.
In general, unless you have supervisory approval you should not provide any gift or entertainment to customers, suppliers, or others that you would not be able to accept from a customer, supplier, or other applicable parties.
All directors, executives, and anyone else in the company participating in vendor selection, must disclose all gifts and entertainment valuing over US$250 for the six months prior to the vendor selection and during the term of the services and for a period of twelve months after services have been completed. The disclosure shall be made to the Legal department, and shall include the value of the gift or entertainment, the individual or company providing the gift, favor, or entertainment, and the date on which it was received. If you have any questions relating to this section, feel free to contact the Legal department.
GitLab is not to engage in activities that could threaten foreign policy and national security interests of the United States or other countries in which GitLab has facilities, international peace and security by distribution of products to end-users that could violate applicable export control laws. This Trade Compliance Policy defines the security transaction controls and control procedures to be developed and implemented at GitLab.
An export is the transfer of goods, technology, technical data and software transfer to a foreign country or a foreign national. Be advised that “export” includes downloads, electronic access to technology, emails and even visual reviews.
Goods, Technology, Technical Data & Software Transfers
Goods, technology, technical data & software transfers may be subject to Export Administration Regulations (the “EAR”) and also to the export control laws of other countries in which GitLab operates. For example, exports by GitLab from Canada would be subject to the EAR and also to Canada’s Export and Import Permits Act and the Canadian Export Control List (the “ECL”). For export purposes, technology and technical data includes any information that can be used or adapted for use in the design, development, manufacture, utilization, or reconstruction of products or commodities. This can include more than tangible items. For example, intangible items such as technical services, presentations, product demonstrations and software would be included in technology and technical information for the purposes of export control laws.
For the purposes of the EAR, an export of technology, technical data, and/or software is defined as the release of technology or software subject to the EAR, released in a foreign country and/or any release of technology or source codes (does not include object codes) subject to the EAR to a foreign national. Release to foreign nationals is deemed to be an export to the home country or countries of the foreign national (a “Deemed Export”). Some other countries, such as Canada, do not control Deemed Exports under their export control laws, however, US export control laws will still apply to Deemed Exports within those countries.
A Deemed Export does not apply to persons lawfully admitted for permanent residence in the United States (“green card” holders) and does not apply to persons who are protected under the Immigration and Naturalization Act.
It is possible that a license may have to be obtained prior to visits with foreign nationals or discussions of technical information with foreign nations, whether these occur at US facilities or in other countries.
Release for Export includes:
Visual inspection by foreign nationals of U.S. equipment and facilities such as demonstrations and on-site training; Oral and written exchanges of information in the U.S. or abroad. This includes exchange or transmission of information through any media such as facsimile, email, internet, intranet, telephone, downloading, or causing the downloading, of software to locations outside the U.S. or to foreign nationals. Applications of situations abroad of personal knowledge or technical experience acquired in the U.S.; or Downloading or actual physical shipment of the technology or software. Similar rules apply in other countries in respect to what is or is not considered to be an export.
NOT subject to Export Administration Regulation (EAR) Control The following technology, technical data and software are not subject to and are outside the scope of the EAR. However, other policy controls and restrictions may apply:
Technology, technical data and software that is publicly available, meaning published in periodicals, books, print, or electronic media that is available to the public at a price that does not exceed the cost of reproduction or distribution; Data that is readily available at universities or other public libraries; All patent information available at any patent office; All technical data presented at open conferences, meetings, seminars or trade shows, provided the gathering is open to all technically qualified members of the public and that attendees are permitted to take notes or otherwise make a record of the proceedings; Technology, technical data or software arising during, or resulting from, fundamental research (as described in the EAR); or Technology, technical data or software that is educational in nature (as described in the EAR).
Other countries have similar exemptions, however, the specific exemptions for each country should be reviewed if technology, technical data or software is being exported from those countries to make sure that the exemptions recognized under U.S. law are also recognized under the law of the applicable country from which an export is being considered.
Release of information into the public domain is a conscious decision on the part of GitLab. In many cases, technology (in the form of product data sheets or technical specifications) has been released through distribution at public trade shows. Technology in the form of detailed drawings for production or manufacturing procedures is not public domain data.
Items are given special classification numbers (ECCNs). These numbers help determine whether a license is required. To determine an ECCN, you must know the ECCNs of the technology that was included in the overall export. Items that are EAR99 are the easiest to export. That said, the addition of a highly-regulated piece of technology can change the overall ECCN of the entire product. Other countries have their own classification systems that specify what is and is not controlled under their export control laws. When obtaining new good, software or technology from third party – make sure you know the ECCN or if an ECCN is not available, the applicable foreign law classification for the applicable good, software or technology.
Company Type Classification GitLab’s current product Export Control Classification Number is 5D992.c. (Contact the Legal Department for a copy of letter.)
New Projects/Products/Tenders The relevant business unit will work with The Legal Department to determine the export classification of new software as soon as possible during the project. Please note that changes to the encryption functionality may require a new export classification. This will usually occur after feature scope is determined and the origin of technologies to be used in the project is known. If an applicable product is going to be exported from GitLab’s facilities outside of the U.S., then an export classification will also need to be done for that country.
Ongoing Surveillance of Export Classification All Product Classification sheets will be reviewed annually to ensure the export classification of the software has not changed, if GitLab is still exporting that software. GitLab will also monitor regulation changes that might affect the classification of GitLab products or other items that could be exported.
Standard Terms and Conditions of Sale Our standard terms and conditions of sale contain text substantially similar to the following: *Exports and U.S. Government Rights. The Products furnished to you may be subject to export and other restrictions under the laws and regulations of the United States of America and other countries. You hereby agree that you shall not transfer, export or re-export, directly or indirectly, any Product or technical data received from GitLab to any destination or entity subject to export or other restrictions under the laws and regulations of the United States of America or any other applicable countries unless prior written authorization is obtained from GitLab and the appropriate United States and applicable foreign agencies. The Products are provided with Restricted Rights. Use, duplication or disclosure by the U.S. government is subject to restrictions as set forth in (a) this Agreement pursuant to DFARs 227.7202-3(a); (b) subparagraph (c)(1)(i) of the Rights in Technical Data and Computer Software clause at DFARs 252.227-7013; or (c) the Commercial Computer Software Restricted Rights clause at FAR 52.227-110 subdivision (c)(1) and (2), as applicable. *
Some countries (and nationals of those countries) are prohibited from accessing US Technology.
Countries prohibited from receiving any technology include: Cuba, Iran, North Korea, Sudan, Syria and the Crimean Region of the Ukraine.
US Government Classified Information must only be accessible by US Citizens who have appropriate clearance and a need to know. If you know or believe GitLab is in receipt of US or Foreign Government Classified Information, please contact Legal or Compliance.
Additionally, companies cannot agree to boycott any other country. If you receive any request to boycott a country, please notify Legal.
Embargoed Countries The United States restricts imports and exports to certain destination without a specific authorization from the government. Products exported to an entity within an embargoed country or to a foreign national of that country, e.g., Cuba, Iran, North Korea, Sudan, Syria, and the Crimean Region of the Ukraine will require a license, even if the shipment is through a reseller or via another country. Some countries have legislation that prohibits the imposition of U.S. embargo requirements on individuals and companies in those countries (“Blocking Legislation”).
U.S. Anti-Boycott U.S. Anti-Boycott regulations exist to counteract foreign economic boycotts that are at odds with U.S. policy. It is GitLab's policy to comply with the requirements of Anti-Boycott regulations. Actions prohibited by the regulations include:
Refusing (or agreeing to refuse) to do business with entities “blacklisted” under a foreign boycott. Discriminating against a person based on race, religion, sex, national origin, or nationality condemned by a foreign boycott. Furnishing information that would assist in furthering a foreign boycott. Implementing letters of credit that include prohibited boycott terms or conditions.
Employees encountering requests or issues to avoid certain countries, nationals or protected individuals should contact Legal immediately. Under certain circumstances, the anti-boycott laws may require filing a report with the U.S. Department of Commerce regarding the request to participate in the boycott even if the employee correctly refuses to participate. Other countries have similar anti-boycott provisions.
Some people have been prohibited from receiving technology by various government agencies. To ensure that a particular person or entity is not prohibited, a Denied Party Screen must be completed before any export occurs. Companies with whom GitLab does business, must undergo a due diligence review which includes a Denied Party Screen, valid contract and background check of the entity.
Due Diligence If there are any suspicions about any particular customer, reseller, or order, they should be discussed with the Export Compliance Officer or Legal.
There must be sufficient information provided about a customer to ensure a proper Denied Party Screen can be completed. If this information is missing, the Sales person shall contact the reseller or the end-user to ask them to provide the requisite information.
To ensure traceability the individual performing the Denied Party Screen shall record the end-user site details for all approved orders received directly from end-users as well as any resellers. It is important to always be assured that the end-user and the end-use is legitimate.
Denied Party Screens Prior to the release of technology to a foreign country or foreign national, sales operations, order processing, shipping, engineering and/or licensing shall ensure that the receiving person or entity is not on an Export Control Watch List by conducting a Denied Party Screen. If an export is being done from a country other than the U.S., then the denied parties list for that country will need to be checked in addition to the US denied persons screening. If any of the customers are on any of the Export Control Watch Lists, the Transaction will be escalated to the Export Control Officer who will work with the relevant departments and government agencies to determine if the delivery is allowed. It is important to note that products that are being shipped to an entity on the Export Control Watch Lists will require a license, even if the shipment is through a reseller or via another country. The outcome of this Legal determination will be binding. The completion of this check will be recorded in the appropriate records and in the appropriate customer record in GitLab’s salesforce.com system.
In some cases, an End Use Certificate may be required from the End User of a product to confirm legitimate uses of the product being exported. If you are suspicious of the intentions of a purchaser, consult Legal.
End Use GitLab's Products are designed and intended for commercial use. In the event that GitLab knows or had reason to know that a customer seeks to use GitLab products for improper or nefarious purposes, please contact Legal so that the appropriate End Use statements can be obtained.
If you have any questions or concerns about anything herein, please contact Compliance@gitlab.com.
We must ensure all statements and representation to government procurement officials are accurate and truthful, including costs and other financial data. If your assignment directly involves the government or if you are responsible for someone working with the government on behalf of GitLab, be alert to the special rules and regulations applicable to our government customers. Please review GitLab's Public Sector Rules of Engagement for more details on dealing with the US Federal Government. Please note that government agencies, in general (US or otherwise) have more strenuous requirements than traditional customers. Be aware of the heightened sensitivity around dealing with any government entity or foreign official.
Any conduct that could appear improper should be avoided when dealing with government officials and employees or contractors. Payments, gifts, or other favors given to a government official or employee are strictly prohibited as it may appear to be a means of influence or a bribe. Failure to avoid these activities may expose the government agency, the government employee, our company, and you to substantial fines and penalties.
This Records Retention Policy promotes and assists with the implementation of procedures, best practices, and tools to promote consistent life cycle management of GitLab records. Because records contain important information, it is essential to take a systematic approach to the management of records.
1. Records Management Records management addresses the life cycle of records, i.e., the period of time the records are in the possession of GitLab. The life cycle usually consists of three stages: 1) Creation or receipt; 2) Maintenance or use; and 3) Destruction or retention. This policy is used in conjunction with the Records Retention Schedule. Records retention does not mean permanent retention. There are certain situations where documents must be preserved permanently, but most records need only be retained for a specified period of time. When the retention period for a particular record expires, we should destroy or delete the record. However, if we destroy or delete a record before its retention period expires, GitLab may be subject to penalties and sanctions. Unnecessary retention of records creates significant burdens for GitLab. For example, unnecessary records take up valuable storage space and make retrieval of needed records more difficult and costly. Consequently, GitLab recommends destruction of records after the retention period expires, except in those instances where GitLab directs otherwise (such as when a Litigation Hold is issued by the Legal Department). In other words, GitLab requires adherence to the records retention requirements and recommends the destruction of records according to the Retention Schedule.
2. The Difference between a “Record” and “Non-Record” GitLab Records Retention Policy is based on a fundamental distinction between a “record” and a “non-record.” GitLab Records Retention Schedule applies only to “records.” Therefore, it is important to understand the difference between a “record” and a “non-record.”
2.1 What is a “record”? A “record” is a Document created or received by a GitLab entity or individual in the transaction of business that contains significant business value. It is maintained to memorialize GitLab’s policies, procedures, functions, decisions, operations, processes or other business activities. The business value of a record is derived from the legal, regulatory, fiscal, operational, or informational significance of the content. “Records” must be retained throughout their life cycle in accordance with GitLab Records Retention Schedule. “Document” as used above is a piece of written, printed or electronic matter that provides information or evidence or otherwise serves as an official record and can include software application files, paper, slide presentations, spreadsheets, CAD drawings, electronic images, pictures, emails, faxes, and the like.
2.2 What is a “non-record”? Simply stated, a “non-record” is everything that does not qualify as a “record.” Non-records are materials that GitLab does not own, materials without substantive business value, or materials that have only temporary use as reference or reminders. They are not subject to GitLab Records Retention Schedule and should be discarded when no longer needed. Examples of non-records include: Correspondence that is only needed for a short period of time and does not have substantive business value; Calendars; Informational items such as publications and extra copies of documents kept only for convenience or reference; personal or casual correspondence, Reminders and ticklers that are needed only for a short period of time and do not have substantive business value. This would include things like reminders, “post-it” notes or superseded drafts.
2.3 The difference between an original record and a copy The original record represents GitLab’s official version of any information asset. Original records may be created by a GitLab employee, received by GitLab from an outside source, or may be forms processed by a GitLab department. A copy of a record is typically a duplicate that was created for dissemination or handy reference. There is no obligation to retain copies. Copies may be disposed of when they are no longer needed.
3. Responsibility for Developing and Managing Records GitLab employees are responsible for making and keeping records of their work. In that regard, they have four basic obligations: Create records needed to do the business of GitLab, record decisions on actions taken, and document activities for which they are responsible.
Maintain records in a legible and readily identifiable format.
Take care of records so that information can be found when needed. This means setting up adequate directories and files, and filing materials regularly and carefully in a manner that allows them to be safely stored and efficiently retrieved when necessary.
Carry out the destruction or retention of records under their control; This includes transferring records to storage or destruction of records in accordance with GitLab Records Retention Schedule and verifying records are destroyed in a manner conducive to prevent the release of sensitive information into the public domain (i.e. erasing, shredding, etc.) The individual or department that maintains the official version of a record is responsible for managing the record. This is known as the Record Owner. The Record Owner is responsible for the use, retention, and destruction of that record, unless and until a record is officially transferred to a designated archive or storage center.
4. Management of Electronic Records The Record Owner ensures that electronically-generated records are identified, and the systems used to store the records comply with this Records Retention Policy and Records Retention Schedule. Records may be managed in either a paper format or an electronic format. Electronic recordkeeping systems must be designed to ensure the security and integrity of the records, preservation of records for the time when they are needed, and migration of data to other GitLab systems or subsequent systems. Consequently, GitLab records should not be maintained solely on the personal hard drive, flash drive, or directories of a GitLab employee assigned only for that person’s use. GitLab employees should create an electronic filing system located in the appropriate server for their department or function, with specific folders for each employee and for each matter, and transfer their GitLab records to those folders, or at least copy them to those folders, as soon as possible after those records are created.
4.1 Emails and Slack Much of the business conducted today is done by email and Slack. GitLab has separate policies with regard the use of GitLab managed messages and attachments, which covers such things as communication etiquette, prohibited use and content of communications, password and encryption key security and integrity, GitLab’s right to access information, confidential GitLab information, privileged communications and personal use of email. Email and Slack communications are subject to the same records retention procedures that apply to other documents and must be retained in accordance with GitLab Records Retention Schedule. The following guidelines apply to emails and Slack:
The status of any particular communication (i.e., whether it is a record and its retention period) is determined by its content, not the method of delivery.
The responsibility of maintaining and retaining an internally created and distributed document most often falls on the author, not the recipient.
GitLab employees who receive emails from outside GitLab are responsible for proper management of those communications. In an effort to be environmentally conscious, the printing of emails for record retention purposes discouraged.
GitLab strongly discourages the storage of voluminous non-record email messages because of the limited value of such messages, and the cost and confusion associated with unmanaged retention and proliferation of email. Unmanaged retention of messages fills up storage space on the network servers, extends the amount of time to backup data, requires additional resources to maintain, slows performance, and can potentially lead to an inaccurate history of GitLab because it is haphazard and incomplete. As a general rule, employees are encouraged to promptly delete any non-record email messages they send or receive that no longer require action and are no longer necessary to GitLab’s business. If a non-record email no longer has business value, it should be deleted.
5. Retention Period The retention periods for specific types of records are set forth in GitLab Records Retention Schedule. The Records Retention Schedule will ensure that records are safely preserved until the retention period has expired. GitLab recommends that the records be destroyed in the normal course of business in accordance with the Records Retention Policy and Records Retention Schedule. In some instances, GitLab may choose to permanently preserve information for business or historical reasons. Such records are specifically designated in the Records Retention Schedule.
6. GitLab Records Retention Schedule GitLab Records Retention Schedule establishes the retention periods for various types of records. It applies to all records, regardless of format. Retention of records according to the Records Retention Schedule must be observed to ensure consistent application of reasonable due diligence in recordkeeping practices.
GitLab’s Records Retention Program promotes the destruction of records and other documents at the earliest possible time, in accordance with the following principles:
All records should be promptly destroyed pursuant to GitLab Records Retention Schedule. As discussed above, "non-record” materials are not subject to the Records Retention Schedule and should be discarded when no longer needed.
The retention periods in the Records Retention Schedule applies to the "original" version, or official record, of each information asset. Copies of records should be destroyed when they are no longer needed.
All Record Control processes will contain documented procedures clearly defining methods for identifying, storing, protecting and retrieving Records.
Identification methods should include a recommended destruction date and a mechanism for efficient retrieval of the information.
Storage will be in such a form as to preserve the integrity of the data and prevent eroding, tampering or altering the data.
Protection of the stored information will be in such a form as to ensure the integrity of the storage mechanism.
Retention will be, at a minimum, for the time period set forth in the Retention Schedule.
Records will be properly disposed of once the respective retention period has lapsed.
Disposal of the information will be in such a form as to protect the sensitive nature of the information therein and prevent release into the public domain.
Litigation Holds or other non-destruct directives issued by GitLab’s Legal Department override any destruction authority granted by the Records Retention Schedule. In addition, destruction of non-record materials identified in the Litigation Hold is suspended.
When the decision is made to destroy GitLab information, it must be destroyed/erased in a secure and confidential manner that is appropriate to the sensitivity of the informational content. Employees will consult the Data Classification and Handling Procedures for details on retention, destruction and storage of all Records.
7. Litigation Holds GitLab is occasionally the subject of threatened or pending litigation or administrative proceedings. Such proceedings may suspend the normal operation of GitLab Records Retention Policy. Where appropriate, GitLab will issue a “Litigation Hold” to certain employees, departments or the entire GitLab. The Litigation Hold will provide a description of records and other documents that must be preserved. The failure to preserve records, documents and other evidence could subject GitLab to fines or sanctions. It is therefore very important to manage documents and other evidence in strict accordance with the Litigation Hold.
8. Special Situations
8.1 Mergers and acquisitions Documents that may come into the possession of GitLab through the acquisition of another business entity, or through mergers or other agreements, are subject to GitLab Records Retention Policy. Such documents will be promptly screened and managed in accordance with the Policy directives.
8.2 Consolidations In the event of consolidations, such as a facility closure, GitLab will continue to manage records associated with such facilities in accordance with GitLab Records Retention Policy. The following guidelines apply: All records should be transferred to the new Record Owner, or as directed by GitLab. Legal Department must be informed of the identity of the new Record Owner and provided a description of the records transferred. If a successor Record Owner is not identified, GitLab records will be transferred to the department or office most closely associated with the record’s business function. For instance, personnel files without new Record Owners must be forwarded to the Corporate HR Department. All other records must continue to be managed in accordance with GitLab Records Retention Policy. To ensure this, Legal Department must be involved in all decisions concerning the destruction or transfer of such records.
8.3 Employee Moves (Office Moves, Reassignments and Termination of Employment) Employees are responsible to follow GitLab’s Policy for ensuring that records are properly maintained. When an employee’s duties are being reassigned or the relationship with the employee is terminated, each employee should conduct an inventory of records and other materials in his or her possession and follow the steps listed below: If the employee has any records that belong in department files, follow the procedures for ensuring that those records are properly stored in the appropriate location. Dispose of non-record materials as soon as the employee no longer needs them. Remove or destroy any personal materials. Employees are reminded that materials relating to their jobs cannot be removed without GitLab’s permission. Identify active records that are needed for current business and arrange for their transfer to the new Record Owner or as directed. The supervisor of the former employee whose employment was terminated is responsible for compliance with the steps described above.
8.4 Contractual obligations In some instances, GitLab may be required to maintain certain types of records or other types of information for designated periods of time pursuant to its contractual obligations with third parties. To the extent agreed to by GitLab, those contractual obligations must be honored. If there is a conflict between the Record Retention Schedule and a contract, the longer of the two terms shall prevail unless otherwise prevented by law.
9. Communications GitLab Legal is responsible for implementing and managing the Records Retention Policy.
Accurate and reliable records are crucial to our business. Records will be maintained accurately to:
GitLab records include:
There is never a reason to make false or misleading entries. Undisclosed or unrecorded funds, payments, or receipts are inconsistent with our business practices and are prohibited.
Our records are our corporate memory, providing evidence of actions and decisions and containing data and information critical to the continuity of our business.
Records consist of all forms of information created or received by GitLab, whether originals or copies, regardless of media. Examples of company records include:
We are responsible for properly labeling and carefully handling confidential, sensitive, and proprietary information and securing it when not in use. We do not destroy official company documents or records before the retention time expires, but do destroy documents when they no longer have useful business purpose.
We have an obligation to make sound business decisions in the best interests of GitLab without the influence of personal interests or gain. Our company requires you to avoid any conflict, or even the appearance of a conflict, between your personal interests and the interests of our company.
A conflict exists when your interests, duties, obligations or activities, or those of a family member are, or appear to be, in conflict or incompatible with the interests of GitLab. Conflicts of interest expose our personal judgment and that of our company to increased scrutiny and criticism and can undermine our credibility and the trust that others place in us.
Should any business or personal conflict of interest arise, or even appear to arise, you should disclose it immediately to leadership for review. In some instances, disclosure may not be sufficient and we may require that the conduct be stopped or that actions taken be reversed where possible. As it is impossible to describe every potential conflict, we rely on you to exercise sound judgment, to seek advice when appropriate, and to adhere to the highest standards of integrity.
GitLab is often required to disclose any organizational or personal conflict of interest to various third parties. To ensure accuracy in our disclosures, please notify Compliance at Compliance@gitlab.com of any organizational or personal conflicts of interest.
GitLab employees and contractors are not authorized to speak with the media, investors, or analysts on behalf of our company unless authorized by our Marketing department. Unless authorized, do not give the impression that you are speaking on behalf of GitLab in any communication that may become public. This includes posts to online forums, social media sites, blogs, chat rooms, and bulletin boards. This policy also applies to comments to journalists about specific matters that relate to our businesses, as well as letters to the editor and endorsements of products or services.
When attending Contribute or any conference, public meeting, customer meeting or meet-up, kindly keep in mind you are representing GitLab. Personal hygiene and hygiene in general helps to maintain health and prevent the spread of diseases and various other illnesses. We motivate everyone to maintain cleanliness. For more information about our Contribute Code of Conduct, read more here.
We pride ourselves on being a company that operates with integrity, makes good choices, and does the right thing in every aspect of our business. We will continually challenge ourselves to define what being a responsible company means to us, and work to translate our definition into behavior and improvements at GitLab. We seek to align our social and environmental efforts with our business goals and continue to develop both qualitative and quantitative metrics to assess our progress.
You may support the political process through personal contributions or by volunteering your personal time to the candidates or organizations of your choice. These activities, however, must not be conducted on company time or involve the use of any company resources. You may not make or commit to political contributions on behalf of GitLab.
We support community development throughout the world. GitLab employees or contractors may contribute to these efforts, or may choose to contribute to organizations of their own choice. However, as with political activities, you may not use company resources to personally support charitable or other non-profit institutions not specifically sanctioned or supported by our company. You should consult the Legal department if you have questions about permissible use of company resources.
We are committed to upholding fundamental human rights and believe that all human beings around the world should be treated with dignity, fairness, and respect. Our company will only engage suppliers and direct contractors who demonstrate a serious commitment to the health and safety of their workers, and operate in compliance with human rights laws. GitLab does not use or condone the use of slave labor or human trafficking, denounces any degrading treatment of individuals or unsafe working condition, and supports our products being free of conflict minerals.
Slavery and Human Trafficking are crimes and violations of fundamental human rights. These violations take various forms, such as slavery, servitude, forced and compulsory labour, and/or human trafficking, all of which have in common the deprivation of a person’s liberty by another in order to exploit them for personal or commercial gain. GitLab is committed to acting ethically and with integrity in our business dealings and relationships by implementing and enforcing systems/controls to ensure modern slavery or human trafficking are not taking place in our business, or with those with whom we do business.
GitLab is also committed to ensuring there is transparency in our business and in our approach to tackling slavery and human trafficking throughout our supply chains and overall organization, consistent with disclosure obligations we may have under applicable law. To that end, we prohibit the use of forced, compulsory or trafficked labor, or anyone held in slavery or servitude, whether adults or children by anyone working for or with GitLab.
All employees, directors, officers, agents, interns, vendors, distributors, resellers, contractors, external consultants, third-party representatives and business partners are expected to comply with this policy.
Every Team Member is responsible to assist in the prevention, detection and reporting of slavery and human trafficking by those working for or with GitLab. Each Team Member is encouraged to raise concerns about any known or suspected incidents of slavery or human trafficking in any parts of our business or supply chains at the earliest possible stage. If you are unsure about whether a particular act, the treatment of workers more generally, or their working conditions within any tier of our supply chains or business partners constitutes any of the various forms of modern slavery/human trafficking, raise it at Compliance@Gitlab.com.
We may terminate our relationship with individuals and/or Business Partners if they breach this policy.
Team members will review and sign the Code of Business Conduct & Ethics Acknowledgment Form during onboarding as well as annually during the Global Compensation Annual Review cycle. Please access the form template by clicking here.
During the annual merit cycle, people operations will be responsible for sending all team members the updated Code of Business Conduct & Ethics acknowledgment form and ensuring all team members review and acknowledge. The Code of Conduct will be sent to each team member via BambooHR. To review and sign the document: log into BambooHR download the PDF and click on the Code of Conduct Link. Once a team member has reviewed the Code of Conduct they will use the BambooHR signature and date tool to complete the acknowledgement. No changes should be made to the Code of Business Conduct & Ethics without prior approval from the VP of Legal.
Team members that joined prior to the established requirement to upload the acknowledgement at hire are the exception but will be subject to capturing their acknowledgement during annual reviews.
All of the policies listed below are important for GitLab team-members to read and understand as they deal with people benefits, procedures, and requirements of the company. If you have any questions around the internal policies, please reach out to People Operations.
In keeping with our values of freedom, efficiency, transparency, kindness, and boring solutions, we have crafted the following protocol around sick leave for all GitLab team-members.
If you or a loved one is ill, we want you to take care of yourself or your loved one(s). To facilitate this, you should take sick leave when you need it. Sick leave is meant to be used when you are ill, or to care for family members including your parent(s), child(ren), spouse, registered domestic partner, grandparent(s), grandchild(ren), or sibling(s).
You still need to report when you take sick leave, by entering the dates as an event in PTO Ninja via Slack. Once entered in PTO Ninja it will automatically update in BambooHR and payroll can update any other systems.
If you need sick leave for more than 8 consecutive calendar days, notify your manager and the Total Rewards Analyst team (aka Total Rewards) to accommodate an extended leave request. What can (or must) be accommodated varies from location to location: GitLab will comply with the applicable laws in your specific location.
Upon request, you should be able to provide proper documentation of the reason for your sick leave (doctor's note).
Employees of GitLab Inc. can take off sick time in line with our paid time off policy. Sick time does not get paid out in case of termination, nor does it reduce your final paycheck in case of a negative balance. Related to the topic of extended leave requests, see information about short term disability through UHC / your state.
Employees of GitLab B.V. have further rights and responsibilities regarding sick time based on Dutch law, as written into their employment contracts:
If you have been injured at work, please contact Total Rewards Analysts to determine what your benefits are.
GitLab is committed to protecting the rights of team members absent on military leave. No team member or prospective team member will be subjected to any form of discrimination on the basis of membership in or obligation to perform service for any of the uniformed services of their country of residency. If any team member believes that he or she has been subjected to discrimination in violation of this policy, immediately contact People Business Partners for assistance. For any questions about how to initiate a military leave, please contact People Operations.
GitLab is committed to a policy of employment and advancement based on qualifications and merit and does not discriminate in favor of or in opposition to the employment of significant others or relatives. Due to the potential for perceived or actual conflicts, such as favoritism or personal conflicts from outside the work environment, which can be carried into the daily working relationship, GitLab will hire or consider other employment actions concerning significant others and/or relatives of persons currently employed or contracted only if all points below are true:
This policy applies to all current employees and candidates for employment. In the spirit of our Transparency value, we ask the team member and the candidate to disclose the family relationship to the recruiter at the beginning of the hiring process. If the candidate progresses through the process as a final candidate, and prior to any offer, the recruiter should notify the hiring manager and the People Business Partner of the family relationship to ensure there is not a conflict of interest. In addition, the GitLab team member should not be part of their family member's interview process.
Preventing Unsafe Situations
While GitLab is 100% remote, there may be times when employees travel for work related functions or co-working events. GitLab is committed to the value of a safe, violence-free work environment and ensuring and exhibiting equal commitment to the safety and health of employees.
In general, please consider the following recommendations to ensure safety when traveling or coworking:
Measures GitLab Takes to Aid Employee Health and Safety
Responding to Unsafe Situations:
The following are GitLab’s procedures in the event an employee feels threatened or unsafe:
The World Health Organization (WHO) defines health as:
The WHO defines mental health as:
Defining the terms from the sentence above:
Why is awareness of Mental Health important at GitLab?
At GitLab we strive to create a stigma-free workplace. In accordance with the National Mental Health Association and the National Council for Behavioral Health we would like to:
What are we doing to get there?
Any questions or concerns? Please feel free to speak with anyone in People Ops.
GitLab is concerned about the safety of its team members and about maintaining appropriate controls to ensure that assets of GitLab and our customer relationships and information are protected. To reduce these risks, GitLab will obtain and review background information of covered prospective, and, as applicable, current employees.
GitLab has contracted with Sterling Talent Solutions to perform these background checks, which will cover criminal history for the last 7 years and employment history for the last 5 years and/or the three most recent employers. GitLab may use the returned background check information to make decisions regarding employment. For certain positions where the candidates financial history is relevant to the position, we may also run a check in the federal database for any financial related offenses.
All candidates who make it to the offer stage with GitLab must undergo a background screening according to this policy as part of the employment screening process. All contracts will state that employment is subject to obtaining results from an approved background screening that are satisfactory to GitLab. If a candidate is unwilling to follow this process we are unable to proceed with their candidacy for any position at GitLab. In the event the background check is not available at the time of hire (switching vendors or delays in processing), GitLab will run the background check as soon as possible. The same adjudication guidelines will apply to current employees as they do with prospective employees.
The Candidate Experience Specialists will initiate all background screenings for candidates. Background check results will be received by the Candidate Experience Specialist and brought to the relevant People Business Partner and functional leader to determine if the results warrant any adverse action, which could include rescinding of the offer or termination of employment.
Candidates (as applicable, employees) will receive an email to fill out the background check application. The application will ask for personal and professional information. The application process includes signing a disclosure and a consent form which explains the rights of an individual undergoing a background examination. The application process is designed to take less than fifteen minutes to complete.
To prepare for the employment verification, candidates should gather each previous employer's name and address, position title held, employment start and end dates, manager’s name and title, their phone number, and email address. Details for a Human Resources contact can be entered instead of a manager's contact details.
Occasionally, Sterling will reach out to the candidate to retrieve additional information, such as backup documentation to act as proof of previous employment or picture IDs. Proof of employment can typically be provided in various ways, such as tax returns (e.g. W2s), pay stubs, LLC documentation, official company registrations, etc.
Background checks will act as an additional mechanism of transparency and will help to build trust with our clients.
Once the background check is completed, Candidate Experience Specialists will review the report and determine if any negative information has a direct connection with an applicant’s ability to fulfill the job duties with competence and integrity. Criminal convictions that would raise a concern are job-related offenses, including but not limited to: embezzlement, extortion, computer/internet crime, fraud, tax evasion, and violent crimes. In addition, the report should be reviewed for omissions or inaccuracies contained in the employment application or made during the interview process.
Step 1: Disclosure and Authorization
The applicant must give the employer consent to have a third party service conduct a background check. The Disclosure and Authorization form can be presented to the applicant at the time they complete the employment application form. The form should grant the employer permission to conduct an initial background check (and, subject to state law, subsequent background checks if the applicant is hired) utilizing a third party service. Also, a “Summary Of Your Rights Under The Fair Credit Reporting Act” should be enclosed with the consent and disclosure form. For New York applicants, a copy of Article 23-A of the Correctional Law also should be enclosed and any other relevant state summary of rights.
The background investigation cannot be lawfully conducted without a signed Disclosure and Authorization form. Applicants can be advised that they will not be considered for employment without submitting the signed form. Equally for current team members, they can be advised that their employment may be impacted if they do not consent to the background check.
Step 2: Pre-Adverse Action: Notify the Applicant of Negative Report BEFORE Adverse Action is taken
If the consumer reporting agency reports information which may be used, in whole or in part, as a basis for an adverse employment action (e.g., rescinding a conditional offer of employment), the applicant must receive notification before a final decision is made to deny employment. As a result, the employer must provide a copy of the consumer report, a pre-adverse action letter, and another copy of the FCRA notice of rights (and for New York applicants, the Article 23-A notice). The applicant shall also receive any applicable state rights as required.
If the disqualification decision is not based on a misrepresentation or omission in the employment application, it is a best practice to discuss the potentially disqualifying information with the individual prior to issuing the pre-adverse action notice. This practice supports the individual job-related nature of any disqualification decision.
Step 3: Wait for a Reasonable Period of Time to Find Out What, if Any, Explanation is Offered by the Applicant
If the applicant does not respond at all to the notification within a reasonable period of time (5 days), the employer may proceed with its decision to rescind the conditional offer. If the applicant responds, the employer should carefully consider the information submitted and then make a decision. If the explanation is reasonable under the circumstances, then it may still be possible to go forward with the new hire (for example, a case of mistaken identity). However, if the applicant's explanation is determined to be insufficient, then the employer should proceed to the next step.
Step 4: Notify Applicant of Adverse Action
The employer must provide the applicant with written notice of the adverse action and the name, address, and telephone number of the consumer reporting agency. The Adverse Action Notice form should be sent along with the federal summary of rights and any applicable state summary of rights. The notice includes a statutorily required statement that the consumer reporting agency did not make the decision and does not know why the decision was made should be included as well as a notice of the applicant's right to obtain the report and dispute the information.
Step 5: Maintain Documentation
For all adverse decisions, document each step taken. Keep copies of all consent and disclosure forms and other documentation sent to the applicant in the event the company has to defend its decision at some later point.
All documents related to the background check process must be retained for at least five years.
GitLab will adhere to all equal employment laws. When reviewing any criminal record information that appears on a background check, the company shall factor in any known factors relating to:
Finance team members only will be required to participate in a federal check through Sterling, which searches for any tax-related or financial offenses. See this page for process details.
When a team member is absent from work for three consecutive workdays, there is no entry on the availability calendar for time off, and fails to contact his or her supervisor, they can be terminated for job abandonment unless otherwise required by law.
If a manager is unable to reach a team member via email or slack within a 24 hour period they should contact their People Business Partner. The People Business partner will access the team member's information to obtain additional contact methods and numbers. The manager and People Business Partner will create an action plan to make all attempts to contact the team member.
GitLab’s Anti-Bribery Policy prohibit giving illegal or improper payments to, or receiving such payments from, any person or organization, including government officials (U.S. and foreign) and persons in the private sector. Such payments also are prohibited by the U.S. Foreign Corrupt Practices Act ("FCPA") and anti-bribery laws and regulations in foreign jurisdictions, including but not limited to the U.K. Bribery Act 2010 and the European Commission on Anti-Corruption (collectively, “Anti-Bribery Laws”).
GitLab’s export policy requires that we ensure compliance with applicable export laws including the Export Administration Regulations (EAR), the International Traffic in Arms Regulations (ITAR) (if and to the extent they become applicable to GitLab’s products), general prohibitions and country control lists (collectively “Export Laws”).
It is an offense under Anti-Bribery Laws for a company to engage a third party who pays bribes in connection with the company’s business. Additionally, it is an offense under US Export Laws for a company to engage a third party who violates export laws. In short, GitLab can be held criminally and civilly liable for the bad acts of its partners.
Therefore, the Anti-Bribery, Anti-Corruption and Export Policy applies not only to GitLab’s employees, but also to all resellers, agents, consultants, joint venture partners or other representatives who provide services directly related to obtaining, retaining or facilitating businesses or business opportunities for GitLab (“Partners”).
In order to minimize the risk relating to Anti-Bribery Law and Export Law violations from such third parties, due diligence will be conducted on GitLab Partners. Due diligence is the process of taking reasonable steps to satisfy legal requirements and ensure that there are no red flags associated with the respective Partner ("Due Diligence"). The manager of the relationship is responsible for ensuring that the Due Diligence is conducted.
For GitLab, Due Diligence is verification that the proper contract terms are in play with the appropriate parties and verification that no Red Flags are present prior to moving forward in a relationship. If a red flag is present, the matter should be escalated to Legal. Legal will make a recommendation on whether or not to pursue the relationship based on the circumstances. Legal, at its sole discretion, will document justification for its final disposition.
Red Flags include: A poor credit check; Presence of media reports or rumours relating to illegal payments, bribes, export violations, corruption or other criminal activity; Requesting an unusually high commission if an agent or if a reseller is requesting to be paid money; Partner requesting a cash payment or payment to a secret account; Partner requesting third parties to be added to a contract; Partner refuses to disclose owners or principals for purposes of a credit check; Partner attempts to negotiate around (or refuses to agree to) terms around penalties around corruption or violation of law; and/or A negative hit on Denied Party Screen. (Denied Party Screens are conducted by Legal or Compliance.)
Please contact Legal or Compliance with questions or concerns about this section.
GitLab, Inc. and its respective affiliates, subsidiaries and divisions (“GitLab”) operate business in a responsible manner. At GitLab, the way we conduct business is as important as the relationships we have and the products and services we provide. Accordingly, GitLab will only do business with suppliers, contractors, resellers, agents and consultants (collectively herein referenced as “Partners”) that comply with applicable and controlling laws, rules, and regulations (collectively herein referenced as “applicable laws”) and at a minimum, with standards of business conduct consistent with those set forth in this Partner Code of Ethics (“Code”).
It is GitLab’s expectation that Partners, their employees, sub-suppliers and any other parties involved with the execution of GitLab work, similarly comply with the applicable laws and the standards set forth in this Code. GitLab expects the following, without limitation, including respecting the human rights of employees from all its Partners:
HUMAN RIGHTS AND LABOR STANDARDS
Forced Labor, Human Trafficking and Slavery Partner shall not use any form of forced labor including prison, indentured, bonded, military, slave or any other forms of forced labor. Partner shall not participate in the recruitment, transportation, transfer, harboring or receipt of any persons by means of threat, use of force, or any other forms of coercion, abduction, fraud, deception, abuse of power or position of vulnerability, or the giving or receiving of payments or benefits to achieve the consent of a person having control over another person for the purpose of exploitation. Partners shall not retain an employees’ government-issued identification, passports or work permits as a condition of employment and shall allow employees to resign from their positions at any time.
Child Labor Partner shall ensure that no underage labor has been used in the production or distribution of their goods or services. Employees must not be younger than the minimum employment age established by the respective country or local jurisdiction. In the event no minimum employment age is established, employees must not be younger than the age of compulsory education; or if no minimum age for compulsory education is established, employees should not be younger than age 14.
Working Hours Partner’s employee working hours must be in compliance with all applicable laws and regulations. Partners should encourage employees to receive at least one day off every seven days in compliance with all applicable laws.
Wages and Benefits Partners must have a system in place to verify and accurately record payroll, deductions and the hours worked by legally authorized employees. Partners must comply with all applicable wage and compensation requirements as defined under applicable labor laws for regular work, overtime, maximum hours, piece rates, and other elements of compensation and employee benefits.
Freedom of Association and Collective Bargaining Partner must adhere to applicable laws regarding the right to affiliate with lawful organizations without interference.
Nondiscrimination Employment by Partner shall be based solely on an individual’s ability and not personal characteristics. Partner shall maintain a workplace free of unlawful discrimination, which includes, but is not limited to, race, gender, sexual orientation, age, pregnancy, caste, disability, union membership, ethnicity, religious belief or any other factors protected by applicable law. Employees shall not be subject to verbal, physical, sexual or psychological abuse or any other form of mental or physical coercion and shall be treated with respect and dignity.
Conflict Minerals Partner shall abide by all regulations and laws relating to conflicts minerals and legal and sustainable sourcing.
HEALTH AND SAFETY
Partners shall provide safe and healthy working and housing environments (if Partner provides housing) to prevent accidents and injury to health. Partners shall minimize employee exposure to potential safety hazards by identifying, assessing and minimizing risks by developing and implementing plans and procedures.
Partners shall be sensitive to its impact on the environment (including but not limited to air emissions, water discharge, toxic substances and hazardous waste disposal) and local communities. Partner shall comply with the environmental laws and standards within its facilities. Partners must use care in handling hazardous materials or operating processes or equipment that use hazardous materials to prevent unplanned releases into the workplace or the environment.
ANTI-BRIBERY AND ANTI-CORRUPTION
Partners shall not engage in any form of corrupt practices including without limitation to, extortion, fraud, impersonation, false declarations, bribery, money laundering, supporting or involved with terrorist or organized crime organizations or activities. Partners shall not offer bribes, kickbacks, illegal political contributions or other improper payments to GitLab representative or agency, any customer, government official or third party, with the intention of obtaining or retaining a business or other improper advantage. Partners must have a written anti-corruption / anti-bribery policy that includes an annual review with its employees of such policy.
PRIVACY AND SECURITY
Partners shall ensure that there are appropriate administrative, technological, physical and technical controls in place to ensure the protection and security of any data subject subject to laws and regulations. Partners will execute any necessary agreement relating to the handling of data and will notify GitLab of any known or suspected vulnerabilities that may compromise individuals subject to the relationship with GitLab.
If a Partner’s efforts to comply with this Code have been deficient and Partner fails to cooperate in developing and implementing reasonable remedial steps, GitLab reserves the right to take appropriate actions up to, and including, discontinuing the relationship with Partner. Nothing in this Code is intended to, in any way, grant any additional rights or expectations to a GitLab Partner or, in any way, modify or otherwise limit any of GitLab’s contractual or legal rights.
No matter where we operate around the world, we are steadfast in our dedication to service and integrity. Strong partnerships are a cornerstone of GitLab’s business and a vital link in setting and achieving expectations for ethical sourcing and corporate social responsibility. At GitLab, the way we conduct business is as important as the people with whom we conduct business. services we provide.