Licensing - Clarification request - GPLv3, LGPLv3 vs. EULA

TrueNAS General
1

For iX Systems only - Following redirection by the support staff to the forum :

Request:

I would like iX Systems to clarify how the the company’s EULA on TrueNAS Scale is intended to work as a restriction of rights under the GPL.

I would like the licensing clarification to be official for both the Community and the Enterprise editions.

Products:

  • TrueNAS Scale Enterprise Edition
  • TrueNAS Scale Community Edition (to be clarified if EULA is applicable)

Observations:

  • TrueNAS SCALE is a Debian-based system
  • It contains some FSF software (grub2, parted) released under the GPL
  • FSF packages are being distributed as deb files on the download site
  • The system console copyright notice states that:
    “TrueNAS (c) 2009-2025, iXsystems, Inc. dba TrueNAS. All rights reserved. TrueNAS code is released under the LGPLv3 and GPLv3 licenses with some source files copyrighted by (c) iXsystems, Inc. All other
    components are released under their own respective licenses.”
  • The documentation of TrueNAS Scale contains a “TrueNAS End User License Agreement” (EULA)
  • In particular, this EULA contains a section “3.0 License Restrictions”
  • GPLv3 contains a section 10. “Automatic Licensing of Downstream Recipients”. This section is mandatory.
  • The scale-build git repo contains a GPLv3 license file
  • The Middleware git repo contains two license files : a LGPLv3 (LICENSE) file and the EULA (LICENSE.ix)
  • The Middleware git LICENSE.ix file states that : “Where Specified, portions of the TrueNAS Middleware Source are licensed for TrueNAS Enterprise Usage only.”
  • The Webui git repo contains a GPLv3 license file
2

The EULA is applied to TrueNAS rather broadly, whereas GPL and other related OpenSource licenses are tied to particular components / features. ZFS is CDDL for example, kernel is GPLv2, WebUI is GPLv3, some others are MIT, BSD, etc ,etc. Each with their own respective license terms and conditions that apply.

The EULA is there to cover the non-open source “bits” that are included in the bundle the comprises TrueNAS ISO. We have a handful of those which are not released under GPL, such as some particular things related to our enterprise products and gear, but are still bundled as part of a single ISO file you download and install.

It means if somebody wants to fork/re-package and distribute a build of TrueNAS, they would need to be responsible enough to do their own review. They would then need to remove or replace any pieces which are not under a license that allows redistribution, or don’t otherwise cannot adhere to the terms of those particular components.

Again, in simple english, if you re-build and distribute, you would have to remove our non-open source code bits. Likewise if you re-distribute the webui, or middleware, you would have to adhere to the terms of their individual license conditions, GPLv3 in this case and make the source code / changes available.

3

Thanks for your response. I have emailed your legal team to inform them of this forum thread. I will now leave the legal analysis to the FOSS licensing experts as this thread is public.

If I understand correctly, proprietary and open-source assets are combined in the TrueNAS Scale product ISO distributed to consumers?

You mentioned that “the EULA is applied to TrueNAS rather broadly” (quote from Kris, post 2, topic 51817). How does this align with the restrictions outlined in GPLv3, section 10?

If the EULA is only intended to cover the non-open-source “bits” (quote from Kris, post 2, topic 51817), why aren’t the proprietary components simply packaged separately ? For example, Oracle separates the GPLv3-licensed base package from the proprietary components in VirtualBox.

As of now, conducting the suggested review would require that all of your repositories include license files (not the case for patches made to grub2 and parted, for example) and that conflicting information is resolved. For instance, the setup.py file in the build system’s GitHub repository indicates a BSD license, while the root repository contains a GPLv3 license file.

4

Thanks for the heads up, considering that will end up on my desk I’ll look forward to reviewing it again :slight_smile:

To be clear, TrueNAS is not a “Distro” in the sense you are thinking of. We’re not shipping packages and allowing mix-n-match loading of them in that fashion. Individual components in the firmware / appliance image have their own respective licenses that must be complied with. We also are well aware of linking clauses and what constitutes a derivative work, which is why LGPLv3 was chosen for middleware specificly, vs GPLv3 for WebUI. Its also why we ship CDDL ZFS as a separate kernel module to avoid GPL complications. This is all really old news by now.

5

I’ve got a little bit of experience in the area but I’m also a TrueNAS user so this one got my attention. By way of background, I’ve worked as a lawyer in the tech sector since '97 and I review and draft OSS licences and CLAs myself (it’s a small circle). I just published a new FOSS model recently that’s being used by some folks working in the Web3 space which you can find on my github page: “daimon-dual-phase-license (DDPL)”.

I’ve also been advising teams on dual licensing models which are becoming more popular as emerging projects try to juggle community and commercial viability. It’s not easy, so hats off to TrueNAS, Proxmox, n8n and all the other teams trying to pull this off. It’s super inspiring and I hope it continues. We’re in a golden age.

While you can have combinations of copyleft licenses or copyleft mixed with closed-source licensing within the same codebase (and it’s basically unavoidable at this point), the developers have to be super careful how it’s handled. That means (A) getting the codebase structured in a way that’s clearly delineated/modular (B) ensuring the licensing can be segregated in a way that replicates the software architecture and (C) complying with the license obligations of any OSS code embedded in the stack. (A) and (B) aren’t always easy to achieve.

The reason why this approach is required when combining closed and copyleft code is because it’s very easy to find closed source software pulled under copyleft licenses such as the AGPL because the GPL and AGPL are pretty aggressive and sticky where the codebase isn’t clearly delineated. It’s also easy to mess up or overlook attributions.

Part of this comes down to the drafting of the AGPL (definitely in need of a refresh) and some of the other older FOSS licenses as well as the changing nature of SaaS and distributed computing since the A/GPL was drafted. It’s the main reason Google and other big dev shops hammer-banned the use of code licensed under those models.

That’s the TLDR background.

I’m not going to provide legal advice to TrueNAS here as I’m sure they have their own legal but they should take a closer look at the licenses in play for the entire codebase as well as the license notice posted above. With the mix of software involved here, a basic software audit wouldn’t hurt. You’d be amazed what you discover when you dig a bit, especially when it comes to libraries. :wink:

The license notice posted above is sub-optimal for the obvious reason that the licensors of the “other components” probably need full attribution if their code is being used within the TrueNAS stack. That’s an easy fix. Microsoft and Oracle are pretty meticulous about this so don’t be afraid to use their attribution pages as a benchmark.

Sadly, it’s a not uncommon problem to pass over IP and licensing early on and have it come back to bite really hard once you are hitting your straps as a business. Sadly, a measure of your success as a software developer is whether you are dealing with patent squatters, trademark infringers and other ratbags leeching off your success so getting it right early can help fend off the sharks.

Happy to expand on the above if there’s value in doing a deeper dive.