Much ink has been spilled on open-source vs. proprietary licensing, and in the end, it’s a clash of civilizations: one whose goal it is to better humanity by making valuable technology freely available, vs. one whose members must return more money to their investors than they had to pay to the developers creating the software. Nobody ever belongs to both of those civilizations, at least not for long, so they won’t ever agree about what’s good and what’s evil, and neither is going to win that argument.
But perhaps it is time to move on to a reframed argument that allows us to make more progress. Here’s is a new attempt. (I think it’s new, please link to previous work from the comments.) Instead of good vs. evil etc etc I’d like to frame it from the perspective of the two major constituents of software. These are:
- people who contribute to the creation of software, aka software committers. I’ll use this term regardless how their software is licensed or distributed, just to keep things simple.
- people who obtain and then run software for some purpose other than caring how the software has been created or could be improved by them. I’ll call those software consumers.
For example, the software developers at Microsoft creating Word are committers, and I’m a consumer if I run Word to write a letter. Similarly, if I download OpenOffice instead, I’m a consumer and the OpenOffice community are the committers. Software licenses enter the picture in two places:
- to enable and guide the flow of money. If there is no legal obligation to pay, for example, businesses can’t rely on getting paid. So we need a legal agreement that defines where and when and how the money flows, and that can be enforced through the legal system: aka a software licensing agreement.
- to guide and often restrict the flow of the software itself. Very few committers choose a “do whatever you want” license agreement; many (proprietary and open-source) licenses are very specific about how to software moves and does not move from one place to another. More importantly, the license agreement governs whether and how consumers can become committers themselves (or at least hire committers working on their behalf).
Here are the main categories as they exist for committers:
|
Committers \ Consumers |
Have no right to obtain $ from consumers in exchange for using the software | Have the right to obtain some $$ from some consumers some of the time or the right to prevent them from using the software in certain ways | Always obtain $$$ from consumers using the software. (Ignoring the rare 100% discount.) |
|---|
Here are the main categories as they exist for consumers:
|
Committers \ Consumers |
|||
|---|---|---|---|
| Can become committers of the software, or a derivative of it, and largely have the same rights the original committers have | |||
| Can become committers of the software under some circumstances, for certain parts or combinations | |||
| Cannot become committers of the software in any meaningful way |
You guessed it, it was going to become a table ;-) . I’ve put the major licensing models into the cells of the table.
|
Committers \ Consumers |
Have no right to obtain $ from consumers in exchange for using the software or prevent them from using it | Have the right to obtain some $$ from some consumers some of the time or the right to prevent them from using the software in certain ways | Always obtain $$$ from consumers using the software. (Ignoring the rare 100% discount.) |
|---|---|---|---|
| Can become committers of the software, or a derivative of it, and largely have the same rights the original committers have | Public domain, MIT, Apache, BSD etc. licenses. | Certain (company-specific) business partner agreements | Requires “sell the source code” agreement |
| Can become committers of the software under some circumstances, for certain parts or combinations | (never heard of it?) | GPL, AGPL, Sleepycat, various dual licensing models | Certain (company-specific) business partner agreements |
| Cannot become committers of the software in any meaningful way | (never heard of it?) | Traditional add-on business to proprietary software | Proprietary software |
[Disclaimer: I’m not a licensing expert at all; this is the best of my understanding. (Please correct if you know better) And in the middle columns and rows, there are of course a myriad of finer points that are different, say GPL vs. AGPL.] But:
How does this reframed matrix help us? It helped me to understand that all these license choices boil down to a choice of “what can the committers do” and “what can the consumers” do? Specifically, under which circumstances the committers can ask for money, and under which circumstances the consumers can become committers. This latter part, as one of the two major axes structuring the space, was a big surprise to me. (I started out with a different axis, but that turned out to be wrong.) If Doc Searls is right and consumers are becoming producers, this second axis is a really important question — perhaps a much more important question than “good vs. evil”. Do you want your consumers be able to be producers with (or of!) your software?
Well, I’ll be “committing” this matrix ;-) with a “do whatever you want”-like license (aka Creative Commons, like everything else on this blog) for the bettering of humanity. And to help create sustainable software businesses!
Of course this creates many questions. Off the top of my head:
- How wrong am I? Followed by the second, advanced level:
- Now enter the cloud. How does this change? Does it? And:
- What’s the optimal business strategy here?
Comments
One response to “Reframing the Open-Source vs. Proprietary Software Licensing Debate”
Speaking of Creative Commons, note that Creative Commons provides tools for BSD, GPL, and LGPL licensing. Here’s their FAQ about it:
http://urlzr.mp/75
Creative Commons doesn’t alter BSD, GPL, or LGPL in any way. Instead, they provide human-readable and machine-readable forms that make those licenses easier to work with.