> 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?
Indeed, outside of cryptography, keeping substantive knowledge secret is quite often a critical component of security. See generally Rogue One ;-)
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.
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.
You see it on FOSS OSes for IoT and embedded devices, none of them is GPL based, rather Apache or MIT.
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 :-(
* https://en.wikipedia.org/wiki/OneFS_distributed_file_system
You can search for "Sponsored by:" in commits for who did work:
$ git log | grep -i '@dell.com' | wc -l
86A better search may be 'Sponsored by:.*[Dell|EMC|Isilon]' or some such.
Some Dell folks may be committers and be pushing things with their @freebsd.org address.
"FreeBSD’s BSD license offers customization flexibility without the obligation to disclose proprietary enhancements."
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:
* https://freebsdfoundation.org/news-and-events/event-calendar...
* https://www.youtube.com/playlist?list=PLugwS7L7NMXzSalaF4l_7...
Basically: if it's not part of your secret sauce, upstream it.