Is Open Source Really Free if We Aren’t Allowed to Break It?

This past week has been an interesting one in the world of open source software. As you likely have heard by now, Marak Squires, the author of two popular open source libraries — colors.js and faker.js — intentionally corrupted the two libraries, partly in the name of standing up to the man (aka “Fortune 500s”), and partly to bring awareness to his own pet conspiracy theories.

In corrupting these two libraries, which collectively account for more than 20 million weekly downloads and thousands of dependent projects, the developer effectively broke thousands of projects that depended on them. While havoc may have been the result, the symbol of a lowly, open source developer standing up to the big, rich companies taking advantage of him was one that resonated for many. It was the response to these actions, however, that caused a bit of debate.

In response to the corrupted libraries, Microsoft quickly suspended his GitHub access and reverted the projects on npm. A GitHub spokesperson offered this statement to the actions:

“GitHub is committed to ensuring the health and security of the npm registry. We removed the malicious packages and suspended the user account in accordance with npm’s acceptable use policy regarding malware, as outlined in our Open Source Terms. We also published a security advisory here: https://github.com/advisories/GHSA-5rqg-jm4f-cqx7.”

While this might seem like an open and shut case to some — the developer committed malicious code and GitHub and npm did what it had to do to protect its users — a debate broke out around a developer’s rights to do what they wish with their code, no matter how many projects and dependencies it may have.

GitHub suspending someone’s account for modifying their own code in a project they own however they want spooks me a lot more than NPM reverting a package.

I kind of love what Marak did to make a point and protest tbh

— Engram Software / Leo (they/them) (@engramsoftware) January 11, 2022

An article on iProgrammer further outlines the dilemma present in what might otherwise seem like a clear-cut case: “Any suspension seems unreasonable if you consider that the code in the repos belongs to [its] originator/maintainer. Yes, it is open source in that you can fork it and can contribute to it but does this mean that GitHub is justified in denying you the right to change or even destroy your own code?”

I think, objectively, they should not do that. Even if they are very important projects, they are still your projects and it’s ultimately your decision to what you do with them.

GitHub and npm acting over someone’s decisions seems quite uncool.

— Shigero (@Shigero8) January 10, 2022

As of last night, however, it would appear that the entire affair is merely one for intellectual debate, as GitHub has indeed lived up to what some might view as its end of the bargain: the developer’s account is active, he has been allowed to remove his faker.js library on GitHub (depended upon as it might be), and has since offered an update that he does “not have Donkey Brains”.

https://twitter.com/keystonelemur/status/1480431994437726209

In the intellectual debate of whether or not an open source developer ought to be able to write a library, offer it under MIT license to the masses, have it be depended upon, and then eventually pull that code, it would appear that they indeed are able to do so.

Before we leave this now-non-issue behind, there is one other take on the whole affair — again focusing on the funding in open source — that we thought it would be worthwhile to point readers to: Dependency Risk and Funding. A quote to perhaps whet your appetite to read more:

“The risk a dependency poses is high with small, more commonly used dependencies, by a single unvetted developer, installed through a package manager like npm, cargo, pypi or similar. Yet when something goes wrong there, everybody immediately notices and people quickly call for funding. Yet those are not the dependencies that actually support our economy. Many of those dependencies became that foundational, not because they are solving a hard problem, but because we collectively started embracing laziness over everything else. When we then focus our funding discussions around these types of dependencies, we’re implicitly also putting the focus away from the actually important packages.”

This Week in Programming

• So You Wanna DIY Docker Desktop? Back in August of last year, Docker announced changes to its pricing structure that would make Docker Desktop a paid subscription for companies with more than 250 employees or $10M in annual revenue. Now, as we find ourselves in mid-January, the deadline for that changeover (January 31) is quickly approaching. It’s do-or-die time for a lot of companies to figure out whether or not they’ll lay down the cash, or try to go their own way. We’ve previously explored both Rancher Desktop and Podman as potential replacements, but this week Docker itself is getting into the game of pondering the trade-offs between Docker Desktop and a DIY solution. As you might imagine, the blog post seems to generally come out on the side of sticking with Docker Desktop in the end, rather than the DIY route, with the guest author writing that “Although some will prefer DIY Docker’s flexibility and control, Docker Desktop requires less setup effort and maintenance, offering a gentler learning curve for everyone from development to QA.” If you’re still undecided, however, the post, along with the other contemplations we’ve covered in the past, might be worth the read.

Let me see if I have this straight:
web1: capitalized HTML tags
web2: CSS border-radius
web3: pyramid schemes

—  Jef  Poskanzer  (@jefposk) January 10, 2022

• Docker Business Gets Single Sign-On: In another quick bit of Docker news, Docker has officially announced single sign-on (SSO) for its Docker Business customers, a feature we let you in on last month when a blog post previewing the feature was accidentally posted. Docker Business, the subscription tier required for those aforementioned businesses to keep using Docker Desktop, will now allow users to sign in using SAML 2.0 and Azure Active Directory identity providers, and all the details on how to get started are in the blog post. It looks like Docker has yet another carrot to dangle in front of their potential paying customers.

Visual Studio 2022 now shows hidden Unicode characters in the editor. pic.twitter.com/bOijYKS2uq

— Mads Kristensen (@mkristensen) January 13, 2022

• AngularJS Long Term Support Ends: AngularJS, the JavaScript framework first put out by Google way back in 2010, has reached the end of the road, with long-term support having finally ended. Not to be confused with the subsequent Angular 2 and Angular 4 JavaScript frameworks, AngularJS was set on this path four years ago now, and even enjoyed an extra year of long term support due to the pandemic, but now the team has officially declared the end, and recommends making the transition over to Angular. While CDN links will remain active and AngularJS.org will remain online, the GitHub repos will go read-only and the AngularJS npm packages will remain, but will be marked as deprecated.
• Open Mouth, Insert Foot: We leave you this week with a fun and brief little essay about four words that every developer has uttered once, if not countless times, in their career — Who wrote this shit? — alongside the realization that each and every one of us has been the name uttered in response.

why does the largest microservice not simply eat all the other microservices?

— Zach Holman (@holman) January 14, 2022