The SCO lawsuit, 20 years later
SCO claimed to be the owner of the Unix operating system which, it said, was the power behind the "global technology economy"; the company sold a proprietary Unix system that ran on x86 hardware. By that point, of course, the heyday of proprietary Unix was already well in the past, and SCO's offerings were not doing particularly well. The reason for that, SCO reasoned, was the growth of Linux — which was true to a point, though Windows had been pushing a lot of Unix systems aside for years. But Linux, SCO said, couldn't possibly have reached a point where it threatened Unix on its own:
Prior to IBM's involvement, Linux was the software equivalent of a bicycle. UNIX was the software equivalent of a luxury car. To make Linux of necessary quality for use by enterprise customers, it must be re-designed so that Linux also becomes the software equivalent of a luxury car. This re-design is not technologically feasible or even possible at the enterprise level without (1) a high degree of design coordination, (2) access to expensive and sophisticated design and testing equipment; (3) access to UNIX code, methods and concepts; (4) UNIX architectural experience; and (5) a very significant financial investment.
It was the claim of access to Unix code that was the most threatening
allegation for the Linux community. SCO made it clear that, in its
opinion, Linux was stolen property: "It is not possible for Linux to
rapidly reach UNIX performance standards for complete enterprise
functionality without the misappropriation of UNIX code, methods or
concepts
". To rectify this "misappropriation", SCO was asking for a
judgment of at least $1 billion, later increased to $5 billion.
As the suit dragged on, SCO also started suing Linux users as it tried to
collect a tax for use of the system.
Send in the clowns
Though this has never been proven, it was widely assumed at the time that SCO's real objective was to prod IBM into acquiring the company. That would have solved SCO's ongoing business problems and IBM, for rather less than the amount demanded in court, could have made an annoying problem go away and also lay claim to the ownership of Unix — and, thus, Linux. To SCO's management, it may well have seemed like a good idea at the time.
IBM, though, refused to play that game; the company had invested heavily into Linux in its early days and was uninterested in allowing any sort of intellectual-property taint to attach to that effort. So the company, instead, directed its not inconsiderable legal resources to squashing this attack. But notably, so did the development community as a whole, as did much of the rest of the technology industry.
Over the course of the following years — far too many years — SCO's case fell to pieces. The "misappropriated" technology wasn't there. Due to what must be one of the worst-written contracts in technology-industry history, it turned out that SCO didn't even own the Unix copyrights it was suing over. The level of buffoonery was high from the beginning and got worse; the company lost at every turn and eventually collapsed into bankruptcy.
At a talk some years ago, your editor got a good laugh by saying that, in
the SCO case, we had the good luck to be sued by idiots. SCO created a
great deal of fear, uncertainty, and doubt in the industry, but a smarter
attack could have been a lot worse. Even as it was, this was a period when
SCO was making waves by threatening to sue any company using Linux — at a
time when our foothold was rather less well established than it is now.
Microsoft, which had not yet learned to love Linux, funded SCO and loudly
bought licenses from the company. Magazines like Forbes were warning
the "Linux-loving crunchies in the open-source movement
" that they
"should wake up
". SCO was suggesting
a license fee of $1,399 — per-CPU — to run Linux.
All of this was a campaign to create a maximal level of fear around Linux and, as a result, to put pressure on IBM to settle. It certainly succeeded to an extent. Such an effort, in less incompetent hands, could easily have damaged Linux badly. As it went, SCO, despite its best efforts, instead succeeded in improving the position of Linux — in development, legal, and economic terms — considerably.
The enduring effects
Consider the charge of directly-copied source code — one that SCO CEO Darl
McBride loudly
made in May of that year. At the time, there was not a lot of
oversight applied to code going into the kernel; the project had only just
begun using BitKeeper as its first version-control system, after all, and
the maintainer hierarchy that has served the project so well was in its
infancy. It seemed almost inevitable that, among the millions of lines of
code poured into the kernel from an unknown number of sources, some would
be found to have been copied from Unix; source for various Unix
distributions was not hard to come by in those days. Richard Stallman allowed
that: "In a community of over half a million developers, we can hardly
expect that there will never be plagiarism
". The real question seemed be just how bad the damage
would turn out to be.
The world waited for McBride to actually show all this copied code — sometimes said to be "millions of lines" — that he had found. The actual code turned out to be a snippet in the ia64 architecture subsystem. It undoubtedly shouldn't have been there; interestingly, it had already been removed by the time SCO fingered it. Beyond that, SCO's claims touched on code — read-copy-update and the Berkeley packet filter, for example — that could not possibly have come from anything it owned. When SCO was asked to put up its evidence, all that came out was a bunch of handwaving.
The important part is this, though: SCO's efforts and those it inspired put the Linux kernel code under the sort of microscope that few projects ever see. There were allegedly billions of dollars at stake, after all. But despite that incentive and all of the resources poured into inspecting the kernel source, nobody ever found all that copied code; it simply did not exist. SCO managed to prove the cleanliness of the kernel's pedigree in a far more convincing way than anybody else could have. Nobody now questions the legitimacy of the kernel's source code.
Another thing that is no longer questioned is the need for the free-software community to have lawyers on its side. It is not enough to be right; we have to be able to prove that we are right and deter potential attackers. The SCO lawsuit brought about a substantial increase in the legal resources available to the community, both within companies and in projects and related organizations. Anybody who hopes to extract rents from the free-software community now will face a strong, united, and capable defense.
A related change is the improved procedures that the community has adopted; just because SCO proved that the kernel's code was clean doesn't mean it will always be. The adoption of the developer's certificate of origin for kernel code is one obvious example; its purpose was to avoid the next SCO case. As Linus Torvalds said at the time:
People have been pretty good (understatement of the year) at debunking those claims, but the fact is that part of that debunking involved searching kernel mailing list archives from 1992 etc. Not much fun.For example, in the case of "ctype.h", what made it so clear that it was original work was the horrible bugs it contained originally, and since we obviously don't do bugs any more (right?), we should probably plan on having other ways to document the origin of the code.
So, to avoid these kinds of issues ten years from now, I'm suggesting that we put in more of a process to explicitly document not only where a patch comes from (which we do actually already document pretty well in the changelogs), but the path it came through.
Many other projects have adopted similar procedures, most of which have the happy result of documenting the provenance of code without imposing heavy bureaucracy on the process. Efforts like SPDX are also partially motivated by the desire to avoid another SCO.
Long live the long-hair smellies
Perhaps the most significant outcome of this whole episode, though, is what it revealed about our community. If SCO wanted to scare developers and users into fleeing Linux, it certainly failed. While IBM waged a devastating campaign in the courts, it often seemed like many of the battles were won in the wider community; it turns out that, when thousands of developers and users join a fight against a common enemy, they can do amazing things.
Developers from across the community (occasionally referred to within SCO as the "long-hair smellies") put their time into debunking SCO's code-ownership claims, to great effect. Resources like Groklaw marshaled information for the defense and, just as importantly, informed the community about what was at stake and how the system works. Encouraged by this work, users stuck with Linux and refused to pay SCO's licensing demands. It was not just IBM's lawyers and money that won this fight; it was a widespread community that had built something special and had no intention of letting a failing company steal it.
Twenty years later, it is fair to say that Linux is doing a little better
than The SCO Group. Its swaggering leader, who thought to make his fortune
by taxing Linux, filed
for personal bankruptcy in 2020. We survived a focused and determined
attack that would have brought an end to many other enterprises, regardless
of the injustice involved. But the SCO attack should never be forgotten,
because of the ways that it changed our community, but also because,
despite our much stronger position now, it could happen again. The Linux
community has created a vast amount of wealth, whether measured in code or
in actual money; when that happens, there will always be those who wish to
steal some of that wealth. Hopefully we will be as lucky when the time
comes to fend off the next one.
Posted Mar 3, 2023 15:47 UTC (Fri)
by corbet (editor, #1)
[Link] (5 responses)
Posted Mar 3, 2023 16:23 UTC (Fri)
by dullfire (guest, #111432)
[Link]
Posted Mar 3, 2023 16:36 UTC (Fri)
by jengelh (guest, #33263)
[Link]
Well, how that turned out. Just look at the numbers at https://lkml.org/lkml . More patches than ever!
Posted Mar 4, 2023 2:18 UTC (Sat)
by felixfix (subscriber, #242)
[Link]
Posted Mar 5, 2023 17:24 UTC (Sun)
by nix (subscriber, #2304)
[Link]
Posted Mar 7, 2023 0:04 UTC (Tue)
by KaiRo (subscriber, #1987)
[Link]
That said, great writing, sounds like an epic saga.
Posted Mar 3, 2023 17:10 UTC (Fri)
by PaulMcKenney (✭ supporter ✭, #9624)
[Link] (2 responses)
Posted Mar 10, 2023 3:45 UTC (Fri)
by NZheretic (guest, #409)
[Link] (1 responses)
Posted Mar 10, 2023 5:14 UTC (Fri)
by PaulMcKenney (✭ supporter ✭, #9624)
[Link]
Posted Mar 3, 2023 18:47 UTC (Fri)
by rweikusat2 (subscriber, #117920)
[Link]
:-)
Posted Mar 3, 2023 19:00 UTC (Fri)
by zeekec (subscriber, #2414)
[Link] (3 responses)
Posted Mar 3, 2023 19:57 UTC (Fri)
by rgmoore (✭ supporter ✭, #75)
[Link] (2 responses)
I miss Groklaw, too, but I think part of the decision to shut it down was that it just wasn't as critical anymore. By the time the shutdown happened, it was pretty clear the lawsuit was going to fail eventually. It was all about how that was going to happen, not whether, and that made it a lot less interesting.
Posted Mar 4, 2023 16:01 UTC (Sat)
by zeekec (subscriber, #2414)
[Link]
When Groklaw shut down, pj was already covering many other cases. None of the last 20 articles are about SCO (I did not look further.).
And lawsuits have not gone away, and I (definitely not a lawyer) have not developed the skills or the knowledge to understand the ins and outs of the legal system. That was the gift that Groklaw provided; pj translated all that lawyer speak into language that I could understand. In addition, she has the skills to research the law and just plain knowledge of the law that would take me another lifetime to learn (i.e. I'm busy doing stuff I enjoy; I want someone who enjoys that stuff to share it with me.).
Posted Mar 5, 2023 0:40 UTC (Sun)
by david.a.wheeler (subscriber, #72896)
[Link]
Posted Mar 3, 2023 19:05 UTC (Fri)
by flussence (guest, #85566)
[Link] (31 responses)
They really feel threatened by that bicycle, and what it represents.
Posted Mar 3, 2023 21:47 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (30 responses)
Those 24-lane highways enable commutes that are faster than in any of "transit heaven" large cities. I was surprised at first when I learned this, but it's true.
Posted Mar 4, 2023 12:35 UTC (Sat)
by tialaramex (subscriber, #21167)
[Link] (29 responses)
One of the ways these numbers most often get fudged is by comparing very different things as if they were the same. Anchorage and New York City aren't similar in any useful way, so the fact a NYC resident who reports any commute at all often spends longer commuting than an Anchorage resident isn't telling us that New York ought to embrace even more car culture than it already has.
Posted Mar 4, 2023 20:02 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (28 responses)
Time in minutes. The average for the US is 26 minutes. Houston (which has that aforementioned 24-lane highway) is right on the average.
Meanwhile, the average commute time for most large European cities is above 33 minutes. And the comparison gets even worse when we consider cars vs. transit. Transit commutes are longer than car commutes pretty much everywhere.
> Anchorage and New York City aren't similar in any useful way, so the fact a NYC
We can compare Houston and NYC. Houston has 24-lane highways and 26-minute commutes. NYC has subways and 32-minute commutes. They have similar populations and a similar enough per-capita income.
Posted Mar 4, 2023 20:57 UTC (Sat)
by pizza (subscriber, #46)
[Link] (1 responses)
Meanwhile, while on "transit commutes" you can actually do something other than try to not die on the road.
Posted Mar 4, 2023 21:23 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Mar 4, 2023 21:14 UTC (Sat)
by khim (subscriber, #9252)
[Link] (23 responses)
Are we talking about some different universe, perhaps? Because in our universe NYC with 8,467,513 population would be, naturally, two times larger than Houston with it's 2,288,250 population. This would mean that 26-min commute in Houston is worse than 32-minute commute in New Year. For them to become comparable you need either 50-min commute in NYC or 17-min commute in Houston. You may argue that it's more result of higher population density in NYC, but then again, of course, things like 24-lanes highways would make population less dense! Again: are you sure that we are dealing with apples-to-apples comparisons? Because when you compare 26 minutes Houston one-way commute to 40 minutes daily commute you are not comparing apples-to-apples either. In apples-to-apples comparisons EU does similarly to US and that's without the need to spend 20% of world oil production for 5% of world population.
Posted Mar 4, 2023 21:20 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (22 responses)
You need to look at "Greater Houston Area" - 7.21 million people vs 8.5 million in NYC.
> Again: are you sure that we are dealing with apples-to-apples comparisons? Because when you compare 26 minutes Houston one-way commute to 40 minutes daily commute you are not comparing apples-to-apples either.
I'm not confusing anything. The average one-way commute in Europe for large cities is 33 minutes. And there are no large (>1000000 population) European cities with a 20-minute one-way commute.
Here's a nice table: https://transportgeography.org/contents/chapter8/urban-tr...
I know this is a shock for many people, but transit never actually improves commute times. It just enables more density.
Posted Mar 4, 2023 22:31 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link] (13 responses)
Posted Mar 4, 2023 23:53 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (12 responses)
Actually, it doesn't. Transit pretty much always increases the housing cost, making it more unaffordable. Sometimes in a runaway fashion (see: Manhattan). Small business impact is a mixed story. A mall with a lot of parking space nearby might be a better space for a small business than a small shop on a transit-enabled street.
The density is basically the only "advantage" that transit provides. People in Houston mostly live in single-family houses with lots of space per capita, while people in NYC mostly live in smaller apartments.
Posted Mar 5, 2023 3:09 UTC (Sun)
by khim (subscriber, #9252)
[Link] (4 responses)
It also makes it possible to sustain the same population on much smaller consumption of fuel. It would be interesting to see what US would be doing when it would lose the ability to get resources for free in coming years. Would it switch to public transit or to bikes when it would lose the ability to drive so many cars? I guess we'll see that soon.
Posted Mar 5, 2023 3:44 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
That is true. But at this point in time we can safely assume that most gas cars will simply be replaced with EVs. Several US states already have programs to start phasing out gas cars by mid-2030-s.
And carbon footprint of EVs can actually be pretty competitive with public transportation: https://ourworldindata.org/travel-carbon-footprint
Posted Mar 5, 2023 23:17 UTC (Sun)
by Wol (subscriber, #4433)
[Link]
Okay, most electric cars have regenerative braking, which gives them better fuel economy, but not THAT much better.
Cheers,
Posted Mar 5, 2023 23:31 UTC (Sun)
by anselm (subscriber, #2796)
[Link]
Never mind how cars work. The big advantage of public transport – certainly in the city where I live here in Germany – is that if even a fraction of the people who are now taking a train, tram, or bus came to the city centre in their own car, there would be no space to park all those cars.
Posted Jan 5, 2024 13:45 UTC (Fri)
by antidopinguser (guest, #168932)
[Link]
Posted Mar 5, 2023 10:06 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (1 responses)
One only has to look at the impact of the Elizabeth Line in London. I guess house prices near the Abbey Wood terminus have maybe doubled. I use that line to commute, and it's brilliant, it's halved journey times to Central London from 40 minutes to 20. But then of course you've got to get from the station to work ... which for me is a second journey. My commute is about 90 minutes, but it is from the edge of SE London, to outside North London, via the centre.
And I can sit and read!
Cheers,
Posted Mar 5, 2023 23:25 UTC (Sun)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Mar 5, 2023 14:04 UTC (Sun)
by kleptog (subscriber, #1183)
[Link] (4 responses)
That's because it provides a value that people are willing to pay for. If you give me a choice between 20 minute transit by car or 40 minute by train, I'll take the latter. In a train I can read a book (that's how I got through the Song of Ice and Fire in a reasonable time), whereas in a car that time is simply wasted. Ditch the car and you have more disposable income you can spend on other things.
> Small business impact is a mixed story. A mall with a lot of parking space nearby might be a better space for a small business than a small shop on a transit-enabled street.
Around here it seems to be going the other way. The malls are dying, the small businesses seem to prefer to be near transit-enabled residential areas. But then, this isn't America, so the way cities are laid out is entirely different.
Posted Mar 5, 2023 20:22 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
As I've said, you can listen to audiobooks and podcasts in a car. And very soon you'll be able to read as well, once the self-driving tech gets up to speed.
> Ditch the car and you have more disposable income you can spend on other things.
I haven't verified this, but I've read that households in Houston, TX actually have a slightly higher income after taxes and housing than NYC-ers.
Posted Mar 5, 2023 20:29 UTC (Sun)
by corbet (editor, #1)
[Link] (2 responses)
Posted Mar 20, 2023 22:18 UTC (Mon)
by flussence (guest, #85566)
[Link] (1 responses)
I genuinely thought nobody would interpret "a 24 lane highway" as anything other than cartoonish hyperbole for the sake of an analogy to big iron mainframes, and definitely did not imagine a flame war defending the existence of such things. Since writing that comment I've been exposed to photographs of one with 26 lanes.
Perhaps car analogies as a whole concept should be consigned to history like SCO. It's hard to keep up with reality.
Posted Mar 22, 2023 10:45 UTC (Wed)
by paulj (subscriber, #341)
[Link]
(Analogies may be useful for bootstrapping understanding of one problem with knowledge from another domain, but one can not use them to /reason/ about one domain using the logic of another domain - unless one can prove the domains are isomorphic).
Posted Mar 5, 2023 3:05 UTC (Sun)
by khim (subscriber, #9252)
[Link] (4 responses)
Why would you compare “Greater Houston Area” to NYC and not to New York metropolitan area? That's still 2.5x times difference in population. Yes, but that's, again, apples-to-oranges comparison: because of Downs–Thomson paradox you wouldn't commute on car faster than on public transit in these cities. It does improve the commute times, but it couldn't fix the issues with inefficient road networks. 24-lane highway would always be faster than 2-lane highway, public transit or no public transit.
Posted Mar 5, 2023 3:31 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
Greater Houston Area is basically what people think then they say "Houston". It's a largely homogenous area of low-density housing. I.e. if you're driving through it, you won't feel a difference when you cross from Houston proper into Jersey Village.
This is true in NYC as well. You won't feel a rapid change once you pass the "Leaving Brooklyn? Fuhgeddaboudit" sign. That's why comparing NYC proper with GHA makes sense. You're comparing two different modes of development, and there's a lot of good statistical data about both of them.
NYC metro area is not like that. It's too diverse within itself for useful conclusions. You can do interesting comparisons _within_ the metro area itself, though.
> Yes, but that's, again, apples-to-oranges comparison: because of Downs–Thomson paradox you wouldn't commute on car faster than on public transit in these cities.
That's true. On the other hand, wouldn't it be nice if everyone could have faster commutes?
> It does improve the commute times
Nope. The average transit times tend to go _up_ within a decade after new commute modes are introduced!
It's a pretty simple effect: you build a new subway line and the people near its stations now enjoy faster commutes. Great! So now more people move in within some distance from the new station and start commuting. Since they are further apart, the average commute goes back up again.
But that's not all! Some people need to commute on routes that are not directly served by non-stop transit, and even one transfer explodes the commute time. And the proportion of these people grows with the scale of the system. So the average time goes even higher.
Posted Mar 5, 2023 8:05 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link] (1 responses)
As someone who grew up in the NY Metro area, I think I simultaneously agree and disagree with you:
* You will feel a significant change moving from Manhattan to any of the other four boroughs, especially Staten Island. But Staten Island is kind of an oddball - it's basically a suburb that got incorporated into the city. So maybe we should ignore it. Still, Manhattan is a very different place to, say, the Bronx.
Posted Mar 5, 2023 20:37 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
It might make sense to include Jersey City in the analysis, as a lot of people there commute to Manhattan. But a lot of statistical data is not well-suited for that.
Posted Mar 10, 2023 9:05 UTC (Fri)
by anton (subscriber, #25547)
[Link]
Posted Mar 5, 2023 7:57 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link] (2 responses)
* Wikipedia says the area includes Pike County, Pennsylvania, but frankly I'm not entirely sure I buy that. It doesn't make much difference in terms of population, though.
Posted Mar 6, 2023 17:33 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
The line does seem to move depending on what side you're on and how you feel about "the city" :) . I think "the 518" is about the only area that "everyone" agrees is "upstate". Anyways, I have this poster[1] at home and I'm happy enough with it.
Myself? I draw the line at the AT's path through the state :) .
[1] https://i.pinimg.com/originals/07/04/e0/0704e010d1504b91c...
Posted Mar 10, 2023 15:05 UTC (Fri)
by kpfleming (subscriber, #23250)
[Link]
Posted Apr 25, 2023 10:59 UTC (Tue)
by Klavs (guest, #10563)
[Link] (1 responses)
Everything I can find - says car traffic in larger cities break badly - and does not scale well.
In Copenhagen (an in Amsterdam) - the time to a "normal job" - which is typicly 1-10km in the city - is faster by bike, than by car. You might beat the bike with a few minutes - outside busy hours - but thats typicly NOT when you need to go there, if its for a job :)
Depending on where you need to go - many places will be faster by train/metro as well (and with the free bike on train that copenhagen enjoys - that makes more places accessible faster via train).
In Copenhagen and Amsterdam, the bike is faster, because the investment was put down in improving bike paths and those routes - and when it snows - the bike lanes are the FIRST to get cleared from snow - every time on those "superbikelanes" as they call them in copenhagen :)
Posted Apr 25, 2023 19:14 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
> You can see this : https://www.nature.com/articles/s42949-021-00020-2
The graphs in the article are dishonest because they all use different (logarithmic!) scaling, obscuring the difference between transportation modes.
Figure 3 shows that European cities cluster around 200000 jobs accessible by transit:
https://media.springernature.com/lw685/springer-static/im...
Figure 4 shows that the US cities cluster around ~800000 jobs accessible by car:
https://media.springernature.com/lw685/springer-static/im...
So yep, well-ran car-oriented cities are plain better.
Posted Mar 3, 2023 19:23 UTC (Fri)
by huntermatthews (subscriber, #4490)
[Link] (3 responses)
Posted Mar 4, 2023 6:50 UTC (Sat)
by dobbelj (guest, #112849)
[Link] (2 responses)
Posted Mar 5, 2023 15:10 UTC (Sun)
by lkundrak (subscriber, #43452)
[Link] (1 responses)
Some years ago they released what seemed to be a rebadged FreeBSD as "OpenServer 10", but now it's gone from their web site. Nowadays they seem to be just selling their ~20 y/o systems.
Posted Mar 6, 2023 10:45 UTC (Mon)
by paulj (subscriber, #341)
[Link]
Posted Mar 3, 2023 19:52 UTC (Fri)
by geofft (subscriber, #59789)
[Link] (1 responses)
I wonder if NFTs and handwavy cryptocurrency coins will be more profitable for him than selling Linux licenses.
Posted Mar 11, 2023 21:03 UTC (Sat)
by Jannes (subscriber, #80396)
[Link]
Another serial fraud is now more of a thorn in the side of open source. It may blow over or he may turn out to be worse than SCO ever was: Craig Wright.
Posted Mar 3, 2023 20:43 UTC (Fri)
by biergaizi (subscriber, #92498)
[Link] (18 responses)
This is potentially a huge problem that affects the copyright status of the historical Research Unix and BSD code, but strangely nobody is talking about it or made any clarification. As a result, although it's already 47 years since the initial publication of John Lions' book, I think its copyright status is still clear as mud because of the SCO affair.
Nowadays, everyone just assumed that historical Unix code is completely free under a BSD-like license, for example, this is claimed by both Wikipedia and The Unix Heritage Society (TUHS).
> Fortunately, much of the historical Unix source code, including the research versions up to 7th Edition and many of the BSDs, are available in the Unix Archive and are covered by the Caldera license. This is essentially a BSD license and allows you to read, modify and distribute the source code.
You can find several original Unix recreations in emulators and also ports to modern platforms (like RISC-V or PIC) as technical demonstrations and history exhibition, under the assumption that the code is safe to work with. However, this Unix license was granted by the CEO of Caldera (i.e. the new SCO who started the lawsuits). If SCO didn't even own the Unix copyrights, is this license still valid? The Unix Heritage Society needs to clarify this problem, if it's found to be invalid, a petition to relicense Ancient Unix should be made to the current Unix copyright holder (Novell?) for the sake of history preservation.
Posted Mar 3, 2023 22:23 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (17 responses)
Pretty much everything you've said is handwaving to cover over the fact that huge chunks of copyright were never AT&T's in the first place, so all this stuff about Novell, and "the current Unix owner", and the Caldera licence, and and and is just hot air.
Simply put, the settlement between AT&T and BSD said "AT&T has pretty much *no* enforceable copyrights whatsoever", and AT&T managed to get a non-disclosure settlement out of BSD in return for walking away from the case, and probably paying most or all of BSD's costs.
Depending on what you mean by "Unix", huge chunks of it were written by the University Lions worked at in Australia, and had that University's copyrights plastered over it. Other huge chunks had University College London copyrights plastered over it, and yet more had, unsurprisingly, Berkeley copyrights plastered all over it.
AT&T removed the lot. And when they sued Berkely they made the mistake of suing Berkeley for a lot of code that Berkeley could prove *they* wrote. So pretty early into the suit, the Judge issued an opinion that said, effectively, "if your record keeping is that bad that you sued Berkeley for stealing their own code, you've just proved your record keeping is worthless and cannot be trusted. You are going to have to provide a proven history for EVERY SINGLE LINE you want to sue over". And AT&T didn't have said history.
So Novell effectively bought a "quitclaim" to the Unix code, and an NDA that said no-one would talk about who actually owned it. AT&T didn't have any defensible copyrights, and the other three main copyright holders (a) probably didn't know what they owned, and (b) had no desire to sue over it, either. (Especially as all three had, I believe, used BSD or BSD-style licences.)
If you want to clarify the copyrights, please do, but it'll be an Augean Stables job ... I don't think you'll find a Hercules to help ...
Cheers,
Posted Mar 3, 2023 23:13 UTC (Fri)
by rgmoore (✭ supporter ✭, #75)
[Link] (13 responses)
I think there's a bit more there than you're getting at. Yes, Berkeley had a version that was completely free of AT&T's code, but that was because they had spent the previous few years rewriting to remove everything that came from AT&T. There absolutely was AT&T code in earlier versions. And, of course, AT&T (actually Unix Systems Labs, by that point) sued Berkeley anyway.
A further complication was a question about the copyright status of some of the older AT&T code. Before the 1976 Copyright Act, anything that was published without a copyright notice attached was made part of the public domain. IIRC, there was some question back then if copyright even applied to software, so at least some of the old code was published without a copyright notice. AT&T tried to put the toothpaste back in the tube by adding copyright notices later, but it was too late for any code that had been published without copyright notices.
Ironically, the AT&T v Berkeley suit was actually a boon for Linux adoption. It kept BSD under a cloud of FUD during the critical period when Linux was first being developed, giving it space to develop. If not for the AT&T suit, Linus might have just got a copy of FOSS BSD rather than writing his own kernel. Even if he had decided to write his own kernel as a learning experience, many of the early contributors probably would have wound up using BSD instead. I kind of wonder if that history was on SCO's mind when they launched their lawsuit.
Posted Mar 4, 2023 10:18 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (12 responses)
Mixed up with that, is a lot of Berkeley / Australian / UCL code which is arguably BSD. And nobody can be bothered to work out which is what. Whether AT&T code was removed has no bearing on the fact that AT&T has no copyrights.
Cheers,
Posted Mar 4, 2023 10:30 UTC (Sat)
by biergaizi (subscriber, #92498)
[Link] (9 responses)
This is an extraordinary statement that I haven't previously seen, and it would be great news if it's true. It's not on Wikipedia, The Unix Heritage Society also didn't mention this in the same web pages that re-distribute historical Unix code, only that they're covered by Candela's 4-clause license. Several articles about the history of BSD is also limited to saying that the AT&T code was proprietary and they were removed/rewritten in 4.4BSD.
What we need is a serious clarification from an authoritative source... But unfortunately, until someone does that, the copyright status of Unix is still as clear as mud...
Posted Mar 4, 2023 10:53 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (8 responses)
We HAVE the AT&T / BSD lawsuit settlement!
I think it's been published on Groklaw - I'm pretty certain somebody did a "Freedom of Information" request, got their hands on it, and sent it to PJ.
This is what I'm referring to - the Judge did an opinion that AT&T - by removing other peoples' copyright notices - had destroyed any chance of them proving that they held any copyrights whatsoever. At which point the case just collapsed.
You (or someone) stated that 4.2.2 (published after the statement) definitely contained no AT&T code. Did that statement mean "code written by AT&T", or did that mean "code copyright AT&T"? Because the lawsuit meant that Berkeley were able to make that *second* statement without even bothering with a code audit! I seriously doubt they either audited and removed code by AT&T, or removed all code of unknown provenance, which they would have had to do to make the *first* statement.
And note that many of those copyright notices were FOREIGN notices. Which are definitely legally enforceable. I would be EXTREMELY surprised if you can publish / record / whatever stuff in America (that may be Public Domain there) and export it abroad to where it is copyright, without paying the local copyright fees. The copyright holders can't touch you in America, but as soon as you move on to their turf, you play by their rules. If they wanted to export to the English speaking world, they couldn't afford to upset UCL or Australia ...
Cheers,
Posted Mar 4, 2023 11:16 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (1 responses)
Cheers,
Posted Mar 7, 2023 17:29 UTC (Tue)
by biergaizi (subscriber, #92498)
[Link]
> Unfortunately for AT&T, was it Bill Joy wrote vi?
Yep, I believe so. Bill Joy did a lot of things during the early days of BSD.
Also, fun fact! When the output destination of ls(1) is a tty, ls(1) outputs file names in a multi-column format. When the output is a pipe or file, ls(1) outputs file names in the conventional one-file-per-line format. Do you know where did this creation came from? BSD 1.0, by Bill Joy.
Anyway, thanks for the pointers. It makes me less nervous about if my brain could be contaminated by the ancient Research Unix or BSD code I've read...
Posted Mar 4, 2023 16:10 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (4 responses)
> We HAVE the AT&T / BSD lawsuit settlement!
http://web.archive.org/web/20200609023731/http://www.groklaw.net/article.php?story=20041126130302760
There's probably more that you want, but I think the best way to explain why I've been saying there are no enforceable AT&T copyrights in Unix, and why AT&T capitulated, can be summed up as ...
Copyright statements were a mandatory part of US law if you wanted to claim copyright.
As a result, especially as a copyright statement is a legal statement of claim, people generally don't forge statements, and practice was a copyright statement was pretty much incontrovertible proof of a claim.
At some point, AT&T decided they wanted to protect Unix with Trade Secret law, and deleted all the copyright statements - including everybody elses'!!!
Then they decided, once copyright was settled US law, that they were going to protect Unix with copyright, and plonked THEIR OWN copyright statements everywhere.
At which point, some bright lawyer presumably thought "Hey, Berkeley are selling / giving away Unix too. We own it, let's sue them."
So they sued Berkeley, and claimed, amongst other things, vi. Berkeley fought back, proved that they owned vi, and that AT&T had deleted the Berkeley copyright statement and replaced it with an AT&T one. More to the point, it became clear that AT&T really believed they owned vi - they had no clue or record that the copyright statements had been replaced! Until they dug, that is, and discovered the orders to do so, but no record of what had actually been done.
At which point, I suspect the Judge ruled that the AT&T copyright notices weren't worth the electrons they were written with, and AT&T would be on a hiding to hell trying to prove anything because they had destroyed all the records. Hence the complete collapse of AT&T's case.
Now to go and read that piece of history again :-)
Cheers,
Posted Mar 5, 2023 3:07 UTC (Sun)
by rqosa (subscriber, #24136)
[Link] (3 responses)
> Copyright statements were a mandatory part of US law if you wanted to claim copyright. That was true prior to (no later than) March 1, 1989 when the US joined the Berne Convention. However, System V Unix and (later) Novell UnixWare continued to be developed after that point in time, and therefore at least some parts of the SysV/UnixWare codebase would be covered by automatic copyright. SCO filed (but eventually lost) their slander-of-title lawsuit against Novell in response to Novell issuing a press release (on May 28, 2003) in which Novell claimed to own the copyrights to (some of) the source code for UnixWare and System V Unix and also claimed that, in 1995, they (Novell) had merely sub-licensed rights to develop and market UnixWare to "the old SCO" (i.e. the original Santa Cruz Operation company in Santa Cruz, CA) rather than having "convey[ed]" the ownership of Novell's UnixWare copyrights to old-SCO. Here's an excerpt of Novell's press release: "Importantly, and contrary to SCO's assertions, SCO is not the owner of the UNIX copyrights. Not only would a quick check of U.S. Copyright Office records reveal this fact, but a review of the asset transfer agreement between Novell and SCO confirms it. To Novell's knowledge, the 1995 agreement governing SCO's purchase of UNIX from Novell does not convey to SCO the associated copyrights."
Posted Mar 5, 2023 9:55 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (2 responses)
> That was true prior to (no later than) March 1, 1989 when the US joined the Berne Convention. However, System V Unix and (later) Novell UnixWare continued to be developed after that point in time, and therefore at least some parts of the SysV/UnixWare codebase would be covered by automatic copyright.
Which is why I used the past tense.
But it's an important part of the story. Because AT&T deleted OTHER PEOPLES' copyright statements. And almost certainly did it long before March 1, 1989.
Cheers,
Posted Mar 5, 2023 12:14 UTC (Sun)
by rqosa (subscriber, #24136)
[Link] (1 responses)
I mentioned the dispute over SysV/UnixWare copyrights because that was the context for corbet's statement in the original article that "it turned out that SCO didn't even own the Unix copyrights it was suing over": the outcome of the SCO v. Novell lawsuit established that (as of 2004 when SCO sued them) Novell actually did own the copyright to some SysV source code written by AT&T/USL that found its way into UnixWare and/or some UnixWare source code written in-house at Novell. Incidentally, the previous CEO of Caldera a.k.a. "new-SCO" (Ransom Love) was quoted by eWeek in September 2003 (i.e. a little over 1 year after Darl McBride took over as CEO, but before SCO sued Novell) as saying that "Indeed, at first we wanted to open-source all of Unixs [sic] code, but we quickly found that even though we owned it, it was, and still is, full of other companies [sic] copyrights. […] We didnt want to spend years clearing out the old copyright issues in the face of corporate opposition". (Of course, the "we owned it" part of his statement was later refuted by the aforementioned lawsuit's final result.)
Posted Mar 6, 2023 10:23 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
AFAICT, the lawsuit doesn't refute the "we owned it" part. What they owned was the aggregation of a large pile of code, and they had permission to use the individual components, but they did not own the individual components.
Thus, if you copied old-UNIX as a whole, they'd have ownership. But individual components were owned by other companies who'd licensed them to SCO.
Posted Mar 7, 2023 18:11 UTC (Tue)
by biergaizi (subscriber, #92498)
[Link]
So BSDi managed to invalidate AT&T's copyright claim without the need to claim BSD's independence. But a code rewritting campaign to free BSD from AT&T code definitely exist. Perhaps not 100% rigorous in a legal sense, but it was still a systematic campaign. According to the O'Reilly book Open Sources: Voices from the Open Source Revolution [1], BSD's core developer Kirk McKusick said they recruited many volunteers on this project.
> During one of our weekly group meetings at the CSRG, Keith Bostic brought up the subject of the popularity of the freely-redistributable networking release and inquired about the possibility of doing an expanded release that included more of the BSD code. Mike Karels and I pointed out to Bostic that releasing large parts of the system was a huge task, but we agreed that if he could sort out how to deal with reimplementing the hundreds of utilities and the massive C library then we would tackle the kernel. Privately, Karels and I felt that would be the end of the discussion.
> Undeterred, Bostic pioneered the technique of doing a mass net-based development effort. He solicited folks to rewrite the Unix utilities from scratch based solely on their published descriptions. Their only compensation would be to have their name listed among the Berkeley contributors next to the name of the utility that they rewrote. The contributions started slowly and were mostly for the trivial utilities. But as the list of completed utilities grew and Bostic continued to hold forth for contributions at public events such as Usenix, the rate of contributions continued to grow. Soon the list crossed one hundred utilities and within 18 months nearly all the important utilities and libraries had been rewritten.
This version eventually became 4.3BSD Net/2. This was why UCB allowed its public release, including to users without an AT&T's Unix license. This was why BSDi was confident enough to launch its competing system based on BSD without worrying about AT&T.
AT&T sued anyway.
[1] https://www.oreilly.com/openbook/opensources/book/kirkmck...
Posted Mar 5, 2023 10:55 UTC (Sun)
by gdt (subscriber, #6284)
[Link] (1 responses)
The question is about Ancient Unix, not Unix. That is, it includes early Unix versions which had not even shipped beyond AT&T, let alone into the hands of those pesky kids at UCB. The basic answer is that the legal protection is the amazingly low stakes in Ancient Linux. Even the SCO v IBM litigation wasn't about access to Unix licensing revenues, but about gaining access to Linux revenues. Unix™ has become even less relevant since, with Ancient Unix of minute relevance within that, being an niche primarily of interest to historians of computing. As for more modern Unix, the claim "*ALL* AT&T code is effectively Public Domain" is a stretch. UNSW-authored files are obviously not public domain (as this is not a concept in Australia's copyright law). If created by students, then those individual students may have an interest in the copyright. If created by staff, the simple question if the Commonwealth of Australia or the state of New South Wales holds the copyright would involve a great deal of paralegal time and money for the expenses of government archives. This supports your basic argument: that the copyrights of Unix are confused beyond usefulness for a litigant. That rights confusion and the low stakes are the issues for someone bringing a suit about Unix. The suit is either (a) about "Unix" and therefore has unclear title, or (b) about "files" and therefore has trivial compensation.
Posted Mar 5, 2023 11:50 UTC (Sun)
by Wol (subscriber, #4433)
[Link]
Please use your brain! Sorry to be damn blunt, but this was drummed into us on Groklaw.
UNSW-authored files are - quite clearly - *not* AT&T code. So UNSW-authored files are not included in the claim about AT&T code.
They seem to have been lumped in with the Berkeley code, and are assumed to be BSD-licenced, but everyone assumes they are "free to use", presumably with good cause, and nobody seems to know what that code is anyway.
The legal status is presumably pretty clear. UNSW will have stuck a copyright notice on it. AT&T removed said notice - an act of dubious and vandalous legality, given that those notices were applied in a jurisdiction that recognised them, and outside of the US those copyright statements are still valid. Which probably means exporting that old code is a copyright violation :-) but at the end of the day nobody cares.
Cheers,
Posted Mar 4, 2023 9:05 UTC (Sat)
by biergaizi (subscriber, #92498)
[Link] (1 responses)
You misread my comment, modern-day BSD systems are not my point. It's clear that they're free. Modern-day BSD systems are derived from 4.4BSD-Lite2, which was released after the AT&T settlement and is free of legal disputes. It's also known for a fact that BSD essentially replaced all AT&T code at this point. My point was made specially on the unclear copyright status of historical Ancient Unix source code that is no longer in use today, what I meant is the Bell Labs / AT&T Unix code in its original form, and since BSD was originally a Research Unix derivative, this would also include all historical BSD versions before the rewrite effort. Examples include the original UNIX v6 source code described in John Lions' book A Commentary on the UNIX Operating System, or 2.xBSD running on the PDP-11 system, which was a fork of 4.xBSD. In the early 2000s, Candela claimed that they were licensing everything under a permissive free software license that is almost identical to the 4-clause BSD-license. [3][4] As a result, the copyright status of these historical Unix versions are widely assumed to "free at last". For example, the Wikipedia page of "Unix v6" says, "License: Originally proprietary commercial software, now free software under a BSD License." [1] The Wikipedia page of "Ancient Unix" says everything from UNIX v1 to Unix v7 is free software. [5] The Unix Heritage Society (TUHS) [2] also claims that Candela license's covered these historical versions. As a result, they're widely circulated and distributed online. Some examples include: * Lions' Commentary on UNIX 6th Edition, with Source Code * Continuous Unix commit history from 1970 until today * A port of UNIX V6 to the PIC32 microcontroller * Xv6 for RISC-V But the question is: If Candela (a.k.a. new SCO) was not even the copyright holder of Unix, did Candela really have the rights to relicense these historical Unix versions under 4-clause BSD? If not, the existence and re-distribution of all of these works for historical and educational interest remain under the threat of its unclear copyright. [1] https://en.wikipedia.org/wiki/Version_6_Unix
Posted Mar 4, 2023 10:24 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
And *MY* point was that the lawsuit was a massive own goal for AT&T, and effectively destroyed any and all copyright they had in Unix, Ancient Or Modern.
The reason for all the secrecy over what was actually sold by AT&T to Novell was that it was effectively NOTHING - a "quitclaim". The only copyrights that *MIGHT* apply to Original Unix were those of Berkeley, UCL and Australia. AT&T themselves had nothing to sell. Novell basically got the business, but no IP whatsoever. Because there was none to sell.
Cheers,
Posted Mar 6, 2023 3:58 UTC (Mon)
by rqosa (subscriber, #24136)
[Link]
> AT&T removed the lot. And when they sued Berkely they made the mistake of suing Berkeley for a lot of code that Berkeley could prove *they* wrote. Apart from the issue of parts of the Unix source code having been written by third parties (such as universities), another problem for USL in their lawsuit against BSDI was the issue that, according to the judge, some older Bell Labs-written source code (specifically, parts of UNIX/32V, the VAX port of 7th Edition Research Unix) qualified as having been "published" without copyright notices pre-Berne Convention: "In order to prevail, Plaintiff must prove that it has a valid copyright in the UNIX code. Plaintiff's chief difficulty here is the "Publication doctrine." […] This doctrine has suffered steady erosion over the years, and it now applies in full force only for works published prior to January 1, 1978. For works such as 32V (published in 1978), which were published after that date but before March 1, 1989, the doctrine is subject to the escape provisions of 17 U.S.C. § 405(a) and the common-law "limited publication rule." […] Version 32V source code has now been distributed, without notice, to literally thousands of licensees. Consequently, Plaintiff can have no valid copyright on 32V unless it can fit within one of the statutory or common law escape provisions. The three statutory escape provisions are listed in section 405(a). […] Plaintiff cannot avail itself of any of these [statutory] provisions. Notice was omitted from thousands of copies of 32V; no contractual agreements require the licensees to affix notice; Plaintiff failed to copyright 32V until 1992, well over five years after 32V was published; and Plaintiff has not yet made reasonable efforts to add notices to the many noticeless publications of 32V. Consequently, Plaintiff must try to fit within the common-law doctrine of limited publication. […] Plaintiff argues that it has only distributed 32V to three select groups of licensees: educational organizations, U.S. government agencies, and carefully-screened corporate entities. Although the former two groups could conceivably qualify as "selected," the latter can qualify only if the screening process is suitably restrictive. […] Even accepting this description of Plaintiff's screening process as true, it is hard to see how the screening would yield a selected group of corporations within the meaning of the doctrine of limited publication. […] I find that Plaintiff has failed to demonstrate a likelihood that it can successfully defend its copyright in 32V."
Posted Mar 3, 2023 21:31 UTC (Fri)
by cjs (subscriber, #45842)
[Link] (2 responses)
What is interesting is that they didn't choose to embrace Linux and developed their own distro...
http://www.groklaw.net/staticpages/index.php?page=2003101...
Posted Mar 3, 2023 22:38 UTC (Fri)
by grahamm (guest, #163964)
[Link] (1 responses)
Posted Mar 3, 2023 23:44 UTC (Fri)
by rgmoore (✭ supporter ✭, #75)
[Link]
There was a Caldera Linux that they put out before they bought whatever it was they bought from Santa Cruz and renamed themselves. This was a possible point to bring up in the lawsuit, since it gave IBM possible defenses of unclean hands and SCOX having licensed the code in question under the GPL.
Posted Mar 4, 2023 2:23 UTC (Sat)
by felixfix (subscriber, #242)
[Link] (1 responses)
Posted Mar 4, 2023 18:36 UTC (Sat)
by MarcB (guest, #101804)
[Link]
Such an attacker would have focused exclusively on the PR and FUD areas, in a much more distributed, "astroturfing" way. Instead of suing IBM and DaimlerChrysler, they could have gone exclusively for small players. Instead of presenting shoddy "evidence", they could have stuck to claims. SCO partially did this, but the focus was the main lawsuit.
The point is that while their claims were false, they were *not* inherently implausible - in particular for outsiders, like management. Even among technical people, at the time, there still was some fundamental opposition towards open source in general, and Linux in particular. There was significant group of "old school" Unix (mostly Solaris) guys who refused to take Linux seriously and clung to every straw. Some of them actually parroted SCO's claims. I recall some lively discussions...
Clever FUD could have convinced management at many companies to stay away from Linux and tainted its reputation for years. To a degree this actually happened, but it was fixable - in particular, because SCO undermined their own cause by making easily falsifiable claims in public.
Posted Mar 4, 2023 12:14 UTC (Sat)
by tonyblackwell (guest, #43641)
[Link] (5 responses)
Our 80286 system with a 100Mb hard drive ran a hospital lab with 10 serial green screens and some instruments hanging off it, the secret being the Stallion serial expansion card manufactured here in Brisbane and with SCO drivers. I thought heaven had come when the HD died and hospital replaced it with 200Mb.
Licensing was a considerable pain....
Posted Mar 4, 2023 18:48 UTC (Sat)
by ccchips (subscriber, #3222)
[Link] (4 responses)
Around the same time, I was building a communications system for membership offices around the country, so our office could help them transfer members from one state to another. It used an Altos computer with only 80 MB of disk space, running Xenix. Then they tried to use Microfocus Cobol for Unix, but the developers had already built the PC version of the membership software, and nobody really cared for the curses version on Altos terminals. But the key takeaway for me was this: I learned UNIX enough to understand Mark Williams Coherrent, which I installed on a really cheap laptop and enjoyed it, especially the really fat book with the UNIX tutorials. Not long afterward, I found Linux on the Practical Peripherals BBS, and that was wonderful, since I had to tailor the OS to work with the laptop, which gave me the confidence to build "sysgen" kernels for the IBM mainframe. Now, I use Linux exclusively, and help other people with their Windows systems.
Posted Mar 5, 2023 0:41 UTC (Sun)
by mtaht (subscriber, #11087)
[Link] (3 responses)
https://www.youtube.com/watch?v=QECNF-GxbDQ&t=40m37s
(the whole play is really funny if you remember the early 90s!)
I was working on SCO's 5 year plan (in light of windows coming out) around 1992, just as Linux arrived, looking at the 4+ pages of copyright holders, whose royalties that had to be paid on every copy sold of Open Desktop (a then $4k/box product), and feeling there was no hope. Then I discovered Linux was already well on their way to duplicating most of "our" functionality, installed it (.99.pl15!), ported some SCO unix apps over easily, looked at the trendlines of the Linux-related commit rates and codebase size vs our every other year "drop" from AT&T, and projected that Linux would exceed SCO's 400+ engineers, in output, and in functionality in 3 years, and completely exceed it in 5, with the possible exception of multi-cpu support.
I tried to convince then-management to get onboard this alternate track, and adopt Linux, and failed. It certainly wasn't obvious then that Linux would succeed, and it looked like BSD WAS going to get dragged down into AT&T's legal hole.
A year or so later SCO started to collapse (as did borland), and in 5 years, was a pale shadow of itself, betting everything on the tarentella product, which no-one remembers. By 1999, everything had turned out as I'd seen in the commit logs.
I note I was a naive kid when I arrived at SCO and left in 93. I thought *every* california tech company had a hot tub in the engineering building!
So while the lawsuit SCO was bad, the 80s, late 80s, early 90s SCO was a lot like early Linux culture, and I prefer to remember that, rather than what happened in the 00s.
My favorite part of the above musical, is the song "scohemian rhapsody", which still *perfectly* captures the tensions in any company attempting to ship good software.
In the end, I fear, all companies become evil.
Posted Mar 5, 2023 0:56 UTC (Sun)
by unixbhaskar (guest, #44758)
[Link]
Posted Mar 5, 2023 8:25 UTC (Sun)
by thoeme (subscriber, #2871)
[Link]
We were using SCO OpenServer 5 in an important 5 year project.
Posted Mar 5, 2023 20:24 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
There's no short-term money in fledging companies, only longer term promises. But once there is money then you just can't win against the greed of activists "investors" and other similar pressure. This forces most of the company to focus on the very short term and you can kiss any sort of strategy good bye. Sometimes you can even say good bye to rules, regulations and ethics because spotting and punishing violations takes time and who cares when the utmost priority is to make money _right now_.
So the cow is getting milked until it dies and gets replaced by the next big thing. I think it's called "Creative Destruction"?
Really good CEOs find ways to make some of this cycle happen _inside_ the same company but it's really hard; I don't want that job :-)
Mitigating this is BTW the very clear reason why some companies go or stay private.
But the most common mitigation is of course to become a monopoly. Monopolies became easier in 2010 when the US "free market" enshrined the freedom to buy congressmen without any limit: https://en.wikipedia.org/wiki/Citizens_United_v._FEC. Now companies can grow and stay evil for much longer :-)
Back to open-source and SCO: you know the end is near when the parasi... lawyers take power and try to sue competitors for all kinds of "intellectual property" violations. This is the very last milk you can get from the cow before it dies.
As an engineer that's why I selfishly prefer to work with free software: it means less opportunity for lawyers to make money off engineers and a smoother transition to the next big thing because most of the code can be re-used. Open-source also makes the easiest resume. And monopolies harder. There are rumours it can solve world hunger.
Companies try hard to instill a sense of belonging in "corporate culture" and pretend they're not just about money but this of course a lie; the only thing that actually matters is the _people_ you work with and it's often with them that you will move onto the next big thing. Random example of the week: "Stormgate is being developed by Frost Giant Studios. Members of our development team have been privileged to help create some of the most acclaimed and best-selling PC games of all time–including Blizzard Entertainment’s WarCraft® III and StarCraft® II."
The old word "company" is funny because it maintains the confusion between the (new) soulless corporate vessel and the (old) team inside it. https://en.wiktionary.org/wiki/company
Posted Mar 4, 2023 13:40 UTC (Sat)
by ballombe (subscriber, #9523)
[Link]
Was the lawsuit brought with the hope to win it ? maybe.
Posted Mar 6, 2023 10:36 UTC (Mon)
by paulj (subscriber, #341)
[Link] (33 responses)
It's literally just a command line flag, which many developers just cargo-cult add, so as to generate the right tag, cause the time they forgot they got nagged at to add it. I have witnessed maintainers do this with submissions missing SoB tags - "Add signed-off-by and resubmit!" many a time. There's no indication at all anyone who does knows why they're doing it, other than that it's a textual hoop to jump through that must be added to the commit text.
Well?
My recollection at the time is that Linus came up with this because other kernel devs were clamouring for much more heavyweight things, and he just implemented this as a sop "something must be done, this is something, it'll shut people up". He almost said as much on l-k.
Posted Mar 6, 2023 15:00 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (32 responses)
Given that anybody can sue anyone, for anything, then there's no protection possible. Other than to live in a country with a sane legal system, which at least gives you a chance to nip all this sillyness in the bud.
The point of the DCO, is that the developer concerned is vouching for the legal cleanliness of the code. If your DCO is on there, and there's a problem, YOU will be asked to explain it. Anybody who is stupid enough to cargo-cult legal declarations deserves the grief they get.
What the DCO is supposed to be is an indication that "I wrote this and I am entitled to contribute it to linux". It could be "my company wrote this and I am empowered to contribute it to linux". But if you don't feel comfortable adding your DCO, surely that's a clear sign that the code is tainted and should not be added ...
Cheers,
Posted Mar 7, 2023 11:10 UTC (Tue)
by paulj (subscriber, #341)
[Link] (31 responses)
Unlike the SoB tag, where:
a) you can't even show person the SoB tag even /knew/ they've been listed in that SoB tag. Unless the person /sending/ the commit is the SoB person (but then the SoB tag is redundant)
b) You definitely have no basis at all to claim the person in the SoB tag has any awareness of the DCO
Linus motivation for the SoB tag was just to add some documentation of the path the commit travelled through, and he wanted it in the commit message because of Linux kernel's email based work-flow. Why he came up with the DCO and the claim the SoB shows knowledge of and agreement with the DCO is... bizarre.
Further, given pretty much no other projects use the email workflow, and most other common workflows these days preserve the path - via the git history (merges/pulls), or via the *{hub,lab} meta-systems - the SoB tag is just baggage for nearly all projects.
Posted Mar 7, 2023 11:39 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (1 responses)
The DCO (and to a lesser extent the SoB) don't give a monkeys who the AUTHOR is.
What they care about is the LEGAL OWNER, who may, or may not, be the same person. Or may not even be a person at all!
The DCO says "the legal owner of this code says it's okay".
The SoB says "I've reviewed this patch" - for legality - for being sensible - even for just compiling.
So your git workflow doesn't even *address* the problem the DCO is solving ...
Cheers,
Posted Mar 7, 2023 11:50 UTC (Tue)
by paulj (subscriber, #341)
[Link]
Your comment, that the commit author and/or the entity listed in the SoB tag may not have anything to do with whomever is needed to make the assertation in the DCO is another problem. Not one I'm interested in - IANAL and I'm not really fit to judge the meaningfullness of the declaration.
ALL I'm saying is the SoB tag has *fuck all* use in establishing that anyone involved in the commit even *knows* about the declaration. It's completely useless in that regard.
So, just on that mechanism - NOT the meaningfulness of the declaration itself - a declaration.txt file, with a requirement that developers first provide a commit to append some sign of their identity to that declaration, is a meaningful mechanism (independent of the meaning and strength of the declaration). Establishing the validity of the provided identity is another matter again - there are many possibilities (from just going on the validity of the email, so far as you can establish with email headers; all the way to requiring developers to register through some process that incorporates identity-checks [for which there are service providers you can contract with]).
Posted Mar 7, 2023 11:43 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (28 responses)
Just because the person *sent* the commit, doesn't mean they have a clue what it *does*. You're assuming the person who sent the commit also reviewed the commit. If they're a maintainer, why should they?
Cheers,
Posted Mar 7, 2023 11:54 UTC (Tue)
by paulj (subscriber, #341)
[Link] (27 responses)
I have also seen intermediate developers add on Signed-off-By tags on commit messages of commits they received from someone else /with that someone else's name/, because they know the upstream they're going to send to will reject the commit otherwise.
Complete cargo-culting.
The whole SoB / DCO thing seems to be nonsense, in terms of providing some kind of legal protection - unless someone can show me how it does. I'm surprised to see it touted as doing so in this piece.
Posted Mar 7, 2023 12:02 UTC (Tue)
by paulj (subscriber, #341)
[Link]
Very human thing. We like sops. We can't solve the underlying problem, but we can create a fiction to address the social issue of the fear of the problem and make that go away. We just grasp the sop and pretend.
Posted Mar 7, 2023 13:13 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (25 responses)
Likewise with DCO, although maintainers rejecting stuff for lack of a DCO are on much firmer ground - all code SHOULD have a DCO.
The problem is not with the SoB or DCO, it's with the cargo-culters who are happy to make legal claims on behalf of other people. Still, I think that's pretty true of the legal profession as a whole, so why should J Random Maintainer be any different?
Cheers,
Posted Mar 7, 2023 13:36 UTC (Tue)
by paulj (subscriber, #341)
[Link] (24 responses)
Posted Mar 7, 2023 13:50 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (1 responses)
I'm hoping, in the near future, to have two DCO for ScarletDME. One will be my personal email addy saying "this is my work". The other will be my work addy saying "My employer is happy for me to contribute this work".
SoB is nothing to do with DCO. SoB is saying "I have reviewed this code and am happy with it". Maintainers should NOT be signing off for other people to say said other people have reviewed the code (unless said developer has said "add my SoB"). One SoB of mine that sticks in my memory is where somebody posted a patch that modified code I'd written. I explicitly SoB'd the patch to say I agreed with the changes. THAT is where SoB is important, it's nothing legal, it just says I'm happy with the patch (that modifies my original code, in my case).
(That's why adding your name to a list for DCO purposes is not sufficient - you can have multiple legal personae, and have to sign for all of them...)
Cheers,
Posted Mar 7, 2023 13:58 UTC (Tue)
by paulj (subscriber, #341)
[Link]
"The rules are pretty simple: if you can certify <the kernel DCO text here>
Signed-off-by: Random J Developer <random@developer.example.org>
The SoB is the certification.
This has been cargo-culted to many other projects. Many of whom do not even make reference to the DCO (by including the text or by link) in their contribution guides.
Posted Mar 7, 2023 14:17 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (21 responses)
Consult your own lawyer if you need this advice for a lawsuit; from my non-lawyerly perspective, it does a couple of things:
It's not watertight by any stretch - but it means that when you're faced with a SCO saying "this is our code", and an IBM saying "no it isn't", the IBM side has a little more evidence to show to the judge than the SCO side, complete with a route for the SCO side to take to disprove the IBM side's claims. Given this, a court is likely to lean to the IBM side, at least until the SCO side finds the people involved in the DCO notices and either proves that they're IBM in disguise, or that they didn't have the intentions IBM ascribes to them.
And note that in a civil suit, the court doesn't need perfect proof - they're weighing the evidence in front of them and trying to determine whose story is more likely to be true. If SCO say "that e-mail address doesn't respond", but IBM get someone in front of the court who's willing to testify that it was their e-mail address, and they did the work, SCO needs to prove that the person testifying is lying to the court. In the end, it'll all come down to who is able to convince the court that their version of events is accurate - in the US system, this means convincing the jury of the facts, and the judge of the law that applies.
Posted Mar 7, 2023 14:32 UTC (Tue)
by paulj (subscriber, #341)
[Link] (20 responses)
And apparently, by adding "Signed-off-by: <Joe Bloggs joe@acme.com>" to your commit, which you will do cause you see everyone else do and which you'll be asked to add (usually in a perfunctory manner) if you try submit without, somehow others take this as a demonstration that you have a) read the documentation b) read not just the bits you were interested in, but also did not skip over the boring looking bit about certifying yada yada and carefully read about the DCO c) agree to the DCO.
Again, my primary question here is about the mechanism that certifies the submitter knew about the DCO.
Posted Mar 7, 2023 14:36 UTC (Tue)
by paulj (subscriber, #341)
[Link] (2 responses)
Also, many many developers across the world do not speak english. They may speak C. They may have a very light smattering of English words. But they can not read DCO like language. They can however note that others who send patches stick 'Signed-off-by' lines on their commits - seems the thing you have to do, so do it.
Posted Mar 7, 2023 14:39 UTC (Tue)
by paulj (subscriber, #341)
[Link] (1 responses)
1. To the extent you can say anything about the validity of the intent - but this exact same for SoB.
Posted Mar 7, 2023 14:41 UTC (Tue)
by paulj (subscriber, #341)
[Link]
Posted Mar 7, 2023 14:43 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (16 responses)
The SoB tag is the DCO notice attached to the patch. And it's not watertight - it merely establishes a presumption that you had read the DCO and intended to comply with it (else why would you have done extra work that's only needed to comply with the DCO requirements?)
And note that this is a rebuttable presumption - if I get 成龙 into court, and they say that they just copied the SoB because it looked like standard procedure, and they did not read or understand the DCO, that rebuts the presumption. But it's one more hurdle for the next SCO to jump - the court is allowed to assume that the person attaching the SoB did so because they've read and agreed to the DCO, and in order to overcome that assumption, you need to find that person and get them to testify to the contrary.
Posted Mar 7, 2023 14:45 UTC (Tue)
by paulj (subscriber, #341)
[Link] (15 responses)
"Signed-off-by: Joe Bloggs <joe@example.com>"
Nothing about this demonstrates any knowledge of the existence of the DCO declaration.
Posted Mar 7, 2023 14:47 UTC (Tue)
by paulj (subscriber, #341)
[Link] (12 responses)
There's no understanding that this signifies assent to some declaration to be demonstrated. Not from the submitter, nor even from the maintainers who make the request. IME.
Posted Mar 7, 2023 15:09 UTC (Tue)
by paulj (subscriber, #341)
[Link] (11 responses)
Again, if it were my project, I'd have a declaration.txt and people would send a commit /once/ to add their name to that. A stronger mechanism, and the weaknesses that remain also apply to SoB anyway.
Get rid of the endless tedium of having people forget to add SoBs.
Posted Mar 7, 2023 15:14 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (10 responses)
That's a weaker mechanism, not a stronger one - because it's done once, and not per-commit, instead of being able to show just based on the code under consideration that I probably agreed to the DCO, you've now got to look me up in the history of declaration.txt, and show that it's unreasonable for me to have forgotten that I sent a commit to that file. You then have to get the appropriate parts of the history of declaration.txt into court as evidence, whereas the appropriate parts of the code under scrutiny is already in court as evidence - and thus an attempt by the plaintiff to remove the entire commit that includes the SoB line from consideration removes the code as well as the DCO notification.
Combined with the SoB tag, it becomes a stronger mechanism, because you now have evidence that my identity also read the declaration.
Posted Mar 7, 2023 15:27 UTC (Tue)
by paulj (subscriber, #341)
[Link] (9 responses)
My experience is that for any project using SoBs, that has a stream of contributions from a wide developer base to examine, that you will /readily/ find example after example of communication with submitters that demonstrate that neither submitters nor maintainers have an awareness that SoB is meant to provide some attestation of agreement to some implicit declaration.
Posted Mar 7, 2023 15:34 UTC (Tue)
by paulj (subscriber, #341)
[Link]
1. Everything - from assent to the declaration involved - is entirely implicit and unreferenced, including in social norms, and it is evident from many communication examples that many submitters are entirely unaware of the declaration.
2. There is an explicit step by the submitter that can only be made the submitter having opened the declaration document and edited it, and the commit will explicitly quote the name of the submitter *with* the document name, and even quote a snippet of the document.
And if (as the kernel guidelines say) is is /legally important/ to be able to demonstrate the submitter has made that declaration, then I will choose for the explicit mechanism. Assuming the importance of this, I'd encourage my competitors to use the implicit, former mechanism.
Posted Mar 7, 2023 16:13 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (7 responses)
The SoB shows a presumption that you knew about the DCO - but that can be rebutted.
A commit in the past to declaration.txt carries two problems with it:
The advantage of the SoB mechanism is that it's very hard for the plaintiff to argue that a commit under consideration as part of the evidence in favour of their case should be split into two - generally, the court wants that commit to either be in consideration or not. If they can't produce evidence to rebut the presumption that the developer knew about and agreed to the DCO, then they are faced with a quandary:
In contrast, if you have a separate commit to declaration.txt, and future-SCO can find a procedural reason to strike that commit from evidence, they have no quandary - they can do so without affecting their case negatively.
Part of the excitement here is that, as defendant, we want to do as little as possible, and get judgement on the facts as early in the process as we can. With separated declaration and commit, the plaintiff can argue that they can only find the commit that infringes, and not this commit that you allege shows that I agreed to the DCO terms. The plaintiff has a reasonable chance of getting the court to consider the case on the basis that the commit you claim to have, and they claim not to have, is non-existent, or at least not relevant because it's too old, or has been tainted in a copy from an old VCS or hosting platform, or otherwise is not safe in this case.
In contrast, if the plaintiff claims that their version of a commit without an SoB is the correct version, then they've opened up a new risk - if they're found to have brought false evidence before the court, that's a big deal and opens up the lawyers to penalties, not just the plaintiff. Further, getting the court to agree to only consider parts of the commit that suit the plaintiff is also challenging - why shouldn't the court consider the entire commit?
In the end, it's all theatre for the court - the underlying objective is to make the plaintiff ask the court to construe the case in a way that has the court going "So basically you want us to ignore anything that might cause us to find against you? That is not how this works". Getting the court to say that commits before a cut-off date aren't relevant isn't suspicious. Getting the court to say that part of a commit counts, but the rest doesn't, will make the judge suspicious, as will trying to convince the court that an absent developer didn't really mean their SoB the way the project documentation means it. And, of course, the plaintiff can bring the developer into the case via a subpoena, but then faces the risk that the court will find that what the developer says is not in favour of the plaintiff, either.
Posted Mar 7, 2023 16:33 UTC (Tue)
by paulj (subscriber, #341)
[Link] (6 responses)
I would not place value in this being meaningful in any legal action, where it would benefit me to show you had that understanding - especially if it does not benefit you.
But that's me.
I do find it fascinating how invested people are in ascribing this supposed understanding to some completely disconnected action. See my other comment on sops.
Posted Mar 7, 2023 16:46 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (5 responses)
And I find it fascinating how determined you are to attack a system that has well-known legal properties, and to suggest replacing it with one that's considerably weaker in the face of standard court process (e.g. ruling all commits outside a date range as inadmissible, and ruling all commits that do not touch files under consideration as inadmissible).
You are basically creating a lot of work for your legal team to get a small amount of certainty that is almost certainly not relevant (it would not have been relevant in the SCO case, for example, since it would have shown that the code under consideration was contributed by SGI, not IBM, and SGI had no incentive to help SCO).
The only time the extra certainty even matters is when SCO can be shown to have contributed the code that SCO claims is infringing SCO's rights. And even then, it only matters in as far as the court is willing to take SCO's word for the idea that SCO contributed this code in error, and didn't mean it to be merged when they sent it to you. The rest of the time, the value of the SoB line is to show that the code under consideration was deliberately contributed by a third party, and therefore that that third party ought to be a co-defendant (making the plaintiff's life harder, since they now need to bring in that third party, and get them to tell the court that they didn't mean it to be merged).
The rebuttable presumption that you read and followed the DCO when you put the SoB tag on is a commonly used legal device - it's how terms and conditions are normally applied, for example, where the fact that you did something that's otherwise unnecessary (e.g. ticked a box on a web form) is enough to demonstrate that you really did read the T&Cs, even though that's also something you might be doing just by copying others.
Courts are very wary of getting rid of this presumption, precisely because there are so many cases outside the digital world where it's used - signs in car parks or above the entrance to something, for example.
Posted Mar 7, 2023 16:54 UTC (Tue)
by paulj (subscriber, #341)
[Link] (4 responses)
Adding a signature to an agreement, on the other hand, is a mechanism with a plethora of precedence and reasoning in the literature, going back many hundreds of years.
Posted Mar 7, 2023 17:01 UTC (Tue)
by paulj (subscriber, #341)
[Link] (3 responses)
Signing of declarations is legally well understood (even if I, not being a lawyer, can not detail that understanding, I know it is).
Your claim that signing a declaration or agreement can then easily be forgotten is something I find dubious in legal terms too. To the extent that is true, it applies to "forgetting" the DCO generally. (Again, you can't show SoB shows any knowledge or memory of the DCO by the submitter - it is in /your/ head this presumption exists, not the submitter).
Posted Mar 7, 2023 17:11 UTC (Tue)
by paulj (subscriber, #341)
[Link] (2 responses)
Even click-through agreements, where a user clicked "I agree" have been ruled invalid, because the wall of legalese and other context made the click performative and not indicative of understanding by the user.
"Signed-off-by: Me" - with no context showing I had any reason to be aware of some legalese on a web page somewhere, or buried in a file in a folder full of files - doesn't indicate much.
But... you consult your legal adviser, I'll consult mine - when it matters.
Posted Mar 7, 2023 17:14 UTC (Tue)
by corbet (editor, #1)
[Link]
Thank you.
Posted Mar 7, 2023 18:40 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
It varies by type of agreement, and by what the agreement claims to show. To enforce the agreement against the party that agreed needs bigger actions than to enforce it against a third party who's claiming their rights were infringed.
And that's what the DCO is there to protect against - the next SCO will face us being able to show that (e.g.) the infringing code was contributed by SGI, and therefore SCO has to bring SGI (and others) into the case. This expansion means that the defence side has many more lawyers involved than the plaintiff, and thus that it's harder for them to show that their chosen target is liable.
Posted Mar 7, 2023 15:04 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (1 responses)
I am aware of the SoB tag. However, because the kernel's process documentation says that you attach that tag because you have agreed to the DCO, the court is permitted to presume (in the absence of other evidence) that your reason for attaching that tag is that you've read and agree to the DCO.
That presumption is a weak presumption, hence easy to rebut, since there's only a very loose link between the SoB and the DCO itself, but it's a presumption the court would normally have to follow. It would be up to a future SCO to show that the people attaching SoBs to code under consideration in court did not agree to the DCO, not up to a future IBM to show that they did.
Posted Mar 7, 2023 15:11 UTC (Tue)
by paulj (subscriber, #341)
[Link]
Again, if it were my project, I'd have a declaration.txt and people would send a commit /once/ to add their name to that. A stronger mechanism, and the weaknesses that remain also apply to SoB anyway.
Get rid of the endless tedium of having people forget to add SoBs, having to reply with "please add SoB", them having to resend, etc. It's a completely daft mechanism (so far as attesting assent to a declaration goes).
(Accidently replied that to another comment).
Posted Mar 6, 2023 19:08 UTC (Mon)
by ncm (guest, #165)
[Link]
It is as if everybody involved, from the various judges on down, wanted it to be allowed to drag on as long as it could possibly be made to, facts be damned.
The Microsoft anti-trust case was similarly weird: MS was caught red-handed submitting grossly fabricated evidence, but saw no contempt of court citation. Somebody should have, at least, spent the weekend in jail.
Posted Mar 7, 2023 16:08 UTC (Tue)
by mlauzon (guest, #164020)
[Link] (1 responses)
Posted Mar 7, 2023 16:11 UTC (Tue)
by corbet (editor, #1)
[Link]
But yes, it would be nice to hear how she looks back on the whole thing.
Posted Mar 9, 2023 9:08 UTC (Thu)
by kena (subscriber, #2735)
[Link] (1 responses)
What a pleasure it was to deal with such stalwart, intellectually honest guardians of truth and--- OH WHO AM I KIDDING?
I wept tears of joy when their website redirected to a soccer club. And Ken's repeated attempts to not just undermine, but smear Linux and "open sores" -- his words -- were so laughably inept, it hurt. Especially after his book was torn to shreds before even being released.
What horrible, horrible people.
Posted Mar 9, 2023 10:21 UTC (Thu)
by paulj (subscriber, #341)
[Link]
Posted Mar 17, 2023 19:31 UTC (Fri)
by rkhalloran (guest, #74263)
[Link] (1 responses)
The problem is with the rise of the 'Net their "paided shills" (to riff on the old Y! stock board...) were being debunked in real time, and with Groklaw posting the progress of SCOX' various court cases almost as fast, said PR was cut off at the virtual knees before it could be leveraged to any advantage. [ as always, thank you PJ, wherever you are now.. ]
Given that SCOX' successor explicitly didn't get litigation rights in their purchase deal, said for the record they had no interest in pursuing their own lawsuits at the time, and let SCOX continue with *their* suit for another decade before making objections when IBM finally decided to settle ("Your Honor , I object!" "And why is that?" "Because it's devastating to my case!" - Liar Liar, 1997), we can all simply hope Xinuos' attempt to resurrect this particular corpse of a lawsuit fails faster than its predecessor.
XINUOS DELENDA EST!!
Posted Mar 17, 2023 20:58 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Come on, it's time for a reboot or at least a remastered version!
Posted Apr 24, 2023 10:29 UTC (Mon)
by error27 (subscriber, #8346)
[Link] (1 responses)
Forbes has gone through a bunch of editorial policy changes. At times they would print any garbage from "contributors" but it hurt their reputation so these days they don't.
Posted Apr 24, 2023 10:38 UTC (Mon)
by error27 (subscriber, #8346)
[Link]
https://www.forbes.com/2007/09/19/software-linux-lawsuits...
As I was digging through old stuff for this article, I ran across this bit of fun that I had long since forgotten about. There wasn't a place for it in the article, but hopefully it can bring a smile or two still...
Darl McVader
Darl McVader
Darl McVader
>To be written in about 20 years
Darl McVader
Darl McVader
Darl McVader
The SCO lawsuit, 20 years later
The Trillian Project : Proof of SCO's actions
Posted Jun 12, 2003 15:57 UTC (Thu) by NZheretic (guest, #409)
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
I still miss Groklaw
Missing Groklaw
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
> They have similar populations and a similar enough per-capita income.
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
> The density is basically the only "advantage" that transit provides.
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
Wol
The SCO lawsuit, 20 years later
But at this point in time we can safely assume that most gas cars will simply be replaced with EVs.
The SCO lawsuit, 20 years later
just to make it clearer, it took just five minutes more (50 min) to go from rome to palermo by flight. Go figure
The SCO lawsuit, 20 years later
Wol
The SCO lawsuit, 20 years later
Wol
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
This conversation has gotten pretty far off topic, perhaps it's time to wind it down.
Off topic
Off topic
Off topic
> You need to look at "Greater Houston Area" - 7.21 million people vs 8.5 million in NYC.
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
>
>This is true in NYC as well. You won't feel a rapid change once you pass the "Leaving Brooklyn? Fuhgeddaboudit" sign. That's why comparing NYC proper with GHA makes sense. You're comparing two different modes of development, and there's a lot of good statistical data about both of them.
* You will feel a much smaller, but still significant change when moving from Queens or Brooklyn to Long Island. Long Island is primarily single-family homes with some apartments, whereas Queens and Brooklyn are the reverse. You see a similar dynamic in several of the other NYC suburbs.
* Subway access is a big deal. Moving between Brooklyn and the Bronx (for example) is much, much faster and easier than moving between the NYC suburbs and the four boroughs (that aren't Staten Island).
The SCO lawsuit, 20 years later
According to Wikipedia:
The SCO lawsuit, 20 years later
Houston New York
Pop Area Pop Area
2.3M 1739km^2 8.8M 1223km^2 city
5.8M 4299km^2 19.4M 8412km^2 urban area
7.1M 26061km^2 20.1M 8936km^2 metropolitan area
I find it hard to believe that the 26061km^2 metropolitan area of Houston is more comparable to the 1223km^2 NYC than to the 8936km^2 New York metropolitan area (of which the part outside NYC has a higher average population density than the city of Houston).
The SCO lawsuit, 20 years later
** People who live in NYC or on Long Island will be surprised to learn that the rest of the state does not uniformly consider itself to be "upstate," and will use the term "downstate" to refer to a wide variety of locations other than NYC and Long Island. In particular, when I have suggested to people living in the Capital District (i.e. near Albany) that "upstate is everything north of the Bronx," they tend to ask about Buffalo, but you could just as easily point to Poughkeepsie.
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
So you will not see the commute time spent on average go down, just because commute of X km. is faster by central transit, than by car f.ex. - and commute time is by any transport means - so how do you figure that commute is helped by 24lane express way?
Its my experience here in Denmark as well.
You can see this : https://www.nature.com/articles/s42949-021-00020-2
which shows more about the "access to jobs" via different ways of transit.
The SCO lawsuit, 20 years later
Status of the original lawsuit
Status of the original lawsuit
Status of the original lawsuit
Status of the original lawsuit
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
Wol
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
Wol
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
Wol
The SCO lawsuit, 20 years later
Wol
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
Wol
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
Wol
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
Wol
The SCO lawsuit, 20 years later
https://warsus.github.io/lions-/
https://github.com/dspinellis/unix-history-repo
https://codeberg.org/zerocool32/v6pic32
a re-implementation, but the author used UNIX v6 source code from John Lions's book as a reference.
https://github.com/mit-pdos/xv6-riscv
[2] https://wiki.tuhs.org/doku.php?id=source:start
[3] http://www.lemis.com/grog/UNIX/
[4] https://www.tuhs.org/Archive/Caldera-license.pdf
[5] https://en.wikipedia.org/wiki/Ancient_UNIX
The SCO lawsuit, 20 years later
Wol
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
At any rate, Groklaw did a great job covering the case for those interested..
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
Tony
The SCO lawsuit, 20 years later
Fond memories of old SCO
Fond memories of old SCO
Fond memories of old SCO
>
>https://www.youtube.com/watch?v=QECNF-GxbDQ&t=40m37s
>
>(the whole play is really funny if you remember the early 90s!)
That was really wild ! And I do remember the time this was done :-)
While it was a strange beast to run for someone coming from Atari
STs (yeah) and IBM DOS/Win3.1 (booh), it got me interested in the
UNIX world, which for me ended up in switching to Linux :-)
Fond memories of old SCO
The SCO lawsuit, 20 years later
Was it done as a pump and dump scheme ? probably.
Was it done to deflect media attention from the real action? almost certainly.
But in all case, Linux was just collateral damage.
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
Wol
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
Wol
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
Wol
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
Wol
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
Wol
The SCO lawsuit, 20 years later
then you just add a line saying::
"
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
I think it is reasonable to conclude at this point that you are not going to resolve this issue in this forum. Perhaps we can wind down this discussion here?
A suggestion
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The abiding mystery
The SCO lawsuit, 20 years later
I've not had any communication with PJ for quite a few years at this point. As far as I can tell, she was never really comfortable in the public eye and has long since chosen to remove herself from it.
PJ
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later
The SCO lawsuit, 20 years later