[TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)

["G. Branden Robinson" <g.branden.robinson@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 10630 bytes --]

Thanks for the reply, Ted.  It was helpful in part.

At 2024-11-09T15:30:01-0500, Theodore Ts'o wrote:
> On Sat, Nov 09, 2024 at 12:29:55PM -0600, G. Branden Robinson wrote:
> > 
> > Whether the GPL truly applies to the Linux kernel at all is an
> > interesting question.  It appears to me that it does--unless and
> > until you pay membership dues to the Linux Foundation.[2]  You can
> > then treat it as being under the 2-clause BSD license, MIT/X11
> > license, or similar.  If anyone knows of a counterexample (that is,
> > of a case of an LF member out of compliance with the GPL _in the
> > Linux kernel_ being compelled to come into compliance), I'm all
> > ears.
> 
> The Linux Foundation does not exclusively own the copyright on the
> Linux kernel.  The copyright is jointly owned by all of the
> contributors of the Linux kernel.  This makes it quite unlike the FSF
> projects, where contributions to FSF project require a copyright
> assignment[1].

That's a myth.  It is the FSF's stated _preference_, but it is a
negotiable point.  For example, Thomas Dickey negotiated reversion of
copyright to himself when becoming ncurses maintainer 26 years ago.[A]

More recently, in 2021 GCC stopped requiring copyright assignment.[B]
Shortly thereafter, the GNU C Library considered making the same
decision,[C] but I don't know that turned out.

One could argue that ncurses was a special case because it was regarded
as critical infrastructure[J] and its maintainership had been in crisis,
and that GCC and glibc were also special because of the heavy
involvement of deep-pocketed corporate interests in their development.

But is it true for less prestigious projects or individual contributors
with no clout to speak of?

Well, in September I became the maintainer of groff, which is an
official GNU Project.[D]  I quote the onboarding email that was sent to
me when the maintainership change was approved:

>>> For a program to be GNU software does not require transferring
>>> copyright to the FSF; that is a separate question.  If you transfer
>>> the copyright to the FSF, the FSF will enforce the GPL for the
>>> program if someone violates it; if you keep the copyright,
>>> enforcement will be up to you.

Like the "virality" of the GPL, mandatory copyright assignment to the
FSF appears to be one of those things that people like to repeat without
having their facts in order.  Some of them, I suspect, know better but
spread falsehoods anyway, because it is virtuous to oppose RMS for
transgressions real and imagined.  (I've had my own fight with him, and
haven't changed my mind about it.)

> The FSF requires the copyright assignment primarily to make it easy to
> due entities which the FSF perceives to have violated the GPL.

Personally, I think the Linksys lawsuit produced a good outcome.  I
appear not to be alone.[K]

> The Linux community tends to not prioritize using lawsuits to enforce
> the GPL.  Our preference is to use public shaming and pursuading
> companies that by holding their changes back, they are actually
> hurting themselves.

As you say, that's a preference--like the FSF's _preference_ for
copyright assignment.  Please cite some instances of public shaming
leading to public repentance and correction among GPL-violating
distributors of the Linux kernel.

> This is because the Linux kernel is constantly improving,

Unlike all other software...

> and if you don't contribute the changes back, in order to to take
> advantage of the new features in the latest upstream kernel, you would
> have to constantly forward port your patches to tha latest kernel is
> P-A-I-N-F-U-L.

Yes it is.  Another "solution" is to keep ancient kernels around long
after LKML has given up on them.[E]

> For example, consider the data center kernel used by Google.  Since it
> is not distributed outside of Google, there is no obligation under the
> GPL to distribute sources for any changes made to the Linux kernel.

Sure.  The Debian Desert Island and Dissident Tests[F][G] are useful.

> However, Google *wants* to contribute those changes back, because
> forward-porting 9,000 out-of-tree patches is a huge amount of
> engineering effort.  Hence, Project Icebreaker[1], which is an effort
> to reduce this technical debt by getting as many patches upstream as
> possible, with a goal to be able to update to each year's Stable
> kernel every year.  (And if you have to forward-port 9,000 commits,
> and then test and qualify all of these changes, it's simply
> impossible.)

Okay.  This could be an example of Google undertaking good citizenship
(or, more cynically, trying to offload the labor of maintaining kernel
features they value onto others).  But as you say, "since it's not
distributed outside of Google", I don't see how it proves or refutes
anything about LF membership vis à vis GPL enforcement.

> Linux Foundation membership has absolutely nothing to do with GPL
> license obligations.

With respect to the Linux kernel in particular, it seems the GPL _in
practice_ imposes no obligations.  That was my point.  Little
enforcement is visible.  As far as "public shaming" goes, I've seen it
from the FSF and the Software Freedom Conservancy, not from the LF.

Give me examples of the LF leaning on infringers and getting results!
I want them!

(To put on my Carnac hat, one could certainly claim that a ton of such
persuasion has gone on using the velvet glove approach, on a
confidential basis to avoid disturbing the delicate feelings of limited
liability corporations and their share prices.  That's a choice.  One of
the consequences of committing to non-disclosure of evidence is that you
can't blame the public for not being aware of it.)

> All Linux Foundation members and non-members, are obliged to following
> the GPL license.

With what consequence if they don't?

They are obliged to the _copyright holder_; as you point out, "the Linux
Foundation does not exclusively own the copyright on the Linux kernel."
(More's the pity, I reckon, when one of those other copyright holders is
named Patrick McHardy.[L])

If the LF prefers to leave enforcement of the GPL in the Linux kernel to
copyright holders other than themselves, I think they should explicitly
state this policy.

> And although Linux Foundation members might wish otherwise, LF
> membership also doesn't guarantee that your changes will be accepted
> upstream.  Getting changes upstream requires that they pass peer
> review and the bar that subsystem maintainers set for technical
> assistance is quite difficult.  Despite it being a high bar, many
> companies spend a lot of effort to make to get their changes upstream
> --- because it's worth it for them.
> 
> And because Google wants the changes contributed by Facebook and
> Amazon, and Facebook wants the changes from Amazon and Google, etc.,
> this becomes a virtuous circle which encourages other companies, like
> IBM, Samsung, etc., to contribute *their* changes back to the Linux
> kernel mainline.

This seems like a distraction from my point about copyright license
enforcement.  I distinguish that activity from patch integration.

> So why do companies join the Linux Foundation?  Well, there are a
> number of benefits, but one very important one is that it provides a
> way for companies to directly collaborate with funded programs to make
> improvements to Linux without worrying about anti-trust conerns.

Are these concerns anything more than notional?  Is there any precedent
for an antitrust action being undertaken predicated on the use of
technology that is available free of charge to, and customizable without
bound by, anyone in the world?  (I'm well aware of FTC cases around free
web browsers--these typically have turned on bundling with the OS and/or
the placement of site-specific branding icons or configured default
search engines.  To the extent that such examples can be applied to the
Linux kernel at all, is there evidence of any contract anywhere ever
having been signed that prohibits a party from altering the kernel?)

A fortiori, practically speaking, if your firm has an antitrust problem,
all it has to do is protract the case until the next Republican U.S.
administration, which could direct the DoJ to dismiss the case on the
grounds that antitrust actions inherently constitute interference with
the free market.[H]  In any event, the likelihood of any antitrust case
proceeding against any tech company on any basis other than merger or
acquisition seems unlikely.[I]

> For example, 15 years ago, IBM, Intel, HP, and other companies
> collaborate to improve Linux Scalability, and the companies
> collaborated about which asspects of the Linux Scalability Effort they
> would work on without having two companies ending up working on the
> same problems.  Of course, 501(c)(6) organizations are not the only
> way companies can safely collaborate; standards development
> organizations like ANSI and ISO are aanother way companeis can work
> together.  But if you think the Linux Foundation membership dues are
> expensive, trust me, having done both, participating in
> ANSI/ISO/INCITS can be *way* more expensive.  (Especially once you
> take into account the mandatory international travel required...)

This, too, seems to have little to do with GPL enforcement.

But I do sympathize with WG14 and the Austin Group; following recent
developments with C23 and POSIX 2014, it seems that ISO is bent
on giving them a hard time.  Maybe ISO/IEC, or certain players within,
are trying to shed some mass, and/or don't see C and Unix as worth
standardizing anymore.  Old and busted.  What's the new hotness?

Regards,
Branden

[A] https://invisible-island.net/ncurses/ncurses-license.html
    https://invisible-island.net/ncurses/ncurses.faq.html#relicensed
[B] https://lwn.net/Articles/857791/
[C] https://lwn.net/ml/libc-alpha/e13a4072-a53e-d9e1-d5c7-bf4179fead56@redhat.com/
[D] https://directory.fsf.org/wiki/Groff
[E] https://www.cnx-software.com/2021/04/13/allwinner-d1-linux-risc-v-sbc-processor/
[F] https://wiki.debian.org/DesertIslandTest
[G] https://wiki.debian.org/DissidentTest
[H] https://www.nationalreview.com/corner/thatcher-and-hayek/
[I] https://rollcall.com/2024/11/08/trump-administration-faces-antitrust-enforcement-dilemma/
[J] albeit not by termcap and S-Lang fans
[K] https://lwn.net/Articles/957255/
[L] https://www.zdnet.com/article/linux-beats-internal-legal-threat/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]