Meta’s Llama 2 License, OpenAI Bug Finding in Linux, and Open Source Regulation Tools

Robert Jacobi: Welcome to Open Channels News. I’m your host, Robert Jacobi. Today, what do you actually get when an AI company calls its model open source? We’ll look at what the label promises, what an AI security experiment found in the Linux kernel, and why a congressman wants the Federal Reserve to put some open source software to the test.

Let’s start with the label. Jorge Aguilar writes in How to Geek about a familiar routine. A company announces an open-source model, developers get excited, then somebody opens the license and discovers conditions the announcement skipped. With conventional software, we have a pretty good idea of what to ask for. Can I inspect the source? Can I change it? Can I share my version? Can I use it for the work I actually do? Those questions come out of decades of open-source practice. They matter when you’re choosing something your team could spend years building on.

With AI, a download often gives you the weights. Those are the numerical values a model learned during training. With the right software and definitely enough computing power, you can take those weights and run the model yourself. That’s pretty cool. Maybe you want to run it locally so your prompts stay on your own machine. Maybe you want to tune it for a narrow job or test how it behaves before putting it in front of customers.

Now imagine you want to understand how the model was made. What went into the training? How was that material filtered? What code and settings would you need to build a comparable model? The weights alone give you very little to go on, and the license can introduce a separate set of limits. Aguilar points to Meta’s Llama 2 license, which required a separate license for companies above a specified threshold of monthly users. That’s the kind of detail that matters a lot more to a deployment team than the words at the top of a press release.

Aguilar’s argument is that the open-source community helped blur the line when it accepted broad labels for releases with very different terms. He also acknowledges why the line can be difficult to draw. Some training material is private, copyrighted, or subject to rules about who can share it. And even a limited release can give developers real options. For me, that makes precision more important. Tell people what they can download, what they can learn about how it was built, and what they have permission to do with it.

That brings us to Linux, where OpenAI has been testing what AI can do with code that’s already open for inspection. The Hacker News reports that an OpenAI research pipeline generated 948 working local privilege escalation exploits in a controlled run. Here’s what that means. Picture somebody who can already run software on a machine with an ordinary user account. A flaw in the kernel could let that person get root, the level of access that gives them control over the system. The researchers demonstrated paths to that outcome on their test systems.

The team started with more than 2,000 suspected findings. The pipeline tried to reproduce them in isolated environments, gathered evidence about which ones could be exploited, and generated candidate patches. Human security researchers reviewed the outputs. OpenAI put the cost of the run at about $1.2 million in API credits.

There’s an important detail in the research write-up. In the time it took to run the scan and analyze the results, Linux maintainers and other contributors had already fixed some of the issues upstream and were working on others. So imagine being the maintainer who gets a report tomorrow morning. Does it still reproduce on current code? Is there enough evidence to judge how serious it is? Does the proposed patch fit the way that part of the kernel works? Each answer determines what happens next. A pipeline can find a lot in a short time. The people responsible for the code still have to decide what ships.

And finally, let’s go to Washington, D.C. FedScoop reports that Illinois Congressman Bill Foster has released a discussion draft called the Real-Time Regulatory Study Act. It would ask the Federal Reserve Board, working with other financial regulators, to build, test, and publicly release open-source demonstration software for bank oversight.

Think about the timing. Payments can move around the clock. A report that was accurate when somebody prepared it may tell a regulator very little about what changed in the last few hours. Foster wants to see whether tools like automated reports, supervisory dashboards, and stress tests could give regulators a more timely picture and reduce some of the reporting work for banks and credit unions. Take a small credit union. If it has to build and maintain its own software to turn internal records into regulatory reports, that takes time and money. A shared tool could reduce some of that work. The study would help answer whether the tool actually saves time and whether regulators can rely on the numbers it produces.

The draft puts boundaries around the experiment. The tests would exclude live customer accounts, and regulators would take no action based on the results. The proposed public release would also include draft security and maintenance plans. I’ll definitely be watching that part. Say a dashboard flags a problem. Can someone trace the alert back to the calculation that produced it? And if that calculation needs to change, who owns that fix?

Thank you all. That’s it for today’s Open Channels News. I’m Robert Jacobi. Be open and stay secure.