Posts tagged 'OSPO'

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.

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.

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.

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.

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.

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.

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

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.

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.