Dr.Mario 64's gzip implementation is taken almost verbatim from gzip source code | Hacker News Reader

Dr.Mario 64's gzip implementation is taken almost verbatim from gzip source code

twitter.com

71 pointsblacktulip61 comments

If you check the file in GZip from 1999 (1.2.4a) it is not licensed with GPL:

   inflate.c -- Not copyrighted 1992 by Mark Adler
   version c10p1, 10 January 1993

   You can do whatever you like with this source file, though I would
   prefer that if you modify it and redistribute it that you include
   comments to that effect with your name and the date.  Thank you.
   [The history has been moved to the file ChangeLog.]

EDIT: Changed formatting

Does that file contain GPLed changes from the gzip project? I know linux's copy is effectively GPL2 because of that. Wouldn't be surprised if gzip's is the same.

It's sort of how bringing BSD code into a GPL project is a bit of a one way street.

Maybe they used an older version of the file before it was GPL licensed? E.g.: https://opensource.apple.com/source/gnuzip/gnuzip-13/gzip/in...

That's correct. You can retrieve the gzip 1.2.4a source from https://ftp.gnu.org/gnu/gzip/ and what looks to be this exact file.

Kinda sad that the state of discourse these days is to induce pitchforks first, and it falls on readers on a news aggregator site to dig up the sources for themselves.

The zlib license [1] is very permissive, so I'm not sure there's any real issue here.

[1] https://en.wikipedia.org/wiki/Zlib_License

Wrong software: the tweeter claims it’s copied from the GPLed Gzip, not zlib. Probably GPLv2, given the release timeline.

Man, if copyright wasn’t 85 years long, Nintendo might already be off the hook.

> Wrong software: the tweeter claims it’s copied from the GPLed Gzip, not zlib.

The tweeter's claim does not matter. If you download the version of gzip they're talking about and look at inflate.c, it clearly spells out that it's authored by Mark Adler free for reuse.

The gzip project can not relicense the file, only any addenda they performed to the original might be GPL'd.

Are you certain about that? Wasn’t GPL-relicensing of BSD X-server code part of the original tensions between the GPL and BSD camps? I want to say that was in relation to Gnome, but it’s been a while since I’ve looked for it.

Nintendo’s defense, of course, would be to say they received the file from a non-gzip source.

Assuming that you mean the incident that resulted in the X.org X11 distribution being actually usable for end users it was essentially the other way around. It was about XF86 relicencing originally MIT licensed code under GPL-incompatible license similar to 4-clause BSD.

That sounds like what I was thinking of, I must’ve misremembered the issue.

Do you have any sources on that history? All I can find with a quick search is blog posts asking whether GPL usage is declining.

you can license BSD-licensed files and changes to them as GPL, as BSD is compatible with the GPL as it contains no clause against adding additional restrictions. However, that doesn't magically remove the original license, so you can of course grab the original file and use it under the BSD license.

I'm unsure why the tweet author thinks this would be a GPL violation?

gzip is GPL-licensed. gzip isn't the same as zlib.

File is imported into gzip from a non-GPL'd project, that gzip is GPL-licensed doesn't relicense the file.

File in question literally starts with a comment stating

   inflate.c -- Not copyrighted 1992 by Mark Adler
   version c10p1, 10 January 1993

They can license the changes that they've made to that file since importing as GPL though. The linux copy still includes that header, despite also clearly having GPL code in it as well.

Nintendo might have a "I didn't know any better because the header was unclear" argument that might limit their practical damages, but if we can only find this file with associated changes in a GPLed project it certainly looks like GPL infringement.

I mean if the file header says you can do what you want, it seems reasonable to do what you want. If you're relicensing, you should modify or remove that.

If it's had changes since Adler's 1993 copy, then it doesn't matter what Adler says.

Grab the original rather than taking code out of GPLed projects if you don't want GPLed code.

Is this zlib source code or gzip source code? gzip is GPL isn't it?

Also, if this is GPL code, does that mean Dr. Mario would need to be licensed under the GPL? And would that mean any other distributed software by Nintendo which uses any code from Dr. Mario 64 would need to be licensed under the GPL? If so, isn't that... kind of a big deal?

gzip is GPL but zlib is not. However since zlib's license is GPL-compatible it's just fine to e.g. vendor zlib inside gzip.

That does not make it gzip code, the zlib code is not relicensed and it keeps its original license.

Furthermore, both gzip and DrMario64 having merged in zlib's code does not give gzip any claim upon DrMario64.

Does gzip actually use zlib? zlib's implementation (https://github.com/madler/zlib/blob/v1.1.3/inflate.c) looks different at first glance, gzip predates it by three years, and I believe gzip is also noticeably slower.

> Does gzip actually use zlib?

If you go and download gzip 1.2.4a (the version mentioned) and open it, the first two lines state:

    /* inflate.c -- Not copyrighted 1992 by Mark Adler
    version c10p1, 10 January 1993 */

Note that the file you link to is copyrighted (rather than not-copyrighted) 1995-1998. Now maybe saying that it's zlib's is inexact because zlib did not actually exist at the time, but that doesn't really make a difference, it's basically the code to what would eventually become zlib, by zlib's author, under a hyper-permissive license.

Saying it's zlib's did confuse me. But I think I understand now, thank you.

That wasn't my question, my question was if the posted code is from gzip or zlib. It looks like it's probably zlib.

> That wasn't my question

But it's the answer.

> my question was if the posted code is from gzip or zlib. It looks like it's probably zlib.

It's zlib code living inside gzip, so it's not an either / or question.

The question I am asking is the code posted "zlib code living inside of gzip" or "gzip code that has nothing to do with zlib." The decompression code posted may be in gzip proper, but probably not. I haven't seen anyone post the zlib source in this thread proving so.

edit: I see you've answered this in another thread. Thanks.

No, it's just copyright infringement, it doesn't magically relicense other people's work.

In theory the publishers of Dr Mario might owe the copyright holders for GNU zip (perhaps the FSF) damages, and of course it would be possible to stop them from shipping more copies of the infringing product, Dr Mario (I doubt this is a real issue since it's an old game).

I don't think it's that virulent. If Nintendo releases Dr Mario under GPL, they could compel themselves to also release derivative works. But I don't think anybody else would have the standing (unless those works also contain gzip or other GPL code)

why wouldn't consumers have the standing, given that the GPL grants them rights to read source code of or create derivative works of the products they purchased if the code is GPL?

Because it's code released by Mark Adler which gzip uses and:

1. there's no evidence so far that Nintendo didn't just independently use the same release

2. that gzip uses it doesn't relicense the file

I wasn’t asking in this scenario but in general if a game company was forced to retroactively license a game under the GPL

Note: this comment is written under the assumption that Nintendo included GPL'd code, which doesn't appear to be the case. But this is an interesting hypothetical either way.

The answers here are in line with my (NAL) understanding of the issue:

https://softwareengineering.stackexchange.com/questions/3318...

If the Nintendo-authored derivatives of Dr. Mario are free of external GPL code; more generally, if they are the sole copyright holders of those derivatives -- they may release them (or not) under any license they like.

For instance, you're welcome to release a work under GPL, and maintain a proprietary patchset that you release only in binary form. But, at the moment that you incorporate code/content written by external contributors under the GPL license, you cannot incorporate that into your proprietary version.

While Nintendo may not be compelled to release derivatives, it is my (NAL) understanding that the gzip authors would have a very strong case to a very expensive discovery process which would provide them very broad access to Nintendo's game source code. While I don't think that all of the revealed code would enter public record, some of it would inevitably be entered as evidence.

There's another fun case worthy of consideration: if you are the sole author of some body of code, and you contribute that code to a GPL-licensed project (but do not assign copyright to that project), you retain full rights to the original code. You may, at a later date, license the original form of that code to an employer for proprietary use, or to another project using an incompatible license. And this is a great use of version control software -- you must not include later improvements to that code that was made by others; and the repo provides excellent historical evidence.

No privity of contract.

(and the fact that the code isn’t actually GPL)

Well only the code that was published with GPL'd code compiled in would have to be made available under the GPL. As Nintendo presumably has copyright on the other parts and can publish them however they want. Unless there are more surprises.

If I release two pieces of software, one GPL, and another closed source which uses some of my GPLed code, if someone discovers the closed source one uses that code am I obligated to apply the GPL’s terms to the other project?

You can offer your code under as many licences as you want. So you can publish the same code under both GPL and a proprietary license. This is called dual-licensing. The people that receive the code from you under one of those licences will not have that liberty. They will have to abide to the licence you gave them. For proprietary licences, that usually means they are not allowed to do more than use it. For GPL, that means they can pass it on under the GPL.

So in your example, while people could share the code you publish under the GPL, it does not impact what you can do with your closed source version. Only when you'd start to integrate patches to the GPL branch from third parties, you'd get into trouble.

zlib and gzip are two different source packages with very different licensing.

Isn't this post talking about gzip, not zlib?

Almost all of the gzip format is the zlib payload. Gzip doesn't even have a data structure for file entries, which is why you gzip tarballs (unlike zip files which have their own file index logic).

An interesting historical curiosity, but I doubt anything actionable would come of it.

Also, damn, Nintendo was still releasing N64 games in 2001? The release date would've been mere months before the Gamecube launch and Luigi's Mansion.

Conker's Bad Fur Day came out in 2001. There were a few last minute games.

A contemporaneous review said it was budget-priced ($30 usd)

It was within the final 10 games released for the N64

Why are uninvestigated Twitter allegations still being reposted to HN and upvoted, causing distraction and confusion?

I think such cases are interesting.

One result is that the allegation got investigated here: HN isn't just regurgitating the news, its readers are making news. Sometimes, misinformation is the result of an honest confusion. Better to discuss it out in the open, than cover it up.

The other result is that it's a teaching moment for people who have incomplete understanding of related licensing issues.

As someone who has written userland implementations of several crypto algorithms in the past (parts of PKCS5: PBKDF2 and PBES2), I’m positive you could say this about my code as well.

If you were both following the same spec, they should be very similar. Intentionally renaming things would just make it more confusing for the next guy and more difficult for anyone to validate your code.

EDIT: and of course that’s not to say they didn’t “steal” it, just saying that similarity in this kind of code is to be highly expected.

My first assignment as a developer was porting some common formats to Java, mostly PNG and MD5 (weird combo I know, but there were reasons).

I spent a week banging my head against the FFI for Java to get MD5 C code wrapped, and then in a fit of pique tried to do an all-Java implementation.

Since Java is a C-family language, transcribing the code from the specification was a cakewalk, and I had something working within a day.

Because of the PNG work (and a fascination with compression) I've also spent some time in the zlib code, and the zlib code is... unusual. Among other things, it has longjmp support built in so you can do cooperative multitasking in single-threaded systems. That and some aggressive work to assert that there is sufficient free memory to run zlib properly, makes the code a bit more novel. I don't think you or I would write the code that way, so it's implausible that someone would accidentally replicate the code, in this scenario or any other.

I will completely trust your superior level of experience in this area regarding the coding approach.

I still think that, given the two pairs of screenshots we have, most of the code and comments looks like obvious boilerplate that could easily be identical. A couple of lines perhaps not, but it’s far from conclusive.

Does that include creating comments in the code that are the same too? :)

Yes, actually. For instance if section 3 of the spec says to pad the hash... my comment will be exactly (or 90%) the same as several other implementations I saw because we’re all literally reading from the same playbook.

There are only so many ways to say something like: // step 2: figure out how many blocks of hash length will be in the derived key, rounding up

According to stack overflow gzip is based on BSD licensed infozip

https://stackoverflow.com/questions/20762094/how-are-zlib-gz...

Does anyone know how someone got their hands on the source code for Dr. Mario 64?

There were two major source code leaks.

https://www.retroreversing.com/gigaleak2

There's been a bunch of Nintendo source code leaked recently.

It's how they found an old unused Luigi model for Mario 64!

Screenshot displayed seems generic coding style.

The style might be generic, but the comments are exactly the same too. For me this creates a reasonable suspicion.

As someone who has taught and graded multiple coding courses, I've had students try to pull things like this off where they just change the formatting a bit and think they've pulled a fast one. This has resulted in many hard conversations and decisions. The code above would absolutely warrant an investigation in any course I taught.

And variable names as well. It seems to me that you can get from one to the author with an automatic formatter.

>And variable names as well. It seems to me that you can get from one to the author with an automatic formatter.

Author = other

Autocorrect Freudian slip? The rights of the author are key to the licensing issues this tweet raises.

Yes, I meant other ;)

Variable names and code comments are character-for-character identical. Highly unlikely for two programmers in different industries in different countries who speak different languages.

Reply on news.ycombinator.com