Somehow, I have yet to come down with COVID-19 (as an asthmatic I’m not expecting it to end well). One of my last big gatherings before the travel bans and lockdowns were enacted was at FOSDEM in Brussels, a chance for nearly 10,000 people in the supra-European software community to get sick. I’m in my element at FOSDEM, as I’m one of those irritating people who makes a distinction between “Open Source” and “Free Software”, and uses the terms in different contexts.
But is there really a difference? Obviously the term Free Software came first, and is summarised in the Free Software Definition as the Four Freedoms (themselves often summarised in Free Software Foundation of Europe literature as “Use, Study, Share, Improve”). The Debian Free Software Guidelines are part of the Debian Social Contract, and largely explains the expectations the Debian project has on how software that forms part of their project can be used. In this way, it constrains the license limitations that can appear in Debian project components, or constrains the Debian project’s use of software to that with compatible license terms.
The Open Source Definition is, as stated in the linked page, itself derived from the Debian Free Software Guidelines. They are almost the same document. A quick diff reveals that where the DFSG says licenses must not be specific “to Debian”, the OSD says they must not be specific “to a particular product”, then one clause is specific to each document. Bruce Perens, one-time Debian Project Leader, wrote both documents.
The DFSG has a clause listing example licenses. The OSD does not, but the OSI’s site lists lots of Open Source-compatible licenses and they frequently have discussions on their mailing lists or at conferences on what licenses are or aren’t open source. Note that the OSI do not have any proprietorial control over the phrase “open source” so can’t enforce any use or proscription of the term, but are seen as influential in the field. The OSD has a clause “The license must be technology-neutral”, which the DFSG lacks.
It seems that there isn’t any significant, material difference between the definition of Free Software and the definition of Open Source, so why be pedantic about the distinction? The GNU project offers one suggestion, saying that Open Source misses the point: Free Software is a social justice movement offering freedom to users of software. Open Source minimises this social angle, instead focusing on the practical aspect of the availability of source code.
I think that the “open source misses the point” essay was probably correct at time of writing. Open Source was certainly created as an unloaded term, avoiding the connotations of “freedom” in a justice sense and “free” in the sense of zero-cost. Netscape wanted a new business model, and it wouldn’t have been compelling for Eric S. Raymond to start his pitch with “there’s no money in this, but why don’t you…”
However, whether or not Open Source was intended as a “neutral” term – and whether there can be such a thing – the phrase now stands in opposition to the Free Software movement and its mission that it initially intended to support through tacit acceptance. In modern usage, Free Software is the creation and curation of an intellectual commons defined by software that enables the four freedoms. There isn’t so much focus on justice; the Free Software Foundation has long-running campaigns against bulk surveillance and digital restrictions management, but much of the discussion at a conference like FOSDEM will focus rather on the availability of free software for particular use cases, the enforcement or suitability of particular licences, and ways to advocate for free software in various contexts.
If Free Software is the maintenance of an intellectual commons, then open source is the enclosure of that commons by and for corporate interests. This is definitely not the intention of the Open Source Initiative, who claim to be defending the “our” in “source”. In practice, companies use the phrase “open source” when they want to extend their existing business into the free software commons. We see certain practices as typical examples of this enclosure.
One is the formation of not-for-profit “Foundations” designed to give an impression of charitability to what is still a for-profit business pursuit. Many of these are business interest associations, non-profits certainly but bound by law to advance the interests of their corporate sponsors. The Linux Foundation, supposedly a “neutral home for collaborative development”, is thus actually a corporate interest group. Projects developed under the aegis of the Linux Foundation (including the OpenJS Foundation, Jenkins, the RISC-V Foundation, Let’s Encrypt, and HospitalRun) are not neutral, but are run in the interests of sponsors like Google, Facebook, AT&T, Cisco, Samsung, and company.
Another practice is the corporate Contribution License Agreement. The Free Software Foundation instituted copyright assignment on the GNU project to improve their position when enforcing copyleft in US-based disputes. Inspired by this precedent, corporations use Contributor License Agreements (CLAs) to gain proprietorial control over contributions from third parties, ensure a lack of competing ownership interest, and enable future relicensing including commercial licensing of the work.
The use of open source contributions in hiring decisions is another way in which companies have enclosed the free software commons. In addition to hobbyist and line-of-work contributions, employees are now expected to do additional open source work as a form of resume building. This work must be visible on Github so that it is easy for hiring corporations to discover and use the work for free, and it must be on popular projects (those used by a lot of other corporate open source users) to be deemed valuable and raise the profile of the contributor. Large companies freely admit that they use their open source projects as recruitment exercises, relying on the free labour contributed by the non-employee pool as information on who to groom for their notoriously low-value interview processes.
You will also see corporations downplay their interests in a project that they have commercialised, pretending that the software is entirely community-supported to both externalise their costs onto individual community members and minimise the impression that the project has been commercially enclosed. In a recent announcement of a new version of the GCC compiler, an employee at Red Hat—a $34Bn division of the $109Bn IBM corporation—asked readers to “consider a donation to the GNU Toolchain Fund to support the continued development of GCC”. Of course, GCC will continue development as long as IBM needs it to support their Red Hat, Power and Blue Gene products, and will continue developing in the direction they and the other corporate interests (Intel, Oracle, ARM, others) dictate due to their stuffing of the ballot boxes, but sure, let’s pretend that chipping in a few dollars keeps this a community-interest endeavour. (Meanwhile, De Programmatica Ipsum is the work of two people who are unpaid, and would welcome your contributions.)
Finally, enclosing open source companies try to apply anti-competitive clauses in license terms: the Commons clause for example, the Server-Side Public License and Defold License are attempts to make particular business models feasible while still sharing the source code to the products on which the businesses are based. These practices are quickly found to be incompatible with both the Free Software and Open Source definition, and cause ructions in the community. There may well be businesses that have made these clauses stick, but often the reaction from “the open source community” causes these companies to backtrack.
The reason that these last attempts to subvert free software fail is that anti-competitive clauses are so clearly not within the Four Freedoms. Freedom Zero is “the freedom to use the software, for any purpose”, which is expressed in the DFSG and the OSD as “No Discrimination Against Persons or Groups” and “No Discrimination Against Fields of Endeavor”. As a common wealth, the corpus of Free Software must be made available to all who can make use of it, regardless of whether we agree with that use. Denying a license to someone who will compete with our business is an understandable commercial decision, but not the basis of a free commons.
This aspect of free software – freedom to all – is therefore itself under attack by corporate interests who wish to undermine the movement in order to enclose and exploit the commons. Under the banner of supposedly reasonable moral concerns, they suggest that free software’s “failure” is that it doesn’t impose any ethical constraints, and propose that it would be better to limit open source software to “good” uses. This movement started, perhaps, with Douglas Crockford’s satirical JSMin license:
The Software shall be used for Good, not Evil.
It has since been taken seriously, with the Hippocratic License among others. For contientious people who like to think that they abide by a consistent ethical code, this idea can seem alluring. Why not restrict use of open source software to ethical applications? The answers, though, are manifold.
First is the question of moral authority. Who is going to deem a specific practice acceptable or unacceptable? Do they apply a Benthamite utilitarian analysis to identify “moral” or “immoral” software, or do they assume a Kantian categorical imperative? Or is there a religious moral code that underpins the morality of software, and does it apply to software creators and users who practise a different religion, or no religion? Or do we follow Nietszche, and accept that there is no “one-size-fits-all” moral code, indeed that it is immoral to demand that some people follow the same moral code as others?
The Hippocratic license indirectly chooses an answer this question by appealing to authority, but only in the case of disagreement between author and licensee over fitting their use case into the framework of the United Nations convention on human rights. Free software licenses are already difficult to enforce, without requiring arbitration in the Hague, or every contributor to interpret international convention and argue their cases with myriad users. Whether or not moral decisions are appropriate when choosing who gets to use software, they are certainly expensive to produce, reproduce, and enforce: a situation that of course tips the balance in favour of the large corporation. Indeed proprietary software licences are already supported by an infrastructure that chooses which customers to acquire and retain, so the Hippocratic license looks more like a particular source-available choice for commercial software than an adaptation of free software.
Also at issue is the appropriateness of the question. If free software users all have to conform to the same moral position in order to enjoy their freedoms, are they truly free? Bradley M. Kuhn, policy fellow at the Software Freedom Conservancy, draws a parallel with the defence of free speech:
Ultimately, fighting for software freedom is a social justice cause similar to that of fighting for free speech and other causes that require equal rights for all. We will always find groups exploiting those freedoms for ill rather than good. We, as software freedom activists, will have to sometimes grit our teeth and defend the rights to modify and improve software for those we otherwise oppose. Indeed, they may even utilize that software for those objectionable activities. It’s particularly annoying to do that for companies that otherwise produce proprietary software: after all, in another realm, they are actively working against our cause. Nevertheless, either we believe the Four Software Freedoms are universal, or we don’t. If we do, even our active political opponents deserve them, too.
Taking the principled stand that software freedoms are rights in themselves requires ensuring those rights are defended for everyone. Defending those rights for everyone makes it clear that you are a person of principle, which lends greater weight to your argument when you speak out against immoral behaviour.
It is correct that software creators, particularly professionals, should practice their craft ethically, should refuse to engage in immoral practices, and should use their skills to combat unethical behaviour. We explored that topic in issue 5. But we should not deny the basic freedoms of our field while claiming that to do so is ethically just.
Photo by Ronan Furuta on Unsplash.
