DeVault: GitHub Copilot and open source laundering [LWN.net]

DeVault: GitHub Copilot and open source laundering

Posted Jun 23, 2022 16:26 UTC (Thu) by mpldr (guest, #154861)
Parent article: DeVault: GitHub Copilot and open source laundering

I would personally love for an independent legal team to take a look at this issue… I doubt that either the FSF's or GitHub's legal teams can be trusted to be impartial on these topics.

to post comments

DeVault: GitHub Copilot and open source laundering

Posted Jun 23, 2022 18:31 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (10 responses)

Emphasis on "legal" team, not engineering team. A lot of engineers have very strange ideas about how the GPL works. For example, some engineers (presumably not including DeVault) think that just reading GPL'd code causes it to magically "infect" any code you write after that point, which is not even close to being true.* The GPL attaches to derivative works. "Derivative work" is a legal term of art, and the license does not attempt to offer a definition for it, because it's defined by the underlying copyright law. That's why you need a team of lawyers, not a team of engineers, to evaluate something like this. In particular, I think DeVault's emphasis on the model itself being a derivative work may be an unnecessary distraction, because:

1. It's not clear to me whether this claim is actually correct. A model is ultimately "just" a big bag of statistical information, and I honestly don't know whether (US) copyright law attaches to such things in the first place, but I'm skeptical (see e.g. Feist v. Rural).
2. It's not relevant. What matters is whether the output of the model is a derivative work of the original, which is a completely different legal question. Derivative works are not subject to some sort of magical "transitive property" that requires the model to also be a derivative work; you can argue that the output is derivative while taking no position on the status of the model itself. Similarly, you could argue that the output is *not* derivative, again taking no position on the model. The status of the model is not relevant to the question, unless you're going to allege an AGPL** violation.

* The kernel of truth here is that, in practice, clean-room engineering is often a good idea for the avoidance of legal risk. But there's nothing in either the GPL or the copyright statute that says you have to do it. Because that would be stupid. Imagine if novelists couldn't read books without running into copyright issues.
** The AGPL is the only widely-used license whose obligations attach on creation of a derivative work, rather than on distribution of that work. As far as I know, GitHub has no intention of distributing the model itself to anyone, so if you want to sue GitHub just for creating the model, you'd have to claim an AGPL violation specifically.

DeVault: GitHub Copilot and open source laundering

Posted Jun 23, 2022 19:26 UTC (Thu) by ballombe (subscriber, #9523) [Link] (1 responses)

The legal issue will probably depend on the specific data you can extract from copilot, and obviously github will not help you to find out, and lawyers might not be sufficient.

Maybe there is some specific request that led copilot to return whole body of some GPL files. For example, by looking for certain patterns that occurs in a single software etc.
That would strengthen the case.

DeVault: GitHub Copilot and open source laundering

Posted Jun 23, 2022 19:52 UTC (Thu) by Gaelan (guest, #145108) [Link]

Someone got Copilot to generate the fast inverse square root function from Quake III (which is GPL'd), "what the fuck?" comment and all: https://twitter.com/mitsuhiko/status/1410886329924194309

Amusingly, it also autocompleted a BSD license onto that code.

DeVault: GitHub Copilot and open source laundering

Posted Jun 25, 2022 1:00 UTC (Sat) by gerdesj (subscriber, #5446) [Link] (2 responses)

"A lot of engineers have very strange ideas about how the GPL works."

Quite. Also, many putative authorities on the GPL seem to forget that there are many legal systems. If you are going to dive in and be authoritative on he GPL then you really should present an argument that works for all legal systems that the GPL attempts to work within. Quite a job!

Legal is as legal does: Some legal systems have a concept of "reasonable" or what a "reasonable" person would do and I think that is what the GPL is riffing off. There's also the concept of being able to "quietly enjoy [something]". I'm a Brit. so my local legal system informs my knowledge here. Not all legal systems work like that.

I think it is fair to say that we all have strange ideas about how the GPL works. There's no need to call out end users.

DeVault: GitHub Copilot and open source laundering

Posted Jun 25, 2022 11:47 UTC (Sat) by Wol (subscriber, #4433) [Link]

> Quite. Also, many putative authorities on the GPL seem to forget that there are many legal systems.

And far too many authorities read what they want to see, not what's actually there. I've sure been guilty of that. I think my knowledge of the GPL now is pretty good, precisely because I've had plenty of people call me out on my mistakes.

How many "experts" have NOT been through that learning experience? The majority of them?

Cheers,
Wol

DeVault: GitHub Copilot and open source laundering

Posted Jun 26, 2022 3:22 UTC (Sun) by gdt (subscriber, #6284) [Link]

The deeper point about differing copyright laws is not so much interpretation of copyright licenses, but the distinction between "fair use" and "fair dealing".

Copilot claims its actions are fair use, and therefore the license is irrelevant. However in fair dealing jurisdictions Copilot's use of the program source must either meet the copyright license or one of the black-letter list of allowed uses in the fair dealing exceptions of that juridiction's copyright law.

DeVault: GitHub Copilot and open source laundering

Posted Jun 26, 2022 9:40 UTC (Sun) by gspr (subscriber, #91542) [Link] (4 responses)

> It's not clear to me whether this claim is actually correct. A model is ultimately "just" a big bag of statistical information, and I honestly don't know whether (US) copyright law attaches to such things in the first place, but I'm skeptical (see e.g. Feist v. Rural).

Surely it does apply in one extreme, namely that of a really good model! If I take a copyrighted picture and create a model that very accurately reproduces said picture, I don't think it's very unlikely that my model runs afoul of the original's copyright.

In the other extreme—that of a really terrible model—it probably doesn't, but we probably shouldn't write off the models in-between those extremes.

DeVault: GitHub Copilot and open source laundering

Posted Jun 27, 2022 16:51 UTC (Mon) by Wol (subscriber, #4433) [Link] (3 responses)

Are you talking about a real-world model - like you made an aircraft model from a photo of an aircraft? In that case it's a physical object and patent rules should apply, or design rules, and NOT copyright rules.

If, however, you're referring to a model like most people here are - computer science, otherwise known as maths - then equally copyright should NOT apply, because it's maths. Or "sweat of the brow". Or a whole other bunch of doctrines that lawyers do their best to mis-understand but that state quite clearly it is not copyrightable material.

Cheers,
Wol

DeVault: GitHub Copilot and open source laundering

Posted Jun 28, 2022 1:26 UTC (Tue) by hummassa (guest, #307) [Link] (1 responses)

I will offer an informed alternative to your pov, Wol:

If a mathematical model produces as its output a perfect reproduction of an copyrightable and copyrighted work (something novel produced by the human mind), then said mathematical model is nothing but a copying apparatus. There is no difference between the neural model of Copilot and a big HD containing all the works it's seen, just well indexed. The output is just a copy of the copyrighted work, subject to the same protections under the laws and treaties.

DeVault: GitHub Copilot and open source laundering

Posted Jun 28, 2022 8:00 UTC (Tue) by Wol (subscriber, #4433) [Link]

(And to gspr)

Oh the joys of the ambiguity of English ...

As I read it "copyright attaches to the model" - in other words there is no copyright *in* the model. But if there is copyright in the *original*, then that applies *to* the model as well ...

I think we're talking at cross purposes ... :-)

Cheers,
Wol

DeVault: GitHub Copilot and open source laundering

Posted Jun 28, 2022 6:37 UTC (Tue) by gspr (subscriber, #91542) [Link]

By this logic, unlicensed redistribution of copyrighted images, video and audio are fine as long as the material is recompressed. It's just math!

Clearly absurd.

DeVault: GitHub Copilot and open source laundering

Posted Jun 23, 2022 20:28 UTC (Thu) by mrugiero (guest, #153040) [Link] (2 responses)

And in the case of the FSF their role is to actively try to be partial in favor of free software. On intent, not by accident. If they can get a win for FLOSS then they accomplished their stated mission.
Impartiality is for the judge, not for the litigants.

DeVault: GitHub Copilot and open source laundering

Posted Jun 23, 2022 20:58 UTC (Thu) by mpldr (guest, #154861) [Link] (1 responses)

> [the FSF's] role is to actively try to be partial in favor of free software

There's nothing wrong with that – quite the opposite – but it's not helpful if what you want is a legal review. You may get some interesting points from them, sure; but it's not exactly helpful when trying to find out what is actually law (let alone that this is a court's job)

DeVault: GitHub Copilot and open source laundering

Posted Jun 24, 2022 2:33 UTC (Fri) by scientes (guest, #83068) [Link]

In the common law system the courts' job is to write law.

/Almost not sarcastic

DeVault: GitHub Copilot and open source laundering

Posted Jun 24, 2022 11:27 UTC (Fri) by flussence (guest, #85566) [Link] (9 responses)

The FSF isn't going to do anything useful at all — the purpose of a system is what it does.

The GPL2 didn't make nVidia *or* AMD play nice with Linux (key phrase: "preferred form for modification"), the GPL3 didn't stop TiVoization (they trivially routed around it; especially Apple), the AGPL3 didn't stop SaaS vendor lock-in (instead they weaponised it against each other), and no current or future iteration of it will stop Microsoft committing automated for-profit piracy at global scale like is happening here.

The only thing the GPL *is*, clearly, is weak DRM powered by magical thinking and a bunch of weird elitist old men clinging to a power fantasy dreamed up half a century ago, from which they refuse to grow up from. People who try to actually play by the stated rules get a worse experience, corporations engage in automated piracy with neural networks with little to no legal repercussions, or often just old-fashioned copyright infringement if they're peddling white-label ARM devices, and any attempts to resist this toothless status quo from within the system get you ostracised. Most users of GPLed software have never and will never know it exists, never mind read or understand it, and if they did wouldn't be able to meaningfully exercise rights granted under it. But it sure makes some people feel smug about themselves on their moral high horse.

I feel like at this point the only way to stop this cancer of trillionaires strip-mining the creative output of individuals is to stop giving away any legal rights to that work in the first place. Make the code utterly radioactive to anyone who takes license texts seriously, especially corporate lawyers: All Rights Reserved, free for personal use only, the software shall be used for good not evil, and with a written threat to DMCA anyone found uploading to github or any other platform of similar size and motive. Piracy is going to happen anyway, but we can still choose who feels safe and comfortable doing it.

Thought experiment: if you train a neural network on the text of the GPL itself and coax output from the machine that superficially resembles the input but with manually chosen tweaks that change its meaning, are you exempt from the copyright header in the original, as MSFT seems to think it is? If so, that's the final nail in the coffin for software copyright as a whole; the words of the legal document and the colour of the bits don't mean anything any more.

DeVault: GitHub Copilot and open source laundering

Posted Jun 26, 2022 0:07 UTC (Sun) by salimma (subscriber, #34460) [Link] (8 responses)

> The GPL2 didn't make nVidia *or* AMD play nice with Linux

Any specific example for AMD here? They seem to be much better citizens when it comes to the GPL, at least compared to nVidia (and even nVidia is finally open sourcing kernel drivers)

DeVault: GitHub Copilot and open source laundering

Posted Jun 26, 2022 0:23 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

ATI had closed the driver for R300 video cards, even though the driver for R200 was open. The opened up only after being acquired by AMD.

DeVault: GitHub Copilot and open source laundering

Posted Jun 26, 2022 10:00 UTC (Sun) by flussence (guest, #85566) [Link] (6 responses)

I'm still a bit distrustful of them after what they did to undermine the xf86-video-radeonhd project.

Rumour has it that AMD middle management wanted the FOSS option they were due to announce to be kept slightly inferior to fglrx for Reasons, and having an independent effort that didn't depend on firmware blobs or the decrepit x86-only int10 VBIOS like that did was severely embarrassing them.

Not many people may remember this now, but the R200/(reverse-engineered)R300 driver also used to be blob-free. Strangely that stopped being the case after AMD took over, even though it was feature-complete.

DeVault: GitHub Copilot and open source laundering

Posted Jun 26, 2022 18:49 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> Not many people may remember this now, but the R200/(reverse-engineered)R300 driver also used to be blob-free. Strangely that stopped being the case after AMD took over, even though it was feature-complete.

Because it made no sense to reimplement the critical power management and link training code multiple times, instead of doing it once in AtomBIOS.

DeVault: GitHub Copilot and open source laundering

Posted Jun 26, 2022 19:40 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (3 responses)

> the R200/(reverse-engineered)R300 driver also used to be blob-free

The DRM side of the R2/3/400 driver always required a firmware blob - but for a long time it was just embedded inside the kernel driver, so wasn't user visible. My recollection (which seems to be supported by the driver, but it's been a long time since I looked at this properly so I could be wrong) is that a bunch of the 2D acceleration in that driver depended on DRM, so effectively the 2D driver also had a blob dependency if you wanted it to work properly.

The difference between -radeonhd and -ati as far as reliance on firmware goes was that the defined interface to various pieces of card functionality was to execute interpreted scripts present in the card flash. These scripts didn't do anything that the driver couldn't, so you could absolutely reimplement that functionality in the driver - the problem is that card vendors used these scripts as a way to abstract hardware differences (eg, using RAM from different vendors with different timing constraints), and ignoring Atom would mean having to have card-specific data in the driver before that card would work correctly. A hybrid approach is to use Atom for data but not for code, but even then there are still risks due to the fact that the defined interface is the scripts and not the data tables. A card vendor could modify the way the script interpreted the tables (or even hardcode stuff directly into the script) and again you'd need card-specific knowledge to avoid that. -radeonhd spent a while trying to avoid executing any Atom code, but effectively relied on it anyway - it couldn't program the card from cold and so depended on the system firmware having executed the scripts before it ran. In any case, support for executing Atom code (including running the ASIC init function) was added to -radeonhd by September of 2007.

Looking at the initial commits to support r500 in the -ati driver, I think the only time it would ever call int10 is if the card was entirely uninitialised. -radeonhd would do exactly the same if it was configured without support for doing Atom-based init.

DeVault: GitHub Copilot and open source laundering

Posted Jun 29, 2022 10:12 UTC (Wed) by flussence (guest, #85566) [Link] (2 responses)

That first paragraph's a letdown, but...

I learned something today. Thanks for explaining all that to my dumb ass.

This is the kind of thing that makes me keep my subscription to the site going.

DeVault: GitHub Copilot and open source laundering

Posted Jun 29, 2022 10:31 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (1 responses)

The easiest way to think about Atom is like ACPI - it's a lump of bytecode that's interpreted in kernel context, and which talks to hardware the kernel could already talk to. We could rip out the ACPI interpreter in the kernel and hardcode knowledge of every singly ACPI board instead, and we'd have successfully replaced non-free code with free code. But we'd also have a kernel that didn't boot on a bunch of new systems until people had reverse engineered the relevant ACPI code and reimplemented it, and so nobody has seriously suggested doing that.

There's tradeoffs. I'd love to avoid having to rely on non-free code to make hardware work, and I'm not going to criticise people for writing drivers that do that. But the reality is that any such driver is going to work less well than a driver that uses the defined interface to call non-free firmware (in much the same way that we call into non-free UEFI code to set boot variables these days), and so there's value in the driver that calls non-free code existing, and also it's unsurprising that distros would pick the one that works with more hardware.

Luc's priorities on -radeonhd were probably based on his experience with the VIA chipsets that were extremely limited by what the BIOS permitted (and yeah it turns out that not being able to set any modes other than those that are hardcoded in the BIOS is not good!), but the outcome was also that his driver for those chipsets simply didn't work on all hardware - I had a VIA-based laptop that would just give a black screen with his driver, because the BIOS didn't match his expectations. To be completely fair, on Radeon I hit some similar constraints when I was researching reclocking the RAM for power management - the Atom scripts simply took too long, so I took out a bunch of the wait statements and hardcoded those into the kernel and it was great, and then after a couple of days of uptime the card would wedge during a reclock and also it didn't work on all hardware, so it turns out there was a reason that those were there in the first place. So I absolutely understand the desire to have native code for all of this, but also in the absence of vendors providing explicit contracts about hardware behaviour, a driver that doesn't use the defined interfaces is inherently going to break things.

DeVault: GitHub Copilot and open source laundering

Posted Jun 29, 2022 11:31 UTC (Wed) by farnz (subscriber, #17727) [Link]

It's also worth noting in this context that part of the reason to have vendor scripts of some form (be they AtomBIOS, ACPI or others) is that power delivery changes can't happen instantly - and different board manufacturers will have done different transient analysis to determine what their hardware can reliably support. The results of that analysis (whether it's a "rule of thumb" assessment or a proper calculation) need communicating to the driver somehow - and a small scripting language is as good as any other way to deal with it, especially since the edge cases get complex if you're doing a per-board calculation based on measuring the final system during post-manufacture testing of a board.

That said, given the quality of some vendor code, I understand Luc's reluctance to trust it - I've encountered one vendor who asserted that the CPU would detect an OUT 0xCF8, EAX instruction in userspace and then ensure that nothing else accessed PCI configuration space until the same userspace process executed either OUT 0xCFC, EAX or IN EAX, 0xCFC later, on the basis that if the CPU didn't do that, it would be possible for their userspace driver to crash. I'm not even sure how this could work under Linux…

DeVault: GitHub Copilot and open source laundering

Posted Jun 26, 2022 20:16 UTC (Sun) by sjj (guest, #2020) [Link]

Isn't 20 years enough to carry a grudge? Those middle managers have moved on a long time ago already.