Blog

One hot topic that keeps coming up with our clients is how to deal with AI models and their associated licenses. Many ML model licenses are inspired by open source licenses, so OSPOs are being brought in for their expertise. Today's topic is how to think about licensing out your own models and datasets if you want to encourage collaboration, but possibly preserve competitive advantage.

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

Most open source companies can be categorized into five main business models. In part one we reviewed the Ketchup Model and the Dual License Model. In this part, we review the Proprietary Crust Model, the Infrastructure Model, and the Adjacency Model.

Many companies have embraced open source to make money and create value. From these efforts, five main business models have emerged for successful open source companies.

OSPOCO is now an official partner of the OpenChain Project. As an official partner, OSPOCO is able to help companies toward OpenChain ISO/IEC 5230 compliance and can act as a third-party certifier for organizations that need audits.

A few months ago we talked about GitHub CoPilot and the controversy it created in the open source community. Since then a lawsuit has been filed against Microsoft, GitHub, and OpenAI (creators of the underlying technology). OSPOs are increasingly being asked whether AI-assisted code is safe to use. The answer, of course, is an unsatisfying maybe.

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.

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.

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.

This guide explains how organizations can build leadership and influence within the open source projects they’re involved in and on which they are commercially dependent. Learn about leadership culture and roles within a project, how decisions are made, how an organization can build leadership, and tips for being a good leader in open source communities.

Open source development requires a different approach to software engineering than many organizations are accustomed to. It becomes easier if you have a clear plan to follow. Fortunately, many companies and individuals have already forged a path to success by contributing to significant open source projects in strategic ways. This practical guide will help you and your company improve your internal development process and prepare you to contribute to the open source projects that matter most to your company.

Open source program managers must demonstrate the ROI of their efforts. This guide provides an overview of some of the standard ways that organizations evaluate their open source programs, projects, and contributions. Learn what to measure, how to define success, and how to best use this information to advance your open source program objectives, demonstrate effectiveness, and gain support.

So what is an open source program office (or "OSPO")? It is the hub of an open source program. The OSPO is a designated place where open source is supported, nurtured, shared, explained, and grown inside a company. With such an office in place, businesses can establish and execute on their open source strategies in clear terms, giving their leaders, developers, marketers, and other staff the tools they need to make open source a success within their operations.