A coworker who used to work at Sun maintains that they really needed to go private to avoid years of chaos from waves of layoffs when they were profitable but not enough to satisfy Wall Street.

I have a legacy production environment that is Debian based OpenVZ and Nexenta. Containers and ZFS were in heavy use a decade ago, the marketing just wasn't there to make it "cool" like Docker.

Sun was great at many things, but they were never great at marketing.

Short sighted capitalism is imho a threat to society. But finding an acceptable solution is not going to be easy.

It still surprises me that Dell was able to somehow go private before Wall Street killed them too.

Google is a Linux shop that doesn't care at all about product continuity. Why would they have cared about Solaris? I'm sure it'd have got the chop instantly if Google had bought Sun. Sure, the engineers might have been able to find other opportunities within the firm, but Solaris would have been scrapped instantly (maybe open sourced, maybe not).

If Google had bought them for the IP, then at least that IP would live on, which is what everyone really wants.

From the article: "Finally, and perhaps most significantly, personal egos and NIH (not invented here) syndrome certainly played a part. I'm told by folks who worked at Apple at the time that certain leads and managers preferred to build their own stuff rather than adopting external technology, even technology that was best of breed. They pitched their own project, an Apple project that would bring modern filesystem technologies to Mac OS X. The design center for ZFS was servers, not laptops—and certainly not phones, tablets, and watches—and the argument was likely that it would be better to start from scratch than adapt ZFS. Combined with the uncertainty above and, I'm told, no shortage of political savvy, the anti-ZFS arguments carried the day. Licensing FUD was thrown into the mix; even today folks at Apple see the ZFS license as nefarious and toxic in some way, whereas the DTrace license works just fine for them. Note that both use the same license with the same grants and same restrictions."

It's still not too late for Linux to merge ZFS: https://youtu.be/6F9bscdqRpo?t=5m14s

https://blog.hansenpartnership.com/are-gplv2-and-cddl-incomp...

There is nothing stopping Linux from mainlining ZFS at the source level apart from kernel developers reluctance to give into "layering violations." Somebody can correct me if I'm wrong.

To wit: I am not sure if linking and terms of binary distribution matter after sources have merged for open source projects. If you have the source code and have right to modify, merge and distribute it, arguing about static or dynamic linking and binary distribution is like arguing about the color of your car door after the car has been made. It's inconsequential compared to amount of IP and resources put into the source code, and easily changed by any user (to a different architecture lets say).

Modifying has no meaning when it comes to binaries. But it's core to copyleft and open source. You would only care about binary licensing if you were a closed source product, and had to have ultimate control. If somebody had complete copyright over a ZFS binary, they could say how it can be used or not. The way an EULA would restrict you. Since no such copyright holder or binary exists for ZFS, and only source does, I don't think most people would stop collaboration in source code once the licenses are compatible.

Linking exceptions are for those who do own all of the copyrights and want to distribute along side open source software, and having a distinction otherwise in the open source world adds to license proliferation and makes no sense. ZFS doesn't have a single copyright holder acting on it's behalf, it has lost certain privileges because of this. I'm sure Oracle would be troll about this too, but they would probably be wrong given FreeBSD and OpenZFS.

I do think the GPLv3 fails a little bit because of the same argument. But I'm no lawyer.

Intent by everyone involved such as the author, the accused and the law writer. If the author intended that the work is used in one way, and the accused knew this but decided to go against it, then that carries a lot of weight. Similar, if the law writer intended the law to address a specific situation, that also carries weight.

Precedence from cases that involve derivate work. There is a fuzzy line when two works merge to create a third. Music has a large legal history, parts which are contradicting itself.

And last there is the law itself. Modifying for example is a explicit exclusive right in some places (such as the US). One case involved a person who bought a painting, cut it down into squares, and rearranged them into a mosaic version. The painter sued and won the case, arguing exclusive right to create modifications. If something is binary or source code should irrelevant to the question about if the "work" has been modified based on what the author originally created.

As this timeline and some Googling shows: https://en.wikipedia.org/wiki/OpenZFS#History Sun did work in good faith with Apple, and the Linux community to get them to adopt ZFS, unsuccessfully (successfully with FreeBSD). Additionally, the fact that Sun did successfully open source quite a few things (virtualbox, jenkins, openam, solaris, staroffice, netbeans, etc..) and relicense Java from SCSL to GPL, makes their intentions towards the open source community pretty clear. Yes, they wanted to make money, but they probably open sourced and created more open source communities than any other company in SV history.

Now, about modification, any open source license listed by the FSF will grant modification rights to users. I don't think compiling is making a derivative work. It's like unfolding a chair to sit on it. It's just a part of normal usage of software, you can decompile a binary and learn from it, also normal usage. The compiler is a tool, like a screw driver or paint gun that will let you assemble a chair or paint your car. Reading and learning from source code is usage too. Modifying the actual source code would be a real modification and could be making ZFS work on an Raspberry Pi, which is allowed by open source. Given that Sun wanted ZFS to be widely adopted in open source, they adopted the CDDL to let people modify ZFS so it could be used by OSes other than Solaris. This is what the OpenZFS community enables, and is completely compatible with GNU/Linux or Apache open source norms. Oracle might come knocking for money, but that's not the history of Sun or current ZFS contributors, who are just out to make better software using the open source process. They would probably not disagree with what Netgear or Canonical did, and if they did, it would be on the OpenZFS mailing list and in a news story or two. It's not.

You can't copy books and sell them, and I can understand you can't modify an original artwork and not affect the copyright owner's rights. You can correct an error in a book or claim inspiration from a painting to make another. You can't claim copyright if someone uses a binary in a VM when you didn't intend it. You can give others the right to modify source code, and ask that others do the same. That is open source and the GPL. OpenZFS, FreeBSD, have as much standing as Oracle, which is really none, to actually stop someone from porting ZFS to anything they would like and distribute it along side proprietary or open source software.

https://youtu.be/6F9bscdqRpo?t=5m40s

The other side is of course each one of the linux developers, each holding the full power of copyright. To cite SFLC, no free software developers have ever sued an other free software developer over license incompatibility, so its very unlikely to happen with ZFS. Such court cases really on happen between companies.

So to sum up, a case over ZFS is very unlikely, but I would not bet on what would happen if android suddenly started to use ZFS.

I wonder what Linux Torvalds thinks about merging ZFS into Linux now, he wasn't too keen a decade ago. Sun is no longer around, someone worse like Oracle has taken their place. A couple of lessons for the open source community here, I think. And Brian Cantrill nails in on the head in the youtube video link.

ZFS will need to be on Linux first before it can show up on Android or media centers or gaming consoles, and I don't doubt Oracle's ability to find a way to patent troll anything. But it will be just that: patent or copyright trolling.

[1] https://en.wikipedia.org/wiki/Common_Development_and_Distrib...

Canonical, Debian and SFLC have really done with right thing by distributing ZFS on Linux, using AFS as a precedence. I hope more merging like this can happen in open source in the future.

Even if they win Oracle v Google, it's been a huge distraction, a huge cost in lawyers (who knows how much they'll recoup), a big unknown and the search for an alternative has to be costly and time-consuming.

$8.3 billion almost seems like a bargain in hindsight.

I doubt Google was ever an alternative. Realistically it was a fight for power over the enterprise customers between IBM and Oracle, with most (non OS) products built or integrated with Java.

Maybe it was even a hot potato- someone needed to keep their strategic bet alive, since Microsoft also share the same strategy in the enterprise app segment. (Sell complex but underperforming applications to ill-advised customers using long feature lists.)

Unfortunately for the free software world, IBM's lawyers got cold feet when it turned out that Sun were mired in bribery claims. Oracle didn't care. Pity, because actually having Java properly open sourced, and likewise with various other Sun technologies (e.g. an OpenSolaris that didn't rely on a couple of binary-only libraries, for example) would have been quite a net win.

I think Sun was (mostly) acquired to prevent Java IP being sold to other, more nefarious parties (such as MS or patent trolls). Both Oracle and IBM were (and still are, though to a lesser extent) heavily invested into the Java ecosystem. Sun OS/Solaris has historically also been the reference O/S and platform for big-time installations of the Oracle RDBMS.

The enemy #1 for Oracle at the time was SAP, which they couldn't force out because it's another cancer (the lock-in is huge); so they developed a strategy of buying loads of ecosystem apps to "surround" it. At that point, they could sell the database and apps in one package, and then slowly erode sap away. Hardware was a natural addition to that strategy.

Unfortunately they borked execution. They didn't invest properly in making solutions ready-made, so after you bought a (very expensive) box, you still had to pay tons to consultants to set it up, making it uncompetitive on the whole. The industry shift to cloud did the rest. Now they're way too busy turning into "bigger Salesforce" to care about metal.

Solaris on PPC existed at various times, IBM could have provided a convergence path for the Fortune 500, AIX/Solaris/Linux/Java all on PPC.

It was actually a close thing, but someone else will have to write that story.

At that point, unless the SPARC hardware has some definitive cost/performance advantage, we'll buy x86. SPARC is for legacy.

Same applies to POWER, BTW. How many new apps have you seen in the past 10 years that were designed for POWER?

And the 6900's features with regard to HA in the field fell well short of advertised.

Now you can get a Linux box with 4Tb of RAM so no-one should buy Solaris over Linux.

And you could cram even more x86 cores with up to five Xeon Phi coprocessor cards, while Intel's supplies last.

https://www.supermicro.com/products/system/7U/7088/SYS-7088B...

IBM Services do a lot of support work for Solaris around the world.

But yeah, other than that it doesn't make a lot of sense.

Red Hat (if they could have afforded it) would have been an awesome home for Solaris/Sun.

Red Hat gets a nice check from us once a year. It isn't free by any means.

We had a bug in our installer recently where it wouldn't work at all on RHEL (I stopped testing on RHEL a few years ago because compatibility was so reliable that it never behaved any differently from CentOS). It took almost 24 hours to get a bug report about it (we see about a hundred new installations a day). So...it may be even less than 1/10th.

That said, we mostly operate in the low-end web hosting market: solo web developers, small design shops, web hosts selling to solo web developers, small businesses, etc. Our software rarely ends up in huge enterprise deployments. Even for our customers that are big businesses that use RHEL on the backend, they might have CentOS on their web server, because it's just a rental and that's what their web host installed for them. So, our numbers are certainly skewed toward CentOS because margins in web hosting are razor thin.

Usually in the same kind of companies that use tons of FOSS software and never give anything back.

Is that true? Don't companies interested in Solaris pay for their OS? Weren't they competing against companies like Red Hat?

I came up during that middle era when the shift was happening. I was an early adopter of Linux, but all of the real training I got (my employer at the time paid for it) was Solaris-based. But, even with the training and access to Solaris, I prefered Linux. I just had more comfort with it because it was my daily driver. When people I worked for were making decisions about OS, the recommendation they nearly always got from me was "Linux". And, I believe that played out millions of times to get us to the world we're in today.

So, yeah, Solaris was competing with free, but not always at the business level...the part that mattered was "how many people with influence are using this OS as their daily driver?" And, Linux was/is a phenomenon. People love Linux. People loved Solaris, too, but it was a much lower number due to lack of access...early days of Linux, you couldn't even get Solaris without a SPARC box to run it on. Later, they made x86 Solaris free, but it was too little too late, and by that time Linux was better than Solaris on a number of extremely important metrics (package management and package selection, for example, but also in terms of just plain fun).

At work GNU/Linux was just an internal server, all real work was being done in Solaris, HP-UX and Aix servers.

So fast forward to modern times and even Microsoft uses Linux kernel syscalls on their new POSIX personality subsystem, instead of actually supporting POSIX.

POSIX support is in the API, not the syscalls. musl libc places great emphasis on POSIX conformance. So if you ran a musl-based distro atop WSL, that should give you what you want, or at least something closer.

What do you mean? Using Linux kernel syscalls is just one of many ways to "actually support POSIX".

Do you know that by default GNU tools don't respect all POSIX expected behaviours and it needs to be explictly enabled?

I remember when we ripped out our 3 6800s and replaced them with 9 Dells, for way more power at a fraction of the price. Would have loved to recompile on Solaris, but the hardware savings easily covered the cost of a port...

Except they did; anyone working in Solaris engineering at that time or even now could tell you that x86 was just as important as SPARC. From a technological perspective, they are completely equivalent.

For example, the ZFS Storage Appliance is x86-based, not SPARC-based.

SmartOS for example only supports i86pc; there is no sparc port.