Hacker News Reader

Comment by hurril | Hacker News Reader

An exact match is of course a derivative, let's call it the identity derivative. So in:

let new_code = f previous_work

where f could be identity. But it could be other transformations such as: rename_all_the_things, move_items_around, object_oriented_to_functional, and what not. Probably a combination. But here's the kicker: all permutations of these functions are all derivatives.

And we don't have to be naive here, thinking that I'm talking about using refactoring tools on an actual code base because I want to hide the fact that I want to steel some piece of code.

I'm talking about the fact that I've seen so much code and this has in fact taught me basically everything I know. I have trained myself on a stream of works. Just like an AI. The difference is in scale, not in nature.

View on HN

You can pretend the identity function is a derivative that is no different from other kinds of derivatives, and has no logical difference.

A judge and jury are going to laugh in your face.

An exact copy is completely different than “produced new code based on everything it’s seen”. You can try your “it’s just an identity function derivative” if you want, but… judges and juries aren’t idiots. They know that a copy is a copy. You’re not going to pull the wool over their eyes

I was trying to explain so that you might understand, that there is a continuum between copying (the identity function) to more complex combinations of other transformations via your memory/ intuition.

I am definitely not trying to conclude that copyright or licensing is bad.

I have read the scheduler implementations in a number of different operating systems. If I were to implement a scheduler in a operating system, would you say that there is a probability that my scheduler will be a derivative to some extent of those that I have read? How is this materially different from training a GPT on those same pieces of code, and then asking it to construct a scheduler?

I would argue that while there are differences, there are also similarities. That means that the dichotomy is not true.

> How is this materially different from training a GPT on those same pieces of code, and then asking it to construct a scheduler?

I am saying sometimes GPT doesn’t do the thing you’re describing. Sometimes it produces exact copies of something that it was trained on.

When it does that (not a “superficially similar” one, but an exact copy) can OpenAI be held liable for copyright infringement?

Because it seems like they want to avoid liability on both ends. They don’t want to be liable for copyright infringement based on ingesting works, and they don’t want to be liable when their tools produces a *copy* of existing works.

I don’t think that’s an acceptable framework.

Thing is: derivatives are verboten, sometimes. Otherwise we could all just steel and rename all the things.

Okay, I think we may be arguing basically the same thing.

I’m arguing that copying is not allowed. And you’re arguing derivative works are not always allowed.

I originally thought you were arguing that derivative works are allowed, and that since copying was a derivative work, that copying was therefore also allowed.

Sorry for my misunderstanding of what you were originally saying.

> An exact match is of course a derivative

Not if neither is derived from the other.

So this comes down to probabilities then. What is the probably that the fact that my TotallyNotLinux-kernel matches line-by-line with the actual Linux-kernel? I didn't copy it. Promise! But my function called println which is very very similar to some other, well it might not be a derivative.

> So this comes down to probabilities then.

Agreed. No "of course" about it.

Reply on news.ycombinator.com