Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Commitment to Open (Red Hat News)
Posted Mar 5, 2011 15:28 UTC (Sat) by ewan (subscriber, #5533)
The GPL doesn't require a form that is 'good enough' or 'workable'; it requires whatever is preferred.
Posted Mar 5, 2011 15:46 UTC (Sat) by corbet (editor, #1)
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.
The idea being that you can modify and rebuild the program. As nice as it might be, I think stretching "preferred form" to "the form that would be most convenient for you" goes beyond what the license is trying to say.
One could say that Red Hat's distribution violates this little provision:
You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
That requirement has been mostly ignored for many years, though, and I'm not sure anybody really wants to bring it back now.
Posted Mar 5, 2011 17:14 UTC (Sat) by ewan (subscriber, #5533)
I think in practice it's usually a bit stronger than that; the 'preferred form' is the actual source, excluding machine generated files. That excludes preprocessor output, as you say, but also plain C code generated from other things, and, I think it's at least arguable, a big single patch that's been generated from something else.
The idea being that you can modify and rebuild the program.
Again, I think it's a bit stronger than that - you could, after all, rebuild something from pre-processor output too, it would just be hard work. It seems to me that it's generally taken to mean that you should have access to the same source as the person distributing the code - if they've written machine code directly with a hex editor, that's the source, if they've generated it from assember, then that's the source, and if it came from a big block of C, then that's the source. And if it came from a VCS, a big set of patches, and scripts to assemble the whole lot, then that is the source.
This is interesting idea, but...
Posted Mar 5, 2011 20:39 UTC (Sat) by khim (subscriber, #9252)
Posted Mar 5, 2011 17:56 UTC (Sat) by pboddie (subscriber, #50784)
I always interpreted "preferred form" to be the original source, rather than, say, object files or preprocessor output. [...] The idea being that you can modify and rebuild the program.
Yes, the intention is surely that you get precisely the source code for the code that is being run, not just a set of patches against some other archive that you have to track down.
After reading an LWN news item a few weeks ago, I ended up on a site which offered patches for a selection of packages to be obtained from their upstream locations for the software suite mentioned in the news item. Since some of the packages were LGPL- and GPL-licensed, I sent a question to the person responsible for licence compliance at the organisation concerned, noting that this links-plus-patches page probably wouldn't be good enough to comply with those licences, but also noting that this wouldn't matter unless the site in question were the primary means of giving the sources to those who had received binaries from that organisation. It turned out that the links-plus-patches page was merely for everybody else on the Internet, as I suspected.
So in fact, as myself and the representative of the organisation concerned agreed, offering separate patches is a convenience, but it probably isn't suitable as a means of complying with copyleft licences, as indeed the GPL FAQ notes.
Posted Mar 6, 2011 0:53 UTC (Sun) by vonbrand (subscriber, #4458)
That is quite different. An SRPM contains the upstream, unmodified source; (optionally) some patches against the above; a set of instructions on how to create and build the binaries from the preceding; and some ancilliary stuff. So there isn't any question of "distributing patches without original source". You might argue SRPMs fail the GPL because they don't give you the modified sources... ;-)
Posted Mar 7, 2011 17:07 UTC (Mon) by pboddie (subscriber, #50784)
Posted Mar 5, 2011 18:19 UTC (Sat) by ballombe (subscriber, #9523)
> You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
I do not think this apply to patches, and as a consequence to the RedHat kernel and more generally SRPMS and Debian source packages: the point of this requirement is to prevent a modified version to pass for the original version, but source packages provide the unmodified source tarball (so no file is actually modified, so the requirement is void) and some patches (which in any case include the lists of files which are modified) and even a changelog that list changes with the date.
Posted Mar 5, 2011 18:33 UTC (Sat) by corbet (editor, #1)
Posted Mar 6, 2011 4:40 UTC (Sun) by branden (subscriber, #7029)
It's not about what's most convenient for *you*, the downstream guy. It's about what was the preferred form for modification *by the upstream provider who modified it*.
This shift in perspective is critical.
The whole philosophy of the GNU GPL is to create a community of users for works of software wherein all are co-equal (within the limits of individual aptitude, of course).
That the one-big-monolith kernel SRPMs are a modifiable form of the work is not the point. As you implied, object files and preprocessor output are perfectly modifiable as well, but are seldom the preferred form for modification under the GNU GPL. These monolithic-patch SRPMS are not, by all accounts, the preferred form of the work for modification by those developing and distributing them--Red Hat's kernel engineers.
Congratulations are in order, I suppose, to Red Hat's management, who look poised to pull off what Larry McVoy could not--lock up a significant chunk of Linux kernel development behind a paywall without ominous notes of caution from the preeminent journalist in the field.
Posted Mar 6, 2011 5:15 UTC (Sun) by corbet (editor, #1)
Those interested in my opinion on this move are likely to get their chance to read it. Until that happens, let me just say that "I believe it complies with the letter of the GPL" is not equivalent to saying "I believe this is a good thing."
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds