Question from a Friend

#1

An old friend asked me this about the new platform:

I do wonder about how paid licenses map to people in this new version. For l0 that was unclear to me. Is it a “seats” model, does everyone who touches a codebase need one or just the people working on that “part”?

He asks the best questions. Here was my e-mail reply:

Your question on the licensing model is a good one. Unfortunately, the strictly correct answer is “if you’d otherwise infringe copyright, you need a license”. But we just don’t know all of the boundaries of that law, much less in all software contexts. I can’t plainly state the boundary with total completeness, because it’s not sharp or compete to begin with.

The history there is basically that site licenses were invented to avoid the fuzzy question of who needs a license. Literally everyone “on site” wherever the machine with the software sat—and therefore stood liable to be used—would be covered. People tended to work on one site daily and indefinitely. From there, seat licensing used to be an extension from there where clarity was practical—on how many machines will you install it?—but now routinely structures SaaS deals, where it may not make any sense. I believe it cropped up after the shift from mainframes to PCs.

My immediate plan was to support fully automated “single seat” or “individual” licensing on the platform. This is essentially what L0 did. Individual users and devs can buy this way. As for groups, the summary description, outside the license itself, would be that if your dev team is using something in its project past a trial, everybody better go ahead and get a license. Which will cover them for other projects, as well.

Since the software’s publicly available to begin with, buying licenses is essentially on the honor system. Inevitable uncertainty would point toward buying a license, especially in situations where it matters, like work for large companies.

I could also support company-wide licenses. My thought there was to publish a form and allow developers to manually list companies on their project pages, as the site automatically lists individual customers. That way they could choose whether to publicize the license or not, and also try subscriptions rather than perpetual licenses where they can.

#2

Yeah this always seemed confusing and complicated.

This is how Tailwind UI does it IIRC. There’s sort of a per project thing in here that J might need to look at again.

#3

I wish I could see a way to cut this down. The “right” answer is “if you’re doing anything that needs copyright permission, you need a license”. But if you ask me what requires copyright permission, I actually can’t state it too clearly. In copyright law, it’s all about whether you’re making copies or “preparing derivative works”. But the boundaries especially of the latter in software aren’t written down in stone anywhere.

A looser guide, setting the idea of getting the legal part right entirely aside, could look something like:

  • If it’s an app and you’re using the app, buy a license.
  • If it’s a tool and you’re using the tool, buy a license.
  • If it’s a library, framework, or other kind of software component and you’re maintaining something that uses it, buy a license.

Especially for relaunch and initial push, I really don’t want to be handling company deals on the platform. I’ve done so many of those deals. You really, really want flexibility to get them done, and done quickly. And that flexibility fully justifies a price hike to the point where you don’t want to be paying Kyle and Stripe a cut. Sign a deal and do a bank transfer!

I think L0 did a particularly bad job of showing that this was possible, because it wasn’t really the obvious use case for any feature of the CLI or the website. I provided forms you could use to sign separate deals and issue waivers, so the companies could use the compliance tools.

The idea with 2.0 is to add a specific feature that allows devs who do make “side deals” with companies to add those companies to the big list of supporters on their project’s page. If the company insists on keeping the deal private, the dev can do that. If they’d rather see it as an ad, or the dev really wants to be sure that anyone can look at their page and see whether someone has rights to use their work, they can add them.

#4

You tend to jump to enterprise deals. Not what I mean :wink: I’m a small company and I have 6 people in my team.

Sell me a “site license” or 6 seat or however you want to do it so it’s one transaction.

This is Tailwind UI. They have sold a ton. I bought this team license from them:

image
image750×814 110 KB

#5

Ah. Thanks.

The earliest version of L0 supported company licenses at a few specific tiers of user counts. I think it was something like <=5, <=10, and <=50 users. Something like that. All licenses at those tiers were self-serve. It was only if you needed more that you had to reach out.

The idea was to make sure companies weren’t buying a new license every time they brought on a new person. Most could pick a tier with some headroom. I also wanted to give developers an easy way to price volume discounts. If your single-seat price was $10, you could price the group licenses at $50, $100, and $500. Or you could taper, like $10, $90, $400. It was also fairly straightforward to do “upgrade” discounts. If you buy a license for 10 but need to move up to 50, you can pay the current price of 50 minus the current price of 10.

Organization licenses belonged to the company, not the workers. So if Acme bought a license, you could use the software so long as you worked for Acme, on jobs for Acme. But you couldn’t use it at home or after quitting the company without buying your own personal license. It was a bit like the way some folks will use IntelliJ at work but have their own personal licenses for hobby stuff, or from past stints as consultants.

Does that seem like the right model? Summarizing:

  • Allow developers to price three standardized tiers of organization licenses: 5 people, 10 people, 50 people
  • “Bind” the license to the company, not the workers.
  • Support simple discounts on upgrades for existing organization customers.
  • Add some kind of manual facility to handle licenses for >50 people handled off the platform.
1 Like
#6

Sounds about right.

I think “call us” is a totally fine tier to have and is expected.

Everybody else would prefer to self serve.

1 Like
#7

Examples of usage allowed by the license:
…

  • Creating a web application where the primary purpose is clearly not to simply redistribute the components … that is free and open source, where the source code is publicly available.

…

In simple terms, use Tailwind UI for anything you like except for projects that compete with Tailwind UI and would have a negative impact on our product sales

The governing law is Ontario. @boris, any idea who their lawyer is?

#8

At least one of the founders is Canadian. No idea who the lawyer, is I can tweet at them.

1 Like