I’ve been thinking a lot about Indie Code Catalog and terms for some of my own software projects that I want to offer through Artless Devices. I’d appreciate some thoughts and gut reactions on a standard deal with perms along these lines:
|End Use||Dev Tool||Distributed Component||Service Component|
|Indie Projects||N/A||Pay when Paid||Pay when Paid||Pay when Paid|
|Commercial||Pay Upfront||Pay Upfront||Pay Upfront||Pay Upfront|
“End Use” means you just run the software, as you might play a game. “Dev Tool” means you run the software to make other software. “Distributed Component” means shipping as a library or framework as part of installed or embedded software. “Service Component” means running as library or framework as part of SaaS.
“Pay Upfront” means you’re not licensed for free. You have to buy a license to use beyond trial. “Pay when Paid” means you’re pre-authorized to use and even resell, but you have to pay for licenses once you start getting paid, on advertised terms and pricing. “Indie Project” means projects under the same kind of deal: open code, noncomm free, commercial paid.
Fundamentally, I feel noncommercial-free, commercial-paid with open code best reflects the change we need in the industry. Those taking money in should be paying over to the devs whose work they build on, and we shouldn’t have to forfeit the quality and process benefits of openness to get there. But striking out with non-comm terms has been a pretty lonely road to date. It’s hard for it to feel like a movement, rather than just a growing trend of ever more disconnected data points.
I think part of that was the framing trap License Zero fell into. Depending on how it’s presented, it can feel like dividing software developers into castes: those who sell and those who buy. The insight underlying the short-lived “strictEq” rebranding was that every dev buying a business-use license is a potential seller of business-use licenses, too. The new deal is just. Sound financial footing is just as important for the projects I depend on as for my own projects.
That addresses the individualistic part of the story, striking out from the pernmissive-open pack. But I don’t think it addresses another key regression in the collective experience: noncommercial projects don’t allow permissionless development like permissive and copyleft projects do. There isn’t the same accretive, network-growing effect to feel a part of as with permissive or even strong-copyleft code.
You can’t take a noncommercial dep and make more noncommercial projects with it if you also want to sell commercial-use licenses. That’s a business, and therefore commercial. So you have to go buy a commercial license for the dep first. Big-picture, you might be working with that deps’ developers to make noncomm licensing more of a thing. But in lived individual experience, the more noncomm succeeds, the more often you’re across from other noncomm devs on licensing deals.
The solution isn’t just to make noncomm devs a posse, and have them give each other free passes to use each other’s work. That’s the exact opposite of the principle we’re after. But there’s nothing to stop us making follow-on development permissionless to start, subject to a requirement to pay across once money’s being made. We can charge royalties, rather than requiring a full license fee upfront. Give permission to commercialize up-front, but require payment later.
Hence the idea for the new deal outlined in table up top:
- keep giving folks who can’t or shouldn’t pay free use
- keep allowing free trials, since that’s good business and is going to happen whether we allow it or not, putting the code out there
- keep requiring big commercial and proprietary users to buy licenses
- but carve out a special deal for other devs doing the same kind of business, which lets them use, build on, and distribute without asking permission first, so long as they pay if and when they make money
The hardest part of implementing that deal in license terms is going to be the mechanisms for determining pricing and terms that fellow indies can rely on. But we’ve got quite a lot of learning from Big Time and XLC to draw on there.
But more generally:
Does this approach make sense as a movement-building tool?
Does Pay when Paid make sense for all categories of uses—tool, distributed, and service?