Making Open Source economy more viable with dual license collectives

1 Like

Basically TideLift but wanting it to be a non profit.

Arguably IndieCC and Open Collective can be seen sort of this as layer too — although don’t aggregate the paid licensing across projects.

Bundling is a thing that usually happens. Interesting to look at the TideLift bundles vs projects that might choose to work together.

It is truly easier to rewrite parts of a small NPM library licensed under (A)GPL than try to buy a commercial license for it, etc.

I really enjoyed seeing this recognized. But I was disheartened, as usual, that the rest of the post simply accepts it as immutable fact.

If I have one message for coders when it comes to the commercial side of licensing, it’s this: This problem can be attacked and utterly destroyed. Commercial licensing can be standardized, automated, regularized. Developers can “own” the process, with law providing necessary inputs, rather than lawyers owning it.

We did it for free licensing, when no money changes hands. MIT, BSD, Apache, &c. We can do it again for paid licensing. In some significant ways that will actually be easier. The old hard part, payment, is way easier to standardized and automate these days. Then we can start realizing fantasies about companies paying developers for software, rather than hours, at meaningful scale.

PolyForm Project is a project here. So is my forthcoming Fast Path License. We have both devs and lawyers who want this.

As for the broader solution, License Zero was very close to what Dawid proposes. It was also obsessed with the “scaling problem” of paid-license transaction costs for many “small” modules. But rather than assuming high transaction costs and therefore “bundling” many licenses into one painful deal per customer, it attacked transaction costs by standardizing license terms and payment method and automating compliance with software. Customers had to buy from several devs or at several times, but buying each time was exactly the same and fully automated.

On the business and legal sides, “bundling” in this sense is called “blanket licensing”. It’s best known in music, where venues buy licenses from organizations that cover any and all compositions their acts may perform on stage, or that they may play as recordings or over the radio for their patrons.

The best part of blanket licensing is that you can do one deal that covers a bunch of artists, albums, and songs. The worst part of blanket licensing is that you’re also doing a deal for a bunch of artists, albums, and songs you don’t want. There were antitrust and other challenges to this kind of approach here in the USA. Obviously, the licensing organizations survived.

License Zero grew a lot of complexity to address the scaling problem, but never actually grew enough scale so they mattered. Indie Code Catalog evolved the concept from there, simplifying the model and stripping out all the anticipatory scaling infra.

Next time I get a gust of energy for this problem, I’ll pare it back even more. Fundamentally, we can solve this problem with:

  • a standard licensing-based model, like Standard Deal. There are serious choices here,
  • a set of standard free license terms (Free License)
  • a set of paid license terms (Paid License)
  • payment processors devs can use to sell paid licenses for their projects — IndieCC currently integrates Stripe Connect, but I suspect Stripe Links could also work here. What I’m not seeing is any way for Stripe Links to have the customer specify who they are buying the license for during checkout.
  • a big, serious, collective push to promote this approach, involving lots of people who not only proselytize in the abstract, but offer licenses for sale
  • a concerted effort to identify and promote successful projects where and as they arise

Last I checked, Tidelift does one-to-many, “bundle” deals. And they go through corporate procurement processes to do it. But they don’t do dual licensing. They sell other benefits—support commitments, maybe add-on warranties, and so on. Projects could theoretically do both Tidelift and dual licensing, but I haven’t seen an example yet.

Yeah I’m thinking just super rough high level. It’s not the same, just wanted to have the link to TL here as an example of what a corporate / commercial version of this looks like.

I’m very interested in co-op / collective models. But! They have similar activation energy to a corporate model, but usually less up front funding and more collective management required.

1 Like


I’m with you on this. I really do think we’re at the evangelism phase at this point around dual and NC as options.

1 Like

I asked Stripe support about having customers specify whether they’re buying for an organization through Checkout of Links. They confirmed that they do not.

Hi. Author here.

TideLift looks interesting, and possibly in a good position to try something like that. Though right now it does not seem to be in any software re-licensing business.

Non-profit is just my personal preference and advice. The experience tells me that middlemen platform like these, when collective larger than both sides of the exchange they facilitate, can exercise a lot of power, so making them less profit-oriented from the start would be wise.

The way I see it is thinking about what would take my (current and past) employers to pay for Open Source software we were/are using. And it really seems to me that it’s not about money, but about effort and complexity.

No one has time to judge “oh this package is $10/mo, and this one is $15/mo”. No one wants to read things, compare complex terms for each project, worry about sending money to 200 authors, collecting licenses, negotiating deals, track status of things etc. That is the biggest obstacle, and that’s why I think bundling is all that is necessary. Software projects are a commodity that is “to cheap to meter” yet not actually free to produce and maintain.

A software business wants a predictable reasonable bill that it can send one check for and get access to large collection of projects at large from which it can decide which to use as need arise.

That’s why I’m reluctant w.r.t some “generic licensing terms etc” for individual project. As a dev in a software shop I don’t want to be dealing with any of that.

That is why I think intermediary is unavoidable so a N:M communication relationship is replaced with a broker and effective two: N:1 and 1:M communication relationship.


@dpc, welcome! I didn’t expect to see you here, but couldn’t be happier to have you. Feel free to use this forum just like the rest of us do—share, discuss, pitch ideas. It’s good people. And not too many of them at once. ;-D

Back on topic:

I think I understand what you mean about costs of identifying projects. Those are not the same costs as doing a deal for a project after you’ve identified it as important.

I’m most useful in the doing-deals part, so I’m sure I’m looking for reasons to focus there. But in the spirit of sharing, here are two that came immediately to mind:

The first is the problem of “what’s in the bundle?” I think about my retired father, who finally learned to stream movies online instead of just watching TV and going to theaters. Now he’s a walking directory of which streaming service—Netflix, HBO, Disney, Amazon—has which movie or show. I never convinced him to really try Netflix back when that was almost always the answer. Times have changed.

I can’t speak for Tidelift. But I suspect this has a lot to do with how hard they push to sign up every open source maintainer and their brother for their subscription. They wanted to be like young Netflix. But even so, there’s a lot of diversity and competition. If you find a project, they might be on OpenCollective, GitHub Sponsors, Tidelift, Patreon, Liberapay, or some combination. They might take payment directly via Stripe or PayPal or Bitcoin or a donation management service. They might have a little company offering something for sale.

Unless there’s an umbrella group that’s specifically focused on software you’re likely to use, like Cojurists Together for Clojure-based companies, the chances of you bumping into a project and finding out you’ve already got a deal that covers it will be pretty low.

The second is motivation to do a deal in the first place. I rarely see deals made ahead of time, when the benefits are only hypothetical. That’s more like buying an insurance policy than anything else. In business, most of the time, companies buy insurance when someone else makes them. A customer. An investor. A law. By analogy, as a music venue owner, you do your blanket-license deals for performance rights with ASCAP, BMI, and SESAC when their agents knock on your door or send you a threatening letter.

When it comes to deals for concrete benefits, you run into a project that makes sense to use and then you buy a license. Or you adopt a free project and find you need support. The deal is both about the project you picked and the product or service you need and are willing to pay for.

I don’t see a singleton organization taking over representation for all small projects anytime soon. But even if it somehow happened, and the “winner” platform or agency represented pretty much everybody too small to do deals on their own, I suspect they would end up functioning a lot like a standards body in practice. The company would stand in the middle, deciding what can be offered, on what terms, and how to divvy up the dollars. Signing a deal with them would be signing onto this framework of standards.

Either way, I think a good system has to solve both identification costs and transaction costs. That’s why I built metadata standards and a command line tool to compile software “bills of materials” for License Zero. And it’s why I PR’d standard funding metadata into the npm CLI for JavaScript.

Do you think we could solve the identification problem with standards, rather than a centralized organization?

1 Like

Unless there’s an umbrella group that’s specifically focused on software you’re likely to use, like Cojurists Together for Clojure-based companies, the chances of you bumping into a project and finding out you’ve already got a deal that covers it will be pretty low.

I think ecosystems like NPM,, RubyGems - basically different programming languages, etc. would be natural lines to make a bundle. Possibly even some of the package managers and repo hosting could be the same thing, which would provide great experience, and ability for these package managers to fund themselves.

At certain scale one can be almost certain to want to use something. Just like I can be certain that my kids will watch something on Netflix, so I continue the subscription.

Also the system can be tiered to ease the barrier to entry. Including maybe a free tier or something. Especially if all of this was well integrated (built-in) into a package manager.

1 Like

The package managers and their repositories are good thinking. They do seem like natural cleavage points for breaking the open software world into chunks, within which interests are better correlated.

As a lawyer, I’ve advised developers, sponsors, and companies behind package ecosystems. I can’t blab any private conversations, even old ones. But it’s definitely been a recurring dream of package manager people to offer sustainability bundled in. Seeing those package systems funded by loose coalitions of sponsors (RubyGems), acquired by more general platforms (GitHub), or nursed by cash-strapped charities (Carbo) tends to work against that.

I suppose GitHub could add a new corporate-sponsorship product alongside Sponsors, more akin to Tidelift, and segment that by language. Charge some amount and divvy it up among developers based on metrics, ASCAP-style. Maybe even pull all the high earners onto payroll. Microsoft subsidiary as open source developer agency. Strange vibes.

Maybe they just buy Tidelift and promote them first-party.