Open Source or Merely Ajar? – InApps Technology 2022

When you think of open source software, do you think of fully free software that is able to be used, copied, altered, and reproduced freely, or does your definition have some wiggle room? Can open source live in an in-between, where it enjoys all the benefits of a community supporting it, but retains some restrictions that make business models more viable? Can a company, basing itself on open-source software, restrict future uses from competing with its own?

These questions seem to be at the core of a debate in the open source community this past week, at the center of which lies a blog post by long-time open source advocate Bryan Cantrill.

“It is clear to me that open source — now several decades old and fully adult — is going through its own midlife crisis,” wrote Cantrill. “I (and others) have been critical of service providers’ parastic relationship with open source, as cloud service providers turn open source software into a service offering without giving back to the communities upon which they implicitly depend.”

Cantrill, it seems, penned the post in response to a number of new licenses with which he takes some umbrage, explicitly calling out CockroachDB’s Community License, MongoDB’s Server Side Public License, and Confluent’s Community License, as “continuing to claim to be entirely open source, but perverting the license under which portions of that source are available.”

Cantrill sees the problem as one lying in a “crisis of confidence” wherein “companies want it both ways: they want the advantages of open source — the community, the positivity, the energy, the adoption, the downloads — but they also want to enjoy the fruits of proprietary software companies in software lock-in and its concomitant monopolistic rents.” He writes that “we could accept these companies as essentially proprietary software companies, albeit with an open source loss-leader. But instead, these companies are trying to license their way into this self-contradictory world.”

Jay Kreps, CEO at Confluent (one of the companies called out by Cantrill), took to his own blog to respond, asking how “you describe a license that lets you run, modify, fork, and redistribute the code and do virtually anything other than offer a competing SaaS offering of the product?”

“I think Bryan’s sentiment may be that it should be called the Evil Proprietary Corruption of Open Source License or something like that, but, well, we disagree. It’s worth coming back to the central point: our goal in all of this is to give away software in as liberal a way as we can sustain,” writes Kreps. “I don’t think the current crop of licenses were handed down from the mountain on stone tablets by our elders to be revered and not questioned.”

Kreps goes on to explain that the restrictions they aim for are only to prevent direct competition with existing offerings, but it looks like some remain wary of this idea.

Cantrill, meanwhile, sees these new licenses in the light of end user license agreements (EULAs), asking if they are merely an EULA in FOSS clothing?

“I think it’s fine for you to be an open core company; just make this software proprietary and be done with it. (And don’t let yourself be troubled about the fact that it was once open source; there is ample precedent for reproprietarizing software.) What I object to (and what I think others object to) is trying to be at once open and proprietary; you must pick one,” Cantrill concludes. “We seem to be in some terrible new era of franken-licenses, where the worst of proprietary licenses are bolted on to the goodwill created by open source licenses.”

So, what do you think? Can open source move in this direction or is open source that isn’t fully open not open at all? Can open source be merely ajar?

While you think that over, here’s something else to consider — the consequences of your code:

This Week in Programming

• Rust Rounds Up Its Tools: With the latest versions of Rust appearing this last month, the Rust team has written a blog post rounding up the tools in the 2018 edition, which it calls “important part of what makes a programming language practical and productive.” According to the post, two popular tools – Clippy and Rustfmt – have been around for a bit, but are not stable and ready for general use. In addition to talking about those, the post also covers the variety of IDEs available for Rust developers, which include IntelliJ, Visual Studio Code, Atom, Sublime Text, and Eclipse.
• OpenJDK Gets Long Term Support on Windows: Red Hat announced this week that it would provide commercial support for OpenJDK on Microsoft Windows, in addition to its existing support for OpenJDK on Red Hat Enterprise Linux. This support, the company says, will further enable “organizations to standardize the development and deployment of Java applications throughout the enterprise with a flexible, powerful and open alternative to proprietary Java platforms.” Of course, this is good news for those Java developers who may have been hesitant due to changes in the Java license set to take place in 2019. Red Hat notes that it has been involved in the OpenJDK community since 2007 and contributed heavily, having already “served in stewardship roles for both OpenJDK 6 and OpenJDK 7.” According to an SD Times article on the subject, Red Hat “also explained when Oracle stops offering free public updates to Oracle JDK in January, Red Hat will work to ensure a smooth transition from Oracle JDK to Red Hat’s distribution.”

• The Modules of GoLang Future, Present and Past: Golang project lead Russ Cox is ending off a somewhat tumultuous year with a blog post summarizing the past, present and future of Go Modules in 2019, calling 2018 “a great year for the Go ecosystem, with package management as one of our major focuses.” Cox discusses, briefly, the events that lead up to the arrival of the package management system that eventually became known as Go modules before getting down to the business of what the team has planned for modules in the year ahead. According to Cox, “the migration to Go modules will be the most far-reaching change for the Go ecosystem since Go 1” and “converting the entire ecosystem — code, users, tools, and so on — from GOPATH to modules will require work in many different areas.” Some key dates to keep in mind include February 2019, which will see Go 1.12 “refine module support but still leave it in auto mode by default,” and then August 2019, when Go 1.13 will “enable module mode by default (that is, to change the default from auto to on) and deprecate GOPATH mode.”
• Facebook Open Sources NLP PyText Framework: Facebook announced this week that it is open sourcing its natural language processing framework for Python PyText. According to an article in SD Times, the company “has been working on its own natural language processing (NLP) framework for overcoming rapid experimentation and large-scale deployment challenges,” and now, “in an effort to help developers build and deploy NLP systems, the company has decided to also open source the PyText framework as well as share its pretrained models and tutorials.” PyText has helped Facebook to “achieve faster experimentation, tackle text processing and vocabulary management at scale, and harness the PyTorch ecosystem for prebuilt models and tools.” Facebook also notes that there is often a tension between frameworks built for research and production and that “we’ve used this framework to take NLP models from idea to full implementation in just days, instead of weeks or months, and to deploy complex models that rely on multitask learning. At Facebook today, PyText is used for more than a billion daily predictions, demonstrating that it can operate at production scale and still meet stringent latency requirements.”
• Python Fills its Governance Void: Earlier this year, Python’s “Benevolent Dictator for Life” (BDFL) Guido Von Russum stepped down, leaving the community to determine what would happen next after a particularly wearisome battle over new features. Well, it appears that the community has spoken, as SD Times writes that “the Python Software Foundation has settled on a new governance model,” which will “rely on a five-person steering council to establish standard practices for introducing new features to the Python programming language.” The new model is anything but, according to the documentation describing it, which it says “sticks to mature, well-known, previously tested processes as much as possible. The high-level approach of a mostly-hands-off council is arguably the most common across large successful F/OSS projects, and low-level details are derived directly from Django’s governance.” In the end, Python will seek consensus but rely on a “steering council” to act as its “court of final appeal” if that cannot be reached, though the developers write that this will be a method of last resort and that the council “should look for ways to use these powers as little as possible.”

Red Hat is a sponsor of InApps Technology.

Feature image via Pixabay.