Log4j doesn't just blow a hole in your servers, it's reopening that can of worms: Is Big Biz exploiting open source?

Would more money have prevented this security flaw? Would the cash be useful in other ways anyway?

Analysis The disclosure of a critical security hole in Log4j last week has renewed calls to rethink how open-source software gets developed, paid for, and maintained, not that the long-simmering issue ever really went away.

The Log4j bug, an unauthenticated remote code execution flaw (CVE-2021-44228) in Apache's open-source Log4j Java-based logging library, is particularly serious and far-reaching because exploitation is not difficult and the software is widely used and buried deep within many programs.

Annoyance with the handful of project maintainers for failing to catch the bug prompted one, developer Volkan Yazici, to voice indignation about all the people bashing the maintainers for their unpaid, volunteer labor without offering any financial support or contributed code fixes.

Illustration of a software bug under a magnifying glass

Log4j RCE latest: In case you hadn't noticed, this is Really Very Bad, exploited in the wild, needs urgent patching

READ MORE

The exploitation of open-source software by companies that use freely available works without giving back to the community has been a sore spot among open source project maintainers for years.

It's sometimes referred to as the open source sustainability problem, a characterization that downplays corporate determination to minimize costs and maximize profits.

Among open-source projects that aspire to become profitable companies and to avoid having their uncompensated labor co-opted by more established rivals, the issue has been described in adversarial terms – predatory tech giants strip-mining open source – instead of ecological euphemisms that avoid assigning blame.

Weighing in on the current state of affairs, Filippo Valsorda, a Google cryptographer and security lead of the internet giant's Go programming language, on Saturday called for open source maintainers to engage with companies using their software on a more professional level, in order to get paid and make open source more sustainable.

"Maintainers need to be legible to the big company department that approves and processes those invoices," he wrote in a personal blog post. "Think about it: no company pays their law firm on Patreon."

Think about it: no company pays their law firm on Patreon

Dan Lorenc, who left Google in October after almost nine years to found security startup Chainguard, said that in terms of Google's interactions with open-source projects, the problem was distribution rather than funding.

"Corporations have a budget and are willing to spend, but it takes too much time," he said via Twitter. "Finding projects that need help and maintainers willing to help in exchange for money is hard."

Yet the notion that companies will ante up if just asked nicely using corporate vernacular, rather than gig economy tooling, doesn't sit well with everyone. For one thing, there is little enthusiasm, among individual users as well as Big Tech, for paying for open-source software at the heart of larger products, projects, and services.

"I've had this kind of conversation with people before and I've gotten a surprising amount of resistance to the prospect of actually making sure that the random smattering of volunteers that LITERALLY MAKE THEIR COMPANY RUN are able to make rent," said a developer known as Xe in a blog post. "There is this culture of taking from open source without giving anything back. It is like the problems of the people who make the dependencies are irrelevant."

Others participating in the discussion contend funding isn't the issue. David Crawshaw, CTO of Tailscale, in a blog post said while Yazici's post about lack of support for Log4j has been receiving attention "because highly profitable companies are using infrastructure they do not pay for," funding "would not clearly have contributed to preventing this bug."

Curl creator and WolfSSL developer Daniel Stenberg seemed to be in alignment with that, reminding us of the goto fail bug in Apple's encryption code: "The Log4j case is not a showcase for bad open-source software funding. It is a showcase for naive and cheap users not doing their due diligence, code review, and testing before using components. Remember goto fail? Silly bugs are shipped even with the greatest funding."

Developer Gabriella Gonzalez elaborated on that point, arguing that the Log4j vulnerability underscores the problem of catering to big business because the bug arose from a feature maintained to appease companies concerned about backward compatibility – LDAP/JNDI URLs.

"The maintainers of the log4j project knew that one of the lesser-known features was potentially problematic (although perhaps they underestimated the impact)," Gonzalez wrote in a blog post. "However, [they] did not remove the feature out of concern for breaking backwards compatibility."

Gonzalez argues that Log4j is a symptom of a larger problem: that public companies are exploitative and abusive toward open-source projects.

But the self-interested behavior of large companies extends beyond software. Whenever money or power are at issue, companies try to shape the rules to their advantage.

Uber and Lyft managed to get Californians to vote for an exemption to a law (found by a judge to be unconstitutional) that would have required drivers to be classified as employees, so they could avoid paying for benefits and reduce costs. Amazon and Google, among many other mega-corporations, fight unions for fear they will negotiate better pay and benefits for workers, thereby increasing costs. Companies like Oracle and IBM have been accused of capping or withholding sales commissions owed to their own salespeople. Employment contracts routinely impose onerous terms that benefit employers and disadvantage workers.

Businesses are simply not in the business of fair dealing. Those prioritizing their own concerns are simply doing what the law or the software license allows. The problem is not payment; it is permission – many popular open-source licenses are extremely permissive while lacking the reciprocity requirements of copyleft licenses. Licenses like the Apache license and the MIT license offer a lot and ask very little.

"Open source maintainers create massive amounts of value and capture almost none of it," said Feross Aboukhadijeh, an open-source developer who runs Socket, in an email to The Register. "Many of the most important open source projects that power the Fortune 500 are maintained by volunteers in their spare time, after work hours.

The software industry needs to find a way to help maintainers start capturing at least a portion of the value they create so they can continue to write new features, fix bugs, improve documentation, and most importantly, fix critical security issues in a timely manner

"The software industry needs to find a way to help maintainers start capturing at least a portion of the value they create so they can continue to write new features, fix bugs, improve documentation, and most importantly, fix critical security issues in a timely manner.

"I expect to see more maintainers explore alternative licensing options, restricting the ways and types of organizations that can use their software – or decide to let their projects stagnate – which will only increase the number of security incidents that we'll continue to face."

Aboukhadijeh added that the Log4j incident also illustrates how almost no company using open-source code in their applications bothers to review it.

"At the end of the day, companies are responsible for ensuring the code they ship to production is safe, secure, and reliable," he said.

Sooner or later someone's going to pay for open-source software, if not in goodwill then in damage control. ®

Similar topics


Other stories you might like

Biting the hand that feeds IT © 1998–2022