Should License Zero support, or default to, recurring payments?

[kemitchell]

Everybody loves recurring revenue. Nobody likes pricing perpetual licenses.

I can see a few approaches:

1. Process payments one-off, but issue licenses with expiration dates. Teach the command-line interface to read the expiration dates and omit expired licenses from its analysis. Consumers running the tool can tell when they need to re-up their licenses. Need to think about standardized expiration dates. Need to think about warning consumers ahead of expiration.

2. Sign customers up for subscriptions, create Stripe subscription objects, and configure. Need some way of authenticating customers for subscription changes, like cancellation. Need to handle payment failures when cards expire.

[kemitchell]

An additional thought: recurring license processes based on private licenses with expiration dates leaves licensees with the risk that a developer will stop privately licensing their work through License Zero, or at all. Having removed the old automatic waiver, which gave up the copyleft conditions of the license if the develop stopped actively dual licensing, we'd end up with code that's only available for reuse in open source. Some folks may want exactly that, but others I've spoken to would rather the code be used than lay fallow.

[ghost]

Another way to achieve a similar outcome, as came up in the meeting, is to periodically relicense a project under a new vanity/marketing version number to get people to pay for the new version. Old licenses would still be valid, but not necessarily updated for new features or patches.

[kemitchell]

@substack, thanks for summarizing!

To put a slightly finer point on it: A developer can always choose to fork their own project and start work on a new version or direction, under a new License Zero project ID. Licenses for the old project ID will continue to cover the old project, under the old project ID. But users of the new fork will need licenses for the new project ID.

[kemitchell]

I'm closing this for now, though I'm still happy to discuss it with others.

My main takeaway: As I saw going in, recurring payments create a lot of complexity. There are simpler ways to achieve similar results.

[fabianhjr]

Hi @kemitchell, maybe a 'recurring for updates' / 'perpetual for licensed versions' approach could be fruitful? (Rephrasing @substack, removing the forking part you mentioned in the reply)

Eg, a 100/USD month recurring payment gives you a perpetual license to every version released up to that month but not subsequent versions. To only buy one version they would only need to pay one month.

[kemitchell]

@fabianhjr, thanks for weighing in.

The licensing approach you describe is possible to implement with License Zero, assuming you make regular contributions to your project. But I agree it's cumbersome, and would take more explaining than if License Zero offered first-class tooling (and documentation!) for that kind of arrangement.

For more comments on why License Zero does single-payment deals, see my prior discussion with James. If you'd like to go more into depth on your particular proposal, feel free to open a new issue.