Thanks for those links!

If I'm interpreting these correctly, you pay once for a license, and get access to all future versions of the library?

Most models for building companies on OSS tend to rely at least somewhat on a service model, rather than selling a piece of software once as a product and then continuing to maintain it for free (relying, then, on continuing to sell new licenses of the same software in order to keep money coming in).

In this case in particular, I feel like this creates misaligned incentives: after someone has already paid me for a license, if they have feature requests or bug reports for me, it's actively against my financial interests to spend time addressing those rather than working on things that will help bring in new paying customers (of course, these two things will sometimes align, but not necessarily). That's presumably most easily fixed by that customer contracting me to make those changes, but at that point I've now got a revenue stream and business model that feels a bit orthogonal to the licensing idea (and would lose all the benefits of e.g. your nice integrated payment system).

Curious if you have suggestions or thoughts about bridging that gap!

Yes. There is some revision going on in the definition of "Work" under the private licensees, but the idea is that if a developer published 1.0.0 to repository A, you bought a private license, and developer published 2.0.0 there later, your private license covers both 1.0.0 and 2.0.0. If they rewrite and push to C, however, that's a new ballgame.

There's no obligation under any L0 form (or any OSS license I'm aware of) to provide any ongoing service. A developer could still offer services---training, support, maintenance, feature adds, etc.---around L0 code.

Speaking of perverse incentives, we see exactly that with pure service-based business models. Why write good doc if you're selling training? Why make it easy to deploy if you're selling installation or hosting? And so on. That _is not_ to say those models can't be done well.

In other words: how to 1) motivate the author to publish project as L0 and 2) motivate the author to keep working on it. Am I right in my understanding of what you are saying?

If "yes" then it is a reasonable question. Some complex projects have quite narrow potential audience to get sustainable cache flow (from new license buyers). But are valuable for those few who already paid.

I run an open core software company. Incentives depends on the complexity of what the software does.

In the "distro" oss companies like cloudera, red hat, us,.. there is usually a lock in component somewhere (usually in the difficulty) but sometimes in a closed source component.

We've had difficulty with "paid extensions" in real practice. The only thing that tends to work is "as a service" or "buy the proprietary part".

I won't comment on the individual developer attempting to sell a JS library. I just want to note how hard it can be for customers to even be convinced of this in the first place. The likelihood of this being a real "revenue stream" for your typical freelance OSS developer building a node library is a stretch at best.

There is still quite some amount of hubris in this.

If A writes software under L0 and gives it to B and is “nice enough” to allow B to use it privately for free, there’s some entitlement to the software.,

You’re overlooking that, in a contemporary environment, you’re standing on the shoulders of the giants (and all the small ones) who came before you. It’s absolutely presumptuous to write code in our time and not publish it under an OSS licence.