> Choosing FreeBSD as the base of ThinOS was a strategic decision driven by several key factors:
> License Advantages: FreeBSD’s BSD license offers customization flexibility without the obligation to disclose proprietary enhancements. This aspect is crucial for Dell, allowing the company to tailor the OS to its specific security and performance needs while maintaining proprietary control over its software.
Ok... I see where this is going...
> Engineering Efficiency: Dell’s engineering team benefits from FreeBSD’s stable kernel source code. It simplifies integrating and maintaining customized code, reducing the effort and resources required to keep ThinOS up to date.
Nice one.
> Security Enhancements: The stability of the FreeBSD kernel, coupled with the permissive BSD license, which allows vendors to keep proprietary modifications under wraps, significantly bolsters ThinOS’s security posture and creates a robust platform less susceptible to attacks than a CopyLeft-based system with GPL components.
Are they really defending security through obscurity (closed-source blobs) and at the same time attacking GPL in the same paragraph?
"Security through obscurity" is the vernacular formulation of https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle and refers to using bespoke encryption algorithms rather than strong encryption keys. I don't see how it has any bearing here.
Indeed, outside of cryptography, keeping substantive knowledge secret is quite often a critical component of security. See generally Rogue One ;-)
Well, the "security though obscurity" principle has been used for many years now to cover alleged extra protections granted by the mere fact of keeping a software source code closed and secret. As in: you will not find that RCE in the software if you don't have access to the source code. And this statement from Dell and the FreeBSD foundation (yeah, it's not just Dell) clearly follows that line of thought.
That is simply a mistaken understanding. Keeping source code closed is obviously a legitimate form of security if the source code itself contains proprietary trade secrets (such as hardware details).
No reasonable person could disagree; the proposition is so self-evident it's virtually tautological.
Well, language and meanings evolve over time and you cannot control how they do it.
Also, how protecting trade secrets via closed source "creates a robust platform less susceptible to attacks than a CopyLeft-based system with GPL components."?
Does keeping the source code for the Death Star exhaust port controller firmware secret help create a robust planet destroyer less susceptible to attacks?
Me too, although it might not be the same thing you are thinking of. I see the license as a way to let corporations take advantage of your free work without giving anything back. I LGPL my public work so that anyone is free to use it but if they change it, I need to get the changes back and decide if I want to incorporate them.
So far, I've been fortunate that nobody's paying attention to my work so I don't have to worry about whether to harass someone for violating the copyleft.
> I LGPL my public work so that anyone is free to use it but if they change it, I need to get the changes back and decide if I want to incorporate them.
The LGPL doesn't do that. If that's what you want, you probably want to use a modified version of the MPL requiring distribution back to you. Note that, while the MPL permits such modifications, they are generally discouraged. Sadly, there are no popular copyleft licenses that do this "out of the box," to my knowledge.
They do give some changes back (like drivers, or the ability to use Linux drivers in this case) because it's easier to have them upstream and not patch with every new release and fix every time it breaks due to other changes. The companies that use FreeBSD are also major donors to the founndation.
Had AT&T not gotten greedy and lawsuit BSD, all the major UNIXes would be around happily taking whatever they felt like from BSD, and Linux would have stayed Linus hobby project.
You see it on FOSS OSes for IoT and embedded devices, none of them is GPL based, rather Apache or MIT.
OTOH nowadays we are seeing how many Apache/MIT softwares are effectively moving to source-available, non-FOSS licenses because other companies took advantage of what Apache/MIT permit. I'm clearly not able to predict what would have happened if all those projects had used a CopyLeft license, but still one does wonder...
Yeah, I cringed when I read the GPL sentence. We get it, Dell. You want a free OS that you have no obligation to contribute any changes back to. Fine. But acting like a GPL-based OS is somehow less secure because people are obligated to share their improvements back to the project is asinine.
Business-wise ... even inane and asinine "security enhancements" (or "security" "enhancements" to make the window dressing more apparent) done proprietary can be turned into software patents. In large orgs, this is a huge incentive. In fact, double it up by making a software patent and a trade-secret private implementation.
I may not like that ... but I also can't unrealize the facts :-(
Thank you. I naturally am very attracted to the permissive licensing, but time and experience of seeing huge companies take permissively licensed code and use it to make, make billions without giving back anything or anything of substance, and comparing that to how the Linux kernel has evolved, has made me really consider whether GPL isn't needed. That debate is forever ongoing, of course, but it greatly warms my heart to see that Dell is contributing back. This seems like a success story of permissive licensing.
> But I suppose maybe some of their less sensitive changes, if upstreamed, relieves them of having to own them.
General best practice is to (a) upstream as much as you can, and (b) keep as close to -HEAD (the development branch) as possible. Some discussion on this at the Vendor Conference from a few months ago:
In addition to the vendor summit, Netflix gave a tech talk recently where they recommended both upstreaming and keeping as close to -CURRENT as possible
It seems like they have some (minor) contributions planned at least based on that article:
"Improving FreeBSD’s Linux application binary interface (ABI) will allow a broader base of Linux applications to run seamlessly on ThinOS, enhancing its versatility and appeal."
> License Advantages: FreeBSD’s BSD license offers customization flexibility without the obligation to disclose proprietary enhancements. This aspect is crucial for Dell, allowing the company to tailor the OS to its specific security and performance needs while maintaining proprietary control over its software.
Ok... I see where this is going...
> Engineering Efficiency: Dell’s engineering team benefits from FreeBSD’s stable kernel source code. It simplifies integrating and maintaining customized code, reducing the effort and resources required to keep ThinOS up to date.
Nice one.
> Security Enhancements: The stability of the FreeBSD kernel, coupled with the permissive BSD license, which allows vendors to keep proprietary modifications under wraps, significantly bolsters ThinOS’s security posture and creates a robust platform less susceptible to attacks than a CopyLeft-based system with GPL components.
Are they really defending security through obscurity (closed-source blobs) and at the same time attacking GPL in the same paragraph?