Blog

Every one of our clients has been asking for help on AI issues. We can't reason about AI correctly without understanding how these tools work. Accordingly, I want to bring my latest publication to your attention: Building and Using Generative Models Under US Copyright Law (18 Rutgers Bus. L.R. No. 1, 2023).

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.

The biggest name in AI right now is OpenAI. With its wildly popular ChatGPT, GPT-3 and GPT-4, and Codex products, OpenAI has most of the buzz. But before you use any of its tools, make sure you are read OpenAI's terms of use.

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.