Summary of Planned Changes (L0 -> stricteq)

I recently sent the following summary of changes coming to platform to @aredridel, who I see just accepted her invite to this forum, too!

So I have someplace to link folks to, and to double down on my openness to feedback, here are the relevant parts:

First, I do think I’ll substantially retire the “License Zero” brand. First because I promised to do so in my commitment to users, which has become something of a limitation, both for L0 and the devs it wants to serve. I also think it’s time to transition from being a strong voice of criticism and harsh realism about the problems in our industry toward advocating more strongly for the better path we’re blazing. I don’t want to go full happy-slappy “enterprise”. I’ll leave that to other platforms. But I want to balance the criticism inherent in what we’re advocating with positive conviction that what we’re advocating is better, and can work.

The leading contender for the new brand is “stricteq”, which came up on the forum. One of the big messages we want to get across is that the model that’s good for us is the same model we’d be glad to see helping the developers we rely on. Or, in more License Zero-ish terms, that the platform is really about support, respect, and regard among peers.

Second, I’m planning some incremental changes to the way the platform actually works.

I anticipate that I’ll eliminate the difference between “free for open source” projects and “noncommercial” projects. The overall gist of the deal devs really seem to want boils down to “if you make money on this, buy a license so I make money, too”. I’ve also found that putting the licenses so far forward obscures the fundamental social point, and that smart, earnest folks trip up and get confused by the choice of license.

I also anticipate that we’ll shift from keeping all transactions fundamentally private to putting each customer who buys a license on the project’s platform page, OpenCollective-style. For one, this helps build social proof, both for the projects and for the platform. And for two, it adds a new layer of accountability.

Fundamentally, the business model works on the honor system. Devs aren’t going to police every company and website on earth to root out people who use their work without buying licenses. But we can hold others accountable by checking online if they’ve supported those whose work they’re using. On the flip side, I like the idea of a profile page where I can show how many developers I’ve personally supported.

Finally, I think the new platform has to take a much more proactive role in helping developers promote their projects and the fact that there are licenses for sale. Rather that promise not to promote projects unless devs ask me to, I think the website itself needs to constantly showcase the projects for sale. We also want to maximize blog, social media, and the like by default.


Something to think about here is to mix and match this with Open Collective, Patreon, and/or Github Sponsors directly. stricteq is a mechanism for handing out licenses. None of those other platforms do that, but they all do take in money as well as provide social visibility.

So basically, I don’t think you should over balance on the social layer, think of the unique pieces here, and how that interacts with and lifts up those other platforms as well.

Thinking more on this, only Patreon offers a patrons-only communications channel. Does stricteq want to help host a Discourse forum where developers can optionally communicate with license holders? (that’s an extreme example, but also … super useful, since an entire Discourse per software library may be overkill?)

I do know that even if stricteq doesn’t want to run such a thing, webhooks that enable this for Slack, Discord, and Discourse would be welcome. I know the various Kickstarter / Backerkit / FigCo things now enable that.


So what is the roadmap going forward?

Is the new changes just making a platform for selling custom licenses?

For example:

  • project x uses restrictive license a for free, but sells license b through the platform
  • project y uses restrictive license c for free, but sells license d through the platform

From the suggestion above by @boris seems selling could even be as simple as:

  • receiving x in total via any supported payment platform
  • receiving x a month via any supported payment platform

With also license expiry options.

Such a platform could even offer a catalog of the restrictive licenses, the purchasable licenses, and an integration form. And a discussion forum as @boris suggested and as what is happening here, for developing new licenses and discussing integrations.

All with the social signal portfolio of who is on the platform, how much are they earning, who is paying, what are the most popular licenses, etc etc

Many projects earn money indirectly- eg. Loss leaders.

Projects like React is a FOSS project, however it is still a project by a commercial entity treating it as a product with a business investment vs liabilities sheet - it earns facebook money, not just from technical savings, but branding prowess, easier recruitment, larger talent pool, larger free workforce, the list goes on, all of which Facebook would have on their internal cost analysis sheet.

When it comes to earning money from it, it is purely whether the entity behind it is a business, be it for-profit or non-profit.

However, personally that is far less important to me than the open vs closed axis; which is an axis about competitive leverage; a commercial company that is open-sourcing it’s contributions and consuming project is still playing fair and maintaining your competitive leverage, even if they don’t pay you, as open-source guarantees a fair competitive landscape due to ease of forking/competing on the same shared/mutual foundations/shoulders. It is only the secret keeping of closed-source usage that steals competitive equality from you, with them having way more competitive leverage in their secrets.

1 Like

This has definitely come to mind. The clearest manifestation is probably the patron license that I published a while back, which ties license rights to patronage on a subscription platform. And I’ve taken to pointing out how successful patronage-model developers often use the patronage platform more or less as a general-purpose payment processor, offering substantial “perks” both on and off the platform.

That said, I do think it worthwhile to emphasize some differences:

  1. The platform isn’t using perk “exchange” as a dodge around money transmitter rules that apply to platforms that just move money from one person to another. (RIP Gratipay) We’re not tacking on “things you’re paying for” to facilitate donations. It’s all about paying for things.

  2. We’re still thinking one-off, perpetual licenses, not subscriptions. At least in terms of what the platform itself facilitates.

In total agreement there. I don’t want to administer a general-purpose customer-relations platform or social network. Rather, I want to move toward transparency by default, rather than confidentiality by default. Projects featured on the homepage. Profile pages listing developers’ projects for sale, as well as the projects they’ve supported. Lists of customers on project pages.

I think that information will have social effects. But I’m not keen to try to draw more social behavior onto the platform.

Webhooks are definitely on the roadmap.


Perhaps I should have said “if you make money onwith this, buy a license so I make money, too”. The intent is to sweep broadly.

1 Like

Overall, I really like this, especially the idea of publicly displaying who has purchased a license. Maybe some would want to keep a purchase private, but there could be a private option with additional cost.

I’d still like to sell perpetual licenses, with updates on subscription as the default at checkout.

Organization accounts also appeal. A company could purchase licenses, and then assign them to their developers.

I’m not ready to sell yet, so don’t prioritize the above for my sake. It makes sense to build the features that a subset of devs need, make them happy, and slowly expand the functionality and user base.


Thanks, @orlandohill. I like how this is shaping up, and the implementation is coming along well.

These things have a way of getting more complicated in practice. But I like how small it seems right now, on paper.

1 Like