Working from Within
At each of my past three employers, one of the first actions I perform when diving into our product repos is to assess our "OSS Vulnerability" (an intentionally trigger-worthy phrase). I make a list of all external dependencies, ensure each is explicitly referenced (not just an anonymous import from some repo), check their versions, and check for CVEs against each. I also check for each OSS project license and if it is included in our releases to our customers. For OSS code that we've modified, I also check that we provide repos our customers can access (for GPL compliance, at least the base code with patches must be publicly shared, but the metadata is exempt).
I then try to approximate the overall product dependency for each OSS project used, starting with how much of it is used (mainly by execution profiling), from as little as a single function call, to being a central piece of the product architecture. I send the resulting list to Management, and ask what level of paid support we have for each OSS element we use, and if we have contingency plans for if/when each OSS project, for whatever reason, stops getting updated.
It's not what Management typically wants to hear from a new hire, but it cements my place within the organization as someone willing and able to do the due diligence and start the risk assessment. After the initial reaction, I then advocate for adding paid support for our most critical OSS components, and also provide a system for employees to create and share OSS PRs upstream without violating their employment contracts (such as by making the company itself the author/contributor, removing the engineer's name from the PR, but tracking it internally).
The biggest push-back from Management is the cost we pay to stay current with the OSS releases we rely upon, as if the churn in our codebase is somehow the responsibility of the OSS project, rather than of our use of it. Politely pointing out such illogic is the most delicate part of my effort.
The biggest battles come when we rely on very large OSS projects (say, Yocto), that are themselves amalgamations of other OSS projects. Some tweaks we make can't be publicly shared due to restrictive hardware vendor IP agreements (I'm lookin' at you, Broadcom and Qualcom), in which case we must "embarrass" such vendors into DTRT ("Doing The Right Thing") when we pass our patches upstream through them. (We even had one such vendor claim we couldn't publish our source changes under the OSS license terms because their IP license took precedence: I typically ask Management to punt such silliness to the lawyers.)
Another part of the process is to get customers on-board with our desire for OSS compliance in both sprit and letter. I have worked on bespoke products that were central and critical to a customer's very existence (not just competitiveness), making them apprehensive concerning any form of disclosure, especially intentionally. One approach that helps is presenting an estimate for the work needed to replace an OSS component with bespoke code, and the ripple-on effects of project delays and increased collateral costs. Money talks. But getting Management and the Customer to add lines to a contract to explicitly fund OSS support is always a Sisyphean effort.
The final battle is convincing the company to be a "Good OSS Citizen" by publicly sharing code that's useful to us, but not core to our products, yet would almost certainly be of general benefit. I try to make the point that, even if we can't release core code, we can at least attempt to strike a balance by releasing other code instead. I have never succeeded in getting an employer to create public repos. Not even for little things, like some scripts used to help our use of cmake be faster (better cache management), easier (automated reminders and sanity-checks) and more reliable (isolated cmake testing).
If you look at each of the above as chokepoints, then the next realization is the existence of a large "impedance mismatch" between OSS projects and their use by most commercial entities.
Are there ways to improve this situation? I'm no Manager or Corporate Officer, so I won't make remarks in those domains. I do believe the best solutions lie in evolution both in corporate structure and regulatory structures (to "level the playing field"), but am unsure what such changes would look like or how they would be implemented.
In the short term, however, we must be pragmatic, and at least try to learn about improving OSS participation by actually doing it, while ensuring minimal risk if over-disclosure occurs. From an engineering perspective, the I have suggested we ensure our software is useless without our bespoke hardware, and to make it extremely difficult to reverse-engineer our hardware. This can be done by implementing key algorithms in FPGAs rather than as executable source code, and storing the FPGA blobs in encrypted memory. Then start with limited increases in OSS participation, staying far, far, far away from OSHW, at least for the moment.
Not an ideal approach, to be sure, but it is, at least, a way to crack the door open, if only slightly.
Biting the hand that feeds IT
