Bundling Third Party and Open Source Code
I first wrote about this topic on my Sybase blog in September 2008. As part of Sybase’s integration with SAP, and the shutdown of the Sybase blog server, that previous post is no longer available, yet the topic remains important for all development organizations. Since our integration with SAP, many aspects of this process for the SQL Anywhere team have changed. As a result, I am revisiting this topic, with some of the previous content, along with many additions and revisions.
One of my tasks as Senior Director of Engineering is to keep a handle on all the 3rd party and open source components we bundle or include in the SAP SQL Anywhere product.
I am sure that our engineering team is not unique in the software industry in looking for ways to speed up development by seeking to include certain 3rd party code to perform specific functions. This code may be object code provided by an operating system vendor such as Microsoft for tasks such as debugging, or it may be open source code providing functionality such as parsing of XML documents. While the bundling of 3rd party code can improve productivity, there are some caveats that development organizations should be very careful to consider prior to bundling the code.
When one of your developers grabs a piece of code from some internet site and integrates it, you, and not the original developer typically assume all liability for the functionality and supportability of the code. You have to ensure that the code is performing only the functionality you intend, and that you understand it enough to support the code in the future. Here on the SQL Anywhere team, our rule is that developers may NOT simply grab code and integrate it.
Here are the two key items we ensure are covered prior to its integration with SQL Anywhere:
- Technical Review – Functionality of the code, and its long term supportability
- Legal Review – License, IP Rights and Distribution Rights
Both of these items are of equal importance for most organizations. In our organization, they are handled together, so any obvious problems are identified as soon as possible.
The development manager must be involved in all evaluations of the technical aspects of the code, including a review of the code’s functionality to ensure that it is only performing the tasks required, and nothing unexpected. The development team must also run the code through one of the static source code analysis tools we use to understand any security flaws that may be present. As well, the development manager must be able to provide an opinion on the long-term supportability of the code.
Usually, I will work with the development manager to perform a preliminary license review even prior to technical review. If I think the license will probably be acceptable, then we proceed with the rest of the process.
As a company, when we review the license, we are looking for several different things:
- Ability to include the 3rd party code in our proprietary product. This rules out all code based on the GPL or similar so-called viral licenses. SQL Anywhere is not open source, and our current business model calls for the code to remain proprietary, so we need to ensure that we retain all rights in this regard. On the SQL Anywhere team, we also restrict the use of any LGPL code. While one interpretation of the LGPL would seem to allow its use in a proprietary software product, various legal opinions over the years have indicated to us that the use of LGPL code presents risks because of the various ambiguities of the LGPL license.
- We require 3rd party distribution rights. This means that we need to not only be able to distribute the code ourselves, but we must also be able to grant our partners the right to distribute it.
- Anything else in the license that is unusual or out of the ordinary.
- While we approve code under a variety of licenses, our task is made much easier if the code is available under one of the industry standard licenses such as the Apache License from the Apache Software Foundation.
We have a structured approval process that must be followed.
- The 3rd party or open source code must first be approved by the development manager
- As a second step, our VP of Engineering has to approve the use, based on its functionality and supportability. In some cases, the question is asked why we don’t simply write it ourselves.
- Justification for the 3rd party or open source item is documented, and submitted by the VP (or designate) to our team’s open source committee for approval. If this group views that the use of the open source likely low risk, then the request is sent to the formal SAP approval process.
- The goal is that the first 3 steps of the approval process will occur in a very short period of time, so the longer, more formal SAP approval process can begin.
- The final stage for approval is the formal SAP process, which involves a complete review of the license, intellectual property rights, and distribution rights. An internal system called “Code Centre” is used to track all the various 3rd party and open source components used by every SAP product. The system also tracks the various aspects of the formal approval process, so product owners know at any time where they stand.
After the bundling of a third party component is approved, there are still three key considerations for our team:
- Legal Notification to Customers
- The ability to track which third party and open source components are used, and in which components of the SQL Anywhere product.
- The third party / open source is checked into a special location in our source code repository
Legal Notification to Customers
Many of our customers have a keen interest in understanding what 3rd party components we include, and under what license. This is especially important to our OEM partners who distribute SQL Anywhere with their own products. As well, many of the 3rd party licenses contain a clause indicating that we MUST inform our customers about their license with respect to that component. To satisfy this requirement, our current in-market versions of SQL Anywhere all include a “Free Download Component / Third Party Terms and Conditions” document. In SQL Anywhere versions 11, 12 and 16, the file is installed (by default) to the ThirdPartyLegal directory.
Tracking of Third Party and Open Source Components
To ease the identification of 3rd party components in SQL Anywhere, the information is maintained in at least 2 different places:
- We maintain a page on our development wiki site that identifies all the third party and open source components in each release. The first thing that is done by the developer after approval step 3 is received is to update the wiki page.
- The SAP corporate Code Center repository
- After approval, the developer checks the third party code into our source control system. We havea separate location in our source depot for third party code. This ensures that we can quickly search our source tree, and helps ensure that third party components don’t accidentally get missed when we compile our list. As part of the check in, the license file itself is added to a special location in our depot, ensuring that we always have access to the license under which we use the third party component.
Prior to each release, we have further due diligence phases. First, the development managers review their projects to ensure that all developers have followed the process, ensuring that third party components are all listed on our wiki, are checked into our source control system, and that the approval has been obtained from SAP legal. Finally, we undergo a complete source code scan using a special product specifically designed to find any open source code. If these all check out, then we are ready to ship.
While the use of open source can certainly be beneficial, the benefits have to be measured against the risks and the compliance costs. As you can see, we take the use of third party and open source code very seriously. I would recommend that you take it seriously too.