Iterative Relicensing at Revenue Thresholds

#1

I was recently contacted with an offer to fund the porting of some of my code. I think the assumption was that I was still releasing under a permissive license (MIT). That got me thinking about sponsored relicensing, the idea of being paid to relicense code under less restrictive terms.

What appeals to me now is the idea of relicensing a version of software when the costs of developing and maintaining that version have been met.

The model would look something like this:

  1. The initial software is developed, and the developers keep a tally of their development costs (e.g. time spent multiplied by an hourly or daily rate).
  2. The software is released under a restrictive public license (e.g. non-commercial).
  3. The developers sell exceptions to the restrictive license via a private license (e.g. commercial license). Those who want to use the software under a permissive license can collectively sponsor relicensing by buying private licenses.
  4. When the total sales revenue reaches the cumulative development cost of a version of the software, that version is relicensed under a permissive license.
  5. The developers make improvements to the restrictively licensed software. This can happen regardless of whether a relicensing event has occurred. As with 0., track development costs for the new version.
  6. GOTO 1.

Time spent on unpaid support, and any other maintenance costs, would need to be factored into the total cost of a version of the software.

It might make sense to have clear branding separation between the commercial/non-commercial and permissive versions. Perhaps different code namespaces too. For example, ProductPro and OpenProduct.

I’m hoping that this would result in a win-win situation. Each version of the software could eventually be released under an OSI-approved “open source” license, but only after the developers have been paid what they consider to be a fair rate.

I can’t remember the details of License Zero’s versioning and relicensing, so I’m not sure whether this model would have been compatible.

Other related models that come to mind are Sponsorware, and the Business Source License.

Does anyone have examples of people using this kind of iterative relicensing model?

One potential downside would be, if it’s the kind of software that doesn’t need much on-going development, then this model could result in lower long-term revenue. That doesn’t bother me, personally.

Are there any other obvious disadvantages?

#2

It depends on what you include in “development costs”, but using the most obvious definition, the main problem here is it systematizes zero developer profit. As soon as you break even, you effectively shut down the business. You can get a rate for your time, maybe. But no reward for taking the risk of nonpayment, unless you build a rate of return into the payout calculation. And no reward that your dev work returns above market for success, as through appreciation on stock in a startup.

Another way of saying this is that you’re looking at rates for dev time on other projects and calling that “market rate” for your own. Instead of letting the market actually set those rates by haggling them directly.

The result is a bit like with larger nonprofits. They can’t pay dividends or sell themselves for the benefit of shareholders, but can and do pay substantial salaries and benefits to personnel. See a Linux Foundation 990 filing, for example. Over $5m in collective exec comp for the last year I checked.

Payments for relicensing open projects onto more permissive terms are totally a thing. It’s been done many times. The legal wrinkle is that you need everyone owning copyright in contributions on board. Or CLAs giving some single person or org the right to relicense all the contributions.

1 Like
#3

I guess the term development costs is insufficient. I certainly don’t want to under price myself. I’ll think about ways to factor in the risks when compared to regular “coder for hire” work.

One of the things that appeals to me about this model is that it helps to preempt the motivation for others to start a permissively licensed competitor.

1 Like
#4

Thinking about it, I like the BSL’s time delay in relicensing, I just don’t want time to be the trigger. I’ll add a minimum time delay between when a version of the software is first released and when relicensing occurs.

1 Like