Copilot, as far as I know, tend to be used to generate snippets and small algorithms that, by themselves, are not a full system/product/game.

There still may be some merit to your argument, but I believe the opposite side should be a bit steelman'ed beforehand.

It's not just one snippet, it's thousands of them, every day being slurped up and copied across code bases everywhere license free.

If the pirate bay can get jail time for facilitating mass copyright infringement, maybe Microsoft needs a little jail time too.

It's been said in this thread already:

Either licenses matter or they don't. Pick one.

I disagree that comparing Copilot with Pirate Bay is a good argument to make your case (maybe Dall-e is a closer comparison if resulting artwork could contain licensed artwork from the training set). You'd probably have other fronts to use and present a stronger argument.

And let me remind you that I have not argumented on behalf of any side, so I do not think this thread requires arguments against arguments I have never brought forward (it feels a bit more emotional than constructive).

so if your work is transformative, it can be exempt as fair use. But i'm not sure what degree counts as transformative - i do think that training an AI model with millions of repos worth of code is transformative.

For example, when Google reimplemented Java for Android, they didn't copy the OpenJDK code. They just wrote their own code that fulfilled what the methods did. If they'd taken the OpenJDK code and just renamed a variable or two in each method, I think Oracle would have had a very strong case.

With Copilot, if it's generating code that is a near-identical copy, that's kinda just copy-paste with extra steps. Let's say that I create a dumb copilot. This will just look at a method signature and fill out the body if it finds an exact match in its database - there's no AI/ML involved. I "train" it on the OpenJDK source - meaning I create a hash of method signature -> method body. I then start writing Java method signatures and it fills in the bodies with the body it "learned" would be good for that method signature.

I think one of the things to always think about is "if the AI were dumber, would it just be copy-pasting?" If the stable diffusion were just taking a copyrighted photo and applying an instagram filter to it, that would be copyright infringement. If I ask for "Robert Downey Jr in a suit" and it gives me back a Getty Images photo run through a filter, that doesn't seem ok to use. If it is truly generating something new and unique from its training dataset, that does seem ok (to me, IANAL).

The problem is that Github Copilot seems to be generating things that are almost identical. In some ways, it seems like they should modify Copilot to catch things that are substantially the same as their training dataset, but that might be difficult.

But I think the process used to create it makes a difference. Copyright doesn't protect against independent creation. If two people independently write the same code, that's ok. However, Copilot isn't independently creating code if it's recreating code that's in its training set.

One of the things I remember reading about that trial was that one of the Oracle lawyers was adamant that a method called "rangeCheck" had been copied and that it was proof that Google was able to get Android out into the market faster than if they hadn't copied code. The method was used inside the standard library (but not exported as part of the API) to check if the index of an array was out of bounds and throw the proper exception (so basically, if index < 0 throw one thing, if index >= length throw a different one, otherwise do nothing). The judge who heard the original case (and the second one at that level after the appeals court sent it back down to judge whether it was fair-use) had programmed in other languages in the past and decided to learn Java before the trial, so he was able to tell that this was such a trivial bit of code that it wasn't at all surprising that the code was the same and that even if it were copied, it would not expedite Android's appearance in the market in any noticeable way, leading to this amazing quote:

"I have done, and still do, a significant amount of programming in other languages. I've written blocks of code like rangeCheck a hundred times before. I could do it, you could do it. The idea that someone would copy that when they could do it themselves just as fast, it was an accident. There's no way you could say that was speeding them along to the marketplace. You're one of the best lawyers in America --how could you even make that kind of argument?"

Obviously most judges won't have this level of technical experience (I remember reading about a different case where a judge upheld an objection to the prosecution zooming into a photo on an iPad due to worrying that it might manipulate the image inaccurately, but then didn't have a problem with them wheeling in a giant TV instead of displaying the imaged scaled up on that), but I think the law has a capacity for nuance about these sort of technical issues that might surprise some programmers, especially with regards to the fact that intent and context can sometimes matter as much or even more than the end of result of something.

In the end the conclusion from the SC was that Google's use was fair use regardless of the question of copyrightability, which they didn't decide on (the previous court, at Oracle's appeal, had found that APIs are in fact copyrightable and that Google's use did not fall under fair use of that copyrighted API as they weren't 100% compatible with other JVMs).

One thing in life is never to get into a position where you need to defend yourself against this scenario which is why I would never even consider using the tool.

The outcome is that introducing the tool actually tangibly increases business risk in a changing climate.

https://en.wikipedia.org/wiki/Structure,_sequence_and_organi...