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)?


  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?

4 Answers 4


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.

  • 10
    That's not completely true for the Debian main repository: one big example is that it uses the mainline Linux kernel instead of Linux-libre. The mainline kernel has included closed-source blobs for 24 years. However, that's mainly driver stuff, so although it might not run on "my processor" from the OP, it's not "external to my machine" either.
    – lights0123
    Commented Dec 24, 2020 at 19:11
  • OK, even GPL programs can communicate with closed source, but in the GPL case, it would have to be a dependency (not a component) of the package, right? So, if I check all the dependencies, wouldn't I have the open-only guarantee? To clarify, I'd like to know if I can sort of imitate that guarantee (from Debian main repo in apt) when I use npm, snap, etc by just checking all licenses including dependencies. (That's why I said it was more like a practical question)
    – geekley
    Commented Dec 24, 2020 at 22:34
  • 2
    @geekley Just the license alone still can't guarantee that. You can't assume, just based on the license, that, say, an npm package won't, when you go to use it, download a closed source binary blob and invoke it as a shell command. Commented Dec 25, 2020 at 1:15
  • 2
    While Debian's policies may change over time, one distribution truly committed to being fully opensource, and that wouldn't make any sense without this commitment, is gNewSense.
    – Ruslan
    Commented Dec 25, 2020 at 7:36
  • @lights0123 Wouldn't those closed-source blobs be considered a violation of GPL? I assume they are executable code, right? Why is it allowed?
    – geekley
    Commented Dec 27, 2020 at 18:42

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.

  • 7
    I could even see a case where an assertion of "100% FLOSS" actually is true at the time the assertion is made, and then the repo is later copied and modified to have nonfree components by someone else (who may not have even noticed or cared about the 100% assertion). This is basically to highlight another edge case that affirms the core of this answer: assertions and licenses are different tools.
    – apsillers
    Commented Dec 24, 2020 at 4:17
  • Maybe I didn't explain myself well in the question, but I'm assuming that the code being open mitigates mistakes and malice reasonably enough for me (specially for large repos with many watchers), and surely more than "trusting" a company. When I say "guarantee", I meant not 100%, but more like "good enough for me" trusting guidelines to use when choosing software. So let me change the question a little... How do the licenses compare when I have this assumption (disregarding mistakes and malice) on FLOSS?
    – geekley
    Commented Dec 24, 2020 at 22:09
  • I consider the above answer to actually be the better one in context of the O.P.'s question. @geekley wrote "...I'm talking about executable code specifically - stuff that runs on my processor, that may raise security or privacy concerns." If the goal is to produce a Trusted, Secure system, then the ONLY way I know of to accomplish that is for someone to vet every line of source code that went into the system. TTBOMK, only well-funded private orgs or government agencies are able to do that. The licenses may provide (or remove) certain rights; they cannot assure trustworthiness.
    – Forbin
    Commented Dec 26, 2020 at 21:43

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)


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.

  • 1
    Interesting. I wish there was some sort of independent web site/service specifically aimed at doing these assertions on public FLOSS hosted anywhere else. It would be really useful to have some site where people could audit and publish their assertions that e.g. some github repo's commit is secure, how well it respects privacy, if compilation is deterministic, if there's any closed/obfuscated code or data files (some checks can be automated). Pkg managers could use this service's data to inform users before installing apps. This is also more useful as ratings than some subjective stars.
    – geekley
    Commented Dec 27, 2020 at 18:13
  • 1
    Somewhat related: askubuntu.com/a/620069/871240
    – geekley
    Commented Dec 27, 2020 at 18:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.