Who We Want to Charge = Who We Can Charge

It occurred to me that a lot of the thinking and writing we ended up doing about the standard deal for IndieCC and its predecessors was phrased in terms of who we wanted to charge, but ended up drawing lines that look an awful lot like defining who it’s practical to charge.

Independent devs and small teams aren’t going to police the Internet hunting “infringers” like the MPAA. The MPAA barely does that anymore. Nor are they going to hunt down solo devs or even medium sized firms in smaller economies who can’t afford the license fee. Even for developers in those same countries, it’s probably not cost effective. We can write a nice exception for kids and those helping kids to learn. But even if we didn’t, with the code on the open Web, any number of those are going to get their hands on the software and use it, regardless.

I don’t think these two sets of criteria—who we feel good about charging, and who it’s practical to charge—happen to coincide in covering exactly the same set of real or potential users. They’re not secret, roundabout synonyms. But the parallels gave me a prompt to think a bit more about how what’s practical in a world with the Web, and what’s not, have shaped what feels good and seems fair.

There’s a very real sense in which permissive public licenses like MIT and BSD merely put a legal stamp over what was going on with the early Internet. There’s also a real sense in which the official permissions proved overbroad, opening the way for behavior that would have been quite taboo in the social scene.

The idealist in me holds hope that more legal terms written to be read, that actively encourage reading, can help collapse the mismatch between what people want and the terms they end up using. But there are clearly other influences all around that phenomenon that also come into play. Do the license people write what the developers want, or the developers want what the license people tell them they can have?

1 Like

Any software worth using, is going to be cracked & pirated, it is simply a fact of life.

There is no way around that, no matter how much work you put into it.

Ultimately software licensing is based upon a trust system, that you will pay for what you use. Kinda like the roadside stalls of fresh fruit and veggies with a coin holder.

Realistically if you do not wish to be proactive in defending your software licenses, all you can do is stop support and stop any additional services provided with it.

Knowing all this, it kinda simplifies your licensing model quite a bit to either being those who are honest or companies with an actual IT department.

1 Like

I agree it’s important to accept that you will lose a certain measure of absolute control over use of your software, unless you take highly aggressive steps to lock it down among a small circle of users, like a trade secret. Black-and-white thinking has led too many people—not just in software, but in music, art, and a thousand other fields—to get entirely too fired up about “piracy”, go on rampages, and wreck their own houses in the process.

At the same time, there are definitely situations where accountability drives people to mind license terms, quite without any noble motive. Companies with valuable assets proactively police themselves on license compliance, because they know they’re worth suing. Those companies also have capacity to drag legal and other processes out, but only at substantial cost. They get sued and settle for meaningful money often enough to spend less money, all the time, avoiding those hits.

Before service-izing itself, Adobe had to accept that a significant number of students, hobbyists, and even smalltime professionals were going to use Photoshop without paying for it, pretty much no matter what Adobe did. That didn’t mean they couldn’t make money, or that other businesses, especially big ones, could get away with the same at scale.

The most relevant question when drafting a license to draw these lines is whether the person or company using the license wants to express the principle that those who use should pay, in pure and simple terms, or whether they want to express something more like the combination of principle and practicalities, which make enforcement cost-prohibitive or even counter-productive in many circumstances.

Plenty of developers and companies have intentionally chosen the former and then accepted doing absolutely nothing about small-dollar violators. That has the effect of requiring them to use “on the lam”. It may inspire a few more to pay up, on the margin. But it may also reduce the number of beneficial freeloaders, who spread word of the software, recommend it at work, and so on.

Tradeoffs everywhere.