AFAIK these are build scripts, but it’s not a good signal…
1 Like
Good thing ZFS replication exists!
Fuckin yikes.
Here is a comment from Reddit. Seems like it is really only about the build toolchain. It’s reasonable and clears the confusion I think.
kmoore134 wrote:
Bottom line is, the open source bits of TrueNAS will remain open source. (They are GPLv3 after all). The build system is another matter. It’s currently changing fairly radically internally now around for a variety of reasons, some of which are related our signing infrastructure for secure boot, etc. Meaning we’d be stuck maintaining two separate builders potentially to assemble an ISO file, one for community builds, one for the official builds. That isn’t super tenable for us in the long term.
That said, the repo is still there. Folks can fork / maintain it. All the open source bits can be built if the community so desires this functionality. But I’d wager 99% of the folks commenting on this thread have never done a build from source before, nor would ever want to? Its a lot of work to do and maintain. Especially since the biggest consumers tend to be overseas forks which contribute nothing back to the overall development effort to create TrueNAS, thats a lot of effort for us to shoulder the burden on for no real gain.
3 Likes
He also said
This is the path that addresses both, and leaves us flexibility in case we do need to ship more closed / proprietary pieces of the OS that can’t be build in the open.
I wonder why they would need that flexibility?
I gave a pretty concrete example in another thread about how we did that for CORE just a few short years ago. At the time we needed a FIPS certified SSL implementation. We couldn’t use the open source version, so we shipped a closed one we licensed. So yes, reasons like this do exist and sometimes thats the best option, even if its not our preferred one at the time.
I do love some of the irony here. Some of the same folks making hay about this change also didn’t understand when we moved from BSD → GPLv3 licensing on our source code. That was literally in the defense of keeping things open when it could have been closed at any moment 
INAL but my understanding is the below. Substitute “iXsystems” for any other party and AFAIK the logic still works..
If iXsystems is the IP owner of the code, they are always the copyright owner. That’s just how this works, unless they commit the software work to the public domain. A work can always be licensed multiple times over.
That’s why individual contributors need to license their work in most (?all?) projects to contribute back to a central repository and not open up a legal can of worms.
Debian, Fedora and other Linux distributions support Secure Boot and have an open build system. Secrets are a thing, you don’t have to upload the keys publicly. Also, some projects, like Bitwarden (i think?), have non-OSS modules in their main OSS build system.
Especially since the biggest consumers tend to be overseas forks which contribute nothing back
This is what GPL is for though, to mandate that you share the changes you make? But I am pretty sure this is the real reason right there - to restrict forks.
thats a lot of effort for us to shoulder the burden on for no real gain
Haven’t there been multiple instances where the open build system helped create useful forks, like the community made ARM version of TrueNAS? You’re just gonna kill off any possibility of such experiments in the future.
3 Likes
Yikes…
FWIW, this is not a valid argument. Most of the time the open source is not about what you do, it is about what you can do. I don’t build most of stuff I am running. I contribute to projects most of people here don’t even know they exist. 
Look what happened with pfSense - while technically open, they now require an online installer, meaning one cannot just download an ISO and install, you have to download a binary phoning home, else you cannot install. For me that was the last straw to switch to OPNsense and never recommend pfSense again.
So don’t be that surprised that people are not buying the secure boot “explanation” and are projecting own experience of where such first little steps lead to, namely that nice word coined by Cory Doctorow…
6 Likes
Honestly, if TrueNAS is now pursuing monetisation by shifting some features as paid options from TrueConnect it would have been easier to stick to go closed source from BSD licensing.
2 Likes
I mean, not wrong here. SecureBoot of course can be done in the open. Thats really more of a timing motivation for us (why now?) vs a hard requirement of a technical reason. The overseas forks & commercial derivatives are the primary motivation for this shift.
2 Likes
Why was turning the build system closed source the decided path? What other paths were considered? Why were they not viable?
This is quite important—if a standalone plugin compilation framework isn’t provided later, communities with unsupported hardware won’t be able to patch things themselves and will have to enable developer mode.
1 Like
My company provides professional services for TrueNAS systems and we will be revisiting whether we continue to work with them based on how this pans out. Our company ONLY works with actually open technologies, and TrueNAS/FreeNAS (yes we have worked with FreeNAS lots too) have met that for many years. But if this doesn’t get revisited and shifted back to a proper open ecosystem, we are likely to completely drop all iXSystems options for our clients.
iXSystems, please don’t go down this path.
6 Likes
That was literally in the defense of keeping things open when it could have been closed at any moment
what ix-systems did then is no indicator of what ix-systems intend now and in the future - people know business rationale changes, and to be frank IX-systems is managing the messaging on this in the worst way possible, and then leaning in to ‘its our users fault they dont understand’ that is usually a bad long term messaging approach, but hey what do i know as someone who has created multiple billion dollar software revenue streams
to anyone not involved in ix-systems internal decisions the optics are you are pissed that folks are using a build system and not contributing and you are battoning down the hatches against that (literally ix systems said this) if that was not the rationale, it shouldn’t have been said
i am not syaing ix-systems are, i am saying the company has a communication issue and it will ultimately burn ix-systems (one day i will remeber to call y’all truenas now 
)if the organization continues with that approach
you ultimately have the issue you could still have had one build system and kept secrets, secret - plenty of other distributions do that, so the argument and rationale about secrets appears weak to outsiders
i don’t expect ix-systems to change the decision, i strongly recommend the team think more carefully about explanations.
3 Likes
I’ll accept some of that criticism. My own messaging initially could have been clearer. Conflated to hard the Secure Boot aspects of this, (which is what drove the timing of the decision and what we’ve been talking mostly about internally here for a while now) with the actual business drivers of the ultimate decision to take the builder scripts internal. But that said, we’ll try to make things clearer up front to folks when we do have significant, or seemingly insignificant changes, to make that might be controversial in the future.
1 Like
Honestly interested - what did I miss? What commercial rip^H^H^Hderivates?
4 Likes