|
|
SMP and 64-bit addressing are passing fads, right?
Only time will tell if copyleft or permissive licensing will take us closer to universal software freedom but I will argue that permissive licensing contains a unseen curse that absorbs and punishes the greed of those who choose to exercise its proprietization option.
There's no doubt about it, permissive licensing leaves plenty of room to be a jerk.
Here is the ISC copyright as an example:
/* * Copyright (c) YYYY YOUR NAME HERE <user@your.dom.ain> * * Permission to use, copy, modify, and distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */
Working our way down, you could try to strip developer's names from their code, withhold your changes to their code or hold the developer liable for any damages their code inflicts upon you. Surprisingly, I have never heard of anyone challenging the latter of these and as for the attribution obligation, two notable incidences come to mind: The Linux ath5k-driver dispute and albeit it GPL-related, Google's Linux kernel header stipping controversy. In both cases the impacted communities mobilized their social and if you will, emotional capital weapons against the offending parties with swift results. Harsh words flew in both cases but the impacted groups pursued resolutions in the open and without legal expenses. Because these copyright violations took place with code that was always out in the open, the community proved to be self-regulating and adequately prepared to address the legal issue at hand. Witness the meritocracy in action and successfully dispensing justice at very little cost.
That said, the greatest controversy of permissive licensing lies is your right to "use, copy, modify, and/or distribute this software for any purpose with or without fee". Herein is a carte blanche for individuals and businesses to proprietize permissively-licensed software and laugh their way to the bank with it. How could anyone resist the chance of slapping their name on free, enterprise-grade software? This opportunity is so great that three distinct business models have emerged over the years:
"Take the code and run" was popular among router and storage vendors in the 1990s who build their products on BSD Unix with the understanding that the disbanded Berkeley CSRG was not going to be generating code like it used to. Vendors tailored BSD to their hardware and broader solutions and never looked back. Apple engaged in this practice to a lesser extent by importing the FreeBSD 5.1 userland, lib.c and other components into Mac OS X and later iOS.
"Ride the code" was the strategy of commercial BSD vendor BSDi and as one person close to the company put it, "we can grab their patches as fast as they can commit them." BSDi did produce their own innovations but they banked on the fact that they provided BSD Unix. I can't think of any notable "black box" BSDs today considering that most vendors have chosen some variation on the more community-oriented "quasi-open core" model.
"Quasi-open core" is probably the most successful of the three models and simply refers to a vendor adding various degrees of "secret sauce" to freely-available upstream software. I say "quasi" open core because a true open core model would involve the offer of a public copyleft version whose community improvements serve a private proprietary version through copyright attributions. Nearly every modern software vendor falls into this category by incorporating some amount of permissively-licensed software into their products but some very clearly add their own features to off-the-shelf BSDs. Good examples from outside the BSD community are the original MySQL AB as an open core provider and EnterpriseDB as an "enhanced" PostgreSQL provider.
Free of any obligation to participate in the upstream community, vendors obviously differ widely in their depth and breadth of engagement with both community developers and their direct competitors. The worse of them thumb their nose at the community and aggressively poach developers while others are prolific community participants who are only recouping development costs while putting food on the table. All of these models are sustainable to one degree or another but they are always fighting an upstream battle against one fundamental reality: only proprietary vendors want proprietary software. No one else does. Your developers don't. Your paying customers don't. Your community doesn't. Software is so complex and fragile that it wants to be free and the bigger your diff, the harder it is to maintain. Furthermore as Joy's Law dictates, "No matter who you are, most of the smartest people work for someone else". Increasingly that means that the best and the brightest are accessible through the community through what is effectively a social contract.
Through greed or arrogance, Bill Joy didn't follow his own advice and took his BSD fork through a painful journey from a nonproprietary operating system to a proprietary one, to an again nonproprietary one with strings attached to eventually a refugee one with strong community support. Legend has it that the Sun developers wanted technologies like ZFS and DTrace to be permissively-licensed but lost out to management. Furthermore, Oracle who is now in control of the destiny of Joy's creation reportedly cannot incorporate community changes and all we must wonder, "Are you satisfied?" How Oracle embraces, tolerates or assaults the open source community it inherited will be quite interesting with countless opportunities for both kindness and disruption.
On less dramatic scale, many of the router and NAS vendors that "took the code and ran" are coming in from the cold having discovered that no piece of software is self-maintaining or self-innovating. Everyone who forked CSRG BSD or a descendant community project must not have foreseen that production-quality symmetrical multiprocessing and 64-bit addressing support would come from the community. To develop these in-house would be costly with only a slight advantage in maintainability by being home-grown. One fruit of this new era of détente is the BHyVe hypervisor courtesy of NetApp and I can confirm first hand that the developers want to see it grow as a community project.
As for the "ride the code" players, it's a question of "Where are they now?" Such vendors can at best only provide a 1% to 5% derivation of the community code base and neither percentage is beneficial: a large set of changes can become a fork while a small number can be easily re-implemented by the community. Support models have proven quite effective but they do not require any forking of community code to succeed.
To his credit, Bill Joy nailed the key factor in all of this: the smartest people. No turn of the software proprietization dial can compensate for the fact that proprietary experience on the part of you and your team will trump every known blatancy or subtlety of open source licensing obligations. Every bit of proprietary in-house software is worthless the moment you lose the employees that maintain it and integrating your software into the community is far more difficult down the road than from the start. The moral of the story is that it is self-defeating to proprietize permissively-licensed software or as Eric Allman of Sendmail, Inc. put it at at EuroBSDcon 2012, "self mutilating".
Resist the temptation to proprietize permissively-licensed software lest you fall victim to its curse.
Happy Halloween!
Copyright © 2011 – 2014 Michael Dexter unless specified otherwise. Feedback and corrections welcome.