In the time that I have spent with OpenLogic, I have worked with companies across many industries, and with companies ranging from a handful of developers to thousands of developers. One thing they have in common is that they typically have some type of open source policy, some far more developed than others.
Open source policies range from the strictest set of guidelines delineating what can and cannot be used, to policies simply prohibiting use of license x, y or z. This blog covers the seven topics I identify as the key topics to be considered, at the very least, when constructing your open source software policy.
1. OSS Acquisition/Approval
How do you acquire and approve the use of open source software? Do you have people who are qualified to approve what open source and open source licenses can be used within the enterprise? This first point is one that every company seems to touch on in some fashion. Open source does not go through the typical channels of procurement. Open source is free for download and is readily available. So, unless your company has a targeted policy and procedures for tracking OSS specifically, you have very little control over what or how it comes into your codebase.
How do you plan to support and maintain the open source that you have acquired? If you decide to use a piece of open source, are there any bugs in the code that will lead to future problems? How will you know when there are new releases to the open source you wish to use (often with bug fixes you need)? Some larger open source projects have newsletters and other means to communicate when new versions are available, but those are few in number compared to all the open source available.
There are two aspects to tracking open source. One, how will you track what new open source is available (mentioned above)? Second, how will you track which open source libraries are in which applications you are developing? This is an area where large companies can really have trouble. At the enterprise level, can you account for which applications are using which open source libraries, and are those libraries up to date? Some companies use spreadsheets or tools like Microsoft SharePoint to try to track where they are using open source, but these will not notify you when new releases of open source are available.
Auditing or scanning codebases plays a large role in managing open source. Most people assume you download one open source project under one open source license. In reality open source is incestuous; one package may include other OSS packages as subcomponents. Scanning and auditing will allow you to have a comprehensive bill of materials, accounting for in-house code, open source code, and commercial code. This step in the policy will help you identify combined projects, and identify bundled dependencies. If your company purchases commercial code or outsource development, you will want to scan and verify no open source shows up in third-party code. If you do not know what you have, how do you expect to support, track and comply with its requirements? Not having a comprehensive list of open source makes these tasks exponentially more difficult.
It is one thing to know what open source you have, it is another to know where you are and are not in compliance with the open source licenses that you are distributing. Do you have open source attorneys who review the licenses and obligations, or a tool like OLEX that will pinpoint all the obligations you need to meet? The legal complexities go beyond just the license obligations. How will the company assess risk around the use of open source? How do you protect your company’s intellectual property?
Training should be part of any company’s open source policy. There are several aspects to training to consider when developing your policy.
– How will you train employees on company open source policy?
– How will they be technically trained on the open source they are using?
– Will they be trained on how to audit code?
– Do they need to be trained on the various open source licenses and corresponding obligations?
Open source training occurs on various levels; it is not enough to train developers on what open source can and cannot be used. Employees need to be aware of issues in open source like bundled dependencies and how to meet various obligations.
7. Community Interaction
How will you allow your developers to interact with open source communities? There are various ways a developer might interact with an open source community. The developer may want to reach out to the community for bug fixes or, depending on the license, may be required to release all modifications of the code in source form. Do you need to worry about company copyright showing up in open source projects? Do you have legal council that will advise developers on the release of modified files?
No one company has the same open source policy. While not all of these topics apply for all companies, for most companies they will. It is important to understand that more goes into an open source policy than just a set of approved open source licenses and packages. You have to decide who should be approving the use of open source, how to support/maintain it, how to comply and train employees in the use of open source. Having a policy that addresses all of these topics will lead to a policy that can be considered best-in-class.
Have you created an open source policy? If so, what were the topics that you considered while writing it?