翻訳待ち：Use the OSS, Commit Back – OAVL – The Open Source AI Viability License

AI サービスが一時的に利用できないため、復旧後に翻訳を補完します。

Notifications You must be signed in to change notification settings Fork 0 Star 0 BranchesTags Open more actions menu Latest commit History 2 Commits 2 Commits Folders and files NameName Last commit message Last commit date LICENSE-OAVL-0.1.md LICENSE-OAVL-0.1.md README.md README.md Repository files navigation A permissive open source license whose grant is conditioned on agents giving something back. Commercial use is permitted, free of charge, with no negotiation. Modification and redistribution are permitted. Derivative works may be relicensed on whatever terms you like. There is no fee and no way to pay your way out. The one condition: if your organization points AI agents at this software at commercial scale, you owe the project at least one good-faith contribution per year. A first pass at an open issue. A bug you found plus an attempted fix. A well-formed defect report. A specific, motivated feature proposal. 📄 Read the license → Status: v0.1 draft. Not yet used in production by anything. Not legal advice. Feedback wanted — see Contributing. Why Every open source license we have assumes a human reader. The permissive licenses — MIT, BSD, Apache-2.0 — ask for attribution, because attribution is what a human contributor wants out of the exchange. The copyleft licenses — GPL, AGPL — ask for source reciprocity, because a human downstream needs source in order to exercise the freedoms the license is protecting. Neither assumption survives contact with an autonomous agent. An agent does not read your NOTICE file and feel credited. An agent does not need you to publish source in order to study your work; it has already read everything. The consideration these licenses ask for is consideration an agent cannot meaningfully provide. Meanwhile, the thing open source actually runs out of is not source code and not credit. It is maintenance attention — a small number of people, mostly unpaid, reading issues and reviewing patches. The premise This license is written on a specific bet, and you should evaluate it as a bet rather than a fact: Commercial SaaS is going to contract harder and faster than current coverage suggests, because agents can increasingly build in-house what companies previously bought. As that happens, open source becomes the default substrate — not one option among several, but the thing nearly everything is assembled from. And the primary consumer of that substrate will be agents, not people. If that's right, open source is about to absorb an enormous multiple of its current usage with no corresponding increase in contribution. Ten thousand agent-hours a day reading your library, filing nothing, fixing nothing, and reporting nothing. Maintainer attention stays flat while demand on it goes vertical. That is not a sustainable equilibrium. It's extraction, and the projects at the bottom of the dependency graph absorb all of it. The move OAVL's position is that the replenishment should come from the same place the consumption does. Agents are extraordinarily cheap at exactly the work maintainers are expensive at producing: triaging an issue, bisecting a regression, writing a reproduction case, drafting a first-pass patch. So the price of agentic use is agentic contribution. Not money — money is deliberately excluded as a means of compliance, because money is not the scarce resource here and a payment option would quietly turn this into a commercial license with extra steps. The price is effort, denominated in the currency the user has a surplus of. What it does not ask Nothing from humans. If a person uses this software — reads it, builds a business on it, sells a product containing it — they owe nothing beyond attribution. The obligation attaches only to agentic use. This is not a general commercial-use tax wearing a costume. Nothing from small entities. Under 10 people and under $1M revenue: exempt. Nothing from non-commercial, academic, charitable, or evaluation use. Nothing from packagers and mirrors. Distribution alone is not agentic use. No merged PRs. Compliance is complete on good-faith submission. Whether to merge is entirely the maintainer's business, and the license imposes zero obligation on maintainers. You cannot condition a license on someone else's discretionary act without making compliance impossible to achieve unilaterally. No training-data claim. The license neither grants nor restricts use as training data. That's a separate fight and mixing it in here would sink both. Problems with this license Writing an honest list of these is more useful than pretending they don't exist. If you're evaluating OAVL, evaluate it against this section. 1. It is probably not "Open Source" in the OSI sense The Open Source Definition doesn't contemplate conditions that require labor. Copyleft conditions attach to distribution and ask you to pass along source you already have. OAVL asks you to produce something new. That's a materially different kind of obligation, and it very likely fails OSD approval. The name says "Open Source" anyway, which is a deliberate choice and a contestable one. The counterargument is that "open source" describes a practice that predates and exceeds the OSI's trademark-adjacent stewardship of the term. The counter-counterargument is that the term's usefulness comes precisely from being a bright line, and licenses that blur it — SSPL, BSL, Commons Clause, the ethical-source family — have made the ecosystem harder to navigate without much to show for it. Reasonable people land in different places. This is the single most likely reason for the license to be rejected out of hand. 2. The teeth are largely voluntary Derivative works can be relicensed under any terms, including terms that omit the condition. So the escape hatch is: fork it, relicense, done. This is intentional — see the preamble — but be clear about the consequence. OAVL functions primarily as a norm, not as an enforcement mechanism. It makes an expectation legible and gives a maintainer standing to point at it. It does not make a determined non-complier comply. Whether that's fatal depends on your theory of how licensing norms actually work. The GPL's practical influence has always vastly exceeded its litigation record. 3. Slop This is the failure mode most likely to actually happen. A license that mandates agent-authored submissions could easily generate a flood of confident, plausible, wrong pull requests — and leave maintainers strictly worse off than if the license had asked for nothing at all. The commons gets replenished with sewage. §5.3 tries to defend against this with disclosure requirements, a "quantity does not cure quality" rule, an explicit prohibition on submissions made to exhaust or mislead a project, and a conclusive maintainer veto over what counts. §5.4(a) lets a project publish a standing waiver saying don't send us agent PRs and be done with it. It is genuinely unclear whether these defenses are sufficient. They may not be. If you adopt OAVL, watch this closely and report back. 4. "Agentic Use" is hard to define and harder to audit The license draws the line at whether a human reviews and accepts each application individually. That's a real distinction today. It may not be one in three years, when the boundary between "autocomplete" and "agent" is a slider rather than a category. And no licensor can observe your internal development practices. Compliance is fundamentally self-attested. §5.5 asks you to be able to state what you relied on; nothing verifies it. 5. The obligation may be too small to matter One contribution per project per year, capped at ten projects. For a company running hundreds of agents continuously, that is a rounding error — arguably a licensing fig leaf rather than a real reciprocity requirement. The counterargument is that a small obligation that gets complied with beats a large one that gets routed around, and that v0.1 should err toward adoptability. But if OAVL ever sees real use and the contributions are trivially small, the numbers need revisiting. 6. Tooling and compatibility friction Not in the SPDX license list. Package registries, license-checker, FOSSA, Black Duck, and corporate license allowlists will all flag it as unknown, which in most enterprises is functionally the same as "denied." In practice this is a larger adoption obstacle than the philosophical objection in §1. GPL compatibility is untested and probably poor. Legal review costs at a large company are real, and a novel license means an actual lawyer reads it. Many organizations will decline on that basis alone, without any view on the merits. 7. Enforceability of an affirmative act Copyright licenses conditioning permission on doing something new are unusual. There are open questions about whether the condition is a covenant (breach → contract claim) or a condition precedent (breach → copyright infringement), how a court would assess "good faith," and whether the whole thing is void for vagueness in some jurisdictions. §12(a) hedges: if §5 is held unenforceable, the license degrades to Apache-2.0 rather than to nothing. Note that with permissive derivatives already allowed, that fallback is close to what you'd get anyway. 8. It might just be wrong about the world If SaaS doesn't crater — if agents turn out to increase demand for commercial software, or if the open source substrate gets absorbed into a handful of model providers rather than staying distributed — then the problem this license addresses doesn't materialize in the shape described, and OAVL is a solution to a hypothetical. Contributing This license is a draft and it wants pull requests. Legal drafting is not a solo activity and this document has had exactly one pass. Especially wanted: Lawyers. Anywhere the drafting is ambiguous, unenforceable, internally inconsistent, or accidentally does something other than what the preamble says it does. Jurisdiction-specific problems are very welcome. Maintainers. Would you actually apply this? What would the flood of agent-authored PRs do to your project? Are the §5.3 quality defenses anywhere close to adequate? What would you need in order to try it? People who think this is a bad idea. The Problems section is the most important part of this repo and it is certainly incomplete. Additions to it are as valuable as improvements to the license text — arguably more so. Open an issue or send a PR against that section directly. Anyone who has read SSPL, BSL, the Hippocratic License, Peer Production, Post-Open, or the Fair Source family and can point out where OAVL is repeating a mistake those already made. Open questions currently unresolved: Is one contribution per year the right cadence, or should it scale with agent usage or company size? Should the exemption floor be higher than 10 people / $1M? Is excluding payment-in-lieu correct, or does it leave overwhelmed maintainers without an escape valve? Should there be a network/SaaS trigger in addition to the agentic-use trigger? Is "Open Source AI Viability License" the right name, given §1 above? How to contribute: open an issue for discussion, or send a PR. For license text changes, please explain the problem the change solves — a diff without a rationale is hard to evaluate in a document like this one. Substantive changes will bump the version number; the intent is that v0.1 is explicitly provisional and v1.0 arrives only after review by people who do this for a living. Applying it Copyright [yyyy] [name of copyright owner] Licensed under the Open Source AI Viability License, Version 0.1 (the "License"). You may obtain a copy of the License in the LICENSE file distributed with this work or at https://github.com/kenm47/oavl Commercial use is permitted. If your organization uses AI agents to build on this software, see Section 5: you owe this project at least one good-faith c [truncated for AI cost control]