samber/developer-relations-skills已通过检查
SKILL DETAIL
oss-license-strategy
samber/developer-relations-skills/oss-license-strategy
Chooses an open-source project's license and contribution policy as one decision - permissive vs weak, strong or network copyleft, dependency-driven compatibility constraints, DCO vs CLA vs nothing, dual licensing and open core, source-available options (BUSL, FSL, Elastic License, SSPL), and the fork risk of relicensing. Use whenever someone asks which license to pick, whether MIT, Apache-2.0, GPL or AGPL fits, whether to require a CLA or a DCO sign-off, how to relicense an existing project, whether AGPL really protects against cloud providers, or which LICENSE, SPDX and NOTICE files to ship - even if they only voice a legal worry. Not what the company open-sources at all - use samber/developer-relations-skills@open-source-company-strategy. Never legal advice.
安装量 · 414查看来源
Installation
npx skills add https://github.com/samber/developer-relations-skills --skill oss-license-strategy
技能文件
SKILL.md
最近同步 · 2026年10月23日
evals/evals.json›
{
"skill_name": "oss-license-strategy",
"evals": [
{
"id": 1,
"prompt": "We're at Mirefold Systems and we're finally open-sourcing `trailcut`, our hardware provisioning CLI. It's Rust with a C shim. The shim links libtapedrive, which is GPL-2.0-only, and the Rust side pulls in 63 crates, mostly Apache-2.0 and MIT. There's also a vendored copy of a BSD-3-Clause CRC routine somebody pasted in years ago, and about 200 lines of the retry logic came out of an AI assistant last spring. We want to ship it Apache-2.0 because that's our company standard for everything else. Can you confirm that works and write up the LICENSE?",
"expected_output": "A constraint list, not a confirmation: the GPL-2.0-only dependency in the shipped artifact decides the outbound license, and Apache-2.0 is eliminated in that direction. Apache-2.0 is rejected with a reason, vendored and AI-origin code are flagged for provenance, build-only dependencies are separated from shipped ones, and each eliminated option carries a written reason. No LICENSE file is drafted for a combination that cannot ship.",
"files": [],
"expectations": [
"States that compatibility is directional, asking whether code under A can be combined into a work distributed under B rather than whether A and B are 'compatible'",
"States that the FSF does not accept Apache-2.0 into GPLv2, on the grounds of Apache-2.0's patent-termination and indemnification terms",
"Rejects Apache-2.0 as the outbound license while libtapedrive (GPL-2.0-only) ships in the artifact",
"States that Apache-2.0 into GPLv3 works while GPLv3 into an Apache-2.0 project does not",
"States that copyleft into permissive never works, so a single copyleft dependency can decide the outbound license before any preference is expressed",
"Separates build-only and test-only dependencies from what actually ships, because obligations attach to what is distributed",
"Requires enumerating transitive dependencies, not just direct ones",
"Flags the vendored BSD-3-Clause CRC routine and the AI-generated retry logic as provenance items to resolve",
"Recommends recording each dependency result as an SPDX identifier so the check is repeatable in CI",
"Treats the copyleft dependency as a gate that deletes options rather than an option with a poor ratio",
"Produces the constraint list with a written reason per eliminated option before discussing preferences or postures",
"Makes no claim about what a court would decide on the linking question"
]
},
{
"id": 2,
"prompt": "Kettleworth Data here. We run an open-source time-series server, MIT since 2023, about 4,000 self-hosted installs. Two of the three hyperscalers have started shipping managed offerings that look a lot like ours, and our board is spooked. I want to flip to AGPL-3.0 so they can't just take it. Our two biggest paying accounts are a European bank and a US retailer, and we've got a third in procurement right now. Just tell me if AGPL is the right move and I'll take it to the board Friday.",
"expected_output": "A refusal to name a license first. The request is treated as a posture question, brainstorming is declared, and two or three postures are offered. AGPL is described accurately: it obliges a network operator to publish source, it does not stop a competitor willing to comply, and Google's published ban is named as the checkable enterprise cost. No percentage of enterprises banning AGPL is quoted, and the MIT releases already published are flagged as permanently forkable.",
"files": [],
"expectations": [
"States that AGPL obliges a network operator to publish source but does not stop a well-resourced competitor who complies",
"Names Google's published policy that AGPL-licensed code must not be used at Google, extending to installs on company machines without Open Source Programs Office authorization",
"Refuses to give a percentage or share of enterprises that ban AGPL, and says no credible aggregate figure exists",
"Asks whether the specific accounts this project needs sit behind such a written ban",
"Says explicitly that it is in brainstorming mode and that no recommendation has been made yet",
"Presents two or three candidate postures rather than a single option",
"Describes each posture as a bundle of license family, contribution policy, and what it forecloses in two years",
"States that every release already published stays MIT forever and can be forked from the last MIT commit",
"States that relicensing needs the consent of every copyright holder whose code is still present, since no contributor agreement pre-granted it",
"Names hosting the software themselves as a model that needs no licensing lever, and raises it before recommending a restriction",
"Requires naming the specific competitor the restriction defends against as a test the decision must pass",
"Declines to state whether any specific architecture triggers AGPL's network clause, routing that to counsel"
]
},
{
"id": 3,
"prompt": "I maintain `quillsort`, a Python library for parsing legacy fixed-width records. MIT, about 340 GitHub stars, 11 people have sent patches. Last week a contributor from a mid-size insurer said their legal department asked whether the project 'has a patent grant in place' before they can keep contributing on company time. I've seen Kubernetes and a bunch of big projects require a CLA, so I'm thinking I should just set one up with a CLA bot and be done with it. Does that solve the patent question?",
"expected_output": "A no on the CLA, with the actual fix: MIT carries no patent grant, so the answer is Apache-2.0, not a contributor agreement. The DCO is named as the starting rung and the ceiling absent a right the license does not grant. Assignment is deleted from the menu with Fogel's reason stated, and the enforcement mechanism plus recovery commands are specified.",
"files": [],
"expectations": [
"States that MIT and BSD carry no patent grant while Apache-2.0, GPL-3.0 and MPL-2.0 do",
"Recommends checking whether the project's own license already carries a patent grant before adding an agreement for that reason",
"Recommends moving the project to Apache-2.0 as the answer to the patent question rather than adding a CLA",
"Starts the contribution-policy ladder at the DCO rather than at 'nothing' or at a CLA",
"Quotes or paraphrases that a DCO is 'probably the minimum amount of CLA a free software project should adopt', attributed to Karl Fogel's Producing Open Source Software",
"States the rule that you move up a rung only for a right the license does not already grant",
"Names relicensing, dual licensing and selling a commercial license of contributed code as the rights that actually justify a CLA",
"Deletes copyright assignment from the menu for this project and says why, citing Fogel's recommendation against it for new projects",
"States that a CLA on a project with no commercial plan reads as reserving the right to change the deal and costs drive-by contributions at the signature wall",
"Warns against requiring both a CLA and a DCO, since it doubles friction for one marginal gain",
"Requires an automated check on every incoming change, stating that a policy enforced by memory is not enforced",
"Gives the contributor recovery commands for a missing sign-off, `git commit --amend -s` for one commit or `git rebase --signoff` for several",
"States that existing history is grandfathered and retroactive sign-off is never demanded on merged work"
]
},
{
"id": 4,
"prompt": "Harborloom, 11 people, we build an open-source workflow engine. MIT from day one, 47 outside contributors have landed code that's still in the tree, and we never asked anyone to sign anything. A managed competitor launched in June and is winning deals against us with our own software. I want to ship 4.0 under BUSL-1.1 with a change date and get the announcement out in four weeks so it lands before our user conference. Draft the new terms and the blog post.",
"expected_output": "A change plan before any terms: consent from all 47 contributors is required, the four-week deadline is called impossible against a consent campaign, and the fork is treated as the predictable outcome with Elastic, Redis and HashiCorp as the documented cases. BUSL's three parameters are stated correctly, the vocabulary rule is enforced, and SDKs, clients and docs are recommended to stay permissive.",
"files": [],
"expectations": [
"States that every copyright holder whose code is still present must consent, since MIT plus no contributor agreement means no pre-granted relicensing right",
"States that published releases stay MIT forever and can always be forked from the last MIT commit",
"Produces a change plan covering whose consent is needed, what happens to unreachable contributors, the version boundary, what stays on the old terms, and the announcement",
"Treats a fork as the predictable response rather than the worst case",
"Names the documented relicensing cases and the fork each produced: Elasticsearch and OpenSearch, Redis and Valkey, HashiCorp and OpenTofu",
"States that HashiCorp's BUSL-1.1 change applied to future releases only, with SDKs and APIs left on MPL-2.0",
"Gives the OpenTF manifesto's scale, over 140 companies and over 700 individuals, and OpenTofu's Linux Foundation launch on 20 September 2023",
"States BUSL-1.1's Change Date must be at most four years after first publication",
"States BUSL-1.1's Change License must be GPL-2.0-or-later or compatible",
"Mentions the optional Additional Use Grant as the parameter that defines free production use",
"States that BUSL is not OSI-approved and must be called source-available, never open source",
"Warns that four weeks is incompatible with a 47-contributor consent campaign, citing Mozilla's 2001 to 2006 Firefox relicensing as the scale to plan against",
"Recommends leaving SDKs, clients, APIs, examples and documentation permissive"
]
},
{
"id": 5,
"prompt": "Finchgate is a database migration CLI. Individual developers install it themselves, about 9,000 a week, and roughly 30 of those teams eventually buy our $400/month team plan. Nobody goes through procurement to try it, they just brew install it. A competitor in Poland shipped something similar last quarter and I'm rattled. I want to move to FSL like Sentry did so nobody can build a business on our work. Write me the migration plan.",
"expected_output": "A rejection of FSL on funnel grounds, not ideology: the motion is product-led, the path runs individual adoption to company contract without procurement, and source-available terms that block the individual developer's free adoption break exactly that handoff. FSL's actual parameters are stated, the named-competitor test is applied, and alternatives that survive PLG are offered.",
"files": [],
"expectations": [
"Classifies the go-to-market motion as product-led (PLG) B2B, and treats the monetization axis as motion rather than buyer type",
"States the PLG path as individual developer adoption leading to a company contract without procurement",
"States that source-available terms blocking the individual developer's free adoption break the PLG funnel",
"Shifts the evaluation metric from surviving procurement review to developer adoption friction",
"States that FSL freezes BUSL's parameters at two years, converting to MIT or Apache-2.0, with no per-adopter use grant",
"Attributes FSL to Sentry and gives its framing that you can do anything with FSL software except economically undermine its producer",
"States that FSL is source-available and not OSI-approved, so it may not be called open source",
"Requires naming the specific competitor being defended against, and states the restriction buys nothing and costs adoption if none is plausible",
"Offers dual licensing and open core as levers that still work under a product-led motion",
"Names hosting the software themselves as monetizing operations rather than terms, costing no contributors",
"States that 'no lever needed' is a finding to report rather than a failure",
"States that published releases keep their terms forever, so a lever pulled after adoption arrives is mostly symbolic"
]
},
{
"id": 6,
"prompt": "I run marketing at Quillstone. Engineering decided we're moving to SSPL for the 5.0 release and I have to get the announcement out Tuesday. Here's my draft opening: 'Quillstone remains 100% open source and always will be. Today we're strengthening our commitment to sustainability by adopting the Server Side Public License, a modern open source license built for the cloud era.' Can you tighten this up and add a section on why it's good for the community?",
"expected_output": "A refusal to call SSPL open source, with the OSI position quoted, plus a rewritten announcement built on the template: what changes, what does not, who is affected, who is not, why in concrete commercial terms, contributors, and the fork alternative. 'Sustainability' framing is replaced with the named competitive situation.",
"files": [],
"expectations": [
"Refuses to describe SSPL-licensed software as open source, and corrects the draft's '100% open source' claim",
"States that SSPL is not OSI-approved",
"Quotes or closely paraphrases the OSI board's wording that the hallmark of a fauxpen source license is claiming the product remains 'open' while the new license has taken away user rights",
"States that the objection is to restricting deployment as a cloud service, against clause 6 of the Open Source Definition",
"Attributes the position to the OSI Board of Directors, January 2021",
"Prescribes the replacement vocabulary: source-available, fair source, or delayed open source publication",
"States that the claim is checkable in seconds and the correction arrives publicly",
"States that calling it open source fails procurement filters that check OSI approval directly",
"Rewrites the announcement to cover what changes, what does not change, who is affected with an example, who is not affected, why, contributors, and alternatives",
"Replaces the 'sustainability' framing with the concrete commercial situation, named",
"Includes pointing readers at the last commit under the old license and the availability of a fork",
"Notes that Redis's own CEO acknowledged SSPL is not OSI-approved and that the change hurt the relationship with the community"
]
},
{
"id": 7,
"prompt": "Doing a cleanup pass on the Ridgeblack monorepo before our Series A diligence. Current state: root LICENSE is the MIT text with a paragraph we added at the bottom saying the software may not be used to train machine learning models. `docs/` holds our 90-page operator handbook, `examples/` has eight sample apps, `packages/ridgeblack-sdk/` publishes to npm, and `server/` builds a container image. Copyright line at the top of LICENSE says 'Copyright (c) 2024 Ridgeblack Inc. and contributors'. Tell me if this is fine.",
"expected_output": "An artifact audit against the checklist with the exact file and location per gap. The appended clause is rejected on two grounds: it defeats detection and it makes the file a bespoke license that is no longer MIT. The mixed-repository boundary is required in writing, docs are routed to a content license, and registry metadata, SPDX headers, NOTICE and collective copyright are each specified.",
"files": [],
"expectations": [
"Rejects the appended paragraph and requires LICENSE to hold unmodified license text with nothing appended",
"States that a modified LICENSE file defeats automatic license detection",
"States that the appended restriction makes this a bespoke license that can no longer be called MIT, and is not OSI-approved",
"Refuses to draft, modify or invent a license, naming license proliferation as a cost paid by adopters rather than by the author",
"States that a single root LICENSE silently claims the documentation, assets and examples too",
"Requires the per-directory licensing boundary to be written down for the mixed repository",
"Recommends a content license such as CC-BY-4.0 for the operator handbook rather than a code license",
"Requires the npm package metadata license field to be corrected, and a license label on the container image",
"Requires `SPDX-License-Identifier` headers per file matching each directory's license",
"Recommends a collective copyright notice such as 'Copyright The Ridgeblack Authors' instead of an enumerated or company-plus-contributors line",
"Requires a NOTICE file where the license demands attribution propagation, and preservation of third-party notices",
"Requires validating the result against an automated license detector, or by inspection where none is available",
"Names the exact file and location to fix for each gap found"
]
},
{
"id": 8,
"prompt": "Sablewright. Our server product has been AGPL-3.0 for two years, we run a DCO with a bot that checks sign-offs on every PR, and 22 outside people have merged code. Our CEO told the board last week that we'll start selling commercial licenses to banks that can't accept AGPL, starting Q1. Engineering says we're fine because AGPL plus a commercial license is just dual licensing. Walk me through what we need to set up.",
"expected_output": "A flag that the rights are missing: a DCO certifies provenance but grants no relicensing or dual-licensing right, so the 22 contributors' code cannot be sold under commercial terms without their consent or removal. A CLA is prescribed going forward with the reason published, history grandfathered, and the corporate-signature timeline called out.",
"files": [],
"expectations": [
"States that a DCO does not grant the right to relicense or dual-license contributed code",
"States that dual licensing requires the vendor to hold or be granted all the rights, which is why dual-licensing vendors run CLAs",
"Requires consent from the 22 existing contributors, or rewriting or removing their code, before selling commercial licenses covering it",
"Prescribes a CLA for new contributions from a stated date, with existing history grandfathered",
"Requires publishing the reason for the CLA in the contributing guide rather than introducing it unexplained",
"Supplies 'why we ask' wording tied to the specific right, selling a commercial license to customers who cannot accept AGPL",
"States that a CLA is a license grant rather than a transfer of ownership, and that contributors keep their copyright and may reuse their own work",
"States that a corporate agreement covers employer-owned work while mature programs still require an individual agreement from each person on top",
"Warns that corporate contributors sit in their employer's legal queue for weeks and must be told up front",
"Ranks the sales-led levers by revenue reached per unit of trust spent: dual licensing above open core above a source-available relicense",
"States that dual licensing works only when the copyleft obligations are genuinely inconvenient to the buyer",
"Requires the CLA to be enforced by an automated check at merge time, not by memory",
"Makes no assertion about whether any specific contributor's employment contract assigns their work to their employer"
]
},
{
"id": 9,
"prompt": "Two of us, both ex-infra engineers, just raised a seed round for Bellrook. The product is a Go library plus a self-hostable scheduler server in one repo. Three friends have sent small PRs. We have a law firm on retainer and an in-house counsel starting in January. Plan is a hosted commercial version about twelve months out, and we need the repo public in three weeks for the fundraise announcement. What license?",
"expected_output": "Interview questions first, then a posture brainstorm with the ranking stated and the interview answers mapped to the moves they caused. The confirmed business model reverses the value order toward commercial optionality; the three-week deadline pulls against a counsel-drafted agreement, and that conflict is surfaced rather than smoothed. The library and the server are treated as separate artifacts with different trigger events.",
"files": [],
"expectations": [
"Asks about the business model, the hard date, whether this is a per-repository or inherited policy, and the acceptable friction ceiling before naming any license",
"States which interview answer moved which option in the ranking",
"States that a confirmed business model reverses the value order to commercial optionality above reciprocity above maximum adoption",
"States that a hard date promotes whatever needs no counsel, and surfaces the conflict between the three-week deadline and a counsel-drafted agreement",
"Re-ranks explicitly because in-house counsel and a retained firm price the commercial-optionality posture differently from a solo maintainer",
"Presents two or three postures, each as a bundle of license family, contribution policy, and what it forecloses in two years",
"Says explicitly that it is brainstorming and that no recommendation has been made yet",
"Makes the user choose the posture before any specific license is named",
"Treats the library and the server as separate artifacts, the library's trigger being distribution and the server's being network interaction",
"Proposes licensing the two artifacts differently rather than one compromise license for the whole repository",
"Labels the three postures as this skill's own working labels rather than a published taxonomy",
"States that every posture is sticky because published releases keep their terms forever and relicensing needs unanimous consent"
]
},
{
"id": 10,
"prompt": "I'm a senior engineer at Calderbrook Logistics. Over about eight months I built a cron replacement called `sleetline` that we use internally for 40-odd jobs. Most of it I wrote on weekends on my own machine, but a decent chunk happened during work hours on my work laptop when I was waiting on builds. My manager said 'sure, go ahead' in a Slack DM. My contract has a paragraph about inventions that I honestly can't parse. I want to put it on GitHub under MIT this month. Which license and am I clear to do it?",
"expected_output": "The ownership question raised as a step 1 constraint and routed to legal, not reasoned about. No license is named while ownership is unresolved. The manager's Slack message is not treated as a release, the work-hours portion is identified as the exposure, and the specific moments needing counsel are named.",
"files": [],
"expectations": [
"Refuses to interpret the employment contract's invention clause and routes it to the employer's legal team or outside counsel",
"States that code written on an employer's time usually belongs to the employer",
"Raises ownership as a step 1 constraint to resolve before any license preference is discussed",
"Treats employer ownership as a gate that deletes options rather than an option ranked low",
"Does not settle on a license while the ownership question is unresolved",
"Names the moments that need counsel, such as a patent portfolio, an acquisition, a contested contribution, or a live dispute",
"Asks whether the employer has a written open-source policy or an approval process, and treats a manager's Slack message as insufficient",
"Declines to assert what a court would decide",
"Identifies the work-hours portion as the part that may need rewriting, removal, or an explicit release from the employer",
"Explains what each licensing instrument obliges rather than asserting a legal outcome",
"States that a public repository with no LICENSE file is legally unlicensed",
"Avoids jurisdiction-specific claims about employee-invention statutes or moral rights"
]
},
{
"id": 11,
"prompt": "Novaquill is our Apache-2.0 service mesh sidecar, about 6,000 stars. A consultancy in Austin forked it, called their build 'Novaquill Enterprise', put up a landing page and is selling support contracts against it. Two of our own prospects asked us last month whether we're the same company. I want to switch the license so they have to stop. What's the strongest license we can move to?",
"expected_output": "A redirect from licensing to trademark: the license governs the code, the name is what stops the fork calling itself the product. Morgan's framing and Planetary Motion are cited, the trademark is treated as a separate asset with its own policy and lead time, and the license change is shown to be both retroactively useless and unanimous-consent bound.",
"files": [],
"expectations": [
"States that the license governs the code while the name and logo are what stop a fork from calling itself the original product",
"States that Apache-2.0 lets anyone ship a relicensed version, but that the one thing they cannot do is call it by the original project name",
"Attributes that framing to William Morgan during the 2025 Synadia/NATS dispute",
"Cites Planetary Motion v. Techsplosion (261 F.3d 1188) for the point that distributing software freely over the internet can still be use in commerce",
"Recommends treating the name as a separate asset with its own written policy",
"Gives roughly two months of trademark clearance lead time before any public mention, and notes a trademark lawyer's own schedule may override it",
"Labels the two-month figure as a practical guideline rather than a legal standard",
"Notes that a foundation will require transferring the trademark, with the CNCF as the example",
"States that a license change applies to future releases only, so the existing Apache-2.0 releases stay forkable",
"States that no license stops a competitor willing to comply with it",
"States that relicensing now would need the consent of every copyright holder whose code is still present",
"Declines to advise on whether the consultancy's specific use infringes, routing that to counsel"
]
},
{
"id": 12,
"prompt": "Thornerly ships `pulsecore`, a C++ signal-processing SDK. Our customers are appliance makers: they compile it statically into firmware that runs on locked-down devices they sell to hospitals, and the firmware is signed so nothing else boots. Right now it's proprietary and we license it per unit. We want to open it up so the fixes our customers make come back to us instead of sitting in their trees. LGPL-3.0 looks right to me since it's a library. Confirm and I'll start the paperwork.",
"expected_output": "A flag that LGPL-3.0 lands its heaviest obligations exactly on this customer base: static linking pulls relink duties onto the application and v3 adds installation-information duties on locked devices, which makes signed hospital firmware a deleted market rather than a slower sale. MPL-2.0 is offered as the file-level alternative, with the FSF's own LGPL recommendation named as the published position and MPL-2.0 labelled as this skill's alternative.",
"files": [],
"expectations": [
"States that LGPL lets proprietary applications link but requires recipients to be able to swap in a modified library",
"States that dynamic linking keeps the relink obligation simple while static linking pulls it onto the application",
"States that LGPL-3.0 raises installation-information duties on locked devices",
"Identifies the customers' signed firmware as where the obligation lands, making those accounts a deleted market rather than a slower sale",
"Offers MPL-2.0 as a file-level copyleft alternative where static linking into a proprietary product is fine and only modified MPL files must be published",
"States that MPL section 3.3 permits combining with GPL, LGPL or AGPL code unless Exhibit B marks the file 'Incompatible With Secondary Licenses'",
"Attributes the LGPL recommendation for a library facing an entrenched non-copyleft competitor to the FSF, and labels MPL-2.0 as this skill's own alternative",
"Matches the family to the artifact's trigger event, distribution of a linked work",
"Declines to rank the candidate licenses inside the posture by efficiency, because the trigger event and the constraints determine the choice",
"Notes that GPL-3.0 adds anti-tivoization terms relative to GPL-2.0",
"Treats 'or any later version' as a separate decision that hands the license steward a future say",
"Refuses to draft a custom linking exception or a modified LGPL"
]
}
],
"trigger_queries": [
{ "query": "MIT or Apache-2.0 for a new Go library?", "should_trigger": true },
{ "query": "which open source license should I pick for my project", "should_trigger": true },
{ "query": "we're open-sourcing an internal tool next week and I don't know what to put in LICENSE", "should_trigger": true },
{ "query": "should we require a CLA from contributors", "should_trigger": true },
{ "query": "DCO vs CLA, which one do we go with", "should_trigger": true },
{ "query": "how do I add a Signed-off-by requirement to our repo", "should_trigger": true },
{ "query": "is AGPL actually going to stop AWS from reselling our server", "should_trigger": true },
{ "query": "we want to move from Apache-2.0 to BUSL for the 3.0 release", "should_trigger": true },
{ "query": "how do we relicense a project that already has outside contributors", "should_trigger": true },
{ "query": "can we still call it open source if we switch to SSPL", "should_trigger": true },
{ "query": "BUSL or FSL for our situation", "should_trigger": true },
{ "query": "our repo has no LICENSE file, what do we put there", "should_trigger": true },
{ "query": "does our dependency graph let us ship under Apache-2.0", "should_trigger": true },
{ "query": "we have a GPL library in our build, what does that mean for what we can ship", "should_trigger": true },
{ "query": "is our repository's licensing set up correctly", "should_trigger": true },
{ "query": "where do SPDX headers go and do we actually need them", "should_trigger": true },
{ "query": "do we need a NOTICE file", "should_trigger": true },
{ "query": "I want to stop cloud providers from reselling our database", "should_trigger": true },
{ "query": "should we dual license this", "should_trigger": true },
{ "query": "how do we sell a commercial license of our AGPL server", "should_trigger": true },
{ "query": "we want to add a clause to MIT saying no AI training on our code", "should_trigger": true },
{ "query": "can I write my own license", "should_trigger": true },
{ "query": "our docs are under the same license as the code, is that a problem", "should_trigger": true },
{ "query": "what license for a monorepo with code, docs and examples", "should_trigger": true },
{ "query": "somebody forked us and is selling it under our name", "should_trigger": true },
{ "query": "how do we protect our project name from a fork", "should_trigger": true },
{ "query": "our contributor's employer is asking about patent grants", "should_trigger": true },
{ "query": "MIT doesn't have a patent grant does it", "should_trigger": true },
{ "query": "our customer's policy says Blue Oak bronze or better, what does that mean for us", "should_trigger": true },
{ "query": "which licenses survive enterprise procurement review", "should_trigger": true },
{ "query": "I wrote this partly on my work laptop, can I open source it", "should_trigger": true },
{ "query": "we're joining the CNCF, what do we need to change about contributions", "should_trigger": true },
{ "query": "should we use the Unlicense or CC0", "should_trigger": true },
{ "query": "LGPL or MPL for a library our customers link statically", "should_trigger": true },
{ "query": "is Apache-2.0 compatible with GPLv2", "should_trigger": true },
{ "query": "can we pull GPLv3 code into our Apache-licensed project", "should_trigger": true },
{ "query": "what happens to old releases when we change the license", "should_trigger": true },
{ "query": "contributors are angry about our new license, what now", "should_trigger": true },
{ "query": "how long does a license change actually take", "should_trigger": true },
{ "query": "write the announcement for our license change", "should_trigger": true },
{ "query": "our lawyer wants a contributor agreement, is that overkill", "should_trigger": true },
{ "query": "do contributors need to sign anything before we merge their PR", "should_trigger": true },
{ "query": "how do I enforce sign-offs in CI", "should_trigger": true },
{ "query": "a first-time contributor's PR is failing the sign-off check and they're stuck", "should_trigger": true },
{ "query": "we want improvements to come back instead of being closed up", "should_trigger": true },
{ "query": "we're a product-led dev tool, would FSL kill our funnel", "should_trigger": true },
{ "query": "what exactly is fair source", "should_trigger": true },
{ "query": "delayed open source publication, is that a real thing or marketing", "should_trigger": true },
{ "query": "Elastic and Redis both changed licenses, what actually happened after", "should_trigger": true },
{ "query": "what should we learn from the OpenTofu fork", "should_trigger": true },
{ "query": "should we go copyleft", "should_trigger": true },
{ "query": "is GPL too aggressive for a client SDK", "should_trigger": true },
{ "query": "what stops a competitor from closing up our code", "should_trigger": true },
{ "query": "our procurement team filters on OSI approval, does that rule anything out", "should_trigger": true },
{ "query": "help me write a licensing decision record", "should_trigger": true },
{ "query": "document why we picked this license so nobody reopens the argument next quarter", "should_trigger": true },
{ "query": "I'm nervous about the legal side of pushing this repo public", "should_trigger": true },
{ "query": "what do I need in the repo before making it public so we're covered", "should_trigger": true },
{ "query": "someone opened an issue asking why there's no LICENSE file", "should_trigger": true },
{ "query": "legal rejected one of our dependencies, what are our options", "should_trigger": true },
{ "query": "we need to change what we ask contributors to agree to", "should_trigger": true },
{ "query": "our project is MIT but we want to start charging some users", "should_trigger": true },
{ "query": "can we restrict our software so competitors can't host it", "should_trigger": true },
{ "query": "our copyright notice lists five people who left the company", "should_trigger": true },
{ "query": "how should we credit contributors in the copyright line", "should_trigger": true },
{ "query": "is it a problem that we pasted our company name into the LICENSE text", "should_trigger": true },
{ "query": "we forked something MIT, what do we owe the original authors", "should_trigger": true },
{ "query": "should the SDK and the server have different terms", "should_trigger": true },
{ "query": "should we open source this product at all", "should_trigger": false },
{ "query": "what should the company open source and what stays proprietary", "should_trigger": false },
{ "query": "who signs off internally on open sourcing a repo", "should_trigger": false },
{ "query": "we need a GOVERNANCE.md", "should_trigger": false },
{ "query": "how do we promote someone to maintainer", "should_trigger": false },
{ "query": "our project has a bus factor of one", "should_trigger": false },
{ "query": "two maintainers are deadlocked on a decision, how do we break the tie", "should_trigger": false },
{ "query": "how do we structure a technical steering committee", "should_trigger": false },
{ "query": "our good first issues get no takers", "should_trigger": false },
{ "query": "nobody contributes to my project, how do I get first-time contributors", "should_trigger": false },
{ "query": "design a first pull request review and recognition loop", "should_trigger": false },
{ "query": "how do we label issues so newcomers find work", "should_trigger": false },
{ "query": "our issue tracker has 900 open issues and no triage process", "should_trigger": false },
{ "query": "write a stale-issue policy for our repo", "should_trigger": false },
{ "query": "how do I close issues without making people angry", "should_trigger": false },
{ "query": "which registries and awesome lists should we target", "should_trigger": false },
{ "query": "adoption flattened after launch, how do people keep finding us", "should_trigger": false },
{ "query": "how often should we cut releases for visibility", "should_trigger": false },
{ "query": "how do we get on GitHub Trending", "should_trigger": false },
{ "query": "plan our Show HN post", "should_trigger": false },
{ "query": "our launch fell flat, what went wrong", "should_trigger": false },
{ "query": "write the Product Hunt copy for our repo", "should_trigger": false },
{ "query": "how should we price the team tier", "should_trigger": false },
{ "query": "what should the free tier limits be", "should_trigger": false },
{ "query": "usage-based or seat-based pricing for our API", "should_trigger": false },
{ "query": "how does a developer tool make money", "should_trigger": false },
{ "query": "open core or managed cloud, which business model fits us", "should_trigger": false },
{ "query": "adoption is high and revenue is flat, why", "should_trigger": false },
{ "query": "should we join the IETF working group for this protocol", "should_trigger": false },
{ "query": "a competitor published a rival spec, how do we respond", "should_trigger": false },
{ "query": "how do we get conformance certification for our implementation", "should_trigger": false },
{ "query": "review my README", "should_trigger": false },
{ "query": "my repo has way too many badges", "should_trigger": false },
{ "query": "nobody understands what my project does from the repo page", "should_trigger": false },
{ "query": "optimize my GitHub profile README", "should_trigger": false },
{ "query": "write release notes for v2.4", "should_trigger": false },
{ "query": "turn these commits into a changelog", "should_trigger": false },
{ "query": "write the upgrade guide for our breaking changes", "should_trigger": false },
{ "query": "how do we deprecate an API endpoint without breaking everyone", "should_trigger": false },
{ "query": "set up sponsor tiers on GitHub Sponsors", "should_trigger": false },
{ "query": "why does nobody sponsor our widely used project", "should_trigger": false },
{ "query": "write our FUNDING.yml", "should_trigger": false },
{ "query": "which brands should we approach to sponsor our open source project", "should_trigger": false },
{ "query": "should we start a Discord for our users", "should_trigger": false },
{ "query": "write a code of conduct enforcement process", "should_trigger": false },
{ "query": "our Discord is dead, how do we revive it", "should_trigger": false },
{ "query": "plan a weekly devlog", "should_trigger": false },
{ "query": "should we publish our revenue publicly", "should_trigger": false },
{ "query": "brief a reporter on our funding round", "should_trigger": false },
{ "query": "we're getting hostile coverage, what do we do", "should_trigger": false },
{ "query": "write an engineering blog post about our storage layer", "should_trigger": false },
{ "query": "restructure our docs site information architecture", "should_trigger": false },
{ "query": "our quickstart takes 40 minutes, fix it", "should_trigger": false },
{ "query": "write a tutorial for our SDK", "should_trigger": false },
{ "query": "what keywords should our docs pages target", "should_trigger": false },
{ "query": "how do we measure devrel impact", "should_trigger": false },
{ "query": "hire a developer advocate", "should_trigger": false },
{ "query": "how much budget should go to conferences next year", "should_trigger": false },
{ "query": "submit a CFP for the platform engineering track", "should_trigger": false },
{ "query": "generate a CycloneDX SBOM in our CI pipeline", "should_trigger": false },
{ "query": "our security scanner flagged a vulnerable transitive dependency, how do we patch it", "should_trigger": false },
{ "query": "add license key validation to our desktop app so trials expire", "should_trigger": false },
{ "query": "review the vendor MSA before we sign with this SaaS provider", "should_trigger": false },
{ "query": "write our privacy policy and terms of service", "should_trigger": false },
{ "query": "negotiate an enterprise procurement contract with a Fortune 500 customer", "should_trigger": false },
{ "query": "which conferences should we sponsor next year", "should_trigger": false },
{ "query": "segment our developer users into personas", "should_trigger": false },
{ "query": "map the developer journey from first visit to production", "should_trigger": false }
]
}
references/business-model-licensing.md›
# Licensing as a business-model lever, and how to change a license
Contents: the three monetizable structures · source-available instruments · Fair Source and DOSP · documented outcomes · relicensing playbook · announcement template.
## The three structures a license can support
**Dual licensing.** The same code under a copyleft license and, for a fee, under a commercial license without those obligations. It only works when the copyleft obligations are genuinely inconvenient - AGPL for server software, LGPL/GPL for a client library where source-disclosure or relink duties collide with the customer's product. The vendor must hold or be granted all the rights, which is why dual-licensing vendors run CLAs (see `contribution-policy.md`).
**Open core.** Permissive or copyleft core plus proprietary add-ons, usually the ones enterprises need: SSO, audit logs, multi-tenancy, support SLAs. The license question becomes where the line sits. Draw it once, publish it, and never move a shipped feature across it toward the proprietary side - that move, not the model, is what burns trust.
**Source-available restriction.** Publish the code, forbid the specific competing use, optionally convert to an open license later. Covered below.
Hosting the software yourself is the fourth model and needs no licensing lever at all: it monetizes operations, not terms. Recommend it before recommending a restriction, because it costs no contributors.
## Source-available instruments
None of these is an OSI-approved open source license: the Open Source Definition forbids restricting a field of endeavour, which is exactly what a non-compete clause does.
- **BUSL 1.1** - three parameters the adopter sets:
- **Change Date**: at most four years after first publication.
- **Change License**: must be GPL-2.0-or-later or compatible.
- **Additional Use Grant** (optional): the production use allowed for free.
Production use outside the grant needs a commercial license until the Change Date.
- **FSL (Functional Source License)** - BUSL with the parameters frozen: two years, converting to MIT or Apache-2.0, no per-adopter use grant. Created by Sentry, framed as "you can do anything with FSL software except economically undermine its producer". Easier for an adopter's legal team because every FSL project reads the same.
- **Elastic License 2.0** - plain source-available terms: no offering the product as a hosted service, no circumventing license keys, no removing notices. No conversion date.
- **SSPL** - copyleft extended to the whole service stack: offering the software as a service obliges publishing the service's management and orchestration source. The OSI board rejected it publicly in January 2021 as a "fauxpen source" license, one whose adopters "claim that their product continues to remain 'open' under the new license, but the new license actually has taken away user rights". This breaches clause 6 of the Open Source Definition by restricting deployment as a cloud service.
- **PolyForm family** (Noncommercial, Small Business, Shield, Perimeter, Free Trial) - short, plain-language licenses when one targeted restriction is really what is wanted, without the parameter machinery.
**Fair Source** (fair.io, 2024) is a definition rather than a license: code publicly readable, usable and modifiable with minimal restrictions protecting the producer's business model, and subject to **Delayed Open Source Publication** - a planned future release under an OSI-approved license. FSL and BUSL satisfy it.
Vocabulary discipline: "source-available", "fair source", "delayed open source". Never "open source". The claim is checkable in seconds and the correction arrives publicly.
## What the documented changes actually produced
| Project | Change | Outcome |
| ------------- | --------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Elasticsearch | Apache-2.0 → SSPL + Elastic License 2.0 (2021) | AWS forked OpenSearch. In 2024 Elastic added AGPL-3.0 as a third option, framed as "adding another option, and not removing anything". |
| Redis | BSD → RSALv2 + SSPLv1 (March 2024) | AWS and Google backed the Valkey fork. Redis added AGPLv3 in Redis 8 (May 2025); its CEO wrote that the change achieved the goal against cloud providers but "hurt our relationship with the Redis community", and acknowledged SSPL is not OSI-approved. |
| HashiCorp | MPL-2.0 → BUSL-1.1 (August 2023), future releases only, SDKs and APIs left on MPL | The OpenTF manifesto gathered over 140 companies and over 700 individuals within weeks; the Linux Foundation launched the OpenTofu fork on 20 September 2023. A 2024 cease-and-desist alleging copied code was publicly rebutted and went no further. |
Three transferable lessons:
- The fork is the predictable response rather than the worst case.
- The community cost outlasts the licensing win.
- The escape hatches everyone uses in practice are the old releases and the permissive SDKs left untouched.
## Relicensing playbook
1. **Establish who must consent.** Every copyright holder whose code is still present, unless a contributor agreement already granted the right to relicense. Mozilla's Firefox relicensing ran 2001-2006 - plan in months, not weeks.
2. **Map the unreachable contributions.** For each: rewrite, remove, or accept that the change cannot cover that code.
3. **Fix the version boundary.** The change binds future releases only; published releases stay under their old terms permanently and can always be forked.
4. **Decide what stays.** SDKs, clients, APIs, examples and documentation are usually best left permissive - they are what keeps the ecosystem intact and the announcement survivable.
5. **Prepare for the fork.** Name who would plausibly lead it, what they would need, and what your response is. A vendor surprised by a fork looks unprepared for the consequence it chose.
6. **Write the announcement before finalizing the decision.** If it cannot be written honestly, the decision is not ready.
Direction matters: moving _toward_ restriction (permissive → copyleft, open → source-available) provokes forks; moving _away_ from it (source-available → OSI-approved) is received well, which is why two of the three cases above eventually did it.
## Announcement template
```markdown
# <Project> licensing change
What changes old license → new license, effective from version X / date Y
What does not change releases up to X, SDKs/clients, docs, the trademark policy
Who this affects the specific use now requiring a commercial license, with an example
Who this does not the uses explicitly still allowed, with examples
Why the concrete commercial situation, named - not "sustainability"
Contributors what happens to existing contributions, what is asked going forward
Alternatives the fork is available; here is the last commit under the old license
```
State the competitor situation plainly. Vague community-protection framing is read as evasion and gets picked apart in public within hours.
references/contribution-policy.md›
# Contribution policy: nothing, DCO, CLA, assignment
Contents: the four rungs · what each buys · enforcement · wording for the contributing guide · institutional positions · failure patterns.
## The four rungs
Numbered by contributor burden, which is a catalogue order and not the order to adopt them in - step 4 of the skill ranks them by what each buys per unit of friction, and starts at the DCO rather than at rung 1.
**1. Inbound = outbound (nothing formal).** Contributions arrive under the project's own license, by the act of contributing - most forges' default terms encode this. Zero friction. It forecloses relicensing without per-contributor consent later.
**2. DCO - Developer Certificate of Origin 1.1.** A short public statement (Linux Foundation, 2004/2006) that the contributor certifies by adding a `Signed-off-by: Name <email>` trailer, produced by `git commit -s`. The contributor asserts they wrote the change or have the right to submit it under the project's license, and that the contribution and the record are public and kept indefinitely. No account, no form, no counterparty to negotiate with.
**3. CLA - individual (ICLA) plus corporate (CCLA).** The contributor grants the project a perpetual, worldwide, non-exclusive, royalty-free, irrevocable copyright license to their contribution - a _license_, not a transfer of ownership. A CCLA covers work an employer owns; mature programs still require an ICLA from each individual on top, and existing bodies of code arrive through a separate software grant.
**4. Copyright assignment.** Ownership transfers to the project or its steward. Maximum flexibility for the steward, maximum burden on the contributor, and the rung practitioners now advise against for new projects. Some contributors simply refuse.
## What each rung actually buys
| Need | Nothing | DCO | CLA | Assignment |
| -------------------------------------------------------------- | ------------------------------ | ------------------------------ | ---------------------------------- | ------------------- |
| Right to distribute the contribution under the project license | yes | yes | yes | yes |
| Auditable provenance claim per commit | no | yes | yes | yes |
| Explicit patent license from contributors | depends on the project license | depends on the project license | yes | yes |
| Right to relicense or dual-license later | no | no | yes, if drafted for it | yes |
| Contributor friction | none | one commit flag | a signature step, minutes to weeks | high, often refused |
The decision reduces to one question: **does the project need rights its own license does not already give it?** Relicensing, dual licensing and selling commercial licenses of contributed code are the real answers. If none applies, a DCO is the ceiling.
## Enforcement
- Automate the check on every incoming change. A sign-off requirement enforced by human memory is not a policy, it is folklore.
- Standard tooling exists on both sides: a bot that fails the check when a `Signed-off-by` trailer is missing, and hosted CLA managers that block the merge until an individual signs or appears on a corporate manager's approved-contributor list.
- Publish the fix, not just the failure. A first-time contributor whose PR is red for a missing trailer needs the exact recovery command in the check output: `git commit --amend -s` then a force-push, or `git rebase --signoff` for a multi-commit branch.
- Grandfather existing history when introducing a policy; never demand retroactive sign-off on merged work.
## Wording to put in the contributing guide
DCO variant:
> This project uses the Developer Certificate of Origin. Add a sign-off line to every commit with `git commit -s`, which appends `Signed-off-by: Your Name <your@email>`. By signing off you certify the statement at developercertificate.org: that you wrote the change, or that you have the right to submit it under this project's license. A missing sign-off fails CI; fix it with `git commit --amend -s` (single commit) or `git rebase --signoff <base>` (several).
CLA variant - the part most projects omit, and the one that decides whether people sign:
> Why we ask: <the specific right the project needs, e.g. "we offer a commercial license of this code to customers who cannot accept AGPL, which requires rights the AGPL alone does not give us">. Signing grants us a license to your contribution; you keep your copyright and may use your own work anywhere else. Contributing on behalf of an employer? Your employer signs a corporate agreement once and maintains the list of approved contributors.
An unexplained CLA reads as a rights grab. A CLA with a stated, checkable reason reads as a business arrangement, and most contributors accept it.
## Institutional positions to cite
- **CNCF charter**: every inbound contribution requires a DCO sign-off and arrives under Apache-2.0; a CLA is optional per project and, when adopted, follows the Apache text. Outbound code is Apache-2.0, documentation is CC-BY-4.0, and project trademarks transfer to the foundation.
- **Apache Software Foundation**: ICLA for every committer, CCLA where an employer's IP is involved, software grants for donated codebases - the reference implementation of a full CLA program.
- **Linux Foundation**: ships EasyCLA precisely because CLA administration is the part that fails; it enforces at merge time with individual, corporate and approved-list workflows.
- **Practitioner consensus** (Karl Fogel, _Producing Open Source Software_):
- A DCO is "probably the minimum amount of CLA a free software project should adopt".
- CLAs "probably offer the best tradeoff between safety and convenience" when the project needs those rights.
- Assignment is not recommended for new projects.
## Failure patterns
- **CLA on a hobby project.** Drive-by contributors abandon the PR at the signature wall, and the maintainer inherits an administrative job with no benefit.
- **Corporate contributors stuck in their own legal queue.** A CCLA needs a signatory who can bind the company; budget weeks, and tell contributors up front so they start early.
- **A policy nobody can find.** It belongs in the contributing guide and in the pull-request template, not in a wiki page from three years ago.
- **Mixing rungs by accident.** Requiring a CLA _and_ a DCO doubles friction for one marginal gain; pick the rung the project's needs justify.
- **Assuming a CLA solves patents.** Check whether the project's own license already carries a patent grant (Apache-2.0, GPL-3.0, MPL-2.0 do; MIT and BSD do not) before adding an agreement for that reason alone.
references/decision-record-example.md›
# Worked decision record, weak version beside strong
Contents: the scenario · the weak record · the strong record · what separates them · artifact checklist.
## Scenario
A four-person company maintains a Go workflow engine. It ships as a library plus a self-hostable server, has 30 outside contributors, MIT today, and is planning a hosted commercial offering next year. Dependencies are all MIT/Apache-2.0 except one BSD-3-Clause parser.
## Weak version - what a rushed session produces
```markdown
# Licensing decision - workflow engine
## Outbound license AGPL-3.0, to protect us from cloud providers reselling our work.
## Contribution policy CLA, for legal safety.
## Notes We'll switch the license before the hosted launch. MIT was too permissive
and we want to keep our competitive advantage.
```
Why it fails, line by line:
- No constraint section, so nobody checked whether the dependencies or the contributors' employers allow the change. The 30 existing contributors are not mentioned at all - and every one of them must consent, since MIT plus no CLA means no pre-granted relicensing right.
- "Protect us from cloud providers" is asserted, not argued:
- No named competitor.
- No statement of what AGPL obliges them to do.
- No acknowledgement that some enterprises ban AGPL in writing - Google's published policy is the checkable example - which may include accounts this project sells to.
- "CLA, for legal safety" hides the real reason (future dual licensing) behind a phrase that reads to contributors as a rights grab.
- "Switch the license before launch" ignores that every published release stays MIT forever - the library is already forkable from the last MIT commit.
- No artifacts, no revisit trigger, no eliminated options. Next quarter the same debate restarts from zero.
## Strong version
```markdown
# Licensing decision - workflow engine
## Artifact & trigger
Two artifacts in one repository. The Go library is imported into users' binaries - the
obligation trigger is distribution. The server is self-hosted and reachable over a network -
the trigger for a network-copyleft license would be interaction, not distribution.
## Constraints
- Shipped dependencies: 41 modules, all MIT or Apache-2.0 except one BSD-3-Clause parser.
No copyleft inbound; no forced outbound license. Verified from go.mod plus the vendor tree.
- Two contributors work for employers with open-source policies restricting copyleft
contributions; both confirmed they can keep contributing under a permissive library license.
- 30 outside contributors hold copyright on code still present. No CLA was ever in place, so
any license change on existing code needs their individual consent.
- Eliminated: GPL-3.0 for the library (kills adoption in the closed-source integrations that
are 60% of current usage). Eliminated: SSPL and BUSL for either artifact (not OSI-approved;
our top three target accounts filter procurement on OSI approval).
## Posture
Commercial optionality on the server, maximum adoption on the library. Split the repository's
licensing rather than picking one compromise license for both.
## Outbound license
- Library: stays MIT. No change, so no consent problem, and integrations keep working.
- Server: AGPL-3.0 for new releases from v3.0. It beat Elastic License 2.0 because AGPL is
OSI-approved and survives procurement filters; it beat staying MIT because a hosted
competitor could otherwise resell the server with no reciprocity.
- Excluded by this choice: enterprises whose policy bans AGPL outright. Accepted, because the
commercial license is exactly the path we want them on.
## Contribution policy
DCO on the library (provenance, near-zero friction). CLA on the server, introduced with v3.0,
with the reason published: we sell a commercial license of the server, which needs rights AGPL
alone does not grant us. Existing history is grandfathered; the CLA applies to new server
contributions only.
## Business model
B2B. The lever is dual licensing on the server: AGPL for everyone, commercial license for
companies that cannot publish their own service source. The competitor addressed is a managed
"workflow engine as a service" offering - named in the internal version of this record. The
library is deliberately outside the lever; it is the distribution channel.
## Artifacts
- LICENSE (MIT, unchanged) at root; server/LICENSE (AGPL-3.0) plus a root LICENSING.md
explaining the boundary, since a root LICENSE would otherwise claim the whole tree.
- SPDX-License-Identifier headers per file, matching each directory's license.
- Collective notice "Copyright The Workflow Engine Authors" replacing three stale personal
notices.
- CONTRIBUTING.md: DCO instructions with the amend/rebase recovery commands, CLA section with
the stated reason, both enforced by a check on every pull request.
- Registry metadata license field updated for the library; container image label for the server.
## Revisit
Reopen if: we join a foundation (their rules override this), a fork of the server gains real
traction, the commercial license produces no revenue within four quarters, or a dependency
adopts copyleft.
```
## What separates the two
- Constraints first.
- Options eliminated in writing.
- Each choice paired with who it excludes.
- One artifact per licensing boundary.
- A stated reason wherever contributors are asked for something.
- A trigger for revisiting.
The strong record is longer only where the extra lines stop a future argument.
## Artifact checklist for any record
- LICENSE files at every licensing boundary, unmodified text, detectable by an automated detector.
- SPDX headers and a collective copyright notice.
- Registry/package metadata and image labels updated.
- NOTICE file if the license requires attribution propagation; third-party notices preserved.
- Contributing guide updated with the policy and its recovery commands.
- An automated check enforcing the policy on every incoming change.
references/license-families.md›
# License families, traits and compatibility
Contents: families and trigger events · per-license traits · compatibility directions · published heuristics · what a license cannot do.
## Families and what triggers the obligation
| Family | Trigger | Obligation | Reference licenses |
| -------------------------- | --------------------------------- | -------------------------------------------------------- | --------------------------------------------------------- |
| Public domain equivalent | none | none | Unlicense, CC0-1.0, 0BSD |
| Permissive | distribution | preserve copyright and license notices | MIT, ISC, BSD-2-Clause, BSD-3-Clause, Apache-2.0, BSL-1.0 |
| Weak / file-level copyleft | distribution of a modified file | publish modified files; larger work may stay proprietary | MPL-2.0, EPL-2.0 |
| Library copyleft | distribution of a linked work | recipients must be able to relink a modified library | LGPL-2.1, LGPL-3.0 |
| Strong copyleft | distribution of a derivative work | whole derivative work under the same license | GPL-2.0, GPL-3.0 |
| Network copyleft | network interaction | remote users count as recipients and can demand source | AGPL-3.0 |
The trigger, not the family name, is what matters. A company can run modified GPL code as a hosted service and publish nothing, because nothing was distributed - that gap is the entire reason AGPL exists.
## Per-license traits worth knowing
- **MIT** - shortest and most recognized permissive license. Silent on patents and on trademarks. Safe default for a small project; leaves every future option open because a sole author can still relicense.
- **ISC / BSD-2-Clause** - functionally MIT with different wording. Choose one and move on; the difference is not strategy.
- **BSD-3-Clause** - adds a no-endorsement clause. Slightly weaker rating in permissive-license reviews because of the extra condition.
- **Apache-2.0** - express patent grant plus patent retaliation (a contributor's patent suit terminates their grant), explicit trademark carve-out, and a `NOTICE` mechanism for required attributions. The default for anything with corporate contributors, patent exposure, or a foundation on the roadmap. Verbose enough that some tiny projects skip it.
- **MPL-2.0** - copyleft per file. Static linking into a proprietary product is fine; modified MPL files must be published. Section 3.3 allows combining with GPL/LGPL/AGPL code unless the author marked Exhibit B "Incompatible With Secondary Licenses".
- **LGPL-2.1 / 3.0** - proprietary applications may link, but recipients must be able to swap in a modified library. Dynamic linking keeps this simple; static linking pulls relink obligations onto the application, and locked devices raise installation-information duties under v3.
- **GPL-2.0 vs GPL-3.0** - v3 adds a patent grant, anti-tivoization terms and clearer termination-cure rules. v2 remains where an ecosystem is pinned to it (kernel-adjacent code). "or any later version" is a separate decision: it future-proofs but hands the steward a future say.
- **AGPL-3.0** - GPL-3.0 plus the network clause. It is a business lever as much as a philosophy: a company unwilling to publish its own service source buys a commercial license instead.
- Some enterprises refuse it outright in writing: Google's published policy says "code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google", and forbids installing AGPL programs on company machines without Open Source Programs Office authorization.
- No credible figure exists for how many companies run that rule, so cite named policies, never a percentage.
- **Unlicense / CC0** - public-domain dedication. Some jurisdictions do not recognize dedication, and some corporate policies reject the ambiguity; BSD-0 or MIT is usually the safer way to say "do anything".
Content that is not code (documentation, specs, media) usually wants a Creative Commons license instead - CC-BY-4.0 is the common choice, and foundations often mandate it for docs. Never apply a code license to prose or a content license to code.
## Compatibility is directional
Ask "can code under A be combined into a work distributed under B", never "are A and B compatible".
- Apache-2.0 → GPLv3 works. GPLv3 → Apache-licensed project does not; the ASF refuses it because GPLv3's authors treat linking as creating a derivative work.
- Apache-2.0 → GPLv2 is **not** accepted by the FSF, which reads Apache's patent-termination and indemnification terms as restrictions GPLv2 does not permit. Mixed dependency graphs hit this in practice.
- MPL-2.0 → GPL/LGPL/AGPL works through MPL §3.3; the combination then ships under both licenses.
- Permissive → anything works, which is precisely why a permissive project can be absorbed into a closed competitor without reciprocity. That is a feature or a defect depending on step 2's posture.
- Copyleft → permissive never works. A single copyleft dependency in the shipped artifact can decide the outbound license before any preference is expressed.
Audit method:
1. Enumerate shipped dependencies, including transitive ones.
2. Separate build-only and test-only dependencies.
3. Check vendored or copy-pasted code.
4. Record each result as an SPDX identifier, so the check is repeatable in CI.
## Published heuristics you can cite
**FSF license recommendations**:
- Programs under about 300 lines → Apache-2.0, because copyleft overhead is not worth it.
- Library against an entrenched non-copyleft competitor → LGPL.
- Library trying to displace a proprietary format → permissive, to buy adoption (the FSF concedes this failed for Ogg Vorbis).
- Library with a specialized capability and no entrenched alternative → GPL.
- Server software → AGPL.
**Blue Oak Council license list** - rates permissive licenses Gold / Silver / Bronze / Lead by drafting quality and patent handling, so a company can write "Bronze or better" into policy instead of maintaining its own allowlist. BSD-2-Clause-Patent is the only Gold; Apache-2.0, MIT and ISC sit in Silver; joke licenses are Lead.
**OSI approval** - the marker most procurement allowlists filter on. If a license is not on that list, expect a bespoke legal review at every adopting company, which is a distribution cost paid on every deal.
## What no license can do
- Stop a competitor willing to comply. Copyleft redirects competition into compliance work; it does not prevent it.
- Protect the project's name. That is trademark, a separate asset needing its own policy; foundations require transferring it as a condition of joining.
- Apply retroactively. Published releases stay under their original terms forever.
- Create adoption. If nothing depends on the project, no clause converts anything.
references/published-findings.md›
# Published findings
Published claims with their sources, the self-set baselines used where no published figure exists, and the claims this skill refuses to make. Read it before quoting any figure, threshold or precedent: a maintainer about to change a license will ask "says who?", and the honest answer differs line by line.
## Sourced claims
| Claim as used in this skill | Source |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
| "Code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google", extending to installs on company laptops without Open Source Programs Office authorization | Google's published AGPL policy, `opensource.google/documentation/reference/using/agpl-policy` |
| SSPL removes rights while claiming openness - "the hallmark of a fauxpen source license is that those who made the switch claim that their product continues to remain 'open' under the new license, but the new license actually has taken away user rights"; the objection is to restricting deployment as a cloud service, against Open Source Definition clause 6 | OSI Board of Directors, "The SSPL is not an Open Source License", 19 January 2021 |
| A DCO sign-off certifies authorship or the right to submit under the project's license, recorded publicly and indefinitely, via a `Signed-off-by` trailer | Developer Certificate of Origin 1.1, developercertificate.org |
| A DCO is "probably the minimum amount of CLA a free software project should adopt"; CLAs "probably offer the best tradeoff between safety and convenience"; copyright assignment is not recommended for new projects | Karl Fogel, _Producing Open Source Software_ |
| Every inbound contribution needs a DCO sign-off; outbound code is Apache-2.0, documentation CC-BY-4.0; project trademarks transfer to the foundation | CNCF charter and IP policy |
| CLA administration enforced at merge time, with individual, corporate and approved-contributor-list workflows | Linux Foundation EasyCLA documentation |
| Under ~300 lines → Apache-2.0; library against an entrenched non-copyleft competitor → LGPL; library displacing a proprietary format → permissive (with the Ogg Vorbis concession); specialized library with no alternative → GPL; server software → AGPL | FSF license-recommendations page |
| Permissive licenses rated Gold/Silver/Bronze/Lead, BSD-2-Clause-Patent the only Gold, Apache-2.0/MIT/ISC in Silver | Blue Oak Council license list |
| The FSF has never treated Apache-2.0 as GPLv2-compatible (patent-termination and indemnification terms); Apache-2.0 into GPLv3 is allowed, the reverse is not | FSF license list and the ASF's GPL-compatibility page |
| MPL §3.3 permits combining with GPL/LGPL/AGPL unless Exhibit B marks the file "Incompatible With Secondary Licenses" | Mozilla MPL-2.0 FAQ |
| BUSL 1.1 parameters: Change Date at most four years after first publication, Change License GPL-2.0-or-later-compatible, optional Additional Use Grant | BUSL 1.1 text and MariaDB's BSL FAQ |
| FSL fixes BUSL's parameters at two years converting to MIT or Apache-2.0; "you can do anything with FSL software except economically undermine its producer" | fsl.software and Sentry's FSL announcement |
| Fair Source is a definition (public readability, minimal restrictions, Delayed Open Source Publication), not a license | fair.io |
| Elastic added AGPL-3.0 in 2024 as "adding another option, and not removing anything" after the 2021 SSPL/ELv2 change produced the OpenSearch fork | Elastic's own announcements |
| Redis moved BSD → RSALv2 + SSPLv1 in March 2024, prompting the Valkey fork, then added AGPLv3 in Redis 8 (May 2025); its CEO wrote the change "hurt our relationship with the Redis community" and acknowledged SSPL is not OSI-approved | Redis's own announcements |
| HashiCorp relicensed MPL-2.0 → BUSL-1.1 in August 2023 for future releases only, SDKs and APIs left on MPL; the OpenTF manifesto drew over 140 companies and over 700 individuals, and the Linux Foundation launched OpenTofu on 20 September 2023 | HashiCorp's announcement, the OpenTF manifesto, Linux Foundation launch coverage |
| Mozilla's Firefox relicensing ran from 2001 to 2006 | Mozilla's relicensing record, recounted in _Producing Open Source Software_ |
| Distributing software for free over the internet can still be "use in commerce" for trademark purposes (_Planetary Motion v. Techsplosion_, 261 F.3d 1188) | US federal case law; the same case underpins `oss-launch`'s trademark-clearance step |
| An Apache-2.0 license lets anyone ship a relicensed version, but trademark ownership means "the one thing you can't do is call that relicensed thing the original project name" | William Morgan, during the 2025 Synadia/NATS trademark dispute |
| Collective copyright notices ("Copyright The <Project> Authors") preferred over enumerated contributor lists | Linux Foundation copyright-notices guidance |
| Per-file licensing information, `LICENSES/<SPDX-ID>.txt`, and `reuse lint` as the CI check | REUSE specification 3.3, reuse.software |
| A root LICENSE file with unmodified text is what automated detection reads; modified or bundled text defeats it | GitHub's licensing documentation (its detector is the `licensee` gem) |
## This skill's own baselines
These are defaults chosen for this skill, never industry standards; say so when you present them, and replace them with the project's own facts when it has any.
| Baseline | Where it appears | How to replace it |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| The six-item pass threshold (full dependency enumeration, recognized and correctly-labelled license, detector-verified LICENSE, automated contribution-policy check, every claim traceable, written reason per eliminated option) | "Pass threshold" | Adopt the adopting organization's own allowlist criteria once you know them - e.g. "Blue Oak Bronze or better", "OSI-approved only" |
| The three postures (maximum adoption, reciprocity, commercial optionality) | Step 2 | A working taxonomy for this skill, not a published one; rename or add a posture when the project's situation needs a fourth |
| "Two or three candidate postures, never one" | Step 2 | Keep the floor of two; the ceiling is a working limit, not a finding |
| The efficiency orderings - postures in step 2, contribution rungs in step 4, monetization levers in step 5 | Steps 2, 4, 5 | Defaults for a project with no confirmed buyer and few contributors; re-rank against the interview answers, and against tooling or counsel the project already has. Fogel's ladder is sourced; the order to climb it in is this skill's |
| Trademark clearance roughly two months before any public mention | "Common failure modes" | Adjust to match a trademark lawyer's own lead time; this is a practical guideline, not a legal standard |
| MIT before Apache-2.0 for a small program, and MPL-2.0 beside LGPL for a library | Step 3, "Fast defaults" | The FSF recommends Apache-2.0 for small programs and LGPL for the library case; this skill softens the first for MIT's brevity and recognition, and offers MPL-2.0 as a file-level alternative. Follow the FSF's own wording when a project prefers a published recommendation |
| The revisit triggers in the worked record (four quarters without commercial-license revenue, a fork gaining traction) | `decision-record-example.md` | Set triggers the project's own board or maintainers will actually act on |
| The entry points in the invocation table (which step each request type starts at) | "Invocation examples" | Plausible routings written for this skill, not observed usage; re-route whenever the user's request spans steps differently |
## Claims deliberately not made
- What a court would decide in any specific dispute, including whether a particular architecture triggers AGPL's network clause.
- Any percentage of enterprises that ban AGPL. Name the published policies instead (Google's), rather than quoting a share of the market.
- Jurisdiction-specific rules - moral rights, employee-invention statutes, enforceability of public-domain dedications. The skill is deliberately jurisdiction-neutral and routes these to counsel.
- Whether a specific employment contract assigns a contributor's work to their employer.
- Any adoption, download or star effect attributed to a license choice.
SKILL.md›
---
name: oss-license-strategy
description: Chooses an open-source project's license and contribution policy as one decision - permissive vs weak, strong or network copyleft, dependency-driven compatibility constraints, DCO vs CLA vs nothing, dual licensing and open core, source-available options (BUSL, FSL, Elastic License, SSPL), and the fork risk of relicensing. Use whenever someone asks which license to pick, whether MIT, Apache-2.0, GPL or AGPL fits, whether to require a CLA or a DCO sign-off, how to relicense an existing project, whether AGPL really protects against cloud providers, or which LICENSE, SPDX and NOTICE files to ship - even if they only voice a legal worry. Not what the company open-sources at all - use samber/developer-relations-skills@open-source-company-strategy. Never legal advice.
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.1"
---
# OSS License Strategy
You are an open-source licensing strategist. Help a maintainer or a company decide - with reasons they can defend in public - which license the project ships under and what it asks of contributors, then produce the files that make the decision real.
Three rules govern everything below:
- **Refuse legal advice.** Explain what each instrument does, what it obliges, and what it has produced for projects that used it. Never assert what a court would decide, never interpret a specific employment contract, and name the moments that need counsel: a patent portfolio, an acquisition, a contested contribution, any live dispute.
- **Argue the license as a distribution decision before an ideological one.** It sets who can adopt the project without asking permission, which companies' legal reviews it survives, and which business models stay available later.
- **Source every claim, or label it as this skill's own default.** The published positions this skill leans on - the FSF's license recommendations and Blue Oak's tiers for family selection, Karl Fogel's _Producing Open Source Software_ for the contribution ladder, the OSI definition for what may be called open source - are named where they are used. Every self-set default is listed in [references/published-findings.md](./references/published-findings.md); never present one as an industry standard.
## Interview
Ask one question at a time, multiple-choice where you can. Stop as soon as you can name the artifact, the dependency situation and the goal - confirm the rest as you go.
**Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.**
1. What is the project, and does it already have a license? (New project, unlicensed public repo, or a change to an existing license - each is a different job.)
2. What ships to users: a library, an application or CLI, a hosted service, a plugin for a host product, a spec or schema, or several of these in one repository?
3. Who wrote the code, and under what circumstances - personal time, employer time, a mix, contractors, an existing team?
4. What are the dependencies, and does any of them carry a copyleft license? (If unknown, that is step 1's job.)
5. Who do you want adopting it: individual developers choosing for themselves, engineers who need company approval, or both?
6. What is this project _for_ - adoption at any cost, becoming the default in its category, protecting improvements from being closed, feeding a commercial product, hiring signal, standard-setting?
7. Is there a business model attached now or plausibly later? If yes: which one, and who is the competitor you fear?
8. Any constraint fixed in advance - an employer's open-source policy, a funder, a foundation you plan to join, a customer's procurement rules, a license your ecosystem effectively requires?
9. How many people have already contributed code that is still present, and can you reach them?
10. Who maintains this in two years, and could they change the license without you? (Succession itself belongs to `samber/developer-relations-skills@oss-governance`; ask only because the answer decides whether a CLA that pre-grants relicensing rights is worth its friction.)
11. Is there a date this has to be settled by - a release, a launch, a customer's review, a foundation deadline?
12. Is this a one-off decision for this repository, or the policy every future repository inherits?
13. What friction can you actually impose: none at all, a commit trailer, a signature wall, an agreement drafted by counsel? And how much irreversibility are you willing to accept?
Questions 7, 11, 12 and 13 set the step 2 and step 4 rankings. Ask them before naming any license, and say which answer moved which option:
- A confirmed business model or a foreseeable relicense promotes commercial optionality and the CLA rung from last to first.
- A hard date promotes whatever needs no counsel.
- A policy meant to be inherited by every future repository promotes the rung that scales without per-contributor chasing.
- An effort ceiling of "no signature wall" deletes the CLA and assignment rungs outright rather than parking them.
If your harness has persistent memory, store the artifact shape, dependency constraints, adopter type, business model and the final decision. Every later release, contribution-policy question and sibling skill re-uses them.
## Step 1 - Find the constraints before discussing preferences
Constraints can eliminate most of the option space in ten minutes; preferences are worthless until they are known.
1. **Enumerate inbound licenses.** Every dependency that ships in the artifact, transitive ones included, plus vendored or copy-pasted code and any AI-generated code with unclear provenance. Distinguish build-only and test-only dependencies from what actually ships - obligations attach to what is distributed. If you can read the repository, do this from the manifests and lockfiles rather than asking.
2. **Check the direction of every combination.** Compatibility is one-way. Read [references/license-families.md](./references/license-families.md) for the direction rules that trip real projects, notably Apache-2.0 with GPLv2.
3. **Surface the ownership question.** Code written on an employer's time usually belongs to the employer. Say this out loud even when the user is "just" open-sourcing a side project, and route it to their legal team rather than reasoning about their contract.
4. **Record fixed external rules.** Foundation requirements, procurement allowlists, ecosystem norms.
Report the constraints as a short list of eliminated options with the reason for each. That list is the most useful thing you produce in the whole session - it is the part nobody can argue with later.
## Step 2 - Brainstorm postures, do not jump to a license
Say explicitly that you are in brainstorming mode and that no recommendation has been made yet.
Present two or three candidate postures, never just one - a single option is a decision announced, not a choice offered. Describe each as a bundle: license family, contribution policy, and what it makes possible or forecloses in two years. These three are this skill's own working labels, not a published taxonomy - rename them or add a fourth when the project's situation calls for it.
Anything step 1 eliminated is deleted here, not demoted: a copyleft dependency in the shipped artifact, an employer that owns the code, a foundation's license rule or a procurement allowlist are legal gates, not options with a poor ratio. Say which posture each gate removed. Ranking never applies to them, and no posture is ever cheaper than a legal requirement.
Default order, with a handful of contributors and no confirmed buyer - `>` means more of that axis:
- efficiency: `maximum adoption > reciprocity > commercial optionality`
- value, if the interview names no business model: `maximum adoption > reciprocity > commercial optionality`
- value, once a business model or a foreseeable relicense exists: exactly reversed - `commercial optionality > reciprocity > maximum adoption`
- effort: `commercial optionality > reciprocity > maximum adoption`
- compliance cost: `commercial optionality > reciprocity > maximum adoption`
| Posture | Bundle | Effort, friction and reversibility | What it buys |
| ----------------------------- | ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| **1. Maximum adoption** | permissive license, inbound=outbound, monetization deferred to hosting or support | near-zero: one file, no contributor step, no counsel. One-way, though - with no agreement on file, tightening later needs every copyright holder's consent | the widest adopter set and the fewest enterprise legal reviews to survive |
| **2. Reciprocity** | strong or network copyleft, DCO, commercial licensing left open only if a CLA is added now | near-zero for you, a real review for each adopter; a network-copyleft ban at a target account is a deleted market, not a slower one | improvements come back, and a closed fork stops being free |
| **3. Commercial optionality** | copyleft or source-available core, CLA, an explicitly drawn proprietary boundary | the largest: an agreement drafted by counsel, a signature wall on every contributor, and a standing job handling corporate signatures | the only posture that keeps dual licensing and a later relicense available without a consent campaign |
Rows 1 and 2 tie on your own effort - both are a file and a commit convention - so they separate on where the cost lands: row 1 imposes nothing on adopters, row 2 moves the review onto them. That is why row 1 leads and the tie is not a dodge.
Cheapest is not most reversible here, which is the whole reason to lead with the ratio rather than the price. Every posture is sticky, since published releases keep their terms forever and relicensing needs unanimous consent; row 3 is the expensive one precisely because it buys back the reversibility the other two spend.
The order starves row 3: highest value under a business model, highest effort and highest contributor friction, so it loses every round it is ranked in. Promote it anyway when the interview names a real competitor, a dual-licensing plan, a foundation donation, or a corporate contributor whose employer will require a corporate CLA regardless.
Treat the order as a default, not a law - it moves with the project and with who executes it. Re-rank against what you already know:
- A project that already runs a CLA bot has paid row 3's setup cost.
- An ecosystem where every peer ships one license makes deviation cost adoption on its own.
- A team with in-house counsel prices row 3 differently from a solo maintainer.
Then give your recommendation and the reason, and make the user choose the posture before any specific license is named - a posture chosen after a license is really a license chosen by vibes and defended afterwards.
## Step 3 - Pick the license inside the chosen posture
Match the family to the artifact's trigger event, then pick a well-known license inside it. Never draft, modify, or invent a license - OSI and Fogel make the same point: a bespoke license forces every evaluator's legal team into an unbudgeted review, and license proliferation is a cost paid by adopters, not by the author.
Do not rank the licenses inside a posture by efficiency. The choice is determined, not traded off: the artifact's trigger event and step 1's constraint list decide it, and a ratio placed over that would be false precision dressed as rigour. The defaults below are matches, not rungs.
Fast defaults, for when the constraints leave the field open:
- Small program or library where adoption matters most → MIT, moving to Apache-2.0 once patents, corporate contributors or a foundation enter the picture. This split is this skill's own default - the FSF's recommendation for small programs is Apache-2.0; this skill softens it because MIT is shorter and more widely recognized.
- Library facing an entrenched non-copyleft competitor → LGPL (the FSF's recommendation) or MPL-2.0 (this skill's file-level alternative).
- Distributed application where improvements should come back → GPL-3.0 (FSF).
- Hosted/server software where the SaaS loophole is the whole concern → AGPL-3.0 (FSF).
AGPL's cost has a named, checkable example: Google's published policy states that "code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google", down to installing an AGPL program on a company laptop. No aggregate figure for how many enterprises run the same ban exists - name policies, never a percentage - and ask whether the accounts this project needs are behind one.
The full table - families, per-license traits, patent grants, compatibility directions, and the published FSF and Blue Oak heuristics - is in [references/license-families.md](./references/license-families.md).
## Step 4 - Decide what you ask of contributors
Karl Fogel's ladder from _Producing Open Source Software_ has four rungs: nothing beyond inbound=outbound, a DCO sign-off, a CLA (individual plus corporate), and copyright assignment. His own verdicts on them:
- A DCO is "probably the minimum amount of CLA a free software project should adopt".
- CLAs "probably offer the best tradeoff between safety and convenience" when the project genuinely needs those rights.
- He does not recommend assignment for new projects.
Rank the rungs by what each buys per unit of friction imposed, not by ascending burden, since the cheapest rung and the right one are rarely the same:
- efficiency: `DCO > nothing > CLA > assignment`
- value: `assignment > CLA > DCO > nothing`
- effort, meaning contributor friction and your own administration: `assignment > CLA > DCO > nothing`
- compliance cost: `assignment > CLA > DCO == nothing`
**Start at the DCO.** A commit trailer plus an automated check costs a contributor one flag and you nothing, and it buys the provenance and audit trail otherwise credited to a CLA. It leads on efficiency even though `nothing` is cheaper, because `nothing` buys nothing beyond what the license already grants. The DCO and `nothing` tie on compliance cost - genuinely equal, since neither creates an agreement to draft, store, or produce on request; every other pairing on that axis separates.
**Move up only for a right the license does not grant you.** Relicensing later, dual licensing, and selling a commercial license of contributed code are the real answers. For patents, check whether the license already carries a grant (Apache-2.0, GPL-3.0 and MPL-2.0 do; MIT and BSD do not) before adding an agreement for that reason alone. Delete assignment from the menu for a new project, saying you did and why - Fogel's own recommendation - and restore it only when a foundation the project is joining requires it.
The efficiency order starves the CLA. It is the only rung that preserves relicensing optionality, and it imposes the most friction of anything a reader will realistically adopt, so it loses on ratio every time. Promote it anyway when:
- Step 2 chose commercial optionality.
- A foundation donation or dual-licensing plan is foreseeable.
- A corporate contributor's employer requires one.
State the consequence in the same breath: a CLA on a project with no commercial plan reads as a company reserving the right to change the deal, and it costs drive-by contributions at the signature wall.
The order is a default, not a law. Re-rank it against the project's situation: an existing CLA bot and a legal team make the CLA far cheaper than this assumes, while a project whose contributors are drive-by fixers pays that friction on every single change. Mechanics, enforcement and the wording to put in the contributing guide are in [references/contribution-policy.md](./references/contribution-policy.md).
## Step 5 - Attach the business model, or say there is none
Reach for a licensing lever only when a real business model needs one. Every restriction has a contributor cost, so "no lever needed" is a finding to report, not a failure.
The monetization axis is go-to-market motion, not buyer type:
- **Sales-led B2B** - dual licensing, open core and source-available terms work on organizations that run legal and procurement review. Order them by revenue reached per unit of trust spent - efficiency: `dual licensing > open core > source-available relicense`:
- Dual licensing charges the buyer who needs different terms while leaving the open artifact intact.
- Open core moves a boundary that contributors then argue about.
- A relicense to source-available spends the most trust for the same revenue and is the least reversible of the three, having produced a fork every documented time.
Name the specific competitor being defended against - usually a hyperscaler reselling the software as a managed service. If no such competitor is plausible, the restriction buys nothing and costs adoption.
- **Product-led (PLG) B2B** - the path is individual developer adoption → company contract without procurement. The license must support this handoff: permissive or weak copyleft lets the developer adopt freely, while the company later pays for support, SLA, or proprietary modules. Source-available terms that block the individual developer's free adoption break the PLG funnel. Dual licensing and open core still work but the evaluation metric shifts from "procurement review survival" to "developer adoption friction".
- **B2C / individual-facing** - no license term converts an individual. The license is a trust and distribution decision; money, if any, comes from sponsorship or hosted convenience. Recommend the permissive or copyleft choice that maximizes trust and leave the terms alone.
When the license question is really "how do I get paid for this project", choose the offer first with `samber/developer-relations-skills@oss-monetization`, then return here for the license text. If source-available or delayed-open-source terms are genuinely on the table, work through [references/business-model-licensing.md](./references/business-model-licensing.md): dual licensing, open core, BUSL and FSL parameters, the Fair Source definition, and what each documented license change actually produced.
Enforce the vocabulary throughout: source-available is not open source. The OSI board's own wording for the failure is worth repeating to a user who wants both labels - "the hallmark of a fauxpen source license is that those who made the switch claim that their product continues to remain 'open' under the new license, but the new license actually has taken away user rights". Calling it open source costs the audience the project was built for, and it fails the procurement filters that check OSI approval directly.
## Step 6 - If this is a change, plan it as a change
Relicensing an existing project is a different job from picking a license, with one hard rule: it needs the consent of every copyright holder whose code is still present, unless a contributor agreement already granted that right. Published releases stay under their old license forever, so anyone may fork from the last commit - treat the fork as the predictable response, not the worst case (Elastic, Redis and HashiCorp each got one; the documented outcomes are in the reference below).
Produce a change plan, not just a new license:
- Whose consent is needed and how it will be gathered.
- What happens to code from unreachable contributors.
- The version boundary where the change takes effect.
- What stays on the old terms.
- An announcement that states all of it without euphemism.
The playbook, the announcement template and the documented outcomes are in [references/business-model-licensing.md](./references/business-model-licensing.md).
## Step 7 - Ship the artifacts
A decision that produces no files has not happened. Deliver these in the order below - it is an efficiency order, each item costing minutes and ranked by what its absence breaks - and validate against a real license detector where the harness allows it:
1. `LICENSE` at the repository root, unmodified license text, nothing appended - no file means the project is legally unlicensed, and a modified file defeats automatic license detection.
2. For a mixed repository, the per-directory boundary written down - a single root LICENSE silently claims documentation, assets and examples too.
3. The contribution policy in the contributing guide, with the exact sign-off or signature step spelled out, and its automated check - a policy enforced by memory is not enforced.
4. Package/registry metadata license fields, and container image labels where they apply - registries display and filter on them.
5. `SPDX-License-Identifier` headers and collective copyright notices ("Copyright The <Project> Authors") rather than an enumerated contributor list.
6. A `NOTICE` file when the license requires attribution propagation, and preserved third-party notices.
## Invocation examples
Not every request needs all seven steps. Match the request to the entry point, and say which steps you are skipping and why.
| The user says | Where you start | What you hand back |
| ------------------------------------------------------------------------- | ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| "I'm open-sourcing an internal Go library next week - MIT or Apache-2.0?" | Step 1, then straight to step 3 | Constraint list, the two-option comparison decided on patents and corporate contributors, the LICENSE/SPDX/metadata artifact set |
| "Should we require a CLA?" | Step 4, after one question about commercial plans | The rung, the specific right that justifies it (or the finding that none does), the contributing-guide wording and the automated check |
| "We want to stop AWS reselling our server" | Step 2 - the posture is the real question | Two or three postures with what each forecloses, the named-competitor test, and the fork precedents if source-available survives it |
| "Move us from Apache-2.0 to BUSL for the 3.0 release" | Step 6, with step 1 run first on contributor consent | Consent map, version boundary, what stays permissive, the announcement draft, the fork you should expect |
| "Which license does our dependency graph allow?" | Step 1 only | Enumerated inbound licenses and the eliminated outbound options with a reason each - constraints only, no recommendation |
| "Is our repository's licensing set up correctly?" | Step 7 | Artifact audit against the checklist, each gap with the exact file and location to fix |
Run the full sequence when the answer to "what is this project for?" is open, or when the request is a license change on a project with outside contributors - those are the two cases where a shortcut produces a decision that gets reversed in public.
## Output shape
Produce a license decision record the project can commit alongside the code:
```markdown
# Licensing decision - <project>
## Artifact & trigger what ships, and what event the license's obligation attaches to
## Constraints dependency licenses, employer/foundation rules, eliminated options
## Posture the bundle chosen in step 2, and what it forecloses
## Outbound license the license, why it beat the alternatives, who this excludes
## Contribution policy nothing / DCO / CLA, the reason, the enforcement mechanism
## Business model the lever used or explicitly not used, and the competitor it addresses
## Artifacts files to add or change, with their exact locations
## Revisit what would justify reopening this (a business model, a foundation, a fork)
```
Present the record section by section and get agreement before continuing. A wrong constraint at the top invalidates every line under it, and it is far cheaper to catch at heading two than at heading eight. A full worked record, with a weak version of the same decision beside the strong one, is in [references/decision-record-example.md](./references/decision-record-example.md).
## Pass threshold
These six checks are this skill's own bar, not a published standard. Say so when you report against them, and swap in the adopting organization's real criteria whenever you know them (a "Blue Oak Bronze or better" policy, an OSI-approved-only allowlist). Iterate until every check passes, then report the result explicitly:
- Every shipped dependency's license is enumerated, and each combination's direction is verified - 100% coverage, no "probably permissive".
- The outbound license is a recognized, unmodified license, and it is labelled correctly: OSI-approved, or source-available and never called open source.
- The LICENSE file is detected as the intended license by an automated detector (or by inspection where none is available).
- The contribution policy has an automated check on every incoming change; a policy enforced by memory is not enforced.
- Every claim in the record is traceable to the license text, a public statement by its steward, or a documented case - no assertion about what a court would do.
- Each eliminated option carries a written reason, so nobody re-litigates it next quarter.
## Common failure modes
- **The license-picker quiz.** Two questions and an answer of "MIT", with no dependency audit. The constraint step is what makes the recommendation survivable.
- **Choosing a license the dependencies forbid.** Discovered at the first release, by a user, in public.
- **AGPL as a magic shield.** It obliges a network operator to publish source; it does not stop a well-resourced competitor who complies, and it disqualifies the project inside enterprises with a written ban (Google's is the checkable example).
- **A CLA with no plan that needs one.** Pure friction, plus the reputational cost of looking like a rights grab.
- **Calling source-available "open source".** The claim is checkable in seconds, the correction arrives in public, and it fails procurement allowlists that filter on OSI approval.
- **Forgetting the trademark.** The license governs the code; the name and logo are what stop a fork from calling itself your product.
- As William Morgan put it during the 2025 Synadia/NATS dispute, an Apache-2.0 license lets anyone ship a relicensed version, but "the one thing you can't do is call that relicensed thing the original project name".
- Free distribution is no shelter: _Planetary Motion v. Techsplosion_ (261 F.3d 1188) established that giving software away over the internet can still be use in commerce.
- Treat the name as a separate asset with its own policy, cleared roughly two months before any public mention (a trademark lawyer's schedule may override this timeline).
- Expect a foundation to require transferring it (the CNCF does).
- **Deciding late.** Every published release stays under its original terms forever, so a licensing lever pulled after adoption arrives is mostly symbolic.
- **Silent scope creep in a mixed repository.** Docs, examples and assets inherit the root LICENSE unless the boundary is written down.
## References
- [references/license-families.md](./references/license-families.md) - families, per-license traits, compatibility directions, and the published selection heuristics.
- [references/contribution-policy.md](./references/contribution-policy.md) - DCO vs CLA vs assignment: what each grants, enforcement, and contributing-guide wording.
- [references/business-model-licensing.md](./references/business-model-licensing.md) - dual licensing, open core, source-available and delayed-open-source terms, plus the relicensing playbook and documented outcomes.
- [references/decision-record-example.md](./references/decision-record-example.md) - a full worked decision record, weak version beside strong version.
- [references/published-findings.md](./references/published-findings.md) - which claims are sourced and where from, which numbers are this skill's own defaults, and what it refuses to assert.
- samber/developer-relations-skills@oss-governance - decision rights and succession once the license is set.
- samber/developer-relations-skills@oss-contributor-onboarding - the contributing guide the policy lands in.
- samber/developer-relations-skills@devtools-business-model - the model the licensing lever serves.
- samber/developer-relations-skills@oss-launch - trademark clearance timing and for announcing a licensing change during a launch window.
- samber/developer-relations-skills@tech-press-relations - the license-change press playbook and the hostile-coverage precedent to plan against.
- samber/developer-relations-skills@oss-distribution-strategy - the channels that will read the license metadata you ship.