NetBux All articles
Community & Digital Equity

Who Owns the Code the Machines Learned From? Open Source's Reckoning With the AI Training Economy

NetBux
Who Owns the Code the Machines Learned From? Open Source's Reckoning With the AI Training Economy

Photo: Al Piskun, CC BY-SA 4.0, via Wikimedia Commons

Somewhere in the weights of a large language model, there's probably a trace of your code.

If you've ever pushed a public repository to GitHub, contributed to an open source project, or posted a Stack Overflow answer that got upvoted a few times — your work almost certainly ended up in the training data for one or more commercial AI systems. Systems that are now being sold as developer productivity tools, enterprise software solutions, and API products generating real revenue for their creators.

You didn't get a check. You probably didn't even get an email.

This is the quiet tension sitting at the center of open source's relationship with the AI industry, and it's getting harder to ignore.

How We Got Here

The open source community built its culture on a simple and genuinely radical idea: share your work, and the whole ecosystem gets better. Licenses like MIT, Apache 2.0, and GPL were designed for a world where software was used to build other software — where attribution, modification rights, and distribution terms were the relevant variables.

Nobody was really thinking about a future where your code wouldn't be used so much as consumed — ingested, processed, and distilled into a statistical model that can mimic your patterns without ever actually running your program. The legal and ethical frameworks that govern open source weren't built for that scenario, and they're showing the strain.

When GitHub Copilot launched in 2021, it cracked this tension wide open. Copilot, trained on public repositories, could reproduce identifiable code snippets — sometimes including comments, variable names, and stylistic quirks that made it obvious where the output came from. A class-action lawsuit followed, arguing that this constituted copyright infringement and a violation of open source license terms. The legal questions are still being worked out in court, but the cultural and ethical debate has already moved well beyond the courtroom.

The Attribution Problem

One of open source's foundational values is attribution. When you use someone's code, you credit them. When you build on their work, you say so. It's not just a legal requirement under many licenses — it's a form of respect that holds the community together.

AI training breaks that norm in a way that's hard to fix with existing tools. A model doesn't cite its sources the way a developer does. It doesn't include a license header. It can't really tell you which of the million repositories it was trained on contributed to a particular output, because the answer is kind of all of them and kind of none of them.

This isn't just a philosophical problem. For developers who've spent years building reputations in the open source community — who've built careers, consulting practices, and job opportunities on the visibility of their public contributions — the idea that their work is now training a commercial product that competes with them professionally is genuinely unsettling.

And it hits differently depending on who you are. A senior engineer at a well-funded startup has other ways to establish credibility. An independent developer in a smaller market, someone whose open source portfolio is their primary calling card, has a lot more to lose.

The Licensing Arms Race

The community's first major response has been to reach for licensing as a solution. New license formats like the Server Side Public License (SSPL) and various "source available" approaches have tried to carve out protections against large-scale commercial exploitation — including, in some cases, explicit prohibitions on using the software as AI training data.

The results have been mixed, to put it diplomatically.

Purists argue that any license that restricts what you can do with software isn't really open source at all — and they have a point. The Open Source Initiative's definition of open source explicitly requires that licenses not discriminate against fields of endeavor, which would seem to rule out "you can use this for anything except training a commercial AI model."

Pragmatists counter that the original open source licenses were written in a different era for different threat models, and that clinging to definitions designed for 2001 isn't serving anyone in 2025.

This is a genuine values conflict, not a technical one, and it's unlikely to resolve cleanly. What it has done is fragment the licensing landscape in ways that make it harder for developers to know what they can actually do with any given piece of code — which creates its own problems for the collaborative ecosystem that open source depends on.

What Compensation Could Even Look Like

Some voices in the community have started pushing for a more direct approach: if companies are profiting from open source training data, they should pay for it.

The mechanics of this are genuinely difficult. Who would collect the payments? How would you calculate each contributor's share of a model's training data? What about code that was committed fifteen years ago by someone who's no longer active? What about contributors who want their code to train AI models because they think it advances the field?

A few proposals have circulated — some version of a collective licensing body, similar to how music royalties work through ASCAP or BMI, has come up more than once. The analogy isn't perfect, but the music industry's experience with digital disruption offers at least some useful precedents for how a community can negotiate its relationship with a technology that changed the value of its work without asking permission first.

Others argue that compensation is a red herring, and that what developers actually want is transparency and control — the ability to opt out of training data collection, better tooling to see where their code has been used, and meaningful governance over how AI companies engage with the open source ecosystem.

Building Something Better

NetBux has always been about the idea that technology works best when it's built collectively and shared openly. That's not an abstract principle — it's a practical bet on how innovation actually happens.

The AI training economy doesn't have to be the end of that model. But it does require the open source community to update its assumptions about what sharing means, who benefits, and what obligations come with building on other people's work at scale.

That means pushing for AI companies to be transparent about their training data. It means developing new norms — and possibly new legal frameworks — around what responsible use of open source code for AI training actually looks like. And it means making sure that the developers who've contributed the most to this ecosystem, especially those who are most economically vulnerable, have a real voice in how these questions get answered.

The machines learned from us. Now it's our turn to decide what we want them to do with that education.

All Articles

Related Articles

Code for Hire: Whether Open Source Can Actually Pay the Bills in 2024

"Open Innovation" Is Mostly a Lie—Here's What It Takes to Actually Mean It

"Open Innovation" Is Mostly a Lie—Here's What It Takes to Actually Mean It

Tech's Inclusion Problem Is Everyone's Problem — And It's Time to Fix It

Tech's Inclusion Problem Is Everyone's Problem — And It's Time to Fix It