Posts by Van Lindberg

Companies tend to increase their use of open source in a recession. Paradoxically, they also tend to cut their open source program personnel. It is more important than ever to tie the work your OSPO does to the financial health of your organization.

One of the keys to success as an OSPO is balance: making sure that you have done enough, but do not have so many procedures and processes that they become counterproductive. But how do you know what is "enough"? One way is to use the OpenChain standards as a guide. This article focuses on the recent OpenChain Security Assurance Standard.

Providing good security procedures and management is one of the things that OSPOs can do to show value. Hands-on security management requires solid technical capability, but no Ph.D.s in cryptography are needed to make a huge difference. Many open source security issues require just as much community engagement as they do technical acumen, and that sits right in the sweet spot of what open source program offices do.

One of the big drivers for investment in open source tooling is security. We want to introduce you to Dependabot - a tool you should probably be using to help you keep your open source components up to date.

The AGPL (short for the " Affero General Public License, version 3 ") is a free and open source software license designed to promote cooperative development of software that is used in a client-server or peer-to-peer context. It is an increasingly common license for server-side software and it is notoriously tricky to comply with.

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.

One of the first tools that we bring when working with OSPOs is the OpenChain 2.1 / ISO/IEC 5230 standard. OpenChain is an international standard for open source programs, helping companies create compliant processes. But what does OpenChain mean for your OSPO?

Each year the Open Source Initiative sponsors a survey about open source usage across multiple industries. The 2022 report provides a good way to compare your use of open source with many industry peers. We took a look at the report to provide a few highlights.

One of the most common questions for businesses is how to create differentiation when building on or using open source code. The answer is that these days, your business differentiators usually aren't your code. It is all the things around your code that usually lead people to buy your products.

The core administrative function of an Open Source Program Office is making sure you know what open source software your organization is using. Every other function relies on this basic knowledge. If you don't know what software you are using, you can't comply with the licenses, you can't respond to security issues, and you can't engage with the larger community. So how do you get that information? In a word, scanning.

One of the first tasks for any OSPO is creating an open source policy. It's the charter for your open source program. It should express your company's take on the big questions: Why does your organization engage with open source? What are your goals? Who is allowed to engage with open source? The answers may be different for each organization, but there are two key concepts that will help you create the most effective policy for your organization.

G-Research wanted to invest in its open source supply chain, but traditional engagement didn't quite fit. Instead they built what they call a "muscular OSPO" with a deep investment in advancing upstream projects. Alex Scammon, head of G-Research's OSPO, talked to us about it.

It was a big week for Github CoPilot last week. There were new allegations of copyright infringement of open sourced code and an announced lawsuit. So how should you think about CoPilot and other machine learning tools trained on open source code?

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.