Which licenses give me a guarantee that a software I'm installing is completely open-source, free of closed-source dependencies or components?

Question

I have a question about free vs open source software that's more about practical implications from the user's perspective. I'll explain the mindset first before the actual question, so you can understand specifically what I'm referring to.

Let's say I want a system that's free of closed source software, as much as possible. So I want to be completely aware of closed-source software when deciding on an installation. For example, I may either not install the app, or use a sandboxed form (like snap/flatpak), or as last resort install it anyway and be aware that I'm "trusting" the code.

To be clear, when I say closed-source, I'm talking about executable code specifically - stuff that runs on my processor, that may raise security or privacy concerns - not about closed-source assets, media or other file formats that are "safe". I'm also not talking about hardware or network services external to my machine.

So let's say I'm installing a program or library in a package manager (e.g. using apt, snap, npm, etc), and I see that the main package has a FLOSS license, but I didn't check the licenses of every dependency it has.

While the package itself may be open source, it's often possible that it depends on closed-source software (and maybe even include closed-source code as components?). Which licenses give me a guarantee that I'm not indirectly installing closed-source code together with the main package? In particular, among:

• GNU AGPL, GPL, LGPL; 3.0, 2.0
• MPL 2.0
• Apache 2.0
• BSD-3-Clause, BSD-2-Clause, MIT

I presume only the GNU licenses (at least AGPL and GPL, not sure about LGPL) would give me that guarantee by just inspecting the main package, is that right?

Addionally, what if I inspect the license of every dependency, would all FLOSS licenses give me that guarantee? Or would the permissive licenses still allow a package to include and run closed-source components (code) within them, even though the package's license is considered OSS (assuming only that license is specified on the repo)?

---

TL;DR

1. Can a Free Software package have a dependency that runs closed source code?
2. Can an Open Source repository include and run closed source code or components?

Answer 1

No Open Source license does that. Even the GNU GPL license allows one program to interact with another non-free program via pipes, sockets, streams etc.

While the licenses can't do this, there are Linux distributions where the distribution creators make a commitment to only including free software, for example the Debian main package repository.

Answer 2

Which licenses give me a guarantee that a software I'm installing is completely open-source, free of closed-source dependencies or components?

Unfortunately, a license cannot do that.

Here's the problem. Anyone can attach put any license file into their project repo that they want to. The text of the license file may assert that that everything in their repo and/or every dependency is open source. But that asserting something doesn't make it true.

Licenses cannot give that kind of guarantee. People can. But people can make mistakes ... or be mischievous.

And as @apsillers pointed out (below), an assertion that a codebase is fully open source (in the sense that you mean) could be correct at the time it was made and then become incorrect later on. For example:

• problematic code or dependencies could be added to the project after its initial release, or
• one of the existing project dependencies could become problematic.

If you want a real guarantee, you need to check for yourself ... or get a trusted third party to check for you.

---

Also, what if I inspect the license of every dependency, would all FLOSS licenses give me that guarantee?

No. It is not what the (dependency) license says that matters; see above.

---

To be clear, when I say closed-source, I'm talking about executable code specifically - stuff that runs on my processor, that may raise security or privacy concerns ...

In that case, this is definitely not something that any open source licenses deals with. Security and privacy concerns can only be addressed by code auditing, etcetera.

FLOSS makes auditing easier, because you have the source code to examine. But it is unwise to assume that problems will be picked up by someone else ... in a timely fashion. Just about every security patch in the Linux ecosystem is proof that FLOSS doesn't automatically give security, etc.

Answer 3

Not directly answering the question, but the Free Software Foundation maintains a list of Free GNU/Linux distributions here

Since in freedom 1 is stated that "Access to the source code is a precondition for this.", I believe that all the distributions listed there are fully open-source too (otherwise the precondition of freedom 1 would not hold)

Answer 4

As others have noted, someone distributing software cannot change substitute their license for whatever license a third part distributed the third-party software under. So no license can offer any assurance there's no third-party components with a more restrictive license.

There is no substitute for examining all third-party pieces and their licenses.

When I have been faced with this task, I start with looking for conventions for placing license information. Text named LICENSE or LICENSE.*, in the distributed media, in directories touched by the installer, inside composite files like .zip, .jar, .war, .rar, etc.

Initially, I do this by hand to get a collection of licenses, from which I make a set of regular expressions to classify each detected license.

This should include looking for the word "license" in any text file (case insensitive), to detect misses.

Then I implement a scanner that scans all the locations where a license could occur.

Run it, then look at the report.

False positives from the "license" check go in a list of location exceptions to ignore, or a regex in the classifier that maps it to ignored.

Repeat, until you have eliminated false positives. Address any real positives.

Ideally, the final result is a report listing what software components were found for each license type.

You can extend this to flag any software component for which no license is identified at all. How you identify "component" will depend on your context; it could be executables in a directory, .jar files, subdirectories of a designated directory, etc.

Diligence on this is about as much as you can do to avoid false-negatives. Again, this can go in a list of exceptions once you have verified the status.

Reducing it to a repeatable script is important for several reasons.

• Evidence of due diligence in case of legal issues.
• Repeatable searches as the software evolves.
• Capture and tracking of your progress in detection. In a large system, it needs a systematic approach.

I highly recommend separating data from code. That is, the list of exceptions and directories to scan and classifiers, to the extent possible, should be in declarative form in a data file. The code then loads this information to drive the scan.

The code needed isn't very complex, and most of the work is in identifying the places to search, classifying licenses, tracking down missing licenses, etc.

In addition to addressing your concerns with proprietary software, such a tool can help you to comply with open-source license terms that require various forms of acknowledgement, etc.

Another thing you may wish to examine in your scan, is code signatures. Check that code is signed, that the signature is valid, including that either the certificate is within its validity dates, or there is a time stamp from a TSA that indicates it was signed within the validity dates, that it is a code signing cert, with a trusted CA in the chain.

Unsigned code needs extra vetting, and you should consider signing it yourself once vetted. Ideally, use a different cert than you use for your own code. A signed manifest then completes the picture, allowing substitutions to be detected.

A new or substituted third-party component can then be caught and examined.

A signed manifest that includes the SHA-1 or similar of the scanning tool and data gives attestation to it having been scanned by that version of the tool, as solid as your protection of your private key. Git tree IDs work well for this. You can also use them to limit the amount of rescanning needed. If the tree ID is the same as is recorded in the prior manifest, a rescan over that tree is not necessary.