Proprietary Licenses #
Zero-Price Proprietary Licenses
Some software isn’t open source, but can be freely downloaded and used to some extent.
When considering dependencies that fall into this category it’s necessary to carefully consider the terms under which the software is offered and the implications of using it.
Here are some specific things to look out for:
- Do the conditions limit how this software can be used? Is it possible that you will ever run into those limitations? If so, how hard will it be to remove this dependency?
- Are there any conditions under which a payware license is required. If there is any chance that you’ll meet those conditions you should evaluate the software as payware.
- If full source code isn’t included, you may not be able to fix bugs or even figure out what the code does.
- If full source code isn’t included, you may not be able to easily run the code on different hardware in the future.
- If there are restrictions on use, you won’t be able to do those things without removing this dependency.
- If the software is provided by Oracle, they may send you a bill for thousands of dollars per user and/or CPU core and send their lawyers after you if you don’t pay up.
More broadly, this stuff falls into two categories:
- Abandoned historical artifacts.
- Traps
Payware Proprietary Licenses
This software requires purchasing a license, and is generally restricted to use on specific computers or by specific people.
Adding payware dependencies is a business tradeoff, but the simple story is that once you do it you no longer own your program.
Buisness people will occasionally talk about a “build / buy tradeoff”. You can buy an office building. You can’t buy software - it only comes on short term leases.
Let’s consider FusionCharts. This is a JavaScript chart rendering library. For only $1899/year you can use this for up to 5 developers, as long as you don’t charge a subscription fee to end users. If you use this dependency, those requirements now apply to your whole project: No more than 5 developers, no subscription fees. Honestly that seems nuts even if there weren’t other charting libs.
License Auditing #
Tools like License Auditor or Organization License Audit can help verify that your deps have reasonable licenses.
Issues with Dependencies #
left-pad
Back in 2016 a bunch of popular JavaScript packages - including React - just broke. The developer of one of their dependencies had gotten mad and deleted it. The dependency was called “left-pad”; it was just one function that added padding characters to a string to make it a minimum length.
And… that was kind of the best case scenario. Every dependency you add is an opportunity for some external developer to make changes to your program. The more typical malicious dependency change is adding code to find and steal bitcoins - that’s happened several times.
- d3
- webpack
- @uiw/react-codemirror
Other examples:
- event-stream (2018) - new developer of library injected cryptocurrency theft code and stole $300k.
- liblzma (2024) - maintainer inserted remote backdoor in C library
- SolarWinds (2020) - Russian hackers breached proprietary software company with IT management platform used by a bunch of companies and US federal government agencies, stole a bunch of government email
- chalk, debug, etc (2025) - Major npm developer account got hijacked and cryptocurrency theft stuff got injected.
Conclusions:
- The threat isn’t just libraries or open source software. Any mechanism that results in software installs, especially automatically or periodically, is a huge threat vector.
- “Universal back door” - Automatic updates + user authentication is a targeted attack vector.
- Cryptocurrency is great for computer security. It gives attackers something moderately valuable to target, effectively creating global bug bounties for all software.
