Posts tagged 'best-practices'

We have previously written about the importance of scanning for compliance. This has become even more important with the introduction of AI-assisted code generation tools like Github Copilot. The next step is making your scanning effective by integrating with your Continuous Integration / Continuous Delivery (CI/CD) system.

A few weeks ago we wrote about how Open Source is coming for AI. At that time we didn't realize how quickly our predictions would start to be realized. In a new leaked document from inside Google, one of their AI team highlighted open source innovation as the primary competition for Google, OpenAI, and other large incumbent firms.

Some of the most valuable work that OSPOs do involves open source project health. It could be that your organization wants to make its sponsored projects successful, or you could be proactively trying to understand and manage your open source supply chain risk. Either way, understanding community health is an under-appreciated part of a successful open source program.

One of the things that can make compliance more difficult is trying to track which open source components have which obligations. Some require general attribution, some require source code, and everything in between. But keeping track of all the differences isn't necessary if your organization has an "open by default" policy.

AI is the new hot topic for open source program offices. We previously discussed licensing for AI models, and how many models are restricted to non-commercial use. But open source is coming for AI. Thankfully, the lessons learned managing open source apply to managing AI as well.

One of the time-honored traditions of open source is reverse engineering - working out how another person accomplished a goal and replicating it. Reverse engineering is an important tool in your toolbox and has been growing in importance. But it always involves some legal risk. So how do you make reverse engineering as effective as possible while managing the risk?

There is a common saying among people that manage storage backups: If you don't test your backup, you probably don't have one. The same logic applies to automated systems designed to help you with open source.

Software licenses can unexpectedly change from version to version. The latest to change is Java, and Oracle is asking for companies to pay up.

Your use of open source is an ongoing process, not a one-time event. Therefore, open source management should be fit into the business processes of your organization, with a focus on simplifying long-term compliance. A few tips can help you be more effective.

You may remember the 2017 Equifax data breach. The records of more than 160 million people were exposed, making it one of the largest cybercrimes related to identity theft. Among various other penalties, Equifax was required to pay out $300 million to a fund for victim compensation, $175 million to the states and territories in the agreement, and $100 million to the CFPB in fines. The cause of the data breach? Not updating an open source component on Equifax's website.

Last year, the Biden administration issued the Executive Order on Improving the Nation's Cybersecurity. What most open source personnel don't realize - yet - is that one of the results of the Executive Order will be a contract requirement to manage open source risks as a mandatory contract term for anyone supplying the Federal Government.

So much of what we do in OSPOs is about trying to get things right. We usually focus on the positive sides of engaging with open source: lower costs, greater control, faster time-to-market, and higher developer satisfaction. But that doesn't mean that we also don't keep an eye on open source risks. A number of independent events have all converged to markedly increase the legal risk of poor open source practices.