Feature Request: One License, different prices for closed/open + commericial/non-commercial

#1

The axis of closed and then commercial are different contributors to competitive threat from their economic incentives.

Companies will often put a dev they have on an open-source project rather than funding an existing maintainer. This makes several companies now have their own independent people working on maintenance, which often results in several commercially backed forks.

Closed companies are playing the economic competitive game with rules that open-source can’t, which is the use of secrets. Secrets are leverage. Secrets inhibit competition by driving the cost of reimplementation up, as the momentum continues internally. To the open-source game, secrets have the same competitive factor as anti-competitive monopolies.

The goal of any sustainable (aka business) model, be it collaborative or competitive, is to gain enough traction and momentum that collaboration and adoption costs less than competition and reimplementation, which is a cost analysis managed by compounding incentives and disincentives.

License Zero provides a way to fairly return momentum from competitive momentum and anti-competitive practices by newly managing the financial incentives and disincentives for the collaborative-competitive threat axis.

For instance, with this proposal, open-source and commercial users fund increased momentum of original maintenance, which in turn, increases the cost of competition (the highest risk comes from initially closed systems within commercial use) as there is more catchup to do and less to gain, feeding back on more license sales from would be closed-source competitors, furthering more original momentum.

Different magnitudes of pricing tiers would make sense depending on the cost of development of the project. A utility library would be a dollar or a few, for all use cases. However an open-source product or large-scale project, which the collaborative incentives are not currently in favour of, rendering most of these projects closed-source in the end, would have much higher costs to wrangle the incentives into a fairness feedback cycle.

Let’s say for a large-scale project that would see a value contribution to adopters of several thousand dollars or more (think a mac app, like photoshop, or a web app, like basecamp), can charge:

  • free for open and non-commercial
  • $500 for private-closed and non-commericial use, as is likely an internal project with limited budget, such as an early-stage evaluation by an individual, or an implementation by a non-profit; this incentivises open experimentation, or where closed maintains competitive value then a financial return to original momentum
  • $1000 for open and commercial, providing a notable return for the received value
  • $1500 for closed and commercial, which provides a $500 incentive for open-sourcing, or a $1500 return to original momentum where closed maintains competitive value

Ultimately the enablement of this feature would reclaim a competitive strategy, that of cost, to original authors, which at their discretion, can be charge differently for their various projects, based on their insights of project usage, project value, and competitive threat, to favour collaborative momentum.

2 Likes
#2

I’d be willing to roll this out to all of Bevry’s open-source packages (over 100, with tens of millions of downloads a month.

It would also enable us to open-source our upcoming large-scale projects (products if we were a for-profit company), which unfortunately are closed-source purely because we do not yet have enough momentum to overcome the risk of competitive reimplementation, especially by companies that can keep secrets when our open collaboration prevents such.

This can enable Bevry to open-source things that would typically be closed, and capitalise on the intrinsic motivation market of open-collaboration while somewhat disarming threat into financial momentum.

1 Like
#3

So other folks know: @balupton brought this up on a call with me, and I was really taken with it. I’d never thought about segementing pricing based on use case like this:

Commercial Noncommercial
Closed $w $x
Open $y $z

My first reaction is that it’s super important for folks to understand that open-closed and commercial-noncommercial are independent variables. @balupton’s obviously way beyond that. But lots of developers aren’t.

My second reaction is a bit of hesitation. I think the roots of it are twofold:

  1. This is complicated. Markus Binsteiner has been an advocate for combining Parity and Prosperity in the past. But I’ve always looked at the resulting license terms and thought, “God, that’s a mess.”

  2. We can and will see use cases shift over time. If I buy a noncommercial-open license for my hobby project, and then somebody funds a startup to commercial it and hires me, do I have to get a new commercial-open license? Simplifying out of this means just charging everybody the commercial-closed price, which means you’ll theoretically “overcharge” at least some users. But they’re free to do whatever from there. And the customer experience remains truly “buy once”.

1 Like
#4

My initial imagination on this, is it would be charged per-use/installation/app rather than per-person/seat. Same model as desktop applications charging per desktop computer (for a desktop app, a single desktop environment is a single installation territory).

There is the question of “can inactive licenses be transferred to new applications?” My initial answer would be no - as that is a different app, and thus, different consumer inputs/outputs as well - it would be double dipping:

App developer makes app A and sells licenses for $10, and paid open-source dev $1 for the library used in App A. Then app developer shuts down app A, and makes app B which also uses the same open-source library used in App A, which has licenses sold for $10, in which the open-source dev should be paid $1 again.

What is noteworthy in that example, is that the app developer earns on each app sale, whereas the open-source dev earns only on each library sale. In the above example, app developer could sell his app 100 times to earn $1,000, yet open-source dev who made the library used in the app still only gets paid $1.

However, this touches on a seperate and optional issue. Seperate, as there are alternative ways of addressing/experimenting with this: e.g. variable pricing (i.e. pay what you want >= X amount), subscriptions (pay monthly/yearly), bundles (i.e. nested bundle, creator bundle, tiered bundle). Optional, as this could be addressed by the open-source dev charging say $200, instead of $1. So app developer is at loss for the first few sales, then is at profit.

Of course, the more complicated and costly the model is, the more paying for it is disincentivized. I’m inclined to do whatever is expedient/convenient first, study the results, then if it turns out the incentive mechanisms need further adaption, add more complexity later.

#5

Thinking about this some more, from a variety of perspectives. I think the easiest model would just be per-seat, which is against the initial thinking in my previous post above.

The seat can be a developer, or be an organisation.

That way, a developer who really likes your software, which is essentially an evangelist that is to be encouraged and supported, can take the licensed software with him to new projects continuing the market share and potentially furthering it.

For per-seat pricing however, the question then becomes what about multi-maintainer projects? Such as the typical organisation project, which is the behemoth of most commercial billing.

Initial thoughts is that multi-maintainer projects then require an organisation seat - be it a github organisation, or a company organisation.

This makes sense from another vector - devs are probably only buying closed non-commercial licenses - companies/organisation on the other hand are probably buying closed commercial license.

One should be able to instantly see the portfolio of projects they own licenses to, for what categories (open-closed, commercial vs non-commercial), and fill in any missing categories in a bulk bill.

Such would also incentivise re-use of what one has already paid for. Which is another competitive advantage: Why use a free unmaintained alternative to project X, when we have already contributed financially via a license purchase toward continued maintenance of project X.

Dividing this ease of use example, by the additional axis of per-app billing, would be daunting and a turn off.

Comparatively, per-seat rather than per-app, I’d imagine would developer a stronger connection between open-source authors and open-source consumers (aka evangelists: those who are the prime movers in getting the license zero software into companies: companies which over time, will grow familiar and routine to purchase license zero licenses for their dependency tree; as is patreon and kickstarter is today to the public, or mongodb commercial licenses are to companies).

However, per-seat pricing does press for a balancing factor of fairness: A company like Facebook could have a dependency used across hundreds of projects, yet without subscription or per-app pricing, would pay only once, which is anti-competitive economics compared to small business and indie devs which would pay the same price for far less usage.

Perhaps the middle-ground would be subscription-pricing, which increases on how many apps you are using. Like how web services charge on usage tiers (e.g. serverless workers). So rather than per-app pricing and complexity, organisations just say, “license me for 5/50/500/5000 apps”

1 Like
#6

Seat Licensing

The idea of a “single-seat license” covering a company won’t make sense to many people in the industry. A “seat license” almost always means a license for an organization that covers more than one person, up to a set number. That number is the “seat count” or “seat quantity”.

Seats may or may not be transferable from individual to individual at will. It’s up to the terms of the license agreement. Usually a seat isn’t bound to any specific individual. The “seat” is something the company has. It belongs to the company, and the company “spends” or “assigns” it for a worker.

Instance Licensing

Per-instance or per-project licensing doesn’t avoid any of the scope-over-time problems that we discussed around commercial and closed use segmentation. If I write a web app for one client, then reuse the same code as a starting point for another client’s app, is that one “project”, two, or three?

Even if we assume the line between one “project” and another is perfectly clear, you will still have people coming back to buy multiple licenses over time.

Simplicity

There are no good licensing models without line-drawing problems. But we can group the major forms of common models in three buckets:

  1. Personal Licenses. You buy a license for Sublime text. It covers your use of Sublime. It doesn’t matter whether you use it for personal projects, for contract clients, or at work, as an employee. These deals are often done self-serve, without any negotiation.

  2. Site Licenses. A company buys a license for Microsoft Office. The license covers people who work for the company. Usually, site licenses come with some kind of upper limit. Per-core licensing was once very common. Now seat licensing probably takes top spot. These deals are often done through procurement departments, through a more or less standardized process.

  3. Product Licenses. A company or individual buys a license a library. The license covers a single product, service, or other integration. The integration is named up front and written into the license. These deals are often done directly by high-level businesspeople and lawyers. If they go through procurement, they’re often handled specially.

In other words, the license “belongs to” a person, a company, or a product. It’s never quite that simple. But if people can’t reduce it to one of those options and get away with it most of the time, the sales process stumbles or fails.

1 Like
#7

Thanks for articulating those differences so clearly.

So how about a form like this:

I, John Smith, would like a personal license for all [x] open, [x] closed, [x] non-commericial, and [x] commercial use across my projects.

Todo: What about co-maintained personal projects - does only one co-author need a license?

We, Org Inc., would like a site license for all [x] open, [x] closed, [x] non-commericial, and [x] commercial use across our projects, in increments of 10 seats. Starting with 50 seats.

Todo: Figure out if seat is per project, per co-author, or interchangeable.

I/we, would like a product license for [x] open, [x] closed, [x] non-commericial, and [x] commercial use within our project XYZ.

With each having different pricing costs for each checkbox.

If a person/organisation has a personal/site license for only open and closed non-commercial use, as that is what they do primarily. They can get a +commercial license for the specific unusual commercial project.

#8

How about I add some sample pricing to all the Bevry packages, and then we have some inputs to figure out what the licensing experience would be like for nested dependencies.

Can add something like this to our package.json files to kick off the experimentation:

{
  "l0": {
    "variation": "balance",
    "cents": {
      "open-noncommercial": 0,
      "closed-noncommercial": 500,
      "open-commercial": 1000,
      "closed-commercial": 1500
    }
  }
}
#9

@balupton, currently, License Zero doesn’t require any information in package metadata, or expect any. If we get to the point where it’s worth revisiting a CLI to automatically detect and process packages that need paid licenses, we may do that again. But right now, it’s a solution to a problem we don’t have.

Back on the licensing model: There’s nothing wrong with the model you proposed. You can certainly license and price your software that way. The question in my mind is whether L0 or its successor service should make that model its default or support it as an option.

I want to stay as open as I can on this. But right now, I’m leaning toward thinking it’s not a particularly great approach, either for the platform or for your projects specifically.

The trouble is the complexity. A lot of us have seen what these kinds of choices do to sales funnels, and it’s not good.

What’s worse, both of the questions that potential customers would have to answer—Is my project commercial? Is my project open?—aren’t easy to answer in many cases, much less over time. “Scene” developers from the free and open community are used to fighting about what is open or not open and used to criticizing noncommercial licenses as vague. Their knee-jerk reflexes will be kick back at the question, and with two feet at a time.

Whenever you let customers decide which license they need or want, as opposed to negotiating with them one by one, you are going to end up with customers who arguably pay too little and customers who arguably pay too much. They will get it wrong in both directions.

In order to spare yourself one-off negotiations, and to spare your customers the chore of figuring out which license is right for them, you can charge a “blended rate” reflecting what you want to charge for each use case and how many of your customers you expect to use in those ways.

For example, if you think you’ll have relatively few closed-noncommercial customers, slightly more open-commercial users, and many closed-commercial users, you can weight your prices thusly:

Closed-Noncommercial 0.2 × $500 = $100
Open-Commercial 0.3 × $1,000 = $300
Closed-Commercial 0.5 × $1,500 = $750
Sum 1.0 =$1,150

Now there is just one question for customers: Do I pay $1,150 or e-mail the developer to see about a special deal?

Overall, I’d expect this approach to decrease the amount of sales-related e-mail you get, since the only e-mails you’ll get about free and open are whether they can use for free or not, not which of the three paid options they need to buy. I’d expect this approach to increase your number of sales, since you’ve removed a substantial stumbling block between clicking the link for your sales page and buying a license.

1 Like
#10

I appreciate the concern.

For npm packages, which is all Bevry does, fortunately the determination of open vs closed can be done automatically by checking if the git repo is accessible, checking the license type, and maybe checking the npm private field. For commercial and non-commercial it can be done by asking the tool runner if the package author field is commercial or non-commercial.

For the lines between those modalities. Here’s a conception of what such a license could look like:

Fair Compete License

Definitions

  • your program: any software you wrote that includes this piece of software, directly or indirectly
  • closed-source: source-code of your program is not available publicly under an OSI license or this license
  • open-source: source-code of your program is available publicly under a OSI license or this license
  • commercial: the primary purpose of your program is to be used within a for-profit organisation
  • noncommercial: the primary purpose of your program is to be used within an organisation that is either non-profit, not-for-profit, a charity, or a hobby/personal endeavour

Terms

This software can be registered for:

  • Free for all use that is noncommercial and open-source
  • $1 for all use that is noncommercial, including open-source and closed-source
  • $5 for all use that is open-source, including commercial and noncommercial
  • $10 for all use, including commercial, noncommercial, open-source, and closed-source

Such registered use also grants license to any necessary patents.

At no point are warranties granted by this license.

For Bevry, I don’t want any sales emails or special deals. I just want a license platform to handle it all and apply the same ruleset to everyone equally.

I’ll continue thinking about the above. Some flaws in it are: resales, selling your program, and whether or not the noncommercial closed-source tier actually makes sense, as why don’t they just open-source it? Leaving the only tiers as free open-source non-commercial, $5 for open-source commercial, $10 for closed-source. So maybe splitting hobby/personal project (free closed use), and non-profit organisation into different tiers makes sense (paid closed use).

Also just throwing ideas out there. These aren’t necessarily requests for L0 or artless devices, just inherently things I wish to experiment with, so foss can receive more competitive momentum.

#11

I’ve been thinking a bit about whether and how to add “allies” projects to the next platform. Projects that are selling licenses, but not through the platform itself.

#12

Been thinking about this more.

Banning closed AND commercial while allowing open or non-commercial can be achieved by dual licensing a project as either parity or prosperity, and letting the consumer pick.

However, there currently isn’t an option to ban anything that isn’t both open and non-commercial.

If there can be a license that does that, then at least that is a starting point.

My goal ultimately is to just enforce the commons sustainably, otherwise pay the rejuvenating fine for diminishing the commons with anti-competitive practices.

Enforcing only the commons, is parity.

Enforcing sustainability, is prosperity.

Enforcing either instead of both is defeating in a world of plagiarism and where secrets = scarcity = money. Secrets need to be defunded and exposed, which is only possible by a combination.

If we can get such a license, then bang, you got docpad and history.js onboard for the experiment.

2 Likes
#13

One of the challenges of this, is whether or not with the “only for non-commercial and open-source” license, if the author is also selling a license for the commercial or closed use cases, then would that count as commercial activity and have to pay the authors of the same license that they consumed and so on?

I think here the philosophical and political goals of such a license needs to find embodiment to make sure integration occurs, and not disintegration into a flawed license.

  1. The revenue from enforcing the commons, are to be viewed as fines, not sales. In the same way speeding fines are issued by the state’s “revenue department”, yet speeding fines are not a sale. The terminology here is important, as it is part of enculturation, just as the state does for traffic violations.

  2. As the “Open Software License” does with its patent pool and invalidating license on patent pursuits, which forces the hand of the eradication of the commons via patents, such a anti-commercial anti-closed pool would be granted by this proposed license, such that those using the same license are exempt from the fine, as it is about manipulating incentives, not manipulating the symptoms of incentives.

This is a lot more challenging than I thought.

Yet it is still vital to me for disinhibiting the proliferation of artificial scarcity. Those charging for real scarcity have nothing to lose by contributing their IP to the commons and thus not paying the fine. It is only those charging for artificial scarcity, the “rent-seekers”, that expand the long-tail of capitalism instead of its rising-tides, that are those who benefit from their secret keeping, who must pay the fine.

Currently those who made it in this long-tail economic model’s advice to those left behind is “be stoic brah”, which is nothing short of a memetic weapon to maintain the system (either considered holy or immutable - those who suffered deserved it in some mysterious way), instead of tackling its shortcomings and supplanting with a different or improved system, such as what blockchain has done to forgery/lying, and crypto has implemented its benefits for money; solving issues like blood diamonds, arbitrary inflation, and bank runs; which blockchain and crypto solve directly from the aether (at the meta-level), which actually offers a truly utopic solution than telling “be stoic brah” to the enslaved miners of Blood Diamonds, and those evicted from their land in Far and Away, or foreclosed with debt in a controlled market of It’s a Wonderful Life.

Secret keeping thwarts the commons by:

  • monopolising competition over open collaboration: in a world where secrets pay, this defunds those who don’t hold secrets, it defunds the commons for the commons sake, where the commons is only a strategic tool of the biggest secret keepers

  • monopolised plagiarism over open collaboration: in a world where scarcity pays, then openness is not currency but the scarcity from it, such as attention, which can be monopolised in open-source by centralising the efforts of the decentralised land grabs in a new frontier, by plagiarising their work and its fragmentised attention into a consolidated monopolised portfolio, achieving a sponsorship and effort cabal, as the scarce resources are now monopolised so the funnel is now controlled.

By fining closed and commercial usage, then that solves the secrets pay issue with the current model by defunding that artificial scarcity and offering a way out (the commons).

the commons here is interesting, as say if Louis Rossman uses an open-source library in his mac repair business, the participating of the commons here is not software but in whatever is the artificially scarce in his industry, such as solutions to hardware fixes. Louis has talked about how the repair industry is in two minds, keep novel fixes secret to have a competitive advantage for a while (artificial scarcity) or open source the fixes via public instructions and streams so that the revenue is from the commons. In software, a company that builds closed software atop of open-software is violating the commons, whereas a company that builds open software atop of open software is not. As such, the definition of commons in the license must span just software.

The unaddressed issue is the monopolisation of sideline scarcity, such as attention. This has these solutions that I can see:

  • communism: anything scarce is illegal and must be distributed evenly, but that then eliminates economies of scale and the benefits of capitalism
  • ubi: have the ass holding the long tail of capitalism pay off those it ejected, however this seems to not have factored in inflationary effects, as it did nothing to address real scarcity, so nothing will change once prices adapt
  • seamless charge all usage: as what flossbank is attempting, however while this does give money to the little guy who wrote something valuable in the commons, it does not stop a monopoly from plagiarising it into their cohort and snuffing him out from the game over time by swallowing the market’s attention
  • plagiarism cohorts within the commons: acknowledge monopolising is inevitable and the only improvement that can be done is offering choice instead of the lack of choice, to the consumer, by having the producers unionise into cohorts that plagiarise each other according to different ideals and technical goals: such as one cohort plagarising everything into esm and latest node only, and then a cohort plagarising everything back into esm+cjs and older node version, and another cohort plagiarising all of that into some other twist, such as different revenue models for distribution within the cohort; giving consumers the choice of any package implemented by a variety of cohorts; somewhat akin to what a fair competitive and free market promises.

I also acknowledge my thinking on this and the justification for such a license needs further work to make less muddled. As it seems what I am really after as an utopic license is a “for the commons” license, as evidently from the above the open-source term and the commercial or profit terms are not suitable as they are too muddy for this philosophical lens, so I need to clear this up more. As should Louis Rossman pay, even if he is furthering the commons? Payment here would help those getting started, but so would joining (plagarism and commercial) cohorts. I will think more on this and what the end goal actually looks like over generations of time. In a world without artificial scarcity, what would one’s relationship and (dis)incentives towards the commons be? And how could they be sustained and facilitated or warred from existence?

1 Like