the company made extensive use of free/open source software but seems to be gravely out-of-compliance with the license terms (I’m told that organizations that do legal enforcement of free/open licenses are now aware of this).
This is actually from a much longer “piece” that has been floating in my mind for weeks but I’ll point out a few things here.
The pros and cons of open source software are greatly misunderstood or deliberately distorted by developers, development / operations managers, executives and those working for software firms selling software.
One misconception – open source is more secure than proprietary (opaque) software. Those believing this assume that anything open-sourced is of sufficient interest to a large enough pool of developers who will look at the code when published and “contribute” to it by adding additional functionality or pointing out flaws which could affect functionality, performance and/or security. It’s like getting a worldwide team of Quality Assurance people double-checking your work. Uhhhhhhh, NO. Those looking at your code are under no obligation to notify you of flaws or vulnerabilities so publishing something and hearing no howls of derision from the peanut gallery is no sign your code is secure. It could be the only person who reviewed your code saw something to save for an exploit on a later day.
Related to security misconceptions – open source is often higher quality than internally developed, proprietary software. True, there are some PHENOMENALLY high quality open source tools (Apache web server, the original MySQL / now MariaDB, Kafka, Cassandra, etc.) used at MASSIVE scale in many companies. But not all software components are shiny, fun projects. Big systems rely on a lot of smaller, more mundane (boring?) components and no one wants to rewrite that stuff at every company. So they don’t, they re-use open-source components that “git 'er done.” But again, once people figure out that some guy in Belarus wrote a library to solve problemX and it takes one minute to add to the build and I don’t have to think about it again, am I going to think about it again for the next five years? Am I going to check every new version for possible flaws introduced accidentally or maliciously? Or am I just going to pull in the new version and move on? This is how the flaw in Solar Winds allowed hundreds of large corporations to be penetrated in the latter half of 2020. To some extent, it’s the same pattern that resulted in the Log4J vulnerability that required MASSIVE labor to correct in nearly every corporation a year later in December of 2021.
Another misconception – open source is free software. This fallacy has been a struggle since the early 90s but there’s a more insidious aspect to this. MANY “open-source” components are developed by COMMERCIAL firms. Their business model amounts to creating new software, open-sourcing it to goose adoption in the market and get YOUR ideas as a user for enhancements (less headcount they spend on product development), offering a “community” version for free and offering “commercial” or “enterprise” licensing for a slightly enhanced version that includes “tech support” and maybe rights to the next version. For example, the community version of a data platform might scale to thousands of simultaneous users… but include no backup utilities. That makes reliable operations very precarious but many developers and admins might not realize that up front. From the vendor’s perspective, though, you’ve adopted the product, put it in production and become dependent on it. The community binary will often contain many of the same capabilities as the “enterprise” version in the distribution BUT THEY’RE NOT LEGAL TO USE with the community edition. And woe to the lowly developer or system administrator who doesn’t understand everything in the community installation isn’t free to use. If the vendor learns you are using any of the “paid” features without paying, you can wind up with a software license auditor crawling over your entire company looking for unlicensed software and outsized penalty fees.
One vendor using this model even lets you modify their software for use within your business. But if you alter THEIR software then include that software in something YOU distribute, not only are you obligated to open-source the changes to THEIR PRODUCT (normal open-source terms…), you are required to open-source the ENTIRE source code to the ENTIRE system you built that includes the altered version of their software. The vendor really doesn’t care about your other code. This clause in their license is designed as a poison pill to ENSURE that you don’t modify their code yourself but just give them the enhancement ideas so THEY can build it and profit from it across multiple customers.
Given the nature of key technologies for browser based portals, big data and basic web services, EVERY major firm on the planet is dependent upon open-source components or those derived from open-source underpinnings. However, I would guess a very small percentage of firms dependent upon open-source have well-defined strategies regarding security, intellectual property and general productivity to make build/buy decisions in an optimal way that reflects the true risks and rewards. Like Deere in this example, many are defaulting to what stirs up the least dust (in the short term) and appears to save money (in the short term).