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

DeVault: GitHub Copilot and open source laundering

Posted Jun 24, 2022 12:25 UTC (Fri) by Wol (subscriber, #4433)
In reply to: DeVault: GitHub Copilot and open source laundering by mjg59
Parent article: DeVault: GitHub Copilot and open source laundering

No. But legal principles? From Groklaw?

PJ was very clear on this - Judges are very reluctant to rock the boat. If "is this a derivative work" is not clear then, given the choice of a NARROW interpretation of the licence that says "the licence denies permission, I'll side with the licence", or a BROAD interpretation that says "all licences like that are invalid", which one are they going to choose?

Especially when the defendant has "known or should have known" the plaintiff's express wish and ignored it.

Cheers,
Wol

to post comments

DeVault: GitHub Copilot and open source laundering

Posted Jun 24, 2022 17:45 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link] (3 responses)

The point is that isn't how licenses work. The idea behind a copyright license is that the licensor grants the licensee some rights they would normally be denied by copyright law in exchange for a consideration. For example, if copyright law would normally deny me the right to use your program to train my ML model, you can write a license that would grant me that right.

But in practice a license can't prevent someone from doing something they would otherwise have the right to do under copyright law. It is possible to write a license that requires the licensee giving up some rights under copyright law as part of the consideration they get for receiving some other rights. But nobody is forced to agree to the license! If they simply refuse to accept the license, they can continue doing anything they normally had the right to do under copyright law. Refusing the licensing terms would deny them whatever rights the license would grant them, but if they weren't intending to do those things it's an empty threat.

DeVault: GitHub Copilot and open source laundering

Posted Jun 24, 2022 20:25 UTC (Fri) by Wol (subscriber, #4433) [Link] (2 responses)

> But in practice a license can't prevent someone from doing something they would otherwise have the right to do under copyright law.

But if copyright LAW is not clear on the matter?

That is what everybody is ignoring - it is down to the Judge to decide what the law IS. If the licence explicitly refuses permission, does the Judge make a NARROW ruling that says the licensor's explicit wishes rule, or a BROAD ruling that all such clauses are invalid.

PJ was quite clear that given a choice between a broad or narrow ruling, the Judge would opt for the narrow ruling every time.

And I don't know which case it was, but there was a discussion about a pro-software-patent Judge some while back, who ruled "In THIS case, the software is clearly non-patentable. I can't conceive of a scenario where any software is patentable". Note he didn't even attempt to say software isn't patentable. He was pro-patents. But he stated, in a ruling, "I don't think it is possible for software to pass the patentability bar". He made a very narrow ruling, but accepted that the consequences would probably be wide.

Cheers,
Wol

DeVault: GitHub Copilot and open source laundering

Posted Jun 24, 2022 21:21 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

PJ was quite clear that given a choice between a broad or narrow ruling, the Judge would opt for the narrow ruling every time.

But that applies only if the broad and narrow ruling turn out the same way. In that case, the judge will usually rule on the narrowest possible grounds that results in the outcome they think is right for the case. If the broad and narrow grounds for the ruling have opposite results, the judge has to go based on which one seems to be a better reading of the law and situation, not just on narrow versus broad. More generally, narrow vs broad is something that's more true of low-level judges than of higher-level ones. Even if individual judges make narrow rulings, it's likely that different judges will rule differently. That will create uncertainty and force a higher court to rule on the matter, creating a broader ruling. That's the way these things usually go.

DeVault: GitHub Copilot and open source laundering

Posted Jun 25, 2022 17:05 UTC (Sat) by khim (subscriber, #9252) [Link]

> But that applies only if the broad and narrow ruling turn out the same way.

Where does that idea comes from? Narrow ruling is used precisely to ensure the possibility of broad ruling (made in a different case by a different judge later) to proclaim the opposite outcome!

> If the broad and narrow grounds for the ruling have opposite results, the judge has to go based on which one seems to be a better reading of the law and situation, not just on narrow versus broad.

Narrow is almost always better. Because, well, it's narrow. It describes the situation more precisely. The only save you can have is to proclaim that narrow reading is so narrow it's not applicable to your case at all.

That often happens with patents (judge is presented with half-dozen of patents which can be, theoretically, be treated as prior art and eliminate the patent completely, but 9 times out of 10 judge doesn't do that, but only just proclaim that yes, patent is still valid, just not applicable for your case).

> That's the way these things usually go.

I would say it's the way these things usually don't go. 99% of time decision doesn't reach high enough courts to decide anything definitively. Usually it takes dozens of cases and decades of litigation for that to happen.

DeVault: GitHub Copilot and open source laundering

Posted Jun 24, 2022 19:30 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (3 responses)

Intent will matter in a bunch of cases, but in this case the defining factor is whether or not something is a derived work. In two otherwise identical scenarios, one involving a license that says "I consider this to be a derived work" and one without that claim, from the standpoint of copyright law we'd expect both outcomes to be the same - the license doesn't determine how far copyright law reaches, so anything else would be bizarre.

DeVault: GitHub Copilot and open source laundering

Posted Jun 24, 2022 20:43 UTC (Fri) by Wol (subscriber, #4433) [Link] (2 responses)

> Intent will matter in a bunch of cases, but in this case the defining factor is whether or not something is a derived work.

And that is exactly the argument in front of the Judge. *IS* it a derived work? And if the law is unclear, and the licensor is explicit that he considers it a derived work, then the only safe option for the Judge is to rule that it IS a derived work and let the legislators sort it out.

And this is why you can NOT "defer to the law" in this argument. The question at issue is not "is this a derivative work according to the law?", but "what is the law?". THAT is the argument in front of the Judge.

The legislators can choose to let the genie out the bottle. The Judge will not be happy about letting the genie out the bottle off his own bat.

Cheers,
Wol

DeVault: GitHub Copilot and open source laundering

Posted Jun 24, 2022 21:13 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (1 responses)

The license stating that something is considered a derived work doesn't make it a derived work. The copyright holder is still going to have to turn up in court and make that argument, and whoever created the allegedly derived work is going to defend against that. If the same judge heard the same arguments in a case where the license made no claims about whether or not something was a derived work, we'd expect to see the same decision.

DeVault: GitHub Copilot and open source laundering

Posted Jul 1, 2022 8:32 UTC (Fri) by nim-nim (subscriber, #34454) [Link]

It would be very hard to argue in court that code produced by an AI trained on an existing code base is anything else than a derivation of this code base, since there is no human inventivity involved to muddy up waters.

Despite years of commercial pretense to the reverse professionals know “smart” systems are no smarter than the human who coded them.