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.]
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.
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.
> 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.
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.
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.
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?
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.
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.
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?
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:
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.
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.
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).
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.
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
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.
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.
