Big Time License

[kemitchell]

I’ve been turning attention back to the Big Time License, which never made it to 1.0.0, but should.

The main gist of Big Time is that it’s free for personal and small business. However, it also guarantees that big companies can get paid licenses on fair terms. If the developer stops selling commercial licenses, or refuses to license a particular big company on fair terms, the license becomes free for them, too.

To a near approximation, it’s a FRAND license for software. Similar to the terms on which large companies agree to license any patents they get accepted into a technical standard.

The main question in my mind about the latest draft of the license is whether my attempt to provide more clarity about what counts as “fair” is really worthwhile. Here’s how I defined “fair commercial license”:

A fair commercial license permits the recipient to do everything that a company qualifying under Small Business can do under these terms, for a fair fee, without additional unreasonable terms or terms that discriminate against particular licensees. A fair commercial license may be perpetual or for a term, and may or may not cover new versions of the software.

But I also went further, defining “fair fee”:

A fair fee is a fair market price for a fair commercial license. If the licensor advertises a fee for generally available fair commercial licenses, and more than one unaffiliated customer has paid that price in the past year, that is a fair fee. However, a fair fee may not be more than:

1. on an annual basis, the number of software developers who have made substantial technical contributions to the software in the last four years times one quarter of the annual wage for software developers reported in the most recent Bureau of Labor Statistics Occupational Employment Statistics survey

2. on a perpetual basis, four times a fair fee on an annual basis

In concrete terms, I wonder whether I should just strike the definition of “fair fee” completely, and leave that entirely up to the company and the developer to negotiate.

[Tammy]

Unsurprisingly, the typical cases involving Standard Essential Patents (SEPs) are mostly among huge telecommunications companies, but there are also other industries like automotive that are interesting.

This is the European Association of Automotive suppliers take on the valuation of SEP licences (bolding added for emphasis):

[…] the licensing terms must bear a clear relationship to the economic value of the patented technology also in conjunction with all the other technologies incorporated in the company’s products. This value needs to primarily focus on the technology itself and in principle should not include any element resulting from the decision to include the technology in the standard. While determining a FRAND value, the present value added by the patented technology needs to be considered, irrespective of the market success of a product that is unrelated to the patented technology. FRAND valuation should avoid royalty stacking, and parties need to take into account a reasonable aggregate rate for the standard, assessing the overall added value of the technology, e.g. technology in conjunction with all the other technologies incorporated in the company’s products.

Your method seems to rely on an evaluation of the value of the labor, that I would hope might appeal to small software producers but would be incomprehensible for the interoperability governance wonks, who always seem to prefer the macros[^1] over the micros.

What you do here I think depends a lot on whose politics you want to advance, the local little fishes or the international trawlermen (so to speak)?
[^1]: Some v. useful methods of negotiation on royalties in this

[drewcrawford]

I’ve considered using this license as I like it a ton in spirit, but I dislike a lot of the magic numbers in it.

In my view, trying to pick the right cutoffs for “big time” licensing is like trying to pick allocation sizes or something. There isn’t a right one, or rather there are a lot of them, and the cutoffs don’t fit well into some particular case.

As far as BLS issue, the real comparison for most projects is something resembling contracting rates. I’ve never met the project that offered full time hours, healthcare, or 401ks. The stuff I do is very specialized, when you look at “developer, applications” it’s not going to be in there. Neither of these matter a ton but it shows how it’s not tailored to my use.

The last time I looked at this, I decided I really wanted NC with some waivers. I got too lazy to write the waivers but I still like that approach for dividing “small” and “big” users.

[kemitchell]

@drewcrawford

but I dislike a lot of the magic numbers in it

We share that feeling.

In practice, I’m more concerned about the magic numbers currently written into the “fair fee” concept than in the distinction between big and small businesses. The theme of the license is focusing on relatively few, larger-dollar deals with big companies, and letting many more, smaller-dollar deals with little companies go. The big companies pay. The small companies build name rec and maybe give feedback.

So the big/small breakpoint goes to which paid deals are financially viable, when the license fees are worth the costs of doing the deal. But the “fair free” calculus currently functions as a ceiling over financial opportunity, whether the would-be customer was over the “Big” threshold by a hair or a mile. It’s a also a hard-edged limit, more prone to misfit in context, than the FRAND concept more generally.

We had a fair amount of research and discussion about the big-small threshold for the PolyForm Small Business license. We found a ton of definitions of “small business” in various places, including several in different US laws and regulations. Numbers and metrics were all over the place.

We heard from folks with opinions about the particular thresholds we chose, but not a lot of principled distinctions. All the ways to measure “bigness” are approximate. Fortunately, some passable proxiess get counted up for other reasons—headcount for HR and compliance, revenue for tax. And that’s basically all you can expect firms asking “can we use for free?” to know offhand, or determine quickly. Using measurements companies don’t routinely take, or more a more complex test, could drive people away without really understanding, or worse, lead them to pester developers with questions about the license.

Some folks seemed concerned that their business would count as “big”, even though, for example, they still “felt” like a scrappy startup, carried a bunch of debt, and so on. Other feedback did hit some important points, like making sure the terms don’t put excess meaning on whether workers are employed or on contract. Big Time addressed a further concern: companies that don’t make money, but have received a lot of financing.

In the end, I’m still thinking it’s more important to have a clear line between small and big business than it is to draw it any particular place. When folks think of licensing “big time”, the companies they think about tend to surpass 100 headcount, $1m ARR, and $1m investment over the last five, by long strides.

[drewcrawford]

@kemitchell

In practice, I’m more concerned about the magic numbers currently written into the “fair fee” concept than in the distinction between big and small businesses.

It’s tricky to separate. For a “very big” customer, your costs are driven by sales and solution engineering, so “number of software developers” is not the right metric for frand. Meanwhile selling to “small big” $1m customers, engineering might be 1 senior contractor, so 1 BLS salary is not the right metric then either. But it’s difficult to pick a metric in the abstract.

When folks think of licensing “big time”, the companies they think about tend to surpass 100 headcount, $1m ARR, and $1m investment over the last five, by long strides.

For what it’s worth, when I read the definition I did not think of licensing “big time”. It’s difficult to see how to get to 100 employees, without 1m in capitalization first (are they paid less than 10k/yr?).

So, I concluded that whatever the license meant by “big time” was probably not what I meant. I do think there is “some definition of big” that I mean, but perhaps more practical for me to achieve with NC + waiver.

[boris]

@drewcrawford

I do think there is “some definition of big” that I mean, but perhaps more practical for me to achieve with NC + waiver.

That’s a really great realization! I think it’s also a great repeatable approach.

[kemitchell]

@drewcrawford

For a “very big” customer, your costs are driven by sales and solution engineering, so “number of software developers” is not the right metric for frand.

Yeah, it’s a proxy of a proxy situation: big companies tend to have big needs tend to have big process tend to be a bigger pain to sell. Not all potential customers will have any software developers on payroll. Those that do may not keep a current count. Note that as currently written, the metric is total headcount, not developer headcount.

@drewcrawford

It’s difficult to see how to get to 100 employees, without 1m in capitalization first (are they paid less than 10k/yr?).

Very good point. The headcount, revenue, and investment metrics were drafted to match intuition. I didn’t give any thought to parity among them, though I’m not sure that’s essential.

[kemitchell]

Thanks so much to everyone for thoughts, here and elsewhere!

It’s 1.0.0 time:

https://bigtimelicense.com/versions/1.0.0

Big Time Public License 1.0.0