Displaying posts tagged CLA
Toward Copyleft Equality for All
byon January 6, 2020
I would not have imagined even two years ago that expansion of copyleft would become such an issue of interest in software freedom licensing. Historically and for good reason, addition of new forms of copyleft clauses has moved at a steady pace. The early 2000s brought network services clauses (such as that in the Affero GPL), which hinged primarily on requiring provision of source to network-remote users. Affero GPL implemented this via copyright-controlled permission of modification. These licenses began as experiments, and were not approved by some license certification authorities until many years later.
Even with the copyleft community's careful and considered growth, there have been surprising unintended consequences of copyleft licenses. The specific outcome of proprietary relicensing has spread widely and — for stronger copyleft licenses like Affero GPL — has become the more common usage of the license.
As the popularity of Open Source has grown, companies have searched for methods to combine traditional proprietary licensing business models with FOSS offerings. Proprietary relicensing, originally pioneered by MySQL AB (now part of Oracle by way of Sun), uses software freedom licenses to compel purchase of proprietary licenses for the same codebase. Companies accomplish this by ensuring they collect all copyright control of a particular codebase, thus being its sole licensor, and offer the FOSS licenses as a loss-leader (often zero-cost) product. Non-commercial users generally are ignored, and commercial users often operate in fear of captious interpretations of the copyleft license. The remedy for their fear is a purchase of a separate proprietary license for the same codebase from the provider. Proprietary relicensing seems to have been the first mixed FOSS/proprietary business model in history.
The toxicity of this business model has only become apparent in hindsight. Initially, companies engaging in this business model did so somewhat benignly — often offering proprietary licenses only to customers who sought to combine the product with other proprietary software, or as supplemental income along with other consulting businesses. This business model (for some codebases), however, became so lucrative that some companies eventually focused exclusively on it. As a result, aggressive copyleft license overreading and inappropriate, unprincipled enforcement typically came from such companies. For most, the business model likely reached its crescendo when MongoDB began using the Affero GPL for this purpose. I was personally told by large companies at the time (late 2000s into early 2010s) that they'd listed Affero GPL as “Never Allowed Here” specifically because of shake-downs from MongoDB.
Copyleft itself is not a moral philosophy; rather, copyleft is a strategy that software freedom activists constructed to advance a particular set of policy goals. Specifically, software copyleft was designed to ensure that all users received complete, corresponding source for all binaries, and that any modifications or improvements made anywhere in the chain of custody of the software were available in source form to downstream users. As orginially postulated, copyleft was a simple strategy to disarm proprietarization as an anti-software-freedom tactic.
The Corruption of Copyleft
Copyleft is a tool to achieve software freedom. Any tool can be fashioned into a weapon when wielded the wrong way. That's precisely what occurred with copyleft — and it happened early in copyleft's history, too. Before even the release of GPLv2, Aladdin Ghostscript used a copyleft via a proprietary relicensing model (which is sometimes confusingly called the “dual licensing” model). This business model initially presented as benign to software freedom activists; leaders declared the business model “barely legitimate”, when it rose to popularity through MySQL AB (later Sun, and later Oracle)'s proprietary relicensing of the MySQL codebase.
In theory, proprietary relicensors would only offer the proprietary license by popular demand to those who had some specific reason for wanting to proprietarize the codebase — a process that has been called “selling exceptions”. In practice, however, every company I'm aware of that sought to engage in “selling exceptions” eventually found a more aggressive and lucrative tack.
This problem became clear to me in mid-2003 when MySQL AB attempted to hire me as a consultant. I was financially in need of supplementary income so I seriously considered taking the work, but the initial conference call felt surreal and convinced me that MySQL AB was engaging in problematic behavior . Specifically, their goal was to develop scare tactics regarding the GPLv2. I never followed up, and I am glad I never made the error of accepting any job or consulting gig when companies (not just MySQL AB, but also Black Duck and others) attempted to recruit me to serve as part of their fear-tactics marketing departments.
Most proprietary relicensing businesses work as follows: a single codebase is produced by a for-profit company, which retains 100% control over all copyright in the software (either via an ©AA or a CLA). That codebase is offered as a gratis product to the marketplace, and the company invests substantial resources in marketing the software to users looking for FOSS solutions. The marketing department then engages in captious and unprincipled copyleft enforcement actions in an effort to “convert” those FOSS users into paying customers for proprietary licensing for the same codebase. (Occasionally, the company also offers additional proprietary add-ons, improvements, or security updates that are not available under the FOSS license — when used this way, the model is often specifically called “Open Core”.)
Why We Must End The Proprietary Relicensing Exploitation of Copyleft
This business model has a toxic effect on copyleft at every level. Users don't enjoy their software freedom under an assurance that a large community of contributors and users have all been bound to each other under the same, strong, and freedom-ensuring license. Instead, they dread the vendor finding a minor copyleft violation and blowing it out of proportion. The vendor offers no remedy (such as repairing the violation and promise of ongoing compliance) other than purchase of a proprietary license. Industry-wide. I have observed to my chagrin that the copyleft license that I helped create and once loved, the Affero GPL, was seen for a decade as inherently toxic because its most common use was by companies who engaged in these seedy practices. You've probably seen me and other software freedom activists speak out on this issue, in our ongoing efforts to clarify that the intent of the Affero GPL was not to create these sorts of corporate code silos that vendors constructed as copyleft-fueled traps for the unwary. Meanwhile, proprietary relicensing discourages contributions from a broad community, since any contributor must sign a CLA giving special powers to the vendor to continue the business model. Neither users nor co-developers benefit from copyleft protection.
The Onslaught of Unreasonable Copyleft
Meanwhile, and somewhat ironically, the success of Conservancy's and the FSF's efforts to counter this messaging about the Affero GPL has created an unintended consequence: efforts to draft even more restrictive software copyleft licenses that can more easily implement the proprietary relicensing business models. We have partially succeeded in convincing users that compliance with Affero GPL is straightforward, and in the backchannels we've aided users who were under attack from these proprietary relicensors like MongoDB. In response, these vendors have responded with a forceful political blow: their own efforts to redefine the future of copyleft, under the guise of advancing software freedom. MongoDB even cast itself as a “victim” against Amazon, because Amazon decided to reimplement their codebase from scratch (as proprietary software!) rather than use the AGPL'd version of MongoDB.
These efforts began in earnest late last year when (against the advice of the license steward) MongoDB forked the Affero GPL to create the SS Public License. I, with the support of Conservancy, rose in opposition of MongoDB's approach, pointing out that MongoDB would not itself agree to its own license (since MongoDB's CLA would free it from the SS Public License terms). If an entity does not gladly bind itself by its own copyleft license (for example, by accepting third-party contributions to its codebases under that license), we should not treat that entity as a legitimate license steward, nor treat that license as a legitimate FOSS license. We should not and cannot focus single-mindedly on interpretation of the formalistic definitions when we recommend FOSS licensing policy. The message of “technically it's a FOSS license, but don't use” is too complicated to be meaningful.
A Copyleft Clause To Restore Equality
My friend and colleague, Richard Fontana, and I are known for our very public and sometimes heated debates on all manner of software freedom policy. We don't always agree on key issues, but I greatly respect Fontana for his careful thought and his inventive solutions. Indeed, Fontana first formulated “inbound=outbound” into that simple phrasing to more easily explain how the lopsided rights and permissions exchanges through CLAs actually create bad FOSS policy like proprietary relicensing. In the copyleft-next project that Fontana began, he further proposed this innovative copyleft clause that could, when Incorporated in a copyleft license, prevent proprietary licensing before it even starts! The clause still needs work, but Fontana's basic idea is revolutionary for copyleft drafting. The essence in non-legalese is this: If you offer a license that isn't a copyleft license, the copyleft provisions collapse and the software is now available to all under a non-copyleft, hyper-permissive FOSS license.
This solution is ingenious in the way that copyleft itself was an ingenious way to use copyright to “reverse” the rights and ensure software freedom. This provision doesn't prohibit proprietary relicensing per se, but instead simply deflates the power of copyleft control when a copyright holder engages in proprietary relicensing activities.
Given the near ubiquity of proprietary relicensing and the promulgation of stricter copylefts by companies who seek to engage (or help their clients engage) in such business models, I've come to a stark policy conclusion: the community should reject any new copyleft license without a clause that deflates the power of proprietary relicensing. Not only can we incorporate such a clause into new licenses (such as copyleft-next), but Conservancy's Executive Director, Karen Sandler, came up with a basic approach to incorporating similar copyleft equality clauses into written exceptions for existing copyleft licenses, such as the Affero GPL. I have received authorization to spend some of my Conservancy time and the time of our lawyers on this endeavor, and we hope to publish more about it in the coming months.
We've finished the experiment. After thirty years of proprietary relicensing, beginning with Aladdin and culminating with MongoDB and their SS Public License, we now know that proprietary relicensing does not serve or extend software freedom, and in most cases has the opposite effect. We must now categorically reject it, and outright reject any new licenses that can be used for it.
Understanding LF's New “Community Bridge”
byon March 13, 2019
Yesterday, the Linux Foundation (LF) launched a new service, called “Community Bridge” — an ambitious platform that promises a self-service system to handle finances, address security issues, manage CLAs and license compliance, and also bring mentorship to projects. These tasks are difficult work that typically require human intervention, so we understand the allure of automating them; we and our peer organizations have long welcomed newcomers to this field and have together sought collaborative assistance for these issues. Indeed, Community Bridge's offerings bear some similarity to the work of organizations like Apache Software Foundation, the Free Software Foundation (FSF), the GNOME Foundation (GF), Open Source Initiative (OSI), Software in the Public Interest (SPI) and Conservancy. People have already begun to ask us to compare this initiative to our work and the work of our peer organizations. This blog post hopefully answers those questions and anticipated similar questions.
The first huge difference (and the biggest disappointment for the entire FOSS community) is that LF's Community Bridge is a proprietary software system. §4.2 of their Platform Use Agreement requires those who sign up for this platform to agree to a proprietary software license, and LF has remained silent about the proprietary nature of the platform in its explanatory materials. The LF, as an organization dedicated to Open Source, should release the source for Community Bridge. At Conservancy, we've worked since 2012 on a Non-Profit Accounting Software system, including creating a tagging system for transparently documenting ledger transactions, and various support software around that. We and SPI both now use these methods daily. We also funded the creation of a system to manage mentorship programs, which now runs the Outreachy mentorship program. We believe fundamentally that the infrastructure we provide for FOSS fiscal sponsorship (including accounting, mentorship and license compliance) must itself be FOSS, and developed in public as a FOSS project. LF's own research already shows that transparency is impossible for systems that are not FOSS. More importantly, LF's new software could directly benefit so many organizations in our community, including not only Conservancy but also the many others (listed above) who do some form of fiscal sponsorship. LF shouldn't behave like a proprietary software company like Patreon or Kickstarter, but instead support FOSS development. Generally speaking, all Conservancy's peer organizations (listed above) have been fully dedicated to the idea that any infrastructure developed for fiscal sponsorship should itself be FOSS. LF has deviated here from this community norm by unnecessarily requiring FOSS developers to use proprietary software to receive these services, and also failing to collaborate over a FOSS codebase with the existing community of organizations. LF Executive Director Jim Zemlin has said that he “wants more participation in open source … to advance its sustainability and … wants organizations to share their code for the benefit of their fellow [hu]mankind”; we ask him to apply these principles to his own organization now.
The second difference is that LF is not a charity, but a trade association — designed to serve the common business interest of its paid members, who control its Board of Directors. This means that donations made to projects through their system will not be tax-deductible in the USA, and that the money can be used in ways that do not necessarily benefit the public good. For some projects, this may well be an advantage: not all FOSS projects operate in the public good. We believe charitable commitment remains a huge benefit of joining a fiscal sponsor like Conservancy, FSF, GF, or SPI. While charitable affiliation means there are more constraints on how projects can spend their funds, as the projects must show that their spending serves the public benefit, we believe that such constraints are most valuable. Legal requirements that assure behavior of the organization always benefits the general public are a good thing. However, some projects may indeed prefer to serve the common business interest of LF's member companies rather than the public good, but projects should note such benefit to the common business interest is mandatory on this platform — it's explicitly unauthorized to use LF's platform to engage in activities in conflict with LF’s trade association status). Furthermore, (per the FAQ) only one maintainer can administer a project's account, so the platform currently only supports the “BDFL” FOSS governance model, which has already been widely discredited. No governance check exists to ensure that the project's interests align with spending, or to verify that the maintainer acts with consent of a larger group to implement group decisions. Even worse, (per §2.3 of the Usage Agreement) terminating the relationship means ceasing use of the account; no provision allows transfer of the money somewhere else when projects' needs change.
Finally, the LF offers services that are mainly orthogonal and/or a subset of the services provided by a typical fiscal sponsor. Conservancy, for example, does work to negotiate contracts, assist in active fundraising, deal with legal and licensing issues, and various other hands-on work. LF's system is similar to Patreon and other platforms in that it is a hands-off system that takes a cut of the money and provides minimal financial services. Participants will still need to worry about forming their own organization if they want to sign contracts, have an entity that can engage with lawyers and receive legal advice for the project, work through governance issues, or the many other things that projects often want from a fiscal sponsor.
Historically, fiscal sponsors in FOSS have not treated each other as competitors. Conservancy collaborates often with SPI, FSF, and GF in particular. We refer applicant projects to other entities, including explaining to applicants that a trade association may be a better fit for their project. In some cases, we have even referred such trade-association-appropriate applicants to the LF itself, and the LF then helped them form their own sub-organizations and/or became LF Collaborative Projects. The launch of this platform, as proprietary software, without coordination with the rest of the FOSS organization community, is unnecessarily uncollaborative with our community and we therefore encourage some skepticism here. That said, this new LF system is probably just right for FOSS projects that (a) prefer to use single-point-of-failure, proprietary software rather than FOSS for their infrastructure, (b) do not want to operate in a way that is dedicated to the public good, and (c) have very minimal fiscal sponsorship needs, such as occasional reimbursements of project expenses.
Update on 2019-04-01: Community Bridge was also discussed on episode 0x65 of Free as in Freedom, which is available in mp3 format and ogg format.
Toward Community-Oriented, Public & Transparent Copyleft Policy Planning
byon October 16, 2018
More than 15 years ago, Free and Open Source Software (FOSS) community activists successfully argued that licensing proliferation was a serious threat to the viability of FOSS. We convinced companies to end the era of “vanity” licenses. Different charities — from the Open Source Initiative (OSI) to the Free Software Foundation (FSF) to the Apache Software Foundation — all agreed we were better off with fewer FOSS licenses. We de-facto instituted what my colleague Richard Fontana once called the “Rule of Three” — assuring that any potential FOSS license should be met with suspicion unless (a) the OSI declares that it meets their Open Source Definition, (b) the FSF declares that it meets their Free Software Definition, and (c) the Debian Project declares that it meets their Debian Free Software Guidelines. The work for those organizations quelled license proliferation from radioactive threat to safe background noise. Everyone thought the problem was solved. Pointless license drafting had become a rare practice, and updated versions of established licenses were handled with public engagement and close discussion with the OSI and other license evaluation experts.
Sadly, the age of license proliferation has returned. It's harder to stop this time, because this isn't merely about corporate vanity licenses. Companies now have complex FOSS policy agendas, and those agendas are not to guarantee software freedom for all. While it is annoying that our community must again confront an old threat, we are fortunate the problem is not hidden: companies proposing their own licenses are now straightforward about their new FOSS licenses' purposes: to maximize profits.
Open-in-name-only licenses are now common, but seem like FOSS licenses only to the most casual of readers. We've succeeded in convincing everyone to “check the OSI license list before you buy”. We can therefore easily dismiss licenses like Common Clause merely by stating they are non-free/non-open-source and urging the community to avoid them. But, the next stage of tactics have begun, and they are harder to combat. What happens when for-profit companies promulgate their own hyper-aggressive (quasi-)copyleft licenses that seek to pursue the key policy goal of “selling proprietary licenses” over “defending software freedom”? We're about to find out, because, yesterday, MongoDB declared themselves the arbiter of what “strong copyleft” means.
Understanding MongoDB's Business Model
To understand the policy threat inherent in MongoDB's so-called “Server Side Public License, Version 1”, one must first understand the fundamental business model for MongoDB and companies like them. These companies use copyleft for profit-making rather than freedom-protecting. First, they require full control (either via ©AA or CLA) of all copyrights in the work, and second, they offer two independent lines of licensing. Publicly, they provide the software under the strongest copyleft license available. Privately, the same (or secretly improved) versions of the software are available under fully proprietary terms. In theory, this could be merely selling exceptions: a benign manner of funding more Free Software code — giving the proprietary option only to those who request it. In practice — in all examples that have been even mildly successful (such as MongoDB and MySQL) — this mechanism serves as a warped proprietary licensing shake-down: “Gee, it looks like you're violating the copyleft license. That's a shame. I guess you just need to abandon the copyleft version and buy a proprietary license from us to get yourself out of this jam, since we don't plan to reinstate any lost rights and permissions under the copyleft license.” In other words, this structure grants exclusive and dictatorial power to a for-profit company as the arbiter of copyleft compliance. Indeed, we have never seen any of these companies follow or endorse the Principles of Community-Oriented GPL Enforcement. While it has made me unpopular with some, I still make no apologies that I have since 2004 consistently criticized this “proprietary relicensing” business model as “nefarious”, once I started hearing regular reports that MySQL AB (now Oracle) asserts GPL violations against compliant uses merely to scare users into becoming “customers”. Other companies, including MongoDB, have since emulated this activity.
Why Seek Even Stronger Copyleft?
The GNU Affero General Public License (AGPL) has done a wonderful job defending the software freedom of community-developed projects like Mastodon and Mediagoblin. So, we should answer with skepticism a solitary for-profit company coming forward to claim that “Affero GPL has not resulted in sufficient legal incentives for some of the largest users of infrastructure software … to participate in the community. Many open source developers are struggling with a similar reality”. If the last sentence were on Wikipedia, I'd edit it to add a Citation Needed tag, as I know of no multi-copyright-held or charity-based AGPL'd project that has “struggled with this reality”. In fact, it's only a “reality” for those that engage in proprietary relicensing. Eliot Horowitz, co-founder of MongoDB and promulgator of their new license, neglects to mention that.
The most glaring problem with this license, which Horowitz admits in his OSI license-review list post, is that there was no community drafting process. Instead, a for-profit company, whose primary goal is to use copyleft as a weapon against the software-sharing community for the purpose of converting that “community” into paying customers, published this license as a fait accompli without prior public discussion of the license text.
If this action were an isolated incident by one company, ignoring it is surely the best response. Indeed, I urged everyone to simply ignore the Commons Clause. Now, we see a repackaging of the Commons Clause into a copyleft-like box (with reuse of Commons Clause's text such as “whose value derives, entirely or substantially, from the functionality of the Software”). Since both licenses were drafted in secret, we cannot know if the reuse of text was simply because the same lawyer was employed to write both, or if MongoDB has joined a broader and more significant industry-wide strategy to replace existing FOSS licensing with alternatives that favor businesses over individuals.
The Community Creation Process Matters
Admittedly, the history of copyleft has been one of slowly evolving community-orientation. GPLv1 and GPLv2 were drafted in private, too, by Richard Stallman and FSF's (then) law firm lawyer, Jerry Cohen. However, from the start, the license steward was not Stallman himself, nor the law firm, but the FSF, a 501(c)(3) charity dedicated to serve the public good. As such, the FSF made substantial efforts in the GPLv3 process to reorient the drafting of copyleft licenses as a public policy and legislative process. Like all legislative processes, GPLv3 was not ideal — and I was even personally miffed to be relegated to the oft-ignored “GPLv3 Discussion Committee D” — but the GPLv3 process was undoubtedly a step forward in FOSS community license drafting. Mozilla Corporation made efforts for community collaboration in redrafting the MPL, and specifically included the OSI and the FSF (arbiters of the Open Source Definition and Free Software Definition (respectively)) in MPL's drafting deliberations. The modern acceptable standard is a leap rather than a step forward: a fully public, transparent drafting process with a fully public draft repository, as the copyleft-next project has done. I think we should now meet with utmost suspicion any license that does not use copyleft-next's approach of “running licensing drafting as a Free Software project”.
I was admittedly skeptical of that approach at first. What I have seen six years since Richard Fontana started copyleft-next is that, simply put, the key people who are impacted most fundamentally by a software license are mostly likely to be aware of, and engage in, a process if it is fully public, community-oriented, and uses community tools, like Git.
Like legislation, the policies outlined in copyleft licenses impact the general public, so the general public should be welcomed to the drafting. At Conservancy, we don't draft our own licenses0, so our contracts with software developers and agreements with member projects state that the licenses be both “OSI-approved Open Source” and “FSF-approved GPL-compatible Free Software”. However, you can imagine that Conservancy has a serious vested interest in what licenses are ultimately approved by the OSI and the FSF. Indeed, with so much money flowing to software developers bound by those licenses, our very charitable mission could be at stake if OSI and the FSF began approving proprietary licenses as Open, Free, and/or GPL-compatible. I want to therefore see license stewards work, as Mozilla did, to make the vetting process easier, not harder, for these organizations.
A community drafting process allows everyone to vet the license text early and often, to investigate the community and industry impact of the license, and to probe the license drafter's intent through the acceptance and rejection of proposed modified text (ideally through a DVCS). With for-profit actors seeking to gain policy control of fundamental questions such as “what is strong copyleft?”, we must demand full drafting transparency and frank public discourse.
The Challenge Licensing Arbiters Face
OSI, FSF, and Debian have a huge challenge before them. Historically, the FSF was the only organization who sought to push the boundary of strong copyleft. (Full disclosure: I created the Affero clause while working for the FSF in 2002, inspired by Henry Poole's useful and timely demands for a true network services copyleft.) Yet, the Affero clause was itself controversial. Many complained that it changed the fundamental rules of copyleft. While “triggered only on distribution, not modification” was a fundamental rule of the regular GPL, we as a community — over time and much public debate — decided the Affero clause is a legitimate copyleft, and AGPL was declared Open Source by OSI and DFSG-free by Debian.
That debate was obviously framed by the FSF. The FSF, due to public pressure, compromised by leaving the AGPL as an indefinite fork of the GPL (i.e., the FSF did not include the Affero clause in plain GPL. While I personally lobbied (from GPLv3 Discussion Committee D and elsewhere) for the merger of AGPL and GPL during the GPLv3 drafting process, I respect the decision of the FSF, which was informed not by my one voice, but the voices of the entire community.
Furthermore, the FSF is a charity, chartered to serve the public good and the advancement of software freedom for users and developers. MongoDB is a for-profit company, chartered to serve the wallets of its owners. While MongoDB employees1 (like those of any other company) should be welcomed on equal footing to the other unaffiliated individuals, and representatives of companies, charities, and trade-associations to the debate about the future of copyleft, we should not accept their active framing of that debate. By submitting this license to OSI for approval without any public community discussion, and without any discussion whatsoever with the key charities in the community, is unacceptable. The OSI should now adopt a new requirement for license approval — namely, that licenses without a community-oriented drafting process should be rejected for the meta-reason of “non-transparent drafting”, regardless of their actual text. This will have the added benefit of forcing future license drafters to come to OSI, on their public mailing lists, before the license is finalized. That will save OSI the painstaking work of walking back bad license drafts, which has in recent years consumed much expert time by OSI's volunteers.
Welcoming All To Public Discussion
Earlier this year, Conservancy announced our plans to host and organize the first annual CopyleftConf. We decided to do this because we seek to create a truly neutral, open, friendly, and welcoming forum for discussion about the past and future of copyleft as a strategy for defending software freedom. We had no idea when we first mentioned the possibility of running CopyleftConf (during the Organizers' Panel at the end of the Legal and Policy DevRoom at FOSDEM 2018 in February 2018) that multiple companies would come forward and seek to control the microphone on the future of copyleft. Now that MongoDB has done so, I'm very glad that the conference is already organized and on the calendar before they did so.
Despite my criticisms of MongoDB, I welcome Eliot Horowitz, Heather Meeker (the law firm lawyer who drafted MongoDB's new license and the Commons Clause), or anyone else who was involved in the creation of MongoDB's new license to submit a talk. Conservancy will be announcing soon the independent group of copyleft experts (and critics!) who will make up the Program Committee and will independently evaluate the submissions. Even if a talk is rejected, I welcome rejected proposers to attend and speak about their views in the hallway track and the breakout sessions.
One of the most important principles in copyleft policy that our community has learned is that commercial, non-commercial, and hobbyist activity3 should have equal footing with regard to rights assured by the copyleft licenses themselves. There is no debate about that; we all agree that copyleft codebases become meeting places for hobbyists, companies, charities, and trade associations to work together toward common goals and in harmony and software freedom. With this blog post, I call on everyone to continue on the long road to applying that same principle to the meta-level of how these licenses are drafted and how they are enforced. While we have done some work recently on the latter, not enough has been done on the former. MongoDB's actions today give us an opportunity to begin that work anew.
0 While Conservancy does not draft any main FOSS license texts, Conservancy does help with the drafting of additional permissions upon the request of our member projects. Note that additional permissions (sometimes called license exceptions) grant permission to engage in activities that the main license would otherwise prohibit. As such, by default, additional permissions can only make a copyleft license weaker, never stronger.
1, 3 I originally had “individual actors” here instead of “hobbyist activity”, and additionally had expressed poorly the idea of welcoming individuals representing all types of entities to the discussion. The miscommunication in my earlier text gave one person the wrong impression that I believe the rights of companies should be equal to the rights of individuals. I fundamentally believe that companies and organizations should not have rights of personhood and I've updated the text in an effort to avoid such confusions.
Software Freedom Ensures the True Software Commons
byon August 22, 2018
Proprietary software has always been about a power relationship. Copyright and other legal systems give authors the power to decide what license to choose, and usually, they choose a license that favors themselves and takes rights and permissions away from others.
The so-called “Commons Clause” purposely confuses and conflates many issues. The initiative is backed by FOSSA, a company that sells materiel in the proprietary compliance industrial complex. This clause recently made news again since other parties have now adopted this same license.
This proprietary software license, which is not Open Source and does not
respect the four freedoms of Free Software, seeks to hide a power imbalance
ironically behind the guise “Open Source sustainability”. Their
argument, once you look past their assertion that
the only way to save Open
Source is to not do open source, is quite plain:
If we can't make money as
quickly and as easily as we'd like with this software, then we have to make
sure no one else can as well.
These observations are not new. Software freedom advocates have always admitted that if your primary goal is to make money, proprietary software is a better option. It's not that you can't earn a living writing only Free Software; it's that proprietary software makes it easier because you have monopolistic power, granted to you by a legal system ill-equipped to deal with modern technology. In my view, it's a power which you don't deserve — that allows you to restrict others.
Of course, we all want software freedom to exist and survive sustainably. But the environmental movement has already taught us that unbridled commerce and conspicuous consumption is not sustainable. Yet, companies still adopt strategies like this Commons Clause to prioritize rapid growth and revenue that the proprietary software industry expects, claiming these strategies bolster the Commons (even if it is a “partial commons in name only”). The two goals are often just incompatible.
Here at Conservancy, we ask our projects to be realistic about revenue. We don't typically see Conservancy projects grow at rapid rates. They grow at slow and steady rates, but they grow better, stronger, and more diverse because they take the time to invite everyone to get involved. The software takes longer to mature, but when it does it's more robust and survives longer.
I'll take a bet with anyone who'd like. Let's pick five projects under the Affero GPL and five projects under the Commons Clause, and then let's see which ones survive longer as vibrant communities with active codebases and diverse contributors.
Finally, it's not surprising that the authors chose the name “Commons”. Sadly, “commons” has for many years been a compromised term, often used by those who want to promote licenses or organizational models that do not guarantee all four freedoms inherent in software freedom. Proprietary software is the ultimate tragedy of the software commons, and while it's clever rhetoric for our opposition to claim that they can make FOSS sustainable by proprietarizing it, such an argument is also sophistry.