Comment by SageRaven | Hacker News Reader

Comment by SageRaven | Hacker News Reader

Parent Full thread

I've used FreeBSD for servers and my personal workstation for quite a few years. I love FreeBSD, and the thought of having to support a Linux variant is not a pleasant one. Not that I have a bone to pick with Linux, since I thought it was an excellent OS for the 10 or so years I used it before trying FreeBSD. But once I tried, and became accustomed to, FreeBSD, there was simply no turning back.

However, I take issue with your #1 bullet point above. If the FreeBSD camp truly was about the technical stuff, we wouldn't be stuck with a crusty, substandard version GCC in the base system.

For those not in the loop, the last GCC version with a GPLv2 license was 4.2.1 (from 20070719 according to "gcc -v" on my 8.1 machine). Due to not liking the GPLv3, the FreeBSD developers have stuck w/ this old GCC version, denying users the current set of optimizations and architecture support.

Sure, we can use GCC from ports, but that's not officially supported for the base system or the ports tree. True, they're working on getting the clang LLVM front-end to be the official base system compiler, it'll be 5 to 10 years before it's as stable and usable as gcc is today.

But that is about my only gripe with FreeBSD, and as far as gripes go, it's a relatively minor one.

The GCC situation is a bit more complicated than that. Importing new versions of GCC is a major PITA due to changes needed in FreeBSD not being accepted into the main GCC tree. We've been saying "gee, it would be great if we could get rid of GCC" since long before GPLv3 came out.

GPLv3 caused Apple to support LLVM development, which caused LLVM to be production-ready; and that combined with the general crappiness of gcc is causing FreeBSD to switch to LLVM. The licensing issue is a slight irritant, and without it we might have ended at 4.3 or 4.4 instead of 4.2.1; but it's certainly not the biggest issue.

Yeah point #1 is odd. GNU/Linux doesn't let licenses get in the way of technical decisions. DTrace and ZFS aren't in Linux because Sun explicitly designed their licensed to be GPL-incompatible.

Where that isn't the case nobody is seeking to replace code due to license reasons. E.g. you don't see Linux people trying to replace X11 or Sendmail because of their licenses. But the BSD systems are actively trying to phase out GPL licensed code due to not liking the license.

Exactly. I always read BSD discussions and think "what a bunch of licensing fanbois". I guess since the OS and the license have the same name...

Anyway, here's why I support Linux and the GPL: the WRT54G. Linksys would have never released the source code for the router's kernel without being forced to. But when they did it, an amazing thing happened, third-party developers made their product one of the most popular wireless routers ever. With open source, everyone benefited -- users got better products, hackers had fun, an d Linksys made more money.

If Linux was BSD-licensed, the WRT54G would be a long-forgotten relic of the past.

Imagine if OpenSSH were GPL'd and every vendor who implemented it got sued for not releasing a few patch files specific to their product.

I'm imagining it. Posting a patch to your website is surely better than rewriting ssh from scratch or licensing SSH.com SSH. (Sure, BSD requires less effort on your part, but the community gets less in return. That's not good for the continued existence of the project.)

Complete secrecy is the typical modus operandi of companies. You'd probably be paying extra for SSL telnet.

How many lawsuits figuring with the GPL have you seen? I know of a handful and I've read and heard that the focus is not to sue but to educate the companies in compliance.

Huh? Who are all of these vendors with secret OpenSSH patches?

I'm not convinced this was such a great thing for Linksys, and I always thought it served as a warning to other companies that using GPL'd code can be a bit of a trap.

Furthermore, as far as I understood, it would be impossible to change the Linux kernel license today because of the large number of people involved (also because some authors are dead now).

Relicensing linux is not an option, whether you believe GPL is good or not.

There are solutions to this, but you have to act in advance: for example if you want to contribute code to the clojure open source project, you have to sign and send by snail mail a contributor agreement (http://clojure.org/space/showimage/ca.pdf) which regulates the ability of the project funder some freedom in relicensing.

btw, this formality, especially the printing and snail mail thing, actually stopped me from contributing my code to clojure-contrib. You know, I just wanted to quickly share a bugfix, I don't know in advance how much involvement I will have with something which starts only as a side effect of my job

furthermore since I made the contribution during my daily job, my company itself would have to sign that contract etc etc, licensing some stuff with GPL is one thing, granting unrestricted sublicensing right is a different issue ...

Couldn't you contribute the code to a developer under public domain, meaning they can do whatever they want with it (relicense it etc...)?

I really don't want to instigate a flamewar, but think for a second about the dogmatic bias required to create a slogan such as "GPL-incompatible".

This is a pot-kettle situation if there ever was one.

Not really.

The effect of Sun licensing dtrace, ZFS and others as GPL-compatible would make Linux more competitive with Sun's Solaris. That's clearly undesirable. Sun faces a lot of competition from IBM and HP, both with offers to migrate to AIX/HP-UX and to Linux on x86 hardware. Enhancing Linux was a big no-no for them.

> The effect of Sun licensing dtrace, ZFS and others as GPL-compatible would make Linux more competitive with Sun's Solaris.

Yes

> That's clearly undesirable

Why? Sun's been bleeding customers towards Red Hat and (to a far greater extent) Novell since the early 2000s. Holding onto the Solaris/SPARC combo in the hope the high end customers would the be last to leave (which they were, but sooner than Sun expected) killed the company.

> Holding onto the Solaris/SPARC combo in the hope the high end customers would the be last to leave (which they were, but sooner than Sun expected) killed the company.

Giving Dell all the tools to fight SPARC/Solaris effectively would only kill it faster.

As a high-end hardware manufacturer, they were pressed from below by Linux on cheap x86 hardware. One possible solution would be to press back with SPARC/Solaris hardware at x86 prices. Sticking to the high-end may be a good strategy, but that's why IBM does not make an x86 version of zOS.

And that's why they lawyer to shreds anyone who tries to sell and support zOS on emulated zSeries hardware.

Sun customers knew and trusted Sun. If they had matched Red Hat and HP/Dell's prices (which they have had to anyway) and actually made Solaris something pleasant to use (like a modern-day Nexenta, but in say 2004/2005) I think the company would still be alive.

Also: Sun never had the opportunity to sue anyone else who made a competing Unix-like OS. If they did, then sure, IBM-type tactic would have certainly held off their competitors.

In order to do it, they should have never ported Solaris to x86.

They couldn't have. Sun don't own Unix.

Reply on news.ycombinator.com