[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: generated source files, GPL and DFSG

On Fri, Jul 22, 2005 at 12:07:05AM +0100, Matthew Garrett wrote:
> > Could you back up a bit, first, and explain to me why that is not the
> > preferred form for modification?  It certainly looks like it to me.
> The preferred form for modification has all of the hex constants
> replaced with preprocessor defines that give you useful register names.
> It's fairly easy to show that this is the case - the code is plainly
> derived from NVidia's earlier (Xfree 3.3 era) driver and their open
> source SDK, which did have useful symbolic constant names.

That depends.  I can see two scenarios: either they removed these constants
from their own codebase, and that's how they now maintain it; or they pass
the code through a filter to remove these constants before distributing it
to the world.

If the former, then what you linked is their preferred form for modification.
For example, perhaps their register documentation doesn't know anything
about the names in those symbolic constants, and it's just more direct for
the programmers to maintain it with the numbers directly.  (I doubt nVidia's
own documentation is that bad.)

The latter is classic obfuscation.  I hope it's not a controversial claim to
say that obfuscated C code is never source[1], and I don't see how anyone
could honestly claim that this is the source to the driver.

"Preferred form for modification" seems to work very well here.

I believe there have been long flamewars about this code, which I havn't
followed, and I don't have time to investigate this particular case in
detail.  (So, please be reasonable and not ask me to file bugs against
packages, when doing so would commit myself to participating in another
resurrected flamewar.)

On the other hand, if nVidia no longer maintains this code, but someone else
does, then it's effectively become their source: that's how they modify it.
Similarly, if I take a BSD-licensed blob of obfuscated C code--clearly not
source--run it through indent, fix up variable names and otherwise make it
usable again, and start releasing my own fork based on that, then the blob
of code has become the legitimate source to my fork, even though it wasn't
source when the original obfuscator released it.  This is uncommon, but worth
considering: something which is not source can become source.  (I think
"preferred form for modification" works fine here, too.)

[1] "except when it's actually written that way, eg. obfuscated code
contests", just to cover the canonical exception

Glenn Maynard

Reply to: