Commitment to Open (Red Hat News) [LWN.net]

Preferred form

Posted Mar 5, 2011 15:46 UTC (Sat) by corbet (editor, #1) [Link]

I always interpreted "preferred form" to be the original source, rather than, say, object files or preprocessor output. The actual text is:

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.

Preferred form

Posted Mar 5, 2011 17:14 UTC (Sat) by ewan (subscriber, #5533) [Link]

rather than, say, object files or preprocessor output

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) [Link]

as I've already noted before Oracle (or anyone else) will have any hope to prevail in court they should answer one simple question: 20 years ago it was perfectly Ok to keep sources in private VCS and only present tarballs to the world (FSF did that, Cygnus did that, etc - it was normal M.O. back then). If, as you assert, times changed and now it's not Ok then you must explain what exactly happened between then and now to change the equation. VCS is not a new idea, you know: SCCS was released 38 years ago.

Preferred form

Posted Mar 5, 2011 17:56 UTC (Sat) by pboddie (subscriber, #50784) [Link]

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.

Preferred form

Posted Mar 6, 2011 0:53 UTC (Sun) by vonbrand (subscriber, #4458) [Link]

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... ;-)

Preferred form

Posted Mar 7, 2011 17:07 UTC (Mon) by pboddie (subscriber, #50784) [Link]

I don't want to mention any names, but I wasn't talking about SRPMs exclusively, although this is obviously Red Hat's preferred mechanism for distribution. Nevertheless, you make a good point: Debian source packaging is done with upstream archives, patch archives, and some stuff which lets you combine them. I imagine that the GPL permits such distribution practices because all the different parts come from the same place and involve widely-available technologies for putting everything together.

Preferred form

Posted Mar 5, 2011 18:19 UTC (Sat) by ballombe (subscriber, #9523) [Link]

> 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.

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.

Preferred form

Posted Mar 5, 2011 18:33 UTC (Sat) by corbet (editor, #1) [Link]

The RHEL kernel SRPM is not packaged that way - there is only the (modified) source tarball.

Preferred form

Posted Mar 6, 2011 4:40 UTC (Sun) by branden (subscriber, #7029) [Link]

"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."

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.

Preferred form

Posted Mar 6, 2011 5:15 UTC (Sun) by corbet (editor, #1) [Link]

Remember that my first post on the subject included an expressed hope that this whole thing was an accident.

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."