Blog

You might think that we would always be in favor of open sourcing code from inside your organization. But sometimes releasing code under an open source license can end up causing more harm than good.

Every OSPO we are working with is being asked to help with AI issues. A well-functioning OSPO already has the cross-disciplinary legal and technical resources to understand and advise on AI issues. As an open source leader in your company, though, AI is a big opportunity to move from being reactive to proactive, from a compliance focus to a strategic focus.

One question that frequently comes up with our clients is how to have a "successful" open source project. The answer, of course, depends on your goals and what "success" means to you.

Meta recently released the LLaMA 2 language model. In several places they said it was "open source." It's not. But it has a fairly permissive commercial license that is driving a lot of interest, including among OSPOs.

It seems everyone is scrambling to understand what to do about AI. Based on our work with our clients, here are the emerging issues and best practices.

If you have been around open source for a while, you might have heard of an "Open Source Maturity Model." An open source maturity model is not about how developed a particular open source project is - it is about how well your organization deals with open source.

One common question we get at OSPOCO is about Java and the OpenJDK. Are they the same thing? What licenses apply? Understanding the difference can save you thousands of dollars if Oracle comes knocking. The takeaway: you need to not only understand that you are using Java, you need to understand where your developers are downloading Java.

When you ship a program that uses open source code, you need to make sure that 1) your licensing is compliant, and that 2) you provide the necessary attribution, licensing, and (possibly) source code for the open source components you use. But many people are confused about how far back their disclosures need to go. Do you need to declare every dependency, including dependencies of dependencies? What do you need to share?

Some time ago we wrote about the President's Executive Order on Improving the Nation's Cybersecurity and its requirement to declare what open source code is used in your products. Now we have a timeline for when it is going to start to affect suppliers.

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. 2, 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.