LWN: Comments on "The SCO lawsuit, 20 years later"

The SCO lawsuit, 20 years later

antidopinguser — Fri, 05 Jan 2024 13:45:14 +0000

here in rome the situation is unbearable, evry movement you have to do with your car lasts on average 45 minutes. Public transport is a joke and the quality of life is zero.
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

Cyberax — Tue, 25 Apr 2023 19:14:29 +0000

Dear editor: I'm sorry about the reply.

> 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.

The SCO lawsuit, 20 years later

Klavs — Tue, 25 Apr 2023 10:59:46 +0000

Well.. Its a funny thing.. people simple consider a LARGER selection of jobs - further away - if commute times are low enough..
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?

Everything I can find - says car traffic in larger cities break badly - and does not scale well.
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.

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 :)

The SCO lawsuit, 20 years later

error27 — Mon, 24 Apr 2023 10:38:02 +0000

Actually that article was a Dan Lyons article. I had forgotten about Dan Lyons. He said four years later that he regretted buying into the SCO nonsense.

https://www.forbes.com/2007/09/19/software-linux-lawsuits...

The SCO lawsuit, 20 years later

error27 — Mon, 24 Apr 2023 10:29:03 +0000

The Forbes article is anonymous. Groklaw readers probably have a guess who wrote it.

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.

Off topic

paulj — Wed, 22 Mar 2023 10:45:05 +0000

"Argumentum ad vehiculum" - the logical flaw of arguing by analogy, as analogies are never perfectly coherent - and very often, the analogies involve cars and the like.

(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).

Off topic

flussence — Mon, 20 Mar 2023 22:18:23 +0000

That's entirely my fault, and my bad.

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.

The SCO lawsuit, 20 years later

Cyberax — Fri, 17 Mar 2023 20:58:57 +0000

> XINUOS DELENDA EST!!

Come on, it's time for a reboot or at least a remastered version!

The SCO lawsuit, 20 years later

rkhalloran — Fri, 17 Mar 2023 19:31:04 +0000

I'd argue that SCOX' PR campaign was meant more to pump their moribund penny stock long enough for the principal players to cash out and run for the hills, as it was to talk the major Linux companies to buy into their nonsense and pay in to indemnify their userbase.

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!!

The SCO lawsuit, 20 years later

Jannes — Sat, 11 Mar 2023 21:03:38 +0000

Unsurprising that a fraud keeps frauding.

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.

The SCO lawsuit, 20 years later

kpfleming — Fri, 10 Mar 2023 15:05:02 +0000

At my previous job I had a colleague for a few years who was born in Lower Manhattan and had lived there his entire life. Working at 58th St and Lexington was a new commute for him, and he often said that in his world the 'numbered streets' in NYC were 'upstate' :-)

The SCO lawsuit, 20 years later

anton — Fri, 10 Mar 2023 09:05:11 +0000

According to Wikipedia:

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

PaulMcKenney — Fri, 10 Mar 2023 05:14:47 +0000

Nice one!!! ;-)

The SCO lawsuit, 20 years later

NZheretic — Fri, 10 Mar 2023 03:45:37 +0000

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

paulj — Thu, 09 Mar 2023 10:21:52 +0000

Funded by... Microsoft.

The SCO lawsuit, 20 years later

kena — Thu, 09 Mar 2023 09:08:10 +0000

Mildly surprised you didn't mention our good friends at the (apparently defunct) Alexis de Toqueville Institution (AdTI), especially Ken Brown.

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.

The SCO lawsuit, 20 years later

farnz — Tue, 07 Mar 2023 18:40:47 +0000

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.

The SCO lawsuit, 20 years later

biergaizi — Tue, 07 Mar 2023 18:11:46 +0000

> 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.

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...

The SCO lawsuit, 20 years later

biergaizi — Tue, 07 Mar 2023 17:29:08 +0000

Thanks for the pointers.

> 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...

A suggestion

corbet — Tue, 07 Mar 2023 17:14:35 +0000

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?

Thank you.

The SCO lawsuit, 20 years later

paulj — Tue, 07 Mar 2023 17:11:09 +0000

Also, I do have a feeling the legal system requires fairly explicit, affirmative actions to indicate agreements.

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.

The SCO lawsuit, 20 years later

paulj — Tue, 07 Mar 2023 17:01:09 +0000

Also, digital additional of signatures to documents is also something that is recognised in legal systems today. Indeed, there are laws explicitly making them equivalent, in a number of jurisdictions. IANAL, so no doubt there are nuances, but some technical procedure that results in your signature being explicitly added to a declaration very arguably is equivalent - so far as legal systems allow the equivalence - to the physical signing of a declaration.

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).

The SCO lawsuit, 20 years later

paulj — Tue, 07 Mar 2023 16:54:10 +0000

Where are these well-known properties of the SoB tag and the DCO? Or, more generally, the legal properties of any mechanism where someone adds some short tag/text and a signature to one message, and this indicates knowledge of and agreement to another, completely unreferenced, document?

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.

The SCO lawsuit, 20 years later

farnz — Tue, 07 Mar 2023 16:46:46 +0000

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.

The SCO lawsuit, 20 years later

paulj — Tue, 07 Mar 2023 16:33:48 +0000

I can hang whatever presumption I want of some implicit understanding you might have, of a behaviour you are likely to exhibit just by copying others doing some unrelated (at face value) thing.

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.

The SCO lawsuit, 20 years later

farnz — Tue, 07 Mar 2023 16:13:55 +0000

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:

It only shows that I knew about the DCO in the specific version that I committed to.
You have to bring that commit into evidence in order to rely on that commit for anything, and if future-SCO can get that commit removed from evidence for any reason, the case goes ahead with no consideration of the DCO at all.

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:

Agree that the entire commit should be stricken from evidence, removing part of their own case.
Attempt to convince the court that only the parts of the commit that support their case should be permitted as evidence, while the parts that don't are not.

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.

PJ

corbet — Tue, 07 Mar 2023 16:11:48 +0000

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.

But yes, it would be nice to hear how she looks back on the whole thing.

The SCO lawsuit, 20 years later

mlauzon — Tue, 07 Mar 2023 16:08:43 +0000

It's too bad you couldn't get some comments from Pamela Jones (PJ) of Groklaw fame who blogged about the SCO lawsuit for years for your article.

The SCO lawsuit, 20 years later

paulj — Tue, 07 Mar 2023 15:34:08 +0000

If I have to choose between 2 mechanisms that certify a submitter assents to some declaration where:

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.

The SCO lawsuit, 20 years later

paulj — Tue, 07 Mar 2023 15:27:45 +0000

We're going to have to agree to disagree that SoB shows any knowledge of DCO. You yourself have stated it is a weak assumption.

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.

The SCO lawsuit, 20 years later

farnz — Tue, 07 Mar 2023 15:14:28 +0000

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.

The SCO lawsuit, 20 years later

paulj — Tue, 07 Mar 2023 15:11:50 +0000

Right, it's a super weak mechanism to tie identy to DCO.

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).

The SCO lawsuit, 20 years later

paulj — Tue, 07 Mar 2023 15:09:56 +0000

Right, it's a super weak mechanism to tie identy to DCO.

Get rid of the endless tedium of having people forget to add SoBs.

The SCO lawsuit, 20 years later

farnz — Tue, 07 Mar 2023 15:04:40 +0000

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.

The SCO lawsuit, 20 years later

paulj — Tue, 07 Mar 2023 14:47:59 +0000

And again, just follow any of the many projects now using SoB, and watch what the standard procedure is if someone forgets to add a SoB tag. They'll just be told to add SoB. No more.

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.

The SCO lawsuit, 20 years later

paulj — Tue, 07 Mar 2023 14:45:59 +0000

The SoB tag does not attach the DCO. It attaches just this text:

"Signed-off-by: Joe Bloggs <joe@example.com>"

Nothing about this demonstrates any knowledge of the existence of the DCO declaration.

The SCO lawsuit, 20 years later

farnz — Tue, 07 Mar 2023 14:43:23 +0000

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.

The SCO lawsuit, 20 years later

paulj — Tue, 07 Mar 2023 14:41:37 +0000

"the validity of the ^identity" I meant.

The SCO lawsuit, 20 years later

paulj — Tue, 07 Mar 2023 14:39:48 +0000

Providing a commit to append a certification to a "Declaration.txt" file can not fix the cargo-culting or language issues, but /at least/ you can know /prove/ the identity[1] that made the commit /knew of the existence of the declaration/. You simply can not make that claim with the SoB tag mechanism.

1. To the extent you can say anything about the validity of the intent - but this exact same for SoB.

The SCO lawsuit, 20 years later

paulj — Tue, 07 Mar 2023 14:36:01 +0000

And I ask, cause I have seen - *many times* - in projects that cargo-culted SoB tags, that submitters - who evidently knew nothing about it or DCO - were told to resubmit patches with SoB tags. no other explanation.

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.