1. Treat Open Source Licensing as Part of Your Software Procurement Process

The use of open source software is a special case of the general software procurement process and should be subject to many of the same guidelines. Of course open source licenses are different than typical proprietary licenses. But the principle of software licensing compliance applies to both traditional and open source licensed software—and so both should be managed under the same general framework.

Remember that we are likely moving into a time of more active compliance within open source. People don't realize that failures on the "easy" open source compliance—providing a copy of the license and attribution—may become a target for litigation.

2. Have an Open Source Program Office (OSPO)

This best practice may seem obvious coming from us, but having an OSPO is an important part of managing your organization's use of open source. Someone needs to manage your organization's use of open source. Having an OSPO means that open source management has been formalized as a need and a process within your organization, making your successful use of open source much likelier.

Getting everyone in the room

Another benefit of having a formal OSPO is that it helps you get everyone in the same room, if not on the same page. One of the reasons that managing open source software can be difficult is because it comes in "from the bottom"—it is brought in by individual engineers using open source code as part of their jobs. Accordingly, managing open source requires a higher level of participation between the legal and technical groups within a company.

Your OSPO brings together managers, engineers, and counsel to make the decisions concerning the use of open source software in product development. It acts as a clearinghouse for open source-related issues and as an ombudsman for open source licensing compliance. It allows you to track community involvement and keep records to show business ROI for open source efforts. By pulling the different interest groups together in a single room, everyone is invested in the proper use of open source software, and there is less chance of a policy that is VOA—Violated On Arrival.

3. Have an Open Source Database

One common pitfall is that administrative decisions about open source are made... and then they stay in an email chain someplace. This makes it likely that decisions get re-made over and over again, important documents get lost, and reduces the amount of self-service that people outside the OSPO can do.

Instead, keep track of all your decisions. When participation in an external open source project is approved, record the decision and keep a copy of the corporate CLA in the same location. When use of an open source product is approved by the OSPO, record all the details of the use in the tracker.

Just use git

Note that this "database" need not be a database at all. One practice we usually recommend is to record all open source decisions in a specialized git repository. While using source code control tools like git is not usually part of the non-developer skillset, there will be people who can use it easily.

More importantly, putting your OSPO's open source decisions into your source code control system makes them extremely convenient for developers to see and use, decreasing the cost of compliance.

4. Create an Internal Open Source Repository

This tip is one that seems most difficult for organizations to implement, but it has a profound impact: Make a copy of the open source you use inside your organization, and then have your developers use those internal copies to build and deploy your software. Not that these are not forks, these are clones of the external "official" repositories and should not cause any extra effort to keep up to date.

This has many positive effects. First, security. Automatically downloading code from the Internet and running it is strongly discouraged by security experts. Further, this gives some protection against supply chain attacks. A supply chain attack is where someone substitutes a malicious copy of software into the distribution stream. while they are not common, they do occur. Using your internal copy can help shield you from these attacks.

Second, keeping copies of your open source software into a central repository makes compliance easier. It establishes a clear line between allowed uses and packages, and those that are disallowed—just look at the repository. It also increases internal transparency with regard to open source use, which simplifies license administration over time.

Third, and aside from the open source-related benefits, adopting an internal source code repository can be helpful in other ways. The source code for most software is usually seen only by the immediate team of developers assigned to work on it. Adopting an internal repository can foster greater communication between teams, leading to higher product quality overall.