Overloadedputting finer points on established fuzzy terms
This post is part of a series, Overloaded.
Boosterism would have us look on open source as an eternal parade of righteous triumphs. Experience suggests we’d better look for and learn from mistakes, as well. There have been plenty. Terminology represents a particularly rich vein of persistent hacker folly, right through the history of doing software online.
This post kicks off a new, running series, Overloaded, addressing terms in and around open licensing used in manifold, confusing ways. I’m going to suggest new, finer-pointed distinctions on top of those terms—not replacements or new, “more correct” definitions, but new names for the different kinds of them—to paint around the potholes we keep falling in. I have a couple in mind to start—“dual licensing” and “relicensing”—but will leave the blog series open for more as they come.
Why not simply deprecate all these troublesome terms? Or push for more “correct” definitions? Because that doesn’t work. No one has the power to stop uncoordinated naming collisions, or to dislodge established usages once they’ve stuck. No one’s that witty.
I have been guilty of thinking I might be. I’ve tried various coinages for specific kinds of “dual licensing”, for example, occasionally on this and other blogs. I’m tempted to resist the latest semantic outbreak of “Artificial Intelligence” by lending my wind to “Fake Smarts” and the like.
I might have learned the folly in this care of one Richard M. Stallman. It’s all as hopeless as the FSF’s dog pound of no-no words and quiverful of put-downs. It’s all as self-limiting as fighting about “Free Software” before “Open Source” source, calling the Kindle the “Swindle”, or dressing down SaaS with “Service as a Software Substitute”. The other side is winning every one of those wars. I lost all of mine, too. The difference between the words we use and the words everyone else uses make neat resumes of our political losses.
At best, “forking” the common parlance gives a smug self-satisfaction, a chance for fellow travelers to smirk conspiratorially, and a fleeting burble of in-group esprit, assuming no one from the out-group’s around to pop the mood. Mostly it just makes the clever one harder to understand. For those who do understand them, and why they choose to make themselves obscure, it’s nice physical therapy for any underused eye-roll muscles. “Digital Restrictions Management” and similar aren’t even so much sour grapes as old vinegar. “Service as a Software Substitute” dries out hungry mouths while “Software as a Service” sips champagne.
No one owns any bits of common English, either. That I learned from the Open Source Initiative. Defending their definition of “open source” is the perfect war for self-styled activists, because it will be fought—and need funding—forever. The legal system denied their trademark on “open source” from the very start. Without compulsion, they’re left with persuasion. Without structural advantages, that’s a never-ending, ever-losing popularity contest unto the end of time.
Well overloaded “open source” itself remains instructive. Too many people still know just that concept—open source—without any finer distinctions. That gets them into trouble, as when they rely on OSI license approval. But savvier players know and use “permissive open source” and “copyleft open source” fluently. Unlike “open source” overall, a malleable political product whose edges have been made fuzzy and slicked down opportunistically over time, permissive and copyleft can be acted upon. Blue Oak Council publishes rigorous lists of both, and they are practically useful.
Permissive open source and copyleft open source—that’s the kind of refinement we need for overloaded terms. Imposing finer-grained understanding does not work. No interest group has the power to make it evenly distributed. Practical, not ideological, benefits drive adoption of new terms and concepts. I can offer some additional, functional structure as a leg up to others. Offer, not impose.
Your thoughts and feedback are always welcome by e-mail.
back to top — edit on GitHub — revision history