[sf-lug] Red Hat Linux source code brouhaha?

[Rick Moen]

Quoting aaronco36 at sdf.org (aaronco36 at sdf.org):

> Thanks much for the background and info to date on this thread (
> http://linuxmafia.com/pipermail/sf-lug/2023q3/thread.html#start ) :-)

Thank _you_ for your well-researched and meticulous pointers
to matters stated by various parties to this issue.

When I commented five days ago, I carefully qualified what I said, thus:

  This is a very complicated topic, but basically I concur with Bradley
  M. Kuhn's analysis.  (Disclaimer:  I have not yet had a chance to read
  Mr. Mike McGrath's quasi-response.)

I was new to the controversy, though I'd heard rumblings, so didn't 
want to just spout off.  I've now read Mr. McGrath's quasi-response, and
wanted to hazard a few comments -- still trying to avoid spouting off,
or at least speak in a measured way.

We should be sympathetic to Mike McGrath's position of being de-facto
spokesperson for a software company, speaking without management
authority and having no say whatsoever in shaping policy, and being a
technical person who be in hot water if he/she says the wrong thing.

I've repeatedly been in the position of being such a technical employee
at a firm that does something, well, bad.  

One example was when I was at VA Linux Systems when it exited the
Linux hardware business, became a proprietary software company named VA
Software Corporation, and set out to monetise SourceForge.  It did this
by slow, stealthy steps concerning the central codebase "Alexandria",
which was GPLed code largely but not entirely of the company's
authorship.  VA Software Corp. approached the outside contributors and
tried to get them to sign over copyright title to their contributions.
One of the recipients of this letter, Loïc Dachary of FSF Europe, saw
through this machination and called public attention to the obvious
implication that _only_ an effort to take SourceForge proprietary could
possibly account for this.  See, e.g.:

https://discussion.fsfeurope.narkive.com/xVQVJjTt/the-fsf-europe-recommends-avoid-sourceforge
https://www.linuxtoday.com/infrastructure/updated-fsf-europe-sourceforge-drifting/

In answer to Dachary, VA employee Patrick McGovern, wrote a widely
distributed so-called "rebuttal".
https://slashdot.org/comments.pl?sid=23673&threshold=3&commentsort=0&mode=nested&cid=2555099

To cut to the chase:  What McGovern said was bullshit.

   SourceForge.net, OSDN and VA Linux systems are committed to the 
   Open Source community.

No, they weren't at all.

  Today VA spends a tremendous amount of money and resources to 
  provide excellent service to 30,000 projects. 

Possibly-maybe true, but irrelevant to the issue.  I mention this
because McGovern, here, as many other places in his "rebuttal", is
firing off irrelevant chaff to distract from the actual subject -- 
something that will also feature in McGrath's quasi-response to Brad
Kuhn.

When a corporate spokesbeing starts wildly gesticulating _around_
the subject, start getting suspicious.

   Loic brings up a number of points that are simply not accurate. 

McGovern then trots out statements implying that Dachary had been
inaccurate about those things, but either he hadn't (most of them)
or they were trivia (e.g, "SourceForge.net is not now, or nor has it 
ever been, exclusive to free software").  Moreover, each of these
items was a distraction from Dachary's actual point.  Again, corporate
misdirection, the standard magician's trick.

  Data Export: The ability to export data from SourceForge.net 
  has not changed.

But then, four sentences down that same paragraph, McGovern admits 
that the XML API for export broke and VA didn't fix it.

And so on.  A while later, VA suddenly disabled CVS access to the
Alexanadria project, and took it proprietary.  So, the firm was
"committed to the Open Source community" until it wasn't.  A very few
people who fully heeded Loïc Dachary's timely warning were not taken by
surprise by these further steps, but most people were.

The immediate result was a confusion of third-party SourceForge forks
based (usually) on old snapshots of the Alexandria codebase.  The 
final GPL source vanished for several years.  And, actually, I tell the
story in my collection of .signatures at
http://linuxmafia.com/pub/humour/sigs-rickmoen.html :

  -- 
  Cheers,                        Open-source SourceForge retakes the lead:
  Rick Moen                      http://gforge.org/  Thank you, Tim Perdue.
  rick at linuxmafia.com  

  (Archivist's Note:  For context, Perdue had been the original architect
  of the SourceForge codebase, which was then taken proprietary by his
  employer in 2002.  After he was laid off, he cleaned up the
  pre-proprietary codebase and released it, as a clearly superior 
  alternative, renamed to "GForge" for trademark reasons.  This .signature
  of mine aimed to give Perdue's project a small mindshare boost.  Since 
  that happened, the active open source version departed from the GForge
  effort and is now FusionForge.  N.B.:  Timothy Dean Perdue succumbed to 
  colon cancer on September 16, 2011, aged 37.)

Specifically, as an employee, Perdue carefully tucked away the very last
GPLed tip code in a tarball, had it at home after he left employment, 
waited until any NDA or such expired, and _then_ published it.

As a fellow VA employee, I was disgusted by the company's bad-faith
actions and by McGovern's forked-tongue "rebuttal", but as an employee
felt I could not ethically say anything in public.  Or rather, anything
Corporate would _want_ me to say, *I* would not want to say.

The best I was able to do, avoiding conflict of interest, but acting
in behalf of the community, was to start keeping a catalogue of
third-party SourceForge forks in my knowledgebase, _and_ start using
that .signature thanking Tim Perdue, at the bottom of some of  my
personal (but certainly not corporate) mails.


Another example of my having been "in the position of being such a
technical employee at a firm that does something, well, bad" was when I
was working, still, at VA Linux Systems when an awkward request arrived
for matching source code access to a binary RPM we had published of the
(upstream-originated) "ndmp" utility (under GPLv2), with VA-added
improvements.  VA had included that utility's package in a distro
specialised for storage clusters.  I checked with Software Engineering,
and they said "No, we can't provide that source code.  It includes code
from two of our business partners that we have under NDA."  This
inclusion was impliedly an unintended screwup.

I did the wise thing of checking with corporate counsel.  He called me
in, and I'd already guessed the answer, but he was glad to go over it
with me.  It was like this:

Either providing or not providing the matching source code commits a
tort.  The issue is, then, which is the less damaging of the two torts.
Providing the source code means we're in breach of contract to two
business partners, potentially causing considerable damage and costs.
Not providing it means we're commiting copyright infringement.  If our
method of doing that is to say "Sorry, this modified ndmp was issued in
error, and we have permanently withdrawn it and apologise for the
inconvenience", then the requestor has no tort cause of action because
he wasn't the copyright owner.  The copyright owner is a guy in New
England who isn't angry at us.  If, hypothetically he becomes angry, he
could sue us for statutory damages, which are tiny because we ceased
distribution immediately, and he cannot sue to compell us to stop
distributing, because we already did.   And he can sue at all _only_ 
after registering the copyright at Library of Congress's Copyright
Office, which most open source authors cannot bother to do.

So, we did that.  And I explained to the requestor exactly as corporate
counsel said, and that was the end of it.


I'll get to Mr. McGrath in a minute.  But first Jesse Smith:

> Seems that just this very weekend, DistroWatch made a stab at addressing
> the ongoing issue at its 'Questions and Answers (by Jesse Smith)
> Red Hat changing its approach to sharing source code' ;
> https://distrowatch.com/weekly.php?issue=20230703#qa

Notably:  

  The GPL does not require organizations to provide public access to
  their source code, it only requires that companies offer to provide
  their source code to people to whom they distribute binary copies of
  their software.

But is this _true_?  Consult the black-letter wording of GPLv2:

  3. You may copy and distribute the Program (or a work based on it,
  under Section 2) in object code or executable form under the terms of
  Sections 1 and 2 above provided that you also do one of the following:
  [snip 3a method of furnishing source code with binaries, or:]
  b) Accompany it with a written offer, valid for at least three years,
  to give any third party, for a charge no more than your cost of
  physically performing source distribution, a complete machine-readable
  copy of the corresponding source code, to be distributed under the terms
  of Sections 1 and 2 above on a medium customarily used for software
  interchange. [...]

"any third party".

Mr. Smith is flat-out incorrect.  And all he needed to do was read the
blessed thing.  (GPLv3, version 2's less-commonly-used successor, has
similar wording.)

https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
https://www.gnu.org/licenses/gpl-3.0.html


The legal question for Red Hat, Inc., as to GPL-covered software it
redistributes whose basic copyrights are held by non-company
stakeholders, where it's using the clause 3b method of source-code
access (the usual method), hinges on a simple factual test:  _Is_ 
Red Hat offering matching source code to _any third party_, for at least
three years, corresponding to each GPLed component of RHEL, on a medium
customarily used for software interchange?  Note that the "written
offer" should accompany the "object code or executable form' of the
software.  

It's a yes or no question.

As GPLv2 and v3 both point out, you can receive a copy of a GPL-covered
codebase if, say, you have lawfully downloaded it, and can decline to
accept the licence's conditions.  But then you have only the few rights
to the codebase from common law, e.g., the implied right to keep your
downloaded copy and compile/run it, but you will not receive _reserved_
rights copyright owners can elect to issue or not, such as making
derivative works, or further distributing the work or its derivatives.
And since Red Hat, Inc. _most_ is distributing other ("upstream")
copyright holders' GPLed work, all of its work as a software company is
lawful _only_ if it accepts and honours the covering licenses.  If they
fail to comply, then then are committing the tort of copyright violation
against the stakeholders.


Let's get to Mike McGrath's non-responsive response at
https://www.redhat.com/en/blog/red-hats-commitment-open-source-response-gitcentosorg-changes .  
The location right on a redhat.com hosted blog telegraphs this being 
corporate PR flackery -- extremely similiar, in that respect, to 
McGovern's non-responsive response on Slashdot (which was then
VA-owned).

  Red Hat’s commitment to open source

Check.  Just like McGovern.  Wave in the reader's face the deliberate
distraction of lots of statements about us being the good guys.  Long
distracting sob story.

  Despite what’s currently being said about Red Hat, we make our hard
  work readily accessible to non-customers.

OK, so are you saying Red Hat will make matching source of RHEL's
GPLed packages available to _any third party_, for at least three years,
on a medium customarily used for software interchange, and include a
written offer stating details?

Anyone?  Anyone?  Bueller?

  Red Hat uses and will always use an open source development model.
  When we find a bug or write a feature, we contribute our code
  upstream.

That's nice.  But what about matching source code, to any third party?

  We don’t simply take upstream packages and rebuild them. At Red Hat,
  thousands of people spend their time writing code to enable new
  features, fixing bugs, integrating different packages and then
  supporting that work for a long time - something that our customers and
  partners need. 

  This is about the hours and late nights we spend backporting a patch to
  code that is now 5 to 10 years old or older; at any given time, we are
  supporting 3-4 major release streams, while applying patches and
  backports to all. Additionally, when we develop fixes for issues in
  RHEL, we don't just apply them to RHEL - they are applied upstream
  first, to projects like Fedora, CentOS Stream or the kernel project
  itself, and we then backport them. Maintaining and supporting an
  operating system for 10 years is a Herculean task - there‘s enormous
  value in the work we do.

Yes, yes, you're very good and meritorious people, and probably kind to
children and animals.  But are you making matching source of RHEL's
GPLed packages available to _any third party_, for at least three years,
on a medium customarily used for software interchange, and including a
written offer stating details?

  We will always send our code upstream and abide by the open source
  licenses our products use, which includes the GPL. When I say we abide
  by the various open source licenses that apply to our code, I mean it.

Great!  Tell us more.  Where is the matching source of RHEL's
GPLed packages available to _any third party_, for at least three years,
on a medium customarily used for software interchange, and written offer
stating details?

Anyone?  Anyone?  Bueller?

{crickets}

Not a word about how they are complying.  Lots of distracting wording 
talking all _around_ the point, but not a word about the actual issue.

Except, oh, here we go:

  I feel that much of the anger from our recent decision around the
  downstream sources comes from either those who do not want to pay for
  the time, effort and resources going into RHEL or those who want to
  repackage it for their own profit. This demand for RHEL code is
  disingenuous. 

Note the distortive connotation about the phrase "RHEL code", as if 
McGrath were talking about 100% Red Hat-produced codebases it publishes
under copyleft licensing out of sheer goodness -- instead of being, 
usually, Red Hat, Inc.'s slight modifications and tweaks of other
people's upstream code, which they are _obliged_ under the licensing
required by those stakeholders (GPL-using ones, at least) to make
available to any third party.

Anyway, McGrath goes on for eight paragraphs of windbaggery calling all 
third-party requestors and re-publishers of RHEL's GPL-covered codebases
ungrateful parasites.

  Ultimately, we do not find value in a RHEL rebuild and we are not
  under any obligation to make things easier for rebuilders; this is our
  call to make.

Actually, no, it's not.  You either comply with upstream's licensing
requirements, or you don't.  

And failing to provide matching source of RHEL's GPLed packages
available to _any third party_, for at least three years, on a medium
customarily used for software interchange, and written offer stating
details, is failure to comply.  Thus, copyright violation against 
upstream, and, ironically, being an ungrateful parasite.

  Simply rebuilding code, without adding value or changing it in any
  way, represents a real threat to open source companies everywhere.

No, Chuckles, that's _being_ open source.


As I said, in a situation where I could have abased myself by distorting
and deflecting the way Pat McGovern did, and now Mike McGrath has done,
personally, I chose to remain silent and carefully avoid conflict of
interest.

Did I choose wisely?  Not sure, but I can live with my conscience, this
way, and am not just visibly a squirrely corporate tool making excuses
for scummy corporate behaviour.


I notice that McGrath's "blog" does not provide for public comments.
Gosh, what a surprise!