Skip to main content

Lack of leadership in open source results in source-available licenses

Amazon’s behavior toward open source combined with lack of leadership from industry associations such as the Open Source Initiative (OSI) will stifle open-source innovation and make commercial open source less viable.

The result will be more software becoming proprietary and closed-source to protect itself against AWS, widespread license proliferation (a dozen companies changed their licenses in 2018) and open-source licenses giving way to a new category of licenses, called source-available licenses.

Don’t get me wrong — there will still be open source, lots and lots of it. But authors of open-source infrastructure software will put their interesting features in their “enterprise” versions if we as an industry cannot solve the Amazon problem.

Unfortunately, the dark cloud on the horizon I wrote about back in November has drifted closer. Amazon has exhibited three particularly offensive and aggressive behaviors toward open source:

  • It takes open-source code produced by others, runs it as a commercial service and gives nothing back to the commercial entity that produces and maintains the open source, thereby intercepting the monetization of the open source.
  • It forks projects and forcibly wrestles control away from the commercial entity that produces and maintains the open-source projects, as it did in the case of Elasticsearch.
  • It hijacks open-source APIs and places them on top of its own proprietary solutions, thereby siphoning off customers from the open-source project to its own proprietary solution, as it did with the MongoDB APIs.

Amazon’s behavior toward open source is self-interested and rational. Amazon is playing by the rules of what software licenses allow. But these behaviors and their undesirable results could be curbed if industry associations created standard open-source licenses that allowed authors of open-source software to express a simple concept:

“I do not want my open-source code run as a commercial service.”

Leadership often comes from unexpected sources.

But the OSI, an organization that opines on the open-sourceness of licenses, is an ineffective wonk tank that refuses to acknowledge the problem and insists that unless Amazon has the “freedom” to take your code, run it as a commercial service and give nothing back to you, your code is not “open source.” The OSI believes it owns the definition of open source and refuses to update the definition of open source, which is short-sighted and dangerous.

To illustrate: The Server Side Public License (SSPL) — the license proposal spearheaded by MongoDB — was patterned exactly after the Gnu General Public License (GPL) and the Affero General Public License (AGPL). SSPL is a perfectly serviceable open-source license, and like GPL and AGPL, rather than prohibit software from being run as a service, SSPL requires that you open-source all programs that you use to make the software available as a service.

A months-long comical debate ensued after SSPL was proposed as an open-source license candidate to OSI, after which OSI made its premeditated opinion official, that SSPL is not an open-source license, even though GPL and AGPL are open source. In its myopia, the OSI forgot to be consistent: If SSPL is not open source, then GPL and AGPL should not be either. MongoDB will continue to use SSPL anyway, but it just won’t be called “open source” because OSI says that it owns the definition of “open source” and it can’t be called that. Great.

Source-available licenses

Is it inevitable that the combination of Amazon’s behavior and this lack of industry leadership will stifle open-source innovation and make commercial open source less viable? Should we just live with either more software becoming proprietary and closed-source to protect itself against AWS, or with widespread license proliferation?

We’ve already seen plenty of license proliferation. MongoDB SSPL, Confluent Community License (CCL), Timescale License (TSL), Redis Source Available License (RSAL), Neo4J Commons Clause, Cockroach Community License (CCL), Dgraph (now using Cockroach Community License), Elastic License, Sourcegraph Fair SourceLicense, MariaDB Business Source License (BSL)… and many more.

The trend is toward “source-available” licensing rather than “open-source” licensing because source-available licenses, uncontaminated by the myopia of open source industry associations, do not require that Amazon have the “freedom” to take your code, run it as a commercial service and give nothing back to you.

To that end, a group of open-source lawyers led by Heather Meeker, a respected and undisputed leader on technology and open-source law who worked on both Commons Clause and SSPL, will soon open a suite of “source-available” licenses for community comment.

The suite of source-available licenses is expected to provide authors of open-source software with a number of methods to address the growing threat from cloud infrastructure providers. The suite will provide short plain-language source-available licenses; standardize patterns in recently adopted source-available licenses; and allow users and companies to mix and match limitations you want to impose (e.g. non-commercial use only, or value add only, or no SaaS use, or whatever else). I believe these frameworks will be a smart alternative to open source, as the OSI refuses to provide leadership in solving the Amazon problem.

AWS and anti-competitive behavior

More broadly, it is clear to most industry observers that AWS is using its market power to be anti-competitive. Unless something changes, calls for anti-trust action against both Amazon and AWS are inevitable, even if AWS is divested from Amazon. That issue is broader than just open source.

Amazon’s behavior toward open source is self-interested and rational.

Within open source, if Amazon isn’t breaking any laws today, then licenses to prevent or curb their behavior are critical. And lack of leadership from the open-source industry associations that squat on the term “open source” means that source-available licenses are the most viable solution to curb such behavior. It doesn’t have to be this way.

Leadership often comes from unexpected sources. There are promising signs that other cloud infrastructure providers are becoming true allies to the open-source community. Take Google, for example. The major announcements at Google Cloud Next in April 2019 were dramatic and encouraging. The company announced partnerships with Confluent, DataStax, Elastic, InfluxData, MongoDB, Neo4j and Redis Labs — companies most affected by Amazon’s behavior.

Google Cloud’s new CEO Thomas Kurian’s remarks echoed what I had been saying for the last year.

Frederic Lardinois of TechCrunch wrote:

Google is taking a very different approach to open source than some of its competitors, and especially AWS. … “The most important thing is that we believe that the platforms that win in the end are those that enable rather than destroy ecosystems. We really fundamentally believe that,” [Kurian] told me. “Any platform that wins in the end is always about fostering rather than shutting down an ecosystem. If you look at open-source companies, we think they work hard to build technology and enable developers to use it.”

It’s smart for Google to align with these commercial open-source players — AWS is beating Google in the cloud wars and giving best-of-breed commercial open-source products first-class status on Google’s cloud will help Google win more enterprise customers.

Perhaps more importantly, the stance and language on how ecosystems thrive is incredibly encouraging.

Disclosures: The author has invested in numerous open companies affected by the behavior of cloud infrastructure providers, indirectly owns shares of Amazon and, apart from any abuse of open source or anti-competitive behavior, is a big fan of Amazon.



from TechCrunch https://tcrn.ch/2Xk6wUM

Comments

Popular posts from this blog

How To Play Doom – And More – On An NES

Doom was a breakthrough game for its time, and became so popular that now it’s essentially the “Banana For Scale” of hardware hacking. Doom has been ported to countless devices, most of which have enough processing ability to run the game natively. Recently, this lineup of Doom-compatible devices expanded to include the NES even though the system definitely doesn’t have enough capability to run it without special help. And if you want your own Doom NES cartridge, this video will show you how to build it . We featured the original build from [TheRasteri] a while back which goes into details about how it’s possible to run such a resource-intensive game on a comparatively weak system. You just have to enter the cheat code “RASPI”. After all the heavy lifting is done, it’s time to put it into a realistic-looking cartridge. To get everything to fit in the donor cartridge, first the ICs in the cartridge were removed (except the lockout IC) and replaced with custom ROM chips. Some modifica...

Try NopSCADlib for your Next OpenSCAD Project

Most readers of this site are familiar by now with the OpenSCAD 3D modeling software, where you can write code to create 3D models. You may have even used OpenSCAD to output some STL files for your 3D printer. But for years now, [nophead] has been pushing OpenSCAD further than most, creating some complex utility and parts libraries to help with modeling, and a suite of Python scripts that generate printable STLs, laser-ready DXFs, bills of material, and human-readable assembly instructions complete with PNG imagery of exploded-view sub-assemblies. Recently [nophead] tidied all of this OpenSCAD infrastructure up and released it on GitHub as NopSCADlib . You can find out more by browsing through the example projects and README file in the repository, and by reading the announcement blog post on the HydraRaptor blog . Some functionality highlights include: a large parts library full of motors, buttons, smooth rod, et cetera many utility functions to help with chamfers, fillets, precis...

The Newbie’s Guide To JTAG

Do you even snarf? If not, it might be because you haven’t mastered the basics of JTAG and learned how to dump, or snarf, the firmware of an embedded device. This JTAG primer will get you up to snuff on snarfing, and help you build your reverse engineering skills. Whatever your motivation for diving into reverse engineering devices with microcontrollers, JTAG skills are a must, and [Sergio Prado]’s guide will get you going. He starts with a description and brief history of the Joint Test Action Group interface, from its humble beginnings as a PCB testing standard to the de facto standard for testing, debugging, and flashing firmware onto devices. He covers how to locate the JTAG pads – even when they’ve been purposely obfuscated – including the use of brute-force tools like the JTAGulator . Once you’ve got a connection, his tutorial helps you find the firmware in flash memory and snarf it up to a file for inspection, modification, or whatever else you have planned. We always apprec...