Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is GitHub Copilot a blessing, or a curse?

fast.ai

Post reply on HN
Print view View original

161–170 of 201 posts

Re: Is GitHub Copilot a blessing, or a curse?

#161

Post by xdennis »

qiqitori wrote: post #96
zaptheimpaler wrote: post #33

Copilot was made from stealing code on Github, ignoring the licenses set on repos such as e.g GPLv2, using AI as a trick to license-launder code. Copilot has announced their plans to become a paid service. So this product that would not be possible without public, open-source code will itself be non-public, closed-source, closed-data. It is extracting value from the commons and funneling it to a private company.

The following is just my opinion, and I'm not that hard-set in case anyone has any nice arguments. Generally, when you (for example) use GANs to learn from (copyrighted) images and generate new images, I see no reason why those new images should inherit any copyrights from the original image if the resulting images look sufficiently different. (Obviously, if you just train on 1000 images of Mickey Mouse, you'll get m…

> Humans work the same way

This is the fundamental issue. They don't.

You can't sneak a camera into a cinema saying "don't worry, it works just like human eyes".

Neural nets aren't neurons.

Re: Is GitHub Copilot a blessing, or a curse?

#162

Post by bluesign »

qiqitori wrote: post #96
zaptheimpaler wrote: post #33

Copilot was made from stealing code on Github, ignoring the licenses set on repos such as e.g GPLv2, using AI as a trick to license-launder code. Copilot has announced their plans to become a paid service. So this product that would not be possible without public, open-source code will itself be non-public, closed-source, closed-data. It is extracting value from the commons and funneling it to a private company.

The following is just my opinion, and I'm not that hard-set in case anyone has any nice arguments. Generally, when you (for example) use GANs to learn from (copyrighted) images and generate new images, I see no reason why those new images should inherit any copyrights from the original image if the resulting images look sufficiently different. (Obviously, if you just train on 1000 images of Mickey Mouse, you'll get m…

What about I train millions of tagged images, then when I write ‘mickey mouse’ it spits something very similar to ‘mickey mouse’?

This is the what copilot does as far as I understand

Re: Is GitHub Copilot a blessing, or a curse?

#163

Post by xdennis »

onion2k wrote: post #99
tvirosi wrote: post #95

Earlier quoted context omitted.

There's a difference between building a product using open source and not contributing back, and copying licensed code into your own codebase. One is rude and the other is straight up illegal.

The code doesn't exist in Copilot. The instructions for how to recreate the code does. On a very pedantic level those are not the same, but it probably is enough to argue that the product is 100% legal. It is still quite rude to do that though.

I don't think people should look at this based on current law, but what is right.

Copyright was established (much) after the printing press made copying so easy.

We now need protection against machine learning (learnright?) because the only way to not work for Microsoft for free now is to not release your source code... so not open source. Remember when people said that Microsoft changed its mind on open source?

Re: Is GitHub Copilot a blessing, or a curse?

#164

Post by xdennis »

FeepingCreature wrote: post #72
zaptheimpaler wrote: post #33

Copilot was made from stealing code on Github, ignoring the licenses set on repos such as e.g GPLv2, using AI as a trick to license-launder code. Copilot has announced their plans to become a paid service. So this product that would not be possible without public, open-source code will itself be non-public, closed-source, closed-data. It is extracting value from the commons and funneling it to a private company.

Copilot generally (excepting rare cases where it produces snippets verbatim) does not steal code. The GPL restricts distribution, not usage. And (to my knowledge) no open-source license restricts learning from code. I cannot see anyone who doesn't want others to learn from their code ever release code as open-source.

> Copilot generally (excepting rare cases where it produces snippets verbatim) does not steal code.

Rare exceptions are not acceptable in other situations.

If you, on rare exceptions, include copyrighted songs in your YouTube videos you still get strikes.

Citibank couldn't recover 900 million dollars it transferred too soon just because it was a rare mistake.

Microsoft shouldn't get a pass.

Re: Is GitHub Copilot a blessing, or a curse?

#165

Post by enumjorge »

qiqitori wrote: post #96
zaptheimpaler wrote: post #33

Copilot was made from stealing code on Github, ignoring the licenses set on repos such as e.g GPLv2, using AI as a trick to license-launder code. Copilot has announced their plans to become a paid service. So this product that would not be possible without public, open-source code will itself be non-public, closed-source, closed-data. It is extracting value from the commons and funneling it to a private company.

The following is just my opinion, and I'm not that hard-set in case anyone has any nice arguments. Generally, when you (for example) use GANs to learn from (copyrighted) images and generate new images, I see no reason why those new images should inherit any copyrights from the original image if the resulting images look sufficiently different. (Obviously, if you just train on 1000 images of Mickey Mouse, you'll get m…

> I don't think training on copyrighted code violates copyright

It might not be illegal, but for a lot of us it feels unethical. IMO licenses should list what they allow versus what they forbid. In other words, if something isn’t explicitly allowed it should be assumed to be forbidden.

We need similar protections for personal data too. Tech companies have gotten too used to ingesting data and profiting from it without asking for consent. I’m willing to bet that had GitHub asked repo owners whether GH could use their work to train a new product, most would have said no, much like what happened when Apple asked iOS users if they were ok with Facebook tracking them.

Re: Is GitHub Copilot a blessing, or a curse?

#166

Post by krageon »

skohan wrote: post #120
krageon wrote: post #79

Earlier quoted context omitted.

What it means that it can't code well, so there's nothing to be excited about. That we cannot predict the future is of course true but really has no bearing on what you're saying, except to lend credence to the idea that it will be able to some day (i.e. that you can predict the future). Which is in essence the opposite of what "we cannot predict the future" should mean. That makes the entire argument kind of disinge…

We can't know the future, but we guess based on past trends. Technology has been pretty good at replacing humans in the past, and a lot of times we've said "a machine can't do this" and been wrong. We'll have to see, but I think it's silly to say it's not working now so it never will.

We've heard breathless claims that AI will replace people coding ever since the advent of AI in some form or another. If we truly were going on past trends, we would conclude it is not very useful and will probably stay that way.

Re: Is GitHub Copilot a blessing, or a curse?

#167

Post by mikro2nd »

skohan wrote: post #36
eminence32 wrote: post #7

> The code Copilot writes is not very good code. This has been my experience as well. Some of the early promo material for Copilot showed someone writing a function signature with docs, and having Copilot write the entire body. This rarely works for me, except for fairly trivial functions. This is also not how I normally write code. However, where Copilot has been rather good is offering intelligent "tab completion",…

Copilot is also almost certainly going to become better. For example, NVIDIA's DLSS was viewed as a failure at launch, but now it's almost magic in terms of offering better results at a lower performance cost.

It might also become worse. It seems to me that GitHub has opened themselves (well, this Copilot thing anyway) up to a form of DoS attack: Just imagine what might happen if a bunch of people opened up a number of public repos filled with utter crap?

Not suggesting anything, here, just musing on a possibility.

Re: Is GitHub Copilot a blessing, or a curse?

#168

Post by nimbius »

ALittleLight wrote: post #57
seumars wrote: post #51

Earlier quoted context omitted.

For what it’s worth, Copilot is not being marketed as anything else than code suggestion software - an alternative to google search, perhaps more of a “I’m feeling lucky” without having to actually type the search term. Knowing how to succinctly express a problem is half the problem after all.

It's called "Copilot" and the tagline is "Your AI pair programmer." It's obviously being marketed as more than code suggestion software. It's being marketed as an AI pair programmer. I agree that it is basically just code suggestion software, or like a big autocomplete. But it's definitely being marketed as more.

the biggest concern and reason to pump the brakes on copilot is the unresolved elephant in the room: the growing consensus that it violates FOSS licenses.

Re: Is GitHub Copilot a blessing, or a curse?

#169

Post by city41 »

toomanyducks wrote: post #16
serenloss wrote: post #9

Earlier quoted context omitted.

This seems like a gross simplification. We want factorable code because that helps with DRY. DRY code is more portable and the end product is smaller in size. Also, there's performance considerations. I'll be surprised if there's a tool like copilot anytime soon that can identify need for memoization, for example, and implement it.

But if a human isn't messing with the code, the code doesn't matter - what the bot does to the code matters. And if the bot can handle bad code in a way humans can't, that means something . Code quality will become less important if automated tools, the ones reading and writing the code, don't care about it.

In some ways this has been the case for a long time. Tools that generate code, such as Visual Studio's form designer as a simple example, often generate really bad code. But no one ever reads it, and if you need to make a change you just run the tool again. So the fact the code is bad isn't very relevant.
Post reply on HN