Slashdot Mirror
SCO vs. IBM Battle Over Linux May Finally Be Over (networkworld.com)
JG0LD writes with this news from Network World: A breach-of-contract and copyright lawsuit filed nearly 13 years ago by a successor company to business Linux vendor Caldera International against IBM may be drawing to a close at last, after a U.S. District Court judge issued an order in favor of the latter company earlier this week.
Here's the decision itself (PDF). Also at The Register.
Here's the decision itself (PDF). Also at The Register.
Burn the remnants of SCO and then stir the ashes.
Somewhere buried in all of this was an opportunity for Netcraft to finally be right about something. Maybe that story has yet to surface, and will appear all in due course in tomorrow's feed bag.
PJ is toasting yet again.
Maybe in another couple years' time, she'll have another decision to toast some more!
Chas - The one, the only.
THANK GOD!!!
SCO is never going away. Fifty billion years from now, long after the last human is dead, alien successors-in-interest will still be suing each other over it.
The groklaw coverage was so good. I know that PJ closed the site down. Did anything ever spring up in its place?
Boy, do I feel like an idiot for paying my $699 License Fee to SCO.
Have you ever used SCO?
I have. It wasn't a bad system. I didn't like it as well as Solaris, but it was stable and reliable and pretty well documented. For a long time, they had a good product and supported it pretty well.
Yeah, the company sucked, but all that work, good programming, is now going to waste. What I'd like to see is IBM take ownership and open source all of it, have it relicensed under GPL and MIT licenses. Ultimately, I'd like to see a lot of that code legally incorporated into Linux.
Why? Just to make the people responsible for the fiasco the lawyers and executives of the company SCO weep.
They should put SVR5 under GPL3 - Unixware, et al. At least Unixware can be used w/ HURD
PJ and Groklaw would be a huge boon for slashdot if you could somehow reach out to her and bring her back.
SYS V needs to go open next, not that overloaded slowlaris, but lean mean SYS V
I was under the impression that the entire POINT of SYS V was for the major UNIX vendors to re-implement the guts of Unix as a clearly, enforceably, proprietary product (after the CONTU recommendations and the resulting copyright law changes explicitly extended copyright to software), then move to it and orphan the original development thread. (This might make opening it a hard sell to the members of the consortium.)
There were at least a couple issues with the proprietary status of the AT&T code:
One issue was that AT&T was still a government-regulated utility monopoly and there were some requirements about disclosing and releasing non-telephone-related inventions they came up with.
The big issue was that, before copyright applied and before software patents were hacked up (by recasting software as one embodiment of, or a component of, a patentable machine or process), the only protection was trade secret and the related contract law. Trade secrets generally stop being enforceable when the secret out of the bag (with some details about whether the claimant contributed to the leak). Bell Labs had shipped code to a LOT of educational institutions. When the U of New South Wales used the System 6 kernel code and an explanation of it as the two-volume text for an Operating System class, the textbooks became an underground classic. This, along with AT&T's benign-neglect licensing policies, led to the burst of little, cheap, generic UNIX boxes, as this was also when microcomputer chips were just becoming powerful enough to do the job.
Up to then a big barrier to entry was that every new machine needed a custom O.S. to deploy, and these were enormous, machine specific, and mostly in assembler. That made it an expensive, undertaking, suitable only for financial giants. But all but under 2,000 lines of Unix was in C, and the entire kernel, which included essentially all the platform-specific code as a subset, was well under 10,000 lines of code. If you had a C compiler and assembler for your new machine, it was a matter of a few man-months to port it and get it up and running. Essentially ALL the utilities and applications came right over. You didn't have to train users, either, because they all worked pretty much just like what they'd used in college.
The game was:
1. Grab a bootleg copy of the code.
2. Port it to your machine and get it working.
3. Go to AT&T and ask for a license "to port Unix to our new machine and sell it."
4. AT&T, as a matter of policy, completely ignores any "violations" you may have committed during the porting phase and cuts you a license at a very reasonable price.
5. You "port Unix in an AMAZINGLY short time" (like the ten minutes it takes to tell Sales to go to market) and you're in business.
6. You (with your new business) and AT&T (with their small cut) slap each other on the back and laugh all the way to the bank. PROFIT! for you. (profit) for AT&T.
7. Because of the policy in 4., everybody ELSE manearly everbody's king a new machine knows they can do the same thing. So many do. AT&T gets a rakeoff from ALL of them. PROFIT! for AT&T. Far more than if they went dog-in-the-manger, held up the first few for all the traffic would bear, and got no more customers for Unix.
And because of this, it was in nearly everbody's interest to NOT challenge the AT&T-proprietary status of Unix. And it stayed this way until SCO's management screwed up and altered step 4. (Even then the case turned on other issues, so it never did come to the point of attacking AT&T's claim that Unix code was proprietary.)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
And... Emacs Wins, Vi loses!!!!
Oops, sorry... wrong battle.
Sadly this case is not over yet, reading the summary of the order there are still outstanding counts, this order only addresses Counts VII and IX. Furthermore SCO still has appeal rights. That said, looking through the summary, it's pretty safe to say that SCO will loose the whole case.
Still pursuing his millions, at least in 2013:
http://archive.sltrib.com/stor...
Many of my customers are still using SCO Open Desktop. For new licenses and users I now deal with XINUOS http://www.xinuos.com/ . They acquired the assets of SCO from the bankruptcy proceedings. They are pretty good people to deal with. The best part is that I can use the same platform that I have used since 1981 when I was supporting AT&T 3B2 computers (with technical upgrades, of course). Open Desktop is the name of the System V 3.2 architecture. It is now time to stop denigrating SCO (the OS) and see it as a viable commercial alternative to Linux or xxxBSD, and is a stable, strongly usable platform for getting actual work done.
"The mind works quicker than you think!"
Darl McBride drove the public company that he'd been allowed to run into the brick wall that is IBM and took it to his brother's panel shop (legal firm). Both made a fortune out of the destruction. Massive legal fees and a golden parachute draining all value out of the company before bankruptcy.
Linux was just the distraction for an old fashioned two man scam.
SysV and the flusterfuck dyslexic script hackery behind SysV was a constant nightmare with a mountain hardware complaints leading back to it.
Even so the clusterfuck of rc scripts in most redhat derivatives was Red-Hat's creation. People aren't using init, via inittab, properly and now the reason cited to replace init is because the rc system, and the script hackery behind it created by red-hat is disliked. Keh?
Wouldn't a better rc system work better?
Here is a thought, why not learn how to use the shell properly so that shell hackery is not required. Or another idea, learn how to implement design patterns in bash/sh/ksh/zsh. Init is a simple elegant idea, people are arguing for it's removal because they aren't skilled enough writing *shell scripts*. It seems a bit silly to me that people who can't write something so simple have any business modifying the way the OS initializes.
It would be great to get Ken Thopson's opinion on the situation.
However, since we have the attention of many systemd advocates, can someone please throw a use case at me that init doesn't satisfy that systemd does? I'm really trying to understand why it is supposed to be better than something that is as tested as init. I don't mind using it, but why it is supposed to be so compelling?
My ism, it's full of beliefs.
Slashdot headline: "May Finally Be Over"
Referenced source: The Register.
from The Register article: "the case isn't over"
Comment removed based on user account deletion
Comment removed based on user account deletion
I'm really confused as to why people hate systemd so much. Based on the negative reactions on Slashdot, I expected systemd to be unstable and bloated, and was thinking about perhaps migrating back to Gentoo or FreeBSD if the rumors were true. However, during the past year I've tested systemd with first Kubuntu 15.10 and then Arch Linux, I've had no trouble with it at all. On the contrary: the bootup was lightning-fast compared to previous systems, and everything just worked out of the box. Taking a look "under the hood", everything looked neat and clean as well: system services are configured through readable config files, that are much shorter and tidier than the typical SysV init scripts I've gotten used to. Most of the design choices make sense as well: I see no reason to keep daemons like e.g. initd and inetd separate on a modern system.
I've also read that systemd apparently saves a lot of work for e.g. the distribution maintainers and desktop environment programmers, in the first case since it is much easier to maintain a systemd service file than a SysV init script, and in the latter case because a lot of work that previously had to be redone for every Linux distribution can now be easily shared or ported between distributions. I don't think some homogeneity among base systems are a bad thing if it makes it much easier to make software work across distributions. For instance, almost nobody's complaining that using the Linux system with the GNU base system and X11 display server is bad because it makes the Linux ecosystem too homogeneous. Sure, you do have legitimate usecases for the BusyBox base system and framebuffer applications, but that's not the majority of Linux desktop systems. There will of course be legitimate usecases for other things than systemd, but I don't believe that holds for the majority of Linux desktop systems either.
The only criticism of systemd that I agree with, is that plaintext log files are a good thing. I think I understand the reason for having binary logs (making it easier to parse for programs and scripts without a making a regex-hell), but in that case it would be much saner if journald automatically transcribed the logs it generated to plaintext files as well. Apparently it is not too difficult to set this up yourself, but I still think human-readable logs should be default.
I've already burned my mod points so I can post normally. It doesn't matter if you agree with it, it's off-topic and just looking to start a fight. -1 is where it belongs.
"Be particularly skeptical when presented with evidence confirming what you already believe." -
I miss the simplicity of the bsd-like init config scripts sitting on top of SysV in Arch, before they adopted systemd. So much could be configured from rc.conf, the daemon commands were simple, and I never had problems booting. gah
Yielding the power of UNIX has always laid in creating your systems inittab file, I thought everyone did that. I used to look upon rc scripts as an unnecessary complication of the system and wondered why they were there. If a service needs to be up, init makes sure it's up. If you want to take the service down, tell init to take it down. vim /etc/inittab && kill -1 1 then get on with the rest of your day.
Network services, is good example, a shell script handled by rc, is a prime candidate for an init controlled service. Getting init to kick of printer services after a short delay so that CPU time is focus on providing a GUI to a user could be another. Messaging system is a perfect example.
What about using runlevel 4 for your customised system state, 3 for shell level maintenance, 5 for GUI level maintenance? How about an ondemand runlevel?
Just learn how to use init *actions*, which is a lot simpler than systemd. Simple, scarily powerful and totally under utilised in Linux.
After spending some time with systemd writing unit files and playing around with jounalctl my sense is that this entire situation would be resolved with a set of small tools that manipulate inittab files properly that could support a GUI based inittab editor, thus complementing/completing the original design philosophy with a small maintainable set of tools that rpm, yast, apt-get could utilize. I wonder if people would be interested in such a thing? Perhaps it's time to contact the Devuan people.
I can agree with systemd supporters that the rc system is crap, however that still isn't init and systemd is as monolithic as the rc system, except it's compiled. I think the main objection to the idea of systemd is init is a core idea of the UNIX Operating System that is powerful. I've never seen a Linux distribution that uses init properly and essentially the argument is to replace a core idea of a stable operating system platform because people just don't understand how to use UNIX's most powerful concept one step removed from the kernel. Fast and lean!
The funny thing is, after all these years, I still haven't got everything I can get out of init. Do you understand what you are destroying systemd guys?
Has anyone got a use case yet?
My ism, it's full of beliefs.
It is nice to see scox lose, even if it is over a decade after it has any relevance.
As I have been saying for a long time, this is much more a msft scam, than scox scam. For msft, $100 million to stomp (if not eliminate) a competitor is money well spent.
Let's not forget that some scox insiders, like Riamondi, were selling their shares when scox was at $16. None of the guilty have been really punished, and they never will be.
As to insiders losing everything, and scox becoming worthless: scox lasted a lot longer, and scox's shares went up a lot higher, than would have happened without the scox scam.
Msft is still doing the same IP scamming. Only now it may be more effective. Msft and redhat have partnered. This makes redhat - and only redhat - immune from patent infringement lawsuits from msft. Sound familiar? It should. It is the scox extortion racket all over again - only this time with more credibility.
> "Only Days After Red Hat Legitimised Microsoft’s Patents Against Linux Another Linux-Using Company Falls Victim to Microsoft’s Patent Extortion"
http://techrights.org/2015/11/10/star-micronics-and-patents/
Of course, msft rarely sues in court, they don't have to. You either quietly settle, or get sued out of existence.
Once non-redhat distros become irrelevant, msft may turn on redhat. Or, maybe not. I think msft is okay with competitors, as long as those competitors can be dealt with, and are not too threatening. In 1998, Apple seemed to be okay as a competitor.
It's not just systemd that is destroying SysV. It's also Solaris, OS X, PC-BSD, and FreeBSD -- we can probably say well over 90% of the major Unix platforms. For better or worse, OpenRC is also making many of the same choices as systemd, including heavy dependence on C libraries, dependency resolution, parallel startup, and cgroup support. The critical failure of SysV init is the pidfile. It was always a bad hack — perhaps necessary for cross-platform support in a world without real process tracking, but now there isn't a hell of a lot of competition in any given market segment, and cross-platform support is being seen as less important than being able to accurately manage services. Yes, pidfiles almost always match the service they are supposed to, but this is not something that should ever have been left to userland. Similarly, daemonizing a process should never have been left up to script writers, given that glibc doesn't even do it correctly.
So now we're putting process tracking back into the kernel and it's a breaking change. If cgroups had been part of the POSIX standard years ago, systemd would have attracted no more attention than upstart when it was released. It *is* init, it has a superset of the same features, only with an event-driven model, and a slightly more sensible approach to dependency resolution than upstart. You may not have reached the limits of inittab, but other people with different use-cases have, and there's nothing in particular wrong with either case. The argument with systemd isn't an argument about how best to manage services, it's about technical debt so entrenched that people think that's the way it's supposed to be.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
Even so the clusterfuck of rc scripts in most redhat derivatives was Red-Hat's creation.
Nope. AT&T. Specifically AT&T system-V. Hence the name, sysvinit.
Debian is not a "redhat derivative".
Watch this Heartland Institute video
The court has already decided many of the claims against SCO including copyrights and ownership. The claim in this order was about tortious interference: Did IBM, by hardening Linux and porting code over to Linux, maliciously interfere with SCO's customers and business relationships?
Like many of SCO claims, the tortious interference were ambiguous and ever changing and lacked any detail. The number of parties that SCO alleged that IBM had caused interference changed by the month despite IBM asking repeatedly (and the court ordering SCO to respond repeatedly) to name the parties and the detail the interference. It was as low as 3 and as high as 150 with 150 being a number that SCO only claimed because one IBM email mentioned that it had 150 new customers on Linux.
Similarily to other claims, SCO brought almost no evidence to the case despite years of discovery. In fact it was often contradicted by indisputable evidence that IBM brought. For example, SCO claims that IBM damaged SCO's Unix by communicating to their third parties like their investor, Baystar, that IBM was supporting Linux and that the third parties should abandon Unix. Almost all customers third parties swore to the court that they never had communications with IBM on the topic. The only party that acknowledged it had any discussions with IBM was Hewlett-Packard and they testified that the discussion did not change their relationship with SCO so there was no damage.
The theory that SCO offered as motivation was that IBM wanted to damage SCO by hardening Linux and porting Unix code. Former SCO employees testified against SCO in that they did not believe damaging SCO was ever the motivation for supporting Linux. Their analysis was that IBM was competing against the likes of Sun and Microsoft by offering a cheaper Unix-like OS on cheaper Intel hardware that was nearly as good or better than Unix.
There are still a few claims left but at this point the pattern keeps repeating: SCO loses on summary judgements because they never had a case.
Well, there's spam egg sausage and spam, that's not got much spam in it.