John Sullivan on free software and corporations

[Carsten Agger]

A really good discussion from the outgoing FSF director:


https://www.fsf.org/bulletin/2021/spring/thinking-clearly-about-corporations


For software to be considered free, its license must allow for 
commercial use and redistribution. Yet, free software as a social 
movement is to a large extent a struggle against for-profit corporate 
control of our lives.

Instead of telling companies they are not welcome in free software, we 
say they are welcome if they follow the ethical principles -- the Four 
Freedoms. In our engagement with them, we see both positive and negative 
impacts. We also see some parts of the community being overly solicitous 
of corporate support, and other parts describing even seemingly positive 
actions as necessarily part of a long con to eventually extinguish free 
software.

We need to think clearly -- somewhere between these extremes -- about 
corporate involvement, neither falling over ourselves to invite it, nor 
being so endlessly suspicious that we miss out on valuable contributions 
and ultimately fail to change the practices of a significant sector of 
global society.

Clear thinking begins with seeing for-profit corporations for what they 
are: for-profit organizations. They are not individuals. A company's 
behaviors can change dramatically, not just from change in the 
individuals they employ, but also from changes in leadership, ownership, 
or business circumstances.

These are not hypothetical concerns. In free software, many eyes are now 
on Red Hat, to see if its behavior toward free software will change as a 
result of being bought by IBM. We saw Redis Labs switch some of its 
software from a free license to a nonfree one which ironically prohibits 
commercial re-use. We've seen Google in the past decide to withhold the 
source code for Android. We've seen Microsoft switch from publicly 
calling free software a cancer to saying "We are all in on open source."

Companies can commit valuable resources to actions that benefit the free 
software movement. They can hire developers, sponsor events, fund 
advocacy and education, and provide infrastructure. Individuals can 
convince their employers to release code under a free license, and to 
distribute it with their products. They can even persuade the company to 
pursue certification under the FSF's Respects Your Freedom program 
<https://ryf.fsf.org/>.

These contributions are meaningful. The challenge is, how do we realize 
them while avoiding the ways corporations can hurt free software? We 
need to avoid financial dependency, keep our standards high, and rely on 
a solid legal framework rather than vague trust.

Avoiding financial dependency means making sure our operations as free 
software projects and organizations won't be seriously harmed by a 
corporation withdrawing its support due to a disagreement or an 
ownership change. As an example, while we appreciate and make productive 
use of all the direct corporate patron support we receive at the FSF, in 
our last audited financial year, it was less than 3% of our total revenue.

To keep standards high, free software projects and organizations should 
be conservative in what we offer in return for contributions. As with 
any donation, specific public recognition and appreciation can make 
sense. But selling conference keynotes, for example, takes the 
interaction out of the realm of a donation and makes it a transaction. 
Plus, when some events offer the moon in exchange for sponsorships, it 
puts more pressure on other events to do so.

Relying on a solid legal framework means relying on copyleft, and on 
explicit, enforceable statements about who holds relevant rights when a 
contribution is made by the employee of a company. The GNU General 
Public License (GPL) has enabled decades of constructive engagement, 
because it requires companies to give back improvements they distribute, 
under the same terms to everyone, and its terms don't change even with 
new company leadership or after an acquisition. For certain GNU 
packages, the FSF gets additional assurances, in the form of copyright 
assignments and employer disclaimers, to help make sure we can 
effectively uphold these license terms according to the Principles of 
Community-Oriented GPL Enforcement, and can protect all of the program's 
users from patent or other ownership claims by contributors' employers.

We should stay watchful and firm on these points. Over the last year, I 
have seen firsthand multiple cases of Google employees encouraging 
projects to relax their license from the Affero General Public License 
(AGPL), because of Google's wrong-headed policy forbidding any 
involvement by employees with AGPL projects. If you receive pressure 
like this from any company, stay strong and explain how copyleft is in 
the best interest of all contributors to the project (also, tell us your 
story at info at fsf.org <mailto:info at fsf.org>).

A person is capable of moral commitments outside of legal agreements, 
but accountability for companies works differently. This position isn't 
based on conspiracy, or on assumptions about corporate employees. It is 
based on relating to for-profit companies as the kind of entity they 
are. If we avoid dependency, keep our standards high, and ensure the 
terms of our work together are copyleft, we can edge the corporate 
sector ever closer to fully embracing free software, which will in turn 
help us move all sectors of society in that direction, securing freedom 
and autonomy for all.

/On a personal note, I'll be finishing my term as FSF's executive 
director before the next issue of the Bulletin is published, so this 
will be my last article. It's been an honor to appear here, to have had 
this chance to contribute to important ongoing conversations in this 
community. We'll be publishing details about the transition to a new 
executive director on fsf.org. Please continue supporting the work of 
the FSF's incredible staff, some highlights of which are described in 
the rest of this issue -- and all the future issues to come!/

//
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fsfe.org/pipermail/discussion/attachments/20210702/356829dc/attachment.htm>