placeholder

/dev/lawyer

>> law, technology, and the space between

All content by Kyle E. Mitchell, who is not your lawyer.

You can subscribe via RSS/Atom or e-mail and browse other blogs.

EULAs Aren’t Inherently Evilproprietary done right can beat free and open for users

Too many software developers simply cannot conceive that a dreaded “proprietary software license” could be reasonable, fair, and beneficial to users. That they might rationally prefer such terms, and paying for software, to free MIT or GPL for code they actually use.

It happens. It’s all about terms and circumstances.

Consider a “proprietary” deal like so:

There’s nothing inherently abusive here. Depending on the software, the price, and the competition, it’s just a good deal or a bad one. Those who take the deal aren’t “locked in” by some dark legal magic. They could become dependent on the software and the vendor, for lack of competition or a failure to diversify. Not due to any legal hooks hidden in the contract.

Through the lens of free and open source ideology, of course, it’s the road to serfdom and a recipe for crapware. Many “freedoms” are present, but some are not, and the matter is all-or-nothing. The customer’s debased, cast down to servitude, bound in chains of copyright.

But also, as we know, exceedingly unlikely to care. Through the lens of lived industry experience, we see that what users reliably need and want, they get on this deal. Plus a lot they can only hope for from open source in the best cases.

Of all the projects we use, we contribute to very few. We fork-adopt fewer still. We download software direct from where developers put it—GitHub, repositories, and project websites—rather than passing among friends. We don’t like paying just to try something out, but once we’re in, we immediately start worrying whether the project will fall out from under us. The question shifts from the software as such to all the life-support work to keep it usable—doc, bugs, maintenance, security, roadmap—and the other people we hope will do that work for us.

Those odds in mind, practically speaking, users under a proprietary deal like this concede a whole lot of nothing. Permission for things they won’t want to do. Protections against problems they won’t have. In return, they get real benefits within the folks of probability. Consider:

In short, instead of trampling developer interests in favor of immediate user interests, the license agreement aligns their interests long-term. The developer gets paid. But they also take responsibility:

The effect is something like a foundation where all the users actually donate. The “foundation” is instead a company, which can can make a profit. Like the users, most of the time.


I write a lot of legal terms, license agreements included. Legal terms have no inherent value, good or ill. Certainly no inherent ethical value. They matter only as applied, in some context, to move property and shape behavior. They shape behavior by invoking sense of duty, staking reputation, and changing incentives. They never set out the whole system of incentives. They only alter some existing state. Existing states vary widely!

In many circumstances, software users and software developers will both be better off under balanced paid commercial terms informed by practical probabilities and market conditions than under easier-to-grok, intellectually pure terms at some “clean” extreme, be it permissive open-source or full-lockdown adhesion. Out in the world, when more is involved and at stake than abstract principle, that often leads to more responsible, and more ethical, outcomes. Savvy devs know this and account for it, recognizing when it applies. It makes their self-interest that much more enlightened.

Sometimes The MIT License works best. Often when the project is a slim-marginally valuable spin in a commodity category, or some big firm wants see it commoditized. Sometimes lock-in-inducing commercial terms work best. Often when the software’s truly innovative, commercially differentiating, and took lots of work. Frequently enough, the best choice for a project shifts over time, along with competitive circumstances. Finding the fair, productive choice is in that sense an engineering problem. “Correctness” is using the right tool to get the right outcome, not self-limiting to anointed means.

Free and open agitprop helped set off a productive explosion. It also wreaked lasting perceptual damage. The black-and-white, oddly essentialist view of software licensing helped polarize perception, build an audience, paint an enemy, and coalesce a movement. Arguably, the new consumer software market of the 1990s worked into an extremely bad state, and needed an reaction to crack loose.

But the correction didn’t set us down a middle course of more nuance, knowledge, and refinement. It reinforced a stark, limited view of the industry—characteristic of young and commercially sheltered coders dealing entirely with dominant apps from megacorps, on one hand, and open source from hackers, on the other—as all relevant reality. There wasn’t any burgeoning gray area of independent software sales in this picture, just speckles of pure black and pure white—open-or-die shops hocking professional services, pure-play closed soaking up free dependencies, pure open core sprinkling on pure closed add-ons. No experience of negotiation—engineering terms to circumstances—to speak of. No rallying call to develop those chops. We accepted that licensing mattered to our industry, defined its most important dividing line. But we also accepted that it was out of our hands, that LICENSE was the one file in our repos we couldn’t hack.

“Proprietary” paints all not-free-and-open terms the same, ominous black. In fact it’s the whole universe of hackable permutations and combinations, except a few “open” licenses, largely written ages ago. A lot more is possible.

Your thoughts and feedback are always welcome by e-mail.

back to topedit on GitHubrevision history