User: Password:
|
|
Subscribe / Log in / New account

Red Hat and the GPL

Red Hat and the GPL

Posted Mar 9, 2011 5:37 UTC (Wed) by frnknstn (guest, #68647)
In reply to: Red Hat and the GPL by branden
Parent article: Red Hat and the GPL

I may be wrong here, but isn't the C preprocessor part of the C standard? And isn't preprocessing the first step of compilation?

If that is true, then supplying preprocessed source code is supplying partially compiled source code, and thus insufficient for GPL compliance.


(Log in to post comments)

Red Hat and the GPL

Posted Mar 9, 2011 5:48 UTC (Wed) by branden (guest, #7029) [Link]

Yes, the C preprocessor is standardized.

The second question is arguable. Preprocessing certainly is not compilation in the classical computer-science sense.

The output of a macro assembler after it has expanded macros is no more object code ready for execution by the host CPU than the output of the C preprocessor is.

To extend your reasoning, enumerate the other "steps of compilation". Assembly is also compilation. So is optimization. So is linking.

What does that leave?

Well, uh, "compilation".

As is often the case, terms have contextual definitions. In some contexts, everything that happens after you execute gcc is "compilation". In others, gcc does a whole bunch of things, only some of which are "compilation".

I think it was astute of Mr. Edge to leave out the preprocessor-output-as-source-code angle, frankly. A close look at that example makes the case against Red Hat's decision with recent kernel SRPMs stronger, not weaker--and that's not the conclusion he wanted to reach.

Good polemics. Substandard journalism.

Red Hat and the GPL

Posted Mar 9, 2011 10:39 UTC (Wed) by AlexHudson (guest, #41828) [Link]

"Similarly, we can view Red Hat's monolithic kernel source RPMs as an *improvement* over that unwieldy, tedious, split-up pile of rubble called patches to the upstream source."

I suspect the number of people who see separate "per-bug" patches as being less useful and a step backwards from a monolithic patch are going to be relatively small. Just considering bidirectionality (the ease of making a monolithic patch versus the difficulty of splitting a monolithic patch) makes that a very difficult argument to subscribe to.

So maybe tone down your own polemic about the standard of journalism.

Red Hat and the GPL

Posted Mar 9, 2011 16:28 UTC (Wed) by MisterIO (guest, #36192) [Link]

Same thing I was thinking. Patches splitted in a way that makes sense are far more readable than a monolithic one.

Red Hat and the GPL

Posted Mar 9, 2011 20:31 UTC (Wed) by branden (guest, #7029) [Link]

I entirely agree with both of you.

My sarcasm was too subtle, alas.

My point was that one big blob of post-cpp C source code is less useful than the original separate .c and .h files, as a monolithic kernel is less useful than a pristine upstream kernel plus a pile of patches.

In both cases, atomization and logical separation is valuable, even essential for downstream to developers to be on equal footing with the distributor. It is that equal footing that the GNU GPL seeks to establish and sustain.

I twigged that Mr. Edge understood how the preprocessor analogy weakened, rather than strengthened, the argument he wanted to make, and that that is why he omitted it despite it being one of the first examples on Mr. Corbet's lips (well, fingers) when the subject came up in an earlier LWN comment thread.

Red Hat and the GPL

Posted Mar 9, 2011 21:17 UTC (Wed) by jake (editor, #205) [Link]

> I twigged that Mr. Edge understood how the preprocessor analogy
> weakened, rather than strengthened, the argument he wanted to make

No, I'm afraid that's incorrect. I didn't even consider the "preprocessor analogy" when writing the article. I don't think it weakens the case that Red Hat is not violating the GPL either.

Red Hat distributed its kernel the same way that various other projects have distributed theirs (including FSF projects). They are also distributing their kernel the same way that lots of embedded vendors do, and the community seems perfectly happy with those embedded vendors when they finally get around to doing so. Why is Red Hat different than the FSF or HTC?

I don't have to like what Red Hat is doing (I don't) to see that it doesn't rise to the level of a GPL violation, at least in my opinion. You are, of course, welcome to your own opinion on the matter.

jake

Red Hat and the GPL

Posted Mar 9, 2011 21:43 UTC (Wed) by branden (guest, #7029) [Link]

Thanks for replying!

"No, I'm afraid that's incorrect. I didn't even consider the "preprocessor analogy" when writing the article. I don't think it weakens the case that Red Hat is not violating the GPL either."

Ah. I must wistfully admit that I wish you'd had a phone conversation or brief email exchange with Mr. Corbet about this, then. It seemed to be an example that was eminent in his mind when he commented in the past week or so.

"Red Hat distributed its kernel the same way that various other projects have distributed theirs (including FSF projects)."

The FSF has copyright in most of the works they distribute, and I can assure you with near-certainty (as I work professionally in this area) that for their most popular and well-known works (glibc, gcc, gdb, bash, ncurses, binutils, etc.) that what little third-party copyrighted code is present is *not* under the GNU GPL, but under far more permissive licenses, such as BSD-style without the advertising clause, the MIT/X11-style license, or others closely resembling the foregoing, none of which mandate redistribution of source forms at all.

Red Hat, as a licensee of the Linux kernel under the GNU GPL, has a responsibility not only to their downstream users but to the other copyright holders in the kernel as well.

Maybe all of the other copyright holders in Linux are cool with this decision. Or maybe they're not, but don't feel they have sufficient resources to pick a fight with a well-heeled public corporation. Or they're not, but have a personal affinity with Red Hat kernel engineers and feel a sense of gratitude to the firm for offering their friends employment. Or they're not, but feel that Red Hat is still a net positive force in Linux kernel development. LWN could try interviewing some of them to find out what they think.

Copyright law is only one avenue of persuasion. Another is the court of public opinion. I had hoped that LWN, as the news outlet of record in Linux kernel development, would have taken a stronger stance against this move.

What Red Hat is doing is corrosive to the community. The reason people are looking closely at the GNU GPL version 2 for possibilities of a license violation here is that this document, in spite of some members' institutional and/or personal biases against the FSF and RMS, is the pre-eminent social contract under which our community has operated for twenty years.

The GNU GPL has a spirit and a letter; both are important and it is foolish to denigrate either, when both have proven their utility time and again. (I invite anyone who doesn't think the GNU GPL has a spirit to read competing licenses like the CPL, the EPL, the MPL, or the APSL, and then reconsider.)

You just said that you don't agree with this decision. Why, then, write an article which gives Red Hat cover for it? Why offer apparently unsourced speculation as to the views of Red Hat's attorneys when you can speak with perfect authority about your own view?

Make your stand, LWN!

Red Hat and the GPL

Posted Mar 9, 2011 21:56 UTC (Wed) by corbet (editor, #1) [Link]

Ah. I must wistfully admit that I wish you'd had a phone conversation or brief email exchange with Mr. Corbet about this, then. It seemed to be an example that was eminent in his mind when he commented in the past week or so.

Well, I did review the article before it was posted... I don't see how the preprocessor discussion changes things here. The GPL requires distributing the source that you modify. Preprocessing it would violate that; shipping your source tree does not.

As a copyright holder in the kernel, I do not agree with or appreciate Red Hat's move in this area. That is a feeling I have communicated on this site and to the people involved in making the decision. It is a step in the wrong direction.

That does not mean that I believe the GPL can be used to force Red Hat to change its mind. As far as I know, nobody has ever challenged tarball distribution of source in all these years. Why would we try to start now?

I am sorry you do not like the stand we have taken. But I still don't believe that this action, obnoxious as it is, can be called a license violation.

Red Hat and the GPL

Posted Mar 10, 2011 0:43 UTC (Thu) by branden (guest, #7029) [Link]

"The GPL requires distributing the source that you modify. Preprocessing it would violate that"

The text of the GPL does not mention the C preprocessor. "Everybody knows" that running source through cpp prior to distribution renders it violative of the GPL. Because this is a comfortable old truth, we haven't troubled ourselves to re-justify it from first principles again.

I think that if you explicitly articulate the reasons why post-preprocessed source code is inadequate to meet the definition of source code under the GNU GPL, the case against Red Hat's monolithification of their kernel SRPMS will become more clear.

I have tried to elucidate the matter myself, but I am clearly not a persuasive enough exponent.

Red Hat and the GPL

Posted Mar 9, 2011 14:00 UTC (Wed) by samth (subscriber, #1290) [Link]

This is pretty badly wrong with regard to the definition of compilation. In the world of C compilers, the term compilation is often used to mean the transformation of the output of the C preprocessor into assembly, but this is far from universal. In general, cpp, gas, and gcc are all compilers. It's easy to see this by considering compilers for other languages with macro systems, such as Common Lisp, where the "compiler" includes macro expansion, and also the term "JIT compiler", which usually refers to the transformation of a low-level bytecode directly into a binary instruction stream.

If you look up the Dragon book, you'll see that they write "a compiler is a program that reads a program written in one language -- the source language -- and translates it into an equivalent program in another language -- the target language". This fits cpp and gas just as it does gcc.

Red Hat and the GPL

Posted Mar 9, 2011 20:36 UTC (Wed) by branden (guest, #7029) [Link]

So you're telling me I'm wrong by reiterating my own assertion that the definition of the term is contextual and scope-dependent?

You might as well just call me names, man--it would save time.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds