In the 20 years since its inception, open source has turned out to be the most successful model for building software. The world today runs on open-source software (OSS). An ecosystem has been created around OSS. Businesses and software builders use OSS directly or indirectly, while others offer services and products based on OSS.

OSS is perceived as being free, fair and/or ethical. This perception, however, may not be entirely true. That may be counter-intuitive, but it’s at the heart of the debate around OSS. As OSS is growing up, it’s becoming more successful, more complex, and ubiquitous. It seems we are entering a new phase for OSS, and it’s not without growing pains.

Commercial OSS in the cloud

The four essential freedoms are a cornerstone of OSS. They refer to what users can do with the software, but they tell us nothing about the economic cost, or benefit, related to the software. OSS is free as in speech, but not free as in beer. Someone has to build the software, and then someone has to maintain, run, and manage it.

As far as the perception of OSS being fair or ethical goes: it’s just that – a perception. The perception stems from the OSS community ethos, but in reality, the OSS freedoms are at odds with notions of fair or ethical use. Anyone can contribute as much or as little as they please to OSS. Anyone can use OSS for any purpose, regardless of contribution.

This has led to where we are today. Cloud vendors like AWS, Google or Microsoft, have built their infrastructure based on OSS. Each of them also contributes to OSS in many ways, including code and outreach for existing OSS projects, as well as establishing new OSS projects. But use of, or contribution to, each OSS project is not really accounted for.

Recently, the Apache Software Foundation, one of the key OSS institutions, celebrated its 20th anniversary. The ASF claims the value of the software under its auspices is around $20 Billion, by its own estimates. Everyone is entitled to use the software for free, and many do. But the ones who create this value are the ones who contribute to OSS, be it in code or in other ways.

As analyses have shown, many OSS contributors do this because they are intrinsically motivated: the software is interesting to them, they need it, or they feel good about their contribution. In that respect, they are not much different from vendors that have chosen to build OSS products. Those vendors have invested in their OSS, and their ROI depends on it.

Which brings us to cloud vendors. As many pundits note, cloud vendors operate on a whole different plane. If commercial OSS vendors are about taking innovation from 0 to 1, cloud vendors are about taking it from 1 to n. This brings value in and by itself. Cloud vendors also release OSS projects of their own, and contribute to existing ones. Their strategies, however, differ, and this is where things get complicated.

AWS is the leader in the cloud market. The strategy AWS has adopted with regards to OSS, however, has exposed it to criticism. Recently, an independent data-driven analysis was done on GitHub, where OSS code lives. The analysis showed that in terms of code, AWS does not seem to be contributing much to the development of the OSS products it offers as a service.

It’s understandable why vendors building those products are looking to tweak their licenses to disallow AWS from running their software as a service. It’s also understandable why the OSI, which has control over OSS licenses, is pushing back: by introducing those tweaks, the software is no longer OSS.

If this was just a clash of commercial interests, we might be getting our pop corn to watch. But for something with such high value to society at large as OSS, the ramifications are important. Is there a way everyone involved can get a fair share of the profit, and keep contributing to OSS? Let’s hear what 2 CEOs from vendors who build OSS, and work with AWS, have to say.

The co-opetition view: one big act vs. many small ones

Dor Laor is the founder and CEO of ScyllaDB, an OSS vendor with an interesting story. ScyllaDB was built on a contentious premise, as it is a re-implementation of another OSS database: Apache Cassandra. Laor has shared thoughts on OSS license changes, as well as Amazon’s latest move to offer Cassandra as a managed service on AWS cloud.

Our discussion started touching upon ScyllaDB’s latest features. According to Laor, these features (most prominently lightweight transactions) do not just bring parity with Cassandra, but go one step further. Laor expanded on the technical aspects of ScyllaDB’s solution. As these seemed technically sound, yet conceptually simple, the discussion moved to a broader topic.

Laor claimed none of ScyllaDB’s closest matches, namely Apache Cassandra and AWS DynamoDB, have such features. When asked why he thinks that is, given the nature of those features, Laor offered 2 answers.

For Cassandra, he mentioned that for the last few years its former main contributor, namely DataStax, has taken a step back. Naturally, this has stalled Cassandra’s development considerably. As for AWS, Laor noted that AWS has the tendency to offer products that are good enough, but not necessarily the best in their league.

As ScyllaDB is also available on AWS, and Laor was present at AWS’s main event, re:Invent, in 2019, he offered a metaphor to explain this. Laor said there were a number of stages set up for various acts in the re:Invent after party, and he found all of them mediocre. Laor went on to add that he sees that as a metaphor for AWS’ philosophy of going wide, rather than deep in its undertakings. This is a point shared in other OSS vendor strategies, too.

But ScyllaDB went beyond that, to do something no other OSS vendor we know of has done before: offer a compatibility layer for one of AWS’ products, namely DynamoDB. ScyllaDB’s DynamoDB API support will be officially available soon, and it will enable DynamoDB users to migrate to ScyllaDB. Laor said there is a waiting list for this.

This is technically feasible, and legally permissible. Unless things change, there are no restrictions on using APIs, as per the famous Oracle vs. Google case verdict. While some of AWS’ own people questioned this move, Laor claimed users are better off using ScyllaDB. In turn, this opens up some interesting questions. What about ethics, and contribution?

Building a new implementation of an existing API seems cleaner than using someone else’s implementation, but it still means benefiting from a userbase others built. Laor acknowledged that, as well as the fact that ScyllaDB leverages contributions from Amazon, Cassandra, and DataStax. He also pointed out that this spurs innovation and benefits users, and measuring contribution is very hard.

ScyllaDB has an open core strategy. Some features are proprietary, while the OSS core is licensed under AGPL, which Laor said AWS avoids. So far this has worked in deterring AWS from offering ScyllaDB as a service, although it could also be that ScyllaDB has not reached critical mass yet. In any case, as Laor said, these things change.

The collaboration view: balancing OSS makers and takers

Most OSS products fall under one of two categories. Many products are largely driven by a single vendor, whose employees contribute most of the related effort and drive its directions. Other products leverage contributions that cross-cut organizations who employ the contributors; often, OSS work is the main activity for such contributors.

But there is an OSS product in which the vendor commercializing it only contributes 5% of its code while still being the largest contributor. The product is commercially successful, has a community-driven decision making process, and is a distinguished AWS partner, too. And these are not the only reasons why Acquia, the vendor commercializing the Drupal CMS, and Dries Buytaert, its founder, stand out.

Recently, Buytaert shared his thoughts on balancing OSS makers and takers in an elaborate blog post. In our discussion, Buytaert confessed it took him a couple of weeks to put his post together. This is understandable, considering how many aspects of OSS it touches upon.

Drupal started in 2000, while Acquia was founded in 2007. As Buytaert highlighted, Acquia and the Drupal community have a unique relationship, which is formally documented in a charter. The community includes about 80.000 contributors, while Aquia employs about 1.000 people.

Yet, Drupal’s governance is not with Acquia. The community sets Drupal’s roadmap, and elects people in leadership roles. People choose to contribute to areas that matter most to them, and Acquia does this, too. Buytaert said that even when there is a decision Acquia does not agree with, the decision is carried through, if there is substantial backing for it.

Buytaert builds on the notion of OSS as part of the Commons, introducing an important distinction. For end users, OSS projects are public goods; the shared resource is the software. But for OSS companies, OSS projects are common goods; the shared resource is the (potential) customer. Makers invest heavily in the software, takers are mostly interested in customers.

Buytaert, leveraging Elinor Ostrom’s work in addition to his own experience, seems to have gotten to the heart of the issue. Research shows that when the Commons are left unchecked, without governance or rules for contribution, they collapse: shared resources are either engulfed or exhausted.

Organizations like the ASF and the OSI have done a good job in making OSS successful. But now that OSS is successful, without a mechanism for fair reward in place, we have no reason to believe OSS will not have the fate of Commons that preceded it. This is why we wondered whether the OSI should perhaps reconsider. Apparently, we are not the only ones, and the OSI seems to be listening.

Ethical software

First off, there seems to be an ongoing debate within the OSI itself as to what should constitute an OSS license today. This goes to show that what worked 20 years ago is not necessarily what works today. In addition, more and more people seem to be realizing the OSS conundrum, and are sharing ideas to move forward. Buytaert, on his part, offers 3 concrete proposals.

One, don’t just appeal to organizations’ self-interest, but also to their fairness principles. Two, encourage end users to offer selective benefits to Makers. Three, experiment with new licenses. Those points were also backed by Laor, who prompted users to consciously vet their OSS providers for fairness, and pointed to precedents like the Open Invention Network.

One thing is clear: AWS should not be excluded, it’s a vital part of the OSS ecosystem. The fact that this is a complex ecosystem with many actors that need to strike a balance is something many people agree on. This includes Buytaert, Laor, and AWS VP/Distinguished Engineer Matthew Wilson, a self-proclaimed “OSS romantic”, to name but a few.

Buytaert also agreed with Laor that while AWS is a good partner to have, if it decided to start offering ScyllaDB or Drupal as a managed service on its own, there would be nothing they could do to stop it. Buytaert was also clear on something else: making OSS sustainable may require a break with OSS as we know it. But if that’s what it takes, so be it.

This also seems to be the gist of Wilson’s position as stated in a number of Twitter threads: this is how OSS works. If you are not happy with it, do it differently – just don’t call it OSS. This is a fair point, made by others, too. Recently Stephen Walli, principal program manager on the Azure engineering team at Microsoft and an OSS veteran, shared his ideas on Software Freedom in a Post Open Source World.

Walli went through the history of OSS, the four essential freedoms, and the ways and reasons people challenge how OSS works. Walli’s message is along similar lines: “I am happy for people to challenge the ideas that define our software collaborations and culture of outbound sharing. But I want them to be bold. If you want to define a new movement then do so.”

Some people call it Commercial OSS, others Cloud Native OSS. Either way, it’s not just commercial interests that question how OSS works today. It’s also people concerned about the ethical implications of OSS. Although it could be argued that fairness touches upon ethics too, Coraline Ada Ehmke and the Ethical Source Movement (ESM) have a somewhat different angle.

Ehmke, who founded the ESM, is a software engineer, a public speaker, and has been an active OSS participant since the early 2000s. Ehmke, who previously stated that “OSI and FSF are not the real arbiters of what is Open Source and what is Free Software” is now running for the board of directors of the OSI, and the OSI’s VP seems open to engaging with her. The ESM states:

“Today, the same OSS that enriches the commons and powers innovation also plays a critical role in mass surveillance, anti-immigrant violence, protester suppression, racist policing, the deployment of cruel and inhumane weapons, and other human rights abuses all over the world.

We want to do something about this misuse of our software. But as developers we don’t seem to have any recourse, no way to prevent our work from being used to harm others. We want to change that”.

Fair software

The definition of Ethical Software breaks with the four essential freedoms of OSS, creating licenses such as the Hippocratic or the Atmosphere Licenses. This raises questions, including how to enforce such licenses. Though a definite answer is not readily available, for the time being the thinking seems to be that fear of exposure of illegal use should work on a first level. People seem sympathetic to the notion.

Ethical software licenses are not the only OSS variant around, however. There is also the Fair Source License, allowing users to view, download, execute, and modify code free of charge. Up to a certain number of users from an organization can use the code for free, too. After an organization hits that user limit, it will start paying a licensing fee determined by the software publisher.

Fair Source was created by Sourcegraph and drafted by Heather Meeker, a prominent OSS lawyer who also drafted the Commons Clause for RedisLabs. Fair Source got featured on Wired, and received praise from GitLab, but it does not look like it got much traction. The reason is probably that as things stand, Fair Source is also not an OSS compatible license.

This all seems to be pointing somewhere: perhaps we’ve reached the limits of what OSS in its current form can do. People are realizing it, and questioning the status quo. Whether that will lead somewhere, remains to be seen. But some first steps are taken, and the potential seems to be there. OSS was a bold step in its time, too, and its pioneers paved the way.

To wrap up, let us revisit the “quantifying OSS contribution is hard, and it’s not only about code” argument. This is true beyond the shadow of a doubt. But before dismissing quantification as mission impossible, we should consider a few things.

Commercial OSS vendors are building platforms to power today’s data-driven economy. As a 3rd party analysis on GitHub data shows, they -expectedly- seem to be key contributors to their own codebases. While there may be communities of practice built around the products, in most cases we would assume vendors do much of the non-code work too – promotion, support etc.

OSS vendors have people who contribute to these tasks in their payrolls. Presumably, these people leave the digital footprint of their work on all sorts of systems. From OSS code repositories to issue trackers, HR, project management tools and spreadsheets, to social media. Nobody should be more motivated or better positioned to develop a holistic, data-driven model for OSS contribution, than commercial OSS vendors.

Doing this would make their claims much more grounded. To be entirely fair, commercial OSS vendors should also apply this to external contributions, be it from individuals or from organizations such as cloud vendors. And to back claims about putting OSS sustainability and the common good first, changing their status to B Corporation to reflect that might help, too.

To get over the OSS midlife crisis, and make software great again, leadership is paramount. There is no doubt the amount of legal, social, software, and data engineering needed to evolve OSS is staggering. But OSS is so important, that it would be irresponsible to shy away from it. Some OSS leaders are showing the way. Opinions may vary, but the issue is being acknowledged. Who would not want to have ethical, fair, open-source software available on demand in the cloud?

This is a chance for everyone to put their data to good use. Amazon, as well as commercial OSS vendors, are leaders, each in their own way. They have great power, which comes with great responsibility. The way other cloud vendors deal with OSS vendors may not be perfect, but it’s a start. We’d like to see that taken to the next level, and involving the entire industry.

Coming up with a way to fix commercial OSS by measuring and rewarding contribution is something that will not just benefit vendors, but the world at large. So if not them, who? If not now, when?

Originally published on Linked Data Orchestration under CC BY-SA 4.0

The post Make software great again: can open source be ethical and fair? appeared first on P2P Foundation.

Written Steven J. Vaughan-Nichols for Linux and Open Source, originally posted on ZDNet on August 28, 2018

Most people wouldn’t know an open-source license from their driver’s license. For those who work with open-source software, it’s a different story. Open-source license fights can be vicious, cost serious coin, and determine the fate of multi-million dollar companies. So, when Redis Labs added a new license clause, Commons Clause, on top of Redis, an open-source, BSD licensed, in-memory data structure store, all hell broke loose.

Why? First, you need to understand that while you may never have heard of Redis, it’s a big deal. It enables real-time applications such as advertising, gaming financial services, and IoT to work at speed. That’s because it can deliver sub-millisecond response times to millions of requests per second.

But Redis Labs has been unsuccessful in monetizing Redis, or at least not as successful as they’d like. Their executives were discovering, like the far more well-known Docker, that having a great open-source technology did not mean you’d be making millions. Redis’ solution was to embrace Commons Clause.

This license forbids you from selling the software. It also states you may not host or offer consulting or support services as “a product or service whose value derives, entirely or substantially, from the functionality of the software”.

If that doesn’t sound like open-source software to you, you have lots of company.

Simon Phipps, president of the Open Source Initiative (OSI), snapped on Twitter: “Redis just went proprietary, which sucks. No, this is not just ‘a limitation concerning fair use,’ it is an abrogation of software freedom.”

In an email, Phipps added, “Adding a significant clause to an existing license that has been approved by OSI instantly renders it non-approved, and the text of the so-called ‘Commons Clause,’ which actually fences off the commons, is clearly intended to violate clause 1 of the Open Source Definition and probably also violates clauses 3, 5 and 6. As such adding this clause to a license would be a major abrogation of software freedom removing essential rights from any affected open-source community.”

Software programmer Drew DeVault made his stance clear from his opening words: “Commons Clause will destroy open source.” Commons Clause, he continued, “presents one of the greatest existential threats to open source I’ve ever seen. It preys on a vulnerability open-source maintainers all suffer from, and one I can strongly relate to. It sucks to not be able to make money from your open-source work. It really sucks when companies are using your work to make money for themselves. If a solution presents itself, it’s tempting to jump at it. But the Commons Clause doesn’t present a solution for supporting open-source software. It presents a framework for turning open-source software into proprietary software.”

Bradley M Kuhn, president of the Software Freedom Conservancy and author of the Affero General Public License, blogged, “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.”

Andrew ‘Andy’ Updegrove, a founding partner of Gesmer Updegrove, a top technology law firm, and open-source legal expert, found it no surprise that many open-source supporters hate Commons Clause. He rejects the conspiracy theory, “that the Commons Clause will be some sort of virus that will deprive innocent developers of the ability to make a living, and will persuade businesses owners to avoid buying or using code that has any commons clause in it.”

Updegrove believes this is because Heather Meeker, a partner at O’Melveny law firm who drafted it, “is a respected attorney and long-term participant in open-source legal circles, so IMHO the conspiracy theory can be ignored. Note also that Kevin Wang [founder of FOSSA]and Heather have both offered the clause as text to initiate a discussion, and not something to be wholesale adopted as it stands.”

That didn’t stop Redis Labs, which is applying Commons Clause on top of the Apache license, to cover five new Redis modules. Redis is doing this, said its co-founder and CTO Yiftach Shoolman in an email, “for two reasons — to limit the monetization of these advanced capabilities by cloud service providers like AWS and to help enterprise developers whose companies do not work with AGPL licenses.”

On the Redis Labs site, the company now explains in more detail that cloud providers are taking advantage of open-source companies by repackaging their programs into competitive, proprietary-service offerings. These providers contribute very little — if anything — back to those open-source projects. Instead, they use their monopolistic nature to derive hundreds of millions of dollars in revenues from them.

Redis Labs contends that “most cloud providers offer Redis as a managed service over their infrastructure and enjoy huge income from software that was not developed by them. Redis Labs is leading and financing the development of open source Redis and deserves to enjoy the fruits of these efforts.” Shoolman insisted that “Redis is open source and will remain under a BSD license.”

Salvatore Sanfilippo, Redis’ creator, added the change just “means that basically certain enterprise add-ons, instead of being completely closed source as they could be, will be available with a more permissive license,” Commons Clauses with Apache.

Software Freedom Conservancy executive director Karen Sandler isn’t so sure. Sandler emailed that Commons Clause “highlights the fundamental problems connected to the wide adoption of non-copyleft licenses, but I think it doesn’t really solve the problem that it seeks to solve. What we really need is strong copyleft licenses where the copyrights are held diversely by individuals and functional charities to make sure that software remains free and that societally we have the rights we need to have confidence in our software in the long run.”

In an email, Wang defended Commons Clause as “mostly used to temporarily transition enterprise offering counterparts of open-source software projects to source-available”. Wang continued: “Open-source software projects are mainly funded by a proprietary offering/service counterparts. Anything to help this layer monetize is good — the fate of the OSS is directly funded by it.

“The world has changed a lot and the open-source software/cloud ecosystem has a lot too,” Wang added. “The Open Source Definition is an immensely [valuable] set of ideals, but maybe it’s outdated to the modern state of the world. … Licensing follows intent, and I certainly don’t think the clause inspires people to close their source. But sometimes people need to change their license.”

Be that as it may, Updegrove wrote Commons Clause is “simple in concept: basically, it gives a developer the right to make sure no one can make money out of her code — whether by selling, hosting, or supporting it — unless the Commons Clause code is a minor part of a larger software product”.

“In one way, that’s in the spirit of a copyleft license (i.e., a prohibition on commercial interests taking advantage of a programmer’s willingness to make her code available for free), but it also violates the ‘Four Freedoms’ of free and open-source software as well as the Open Source Definition by placing restrictions on reuse, among other issues.”

But, “adding the Commons Clause to an open-source license makes it no longer an open-source license,” Updegrove added. And, were the Commons Clause to catch on, “it could give rise to an unwelcome trend”.

“The wide proliferation of licenses in the early days of open source was unhelpful and a cause of ongoing confusion and complexity, since not all licenses were compatible with other licenses. That means that before any piece of open-source code can be added to a code base, it’s necessary to determine whether its license is compatible with the licenses of all other software in the same product. That’s a big and ongoing headache.”

That’s a big reason, Updegrove wrote, why “Bruce Perens and Eric S. Raymond created the Open Source Definition and the Open Source Initiative so that there would be a central reference point and authority to determine what was and was not an ‘Open Source License’. That definition and process has held now for 20 years — an eternity, in open-source history.”

Therefore, Updegrove sees Commons Clause as a step backward from a process point of view. Worse, “it would be a very disturbing development if the release of the Commons Clause inspired more people to come up with their own license ‘extensions’, especially if they are also not compliant with the Open Software Definition and the Four Freedoms.”

The result? Companies and programmers veering away from using any Commons Clause licensed software. That was not its creators’ intent, but it’s a realistic concern.

Updegrove adds, “Speaking as a lawyer, the fact that someone can still charge for a product that includes Commons Clause software so long as the value does not ‘derive[s], entirely or substantially, from the functionality of the software’ is certain to invite disputes. The most obvious is what does ‘substantially’ [mean]? There is no bright-line for guidance.”

Georg Greve, co-founder and president at Vereign, a blockchain-secured communication company and founder of Free Software Foundation Europe, also worried, “Overall it seems purposefully vague & misleading, probably overreaching and terribly one-sided to establish Fear, Uncertainty, and Doubt for any professional use of software licensed under it while making it terribly easy to ‘accidentally’ incorporate such components.”

Still, Updegrove thinks Commons Clause may be “a useful addition to the licensing menu, but not one that will be appropriate for use in all situations. … Developers should be clear in advance what their goals are when they’re put their fingers to their keys. Commons Clause-licensed software is not likely to get the same amount of reuse as might otherwise be the case.”

The post Open-source licensing war: Commons Clause appeared first on P2P Foundation.

Mariana Mazzucato¹ has an article in MIT Technology Review titled Let’s make private data into a public good.

Let’s not.

While Mariana’s criticisms of surveillance capitalism are spot on, her proposed remedy is as far from the mark as it possibly could be.

Yes, surveillance capitalism is bad

Mariana starts off by making the case, and rightly so, that surveillance capitalists² like Google or Facebook “are making huge profits from technologies originally created with taxpayer money.”

Google’s algorithm was developed with funding from the National Science Foundation, and the internet came from DARPA funding. The same is true for touch-screen displays, GPS, and Siri. From this the tech giants have created de facto monopolies while evading the type of regulation that would rein in monopolies in any other industry. And their business model is built on taking advantage of the habits and private information of the taxpayers who funded the technologies in the first place.

There’s nothing to argue with here. It’s a succinct summary of the tragedy of the commons that lies at the heart of surveillance capitalism and, indeed, that of neoliberalism itself.

Mariana also accurately describes the business model of these companies, albeit without focusing on the actual mechanism by which the data is gathered to begin with³:

Facebook’s and Google’s business models are built on the commodification of personal data, transforming our friendships, interests, beliefs, and preferences into sellable propositions. … The so-called sharing economy is based on the same idea.

So far, so good.

But then, things quickly take a very wrong turn:

There is indeed no reason why the public’s data should not be owned by a public repository that sells the data to the tech giants, rather than vice versa.

There is every reason why we shouldn’t do this.

Mariana’s analysis is fundamentally flawed in two respects: First, it ignores a core injustice in surveillance capitalism – violation of privacy – that her proposed recommendation would have the effect of normalising. Second, it perpetuates a fundamental false dichotomy ­– that there is no other way to design technology than the way Silicon Valley and surveillance capitalists design technology – which then means that there is no mention of the true alternatives: free and open, decentralised, interoperable ethical technologies.

No, we must not normalise violation of privacy

The core injustice that Mariana’s piece ignores is that the business model of surveillance capitalists like Google and Facebook is based on the violation of a fundamental human right. When she says “let’s not forget that a large part of the technology and necessary data was created by all of us” it sounds like we voluntarily got together to create a dataset for the common good by revealing the most intimate details of our lives through having our behaviour tracked and aggregated. In truth, we did no such thing.

We were farmed.

We might have resigned ourselves to being farmed by the likes of Google and Facebook because we have no other choice but that’s not a healthy definition of consent by any standard. If 99.99999% of all investment goes into funding surveillance-based technology (and it does), then people have neither a true choice nor can they be expected to give any meaningful consent to being tracked and profiled. Surveillance capitalism is the norm today. It is mainstream technology. It’s what we funded and what we built.

It is also fundamentally unjust.

There is a very important reason why the public’s data should not be owned by a public repository that sells the data to the tech giants because it’s not the public’s data, it is personal data and it should never have been collected by a third party to begin with. You might hear the same argument from people who say that we must nationalise Google or Facebook.

No, no, no, no, no, no, no! The answer to the violation of personhood by corporations isn’t violation of personhood by government, it’s not violating personhood to begin with.

That’s not to say that we cannot have a data commons. In fact, we must. But we must learn to make a core distinction between data about people and data about the world around us.

Data about people ≠ data about rocks

Our fundamental error when talking about data is that we use a single term when referring to both information about people as well as information about things. And yet, there is a world of difference between data about a rock and data about a human being. I cannot deprive a rock of its freedom or its life, I cannot emotionally or physically hurt a rock, and yet I can do all those things to people. When we posit what is permissible to do with data, if we are not specific in whether we are talking about rocks or people, one of those two groups is going to get the short end of the stick and it’s not going to be the rocks.

Here is a simple rule of thumb:

Data about individuals must belong to the individuals themselves. Data about the commons must belong to the commons.

I implore anyone working in this area – especially professors writing books and looking to shape public policy – to understand and learn this core distinction.

There is an alternative

I mentioned above that the second fundamental flaw in Mariana’s article is that it perpetuates a false dichotomy. That false dichotomy is that the Silicon Valley/surveillance capitalist model of building modern/digital/networked technology is the only possible way to build modern/digital/networked technology and that we must accept it as a given.

This is patently false.

It’s true that all modern technology works by gathering data. That’s not the problem. The core question is “who owns and controls that data and the technology by which it is gathered?” The answer to that question today is “corporations do.” Corporations like Google and Facebook own and control our data not because of some inevitable characteristic of modern technology but because of how they designed their technology in line with the needs of their business model.

Specifically, surveillance capitalists like Google and Facebook design proprietary and centralised technologies to addict people and lock them in. In such systems, your data originates in a place you do not own. On “other people’s computers,” as the Free Software Foundation calls it. Or on “the cloud” as we colloquially reference it.

The crucial point here, however, is that this toxic way of building modern technology is not the only way to design and build modern technology.

We know how to build free and open, decentralised, and interoperable systems where your data originates in a place that you – as an individual – own and control.

In other words, we know how to build technology where the algorithms remain on your own devices and where you are not farmed for personal information to begin with.

To say that we must take as given that some third party will gather our personal data is to capitulate to surveillance capitalism. It is to accept the false dichotomy that either we have surveillance-based technology or we forego modern technology.

This is neither true, nor necessary, nor acceptable.

We can and we must build ethical technology instead.

Regulate and replace

As I’m increasingly hearing these defeatist arguments that inherently accept surveillance as a foregone conclusion of modern technology, I want to reiterate what a true solution looks like.

There are two things we must do to create an ethical alternative to surveillance capitalism:

1. 1. Regulate the shit out of surveillance capitalists.The goal here is to limit their abuses and harm. This includes limiting their ability to gather, process, and retain data, as well as fining them meaningful amounts and even breaking them up.⁴
   2. Fund and build ethical alternatives.In other words, replace them with ethical alternatives.Ethical alternatives do exist today but they do so mainly thanks to the extraordinary personal efforts of disjointed bands of so-called DIY rebels.

Whether they are the punk rockers of the tech world or its ragamuffins – and perhaps a little bit of both – what is certain is that they lead a precarious existence on the fringes of mainstream technology. They rely on anything from personal finances to selling the things they make, to crowdfunding and donations – and usually combinations thereof – to etch out an existence that both challenges and hopes to alter the shape of mainstream technology (and thus society) to make it fairer, kinder, and more just.

While they build everything from computers and phones (Puri.sm) to federated social networks (Mastodon) and decentralised alternatives to the centralised Web (DAT), they do so usually with little or no funding whatsoever. And many are a single personal tragedy away from not existing at all.

Meanwhile, we use taxpayer money in the EU to fund surveillance-based startups. Startups, which, if they succeed will most likely be bought by larger US-based surveillance capitalists like Google and Facebook. If they fail, on the other hand, the European taxpayer foots the bill. Europe, bamboozled by and living under the digital imperialism of Silicon Valley, has become its unpaid research and development department.

This must change.

Ethical technology does not grow on trees. Venture capitalists will not fund it. Silicon Valley will not build it.

A meaningful counterpoint to surveillance capitalism that protects human rights and democracy will not come from China. If we fail to create one in Europe then I’m afraid that humankind is destined for centuries of feudal strife. If it survives the unsustainable trajectory that this social system has set it upon, that is.

If we want ethical technological infrastructure – and we should, because the future of our human rights, democracy, and quite possibly that of the species depends on it – then we must fund and build it.

The answer to surveillance capitalism isn’t to better distribute the rewards of its injustices or to normalise its practices at the state level.

The answer to surveillance capitalism is a socio-techno-economic system that is just at its core. To create the technological infrastructure for such a system, we must fund independent organisations from the common purse to work for the common good to build ethical technology to protect individual sovereignty and nurture a healthy commons.

Photo by JForth

The post Out of the Frying Pan and Into the Fire appeared first on P2P Foundation.