Creating a Comprehensive 3rd-Party Package License Policy for OSS
By Kate Downing
Kate Downing is a leading expert in Open Source Compliance. Her law firm focuses on technology transactions, open source compliance, open source licensing, commercial deals, procurement, inbound licensing, contract templates, technical programs, and other transactions and IP-related best practices. Some of her clients include HashiCorp, Auth0, Sysdig, Scale, Fleetsmith, and Keen Research. Check out www.katedowninglaw.com for more info!
A Guide to Creating a Comprehensive Third-Party Package License Policy
Last November, I attended FINOS’s Open Source Strategy Forum in London. It was a terrific opportunity to meet people in the fintech space and to get a sense for how companies large and small in this industry were thinking about open source compliance and the overall open source value proposition for their companies. After the conference, FINOS’s General Counsel & Director of Governance, Aaron Williamson, kindly invited me to present to FINOS’s Open Source Readiness (OSR) Working Group.
The OSR Working Group hosts a regular speaker series, of which my presentation was but one of many. If you’re in the fintech space, I highly recommend checking it out. Even if you’re not in the fintech space, many of the presentations and resources they have available are useful across many industries.
My presentation focused on creating a comprehensive third-party package licensing policy. This is often one of the first things my clients ask me to create for them and creating one is often a major hurdle for companies who otherwise have the tools and desire to jump-start the open source compliance process, but aren’t sure about the legal implications of the various open source licenses and quasi-open source licenses out there. This presentation gives an inside view as to how lawyers go about creating such policies and the types of concerns they often address.
Creating a comprehensive Third-Party Package License Policy
You may wonder why I mention “third-party” packages versus focusing solely on “open source.” Scans turn up a variety of license types - some of them, like CockroachDB and Elasticsearch, are partially under open source licenses and partially under proprietary licenses. There is an untold number of variations of Open Source Initiative, Free Software Foundation, Software Package Data Exchange (SPDX), and proprietary licenses in addition to new licenses that are created all the time.
Most likely your company will need to develop multiple third-party package policies in order to cover all of your products. Different considerations need to be made for different types of software and products under different licenses. For example, a mobile app is treated differently from internal testing software which is treated differently from a proprietary SaaS product.
How Do You Get Started?
Step 1: Create an Inventory of Company “Products”
The first thing that needs to be done is to get an inventory of all of the products that exist in the company. This may sound simple, but it’s a very nuanced and broad question. This list is not just limited to software your company sells but includes all the software you make available to customers and partners (yes free software too). Examples include:
- Products that are downloadable or installable on customers’ or partners’ machines
- Free and for-fee products
- Mobile applications, parts of SaaS products that need to be installed behind a firewall, JavaScript portions of web properties, etc.
- SDKs, plug-ins, tools, etc.
- SaaS applications or platforms (if more than one binary runs a SaaS application, list each one separately)
Step 2: Create “Profiles” for Products
A product profile is a form of knowledge management about products that act as a source of truth for those involved in open source compliance over time. Your product profile should contain all of the answers to any question an open source compliance expert might ask. This information helps give the context needed to determine which type of third-party policy should be applied. Here are examples of the types of information needed to determine what your policy should be:
- Detail what programming languages are used (C++, Java, Go, Node.js, etc.)
- A brief explanation of what each product does, how it’s accessible to customers/partners, whether it’s a tool, and how it communicates with or relates to your other products (if applicable – example “this is a driver for X,” or “this is an on-prem component for Saas Y”)
- Note if the product is shipped as part of a container or virtualized application
- Note if the product is OEMed (licensed to other vendors) or might be in the future
- List the main engineering, product management, and release management contacts w/ contact information.
- List who will be responsible for adding legally required disclosures to the product (likely a specific engineer) and shipping source code
- Track how often the product is released and the next release date. This affects the compliance process.
Long term, you will also want to track how your compliance process is working for each product. you will track whether open source disclosures were created for each release and whether necessary source code and instructions were supplied. Depending on your situation, you may also need to track whether a release went to escrow.
Step 3: Prioritize Your Inventory
Rolling out an open source compliance process is most effective when rolled out incrementally. Trying to roll out a compliance process to every single product at the same time can be very overwhelming. The best way to ensure compliance is adopted at scale is to have success with one product, then iterate on the process as you roll out your compliance process for subsequent products
You are going to want to start with your most vulnerable product first. The best way to prioritize vulnerability is by starting with the products that have the most distribution, or products that are installed on your customers’ or partners’ machines (i.e. downloads or installs). Distribution is a critical factor because the vast majority of open source licenses are only triggered on distribution. This can be counter-intuitive because your most vulnerable product isn’t always your main product, especially if your main product is SaaS. Distributed products are also more vulnerable because downloadable assets are things copyright holders have greater access to audit and inspect.
If several products have similar distribution levels, start by targeting the product with the highest percentage of third-party code, or by proxy the largest project (in megabytes).
The third factor to consider in prioritization is timing. The ideal product will have an upcoming release while allotting enough time to do a solid review.
Keep in mind the product with the highest priority might be a free product. The most vulnerable product from a compliance standpoint is not always the product that causes the highest security risk.
Step 4: Create Categories for a Third-Party Package Policy
Policies will need to be tailored on a per project or product basis based on both license and distribution policy. Generally, there are three buckets a license can fall into. Green licenses are always acceptable no matter how the engineer uses the package. On the other end, the red bucket is your blacklist: open source packages that are never acceptable. Finally, there is the yellow bucket. These are the licenses where the answer is “it depends”. There are a variety of factors, i.e. how engineering uses the package, whether or not there are additional obligations in order to fulfill compliance requirements, etc., that you will want to handle on a case by case basis.
The following is an example of a policy for a proprietary desktop application. This is one of the more complicated examples and has a lot of grey area. This will almost certainly need to be customized to fit your company’s needs.
Example Proprietary Desktop Application Policy
| Explanation | Categories (Generally…not always) | Examples | |
|---|---|---|---|
| Green Light | This type of license is acceptable for this product without exception no matter how an engineer is using it. There are no further obligations. | Permissive licenses, public domain dedications, corporate-style permissive licenses | MIT, Apache License 2.0, Microsoft Limited Public License, OpenSSL, W3C, Python |
| Yellow Light | This scenario is nuanced. This type of license is acceptable provided the engineer is using the package in a certain way or is taking certain additional steps to comply,with the license. | “Weaker” copyleft, weak copyleft (aka corporate-style licenses), proprietary licenses you have paid for, multi-licensed packages | LGPL, Mozilla Public License, Eclipse Public License, Common Public License, Common Development and Distribution License |
| Red Light | This type of license is never acceptable for this product. This is your blacklist. | Strong copyleft, ultra-strong copyleft, badgeware, shareware, proprietary licenses you haven’t paid for, no license, licenses that prohibit commercial use, advertising clauses | AGPL 3, SSPL 1.0 (MongoDB’s Server Side Public License), GPL v2, GPL v3 |
| Other | There is a grab-bag of licenses that are mostly not recognized as open source licenses by either OSI or FSF, but which may be acceptable for your product. Require ad hoc approval. | Freeware, discriminatory licenses, content licenses, otherware, licenses with a field of use restriction |
Understand Open Source License Implications
For a deeper view on open source licenses, concrete examples surrounding issue resolution, and potential policy exceptions you can watch the entire presentation on YouTube here.You can also download the slides here. I recommend downloading the slides and viewing them via PowerPoint because Google Slides preview will strip out a lot of the nice pictures and formatting.