[elktea]

I am sure the authors of the uutils utlities did actually look at the GPL source code. If that is the case, shouldn't this project be GPL as well?

disclaimer: I did actually make the first commit on one of these tools, but I didn't look at the source of the original C code.

[marcan_42]

Looking at source code does not make everything you subsequently write a derivative work of that code.

Not looking is a strong legal defense for whatever you wrote not being a derivative work. Looking just means you can't use that defense, it doesn't mean you actually copied code.

Given the significantly different paradigms of Rust and C, and that most coreutils don't really do that much algorithmically, it would be pretty easy to avoid accidental copying with this kind of project.

[fulafel]

No, that's not how copyright works.

[josephcsible]

Then why are people who look at leaked Windows source code not allowed to contribute to Wine or ReactOS?

[Denvercoder9]

Because by rejecting work from people who've seen the leaked code, you can be sure that your project doesn't become a derived work. That doesn't imply the reverse; that if you accept code from people who've looked, your project must be derived a work.

All cows are animals, but not all animals are cows.

[user-the-name]

https://news.ycombinator.com/item?id=29458419

[johnisgood]

Pretty sure they did. Does it require proving? How would one prove such a thing if so?

[marcan_42]

You would have to prove that the Rust version is substantially similar to the C version, to an extent that wouldn't happen if someone who hadn't looked at the C code had written the Rust version purely from the spec/behavior.

For example, significantly identical code flow, variable naming, or function structure would be red flags, especially if it's not the "obvious" implementation.

[oblio]

I'm reasonably sure that idiomatic Rust code can't really infringe C copyright. I'm not saying that it's impossible, especially as you say, regarding overall code flow or variable naming, but the languages are quite different in how they approach things.

Unlike for example, Java 1.5 and C# 2. I think at the time you could almost copy paste Java code into a C# and have it compile after tinkering with it for 2 minutes.

[colejohnson66]

Copyright doesn't just protect the single implementation, but also any derivative works. If I take some C code and copy it (with a rewrite) into C# (or whatever), the C version's copyright still applies because mine is a derivative work. That's where the "clean room reverse engineering" idea comes from: Implementing a spec isn't infringing, so just have the person reversing and the person implementing communicate using a spec.

In this case, the "spec" of the coreutils would probably the man pages.

Changes to the C code to be idiomatic Rust does throw a wrench into the whole thing, and it would have to be sorted out by a court, but it's not as simple as people like to think.

As usual: IANAL

[marcan_42]

> If I take some C code and copy it (with a rewrite) into C# (or whatever), the C version's copyright still applies because mine is a derivative work.

Copyright protects creative output. That means if you copy creative aspects of the code - things like the structure, naming, algorithms down to small details of the implementation - then you are creating a derivative work (this is what happens if you translate code from one language to another verbatim - not trying to be idiomatic - most of the time). If you merely read the original code to understand what it does and create an implementation that produces the same behavior, but is otherwise not substantially related to the original, then you have not copied any creative aspects and you have not created a derivative work.

"Clean room reverse engineering" (which, done properly, is extremely rare and the vast majority of open source projects related to reverse engineering do not do it to a proper standard) is a strong legal defense to show that creative aspects could not have possibly been copied. However, it is neither water-tight (the spec could've conveyed unnecessary creative aspects accidentally), nor is it required to show non-infringement. It's merely a defense; not doing clean-room RE doesn't mean you are doing anything infringing.

> Changes to the C code to be idiomatic Rust does throw a wrench into the whole thing, and it would have to be sorted out by a court, but it's not as simple as people like to think.

Practically speaking, given the significant differences between what is idiomatic in both languages, and the relative simplicity of what most coreutils actually do, there's a good chance that even a careless "translation" into idiomatic Rust would erase most creative aspects and put you well on the way to being able to claim it's not a derivative work. Effectively, the translation would involve a round-trip through an abstraction to the level of a spec, simply because what's idiomatic is so different. This is, of course, not a hard guarantee, nor would I bet the legality of my project on this aspect alone, but rather just an observation of what is likely to happen in many cases. In other words, you'd have to be really careless to end up creating a derivative work of coreutils here; the language difference works significantly in your favor.

IANAL, but I've been doing reverse engineering projects for over 15 years and my main job these days is leading an open source project to support an undocumented platform via reverse engineering. So I have a bit of experience with this matter :-)

[colejohnson66]

TIL. Thank you for correcting me! BTW, your work on Asahi Linux is incredible!