Reasoning behind the "preferred form" language in the GPL
Reasoning behind the "preferred form" language in the GPL
Posted Mar 7, 2011 5:10 UTC (Mon) by tomcatsdb (guest, #73351)Parent article: Commitment to Open (Red Hat News)
Nothing RH is doing here is violating either the spirit or the actual terms of the GPL.
RH provides the source tarball including required makefiles and configuration files for the source to build the binary as shipped. That's all that's required by the GPL.
The language in the license was added to prevent someone from shipping a printed version of the source or other forms of distributing the source that amount to useless for an end user. Sure it's the source all right, but not machine readable nor editable or usable to make a modified distribution from. The language of the license protects us, the end users, from these kinds of actions by distributors of GPL applications.
Remember that GPL (v2 and earlier) was crafted long before wide spread network access. If a user needs source, it has to be supplied in a form the user can access so they can make changes, recompile, etc. So a tape, or other machine-readable media would need to be supplied by the vendor, and it needs to be in a reasonable format. Wide spread network access makes this easy, as a vendor can put the source of the binary available for download as RH has done. The GPL is about protecting the four freedoms outlined by RMS / the FSF, nothing more, nothing less.
The lack of a public git tree or multiple patch sets may make some workflows difficult for people outside of RedHat's immediate area of concern, but it isn't a GPL violation. It may make some people in the community irked, but that's a completely different matter than anything the GPL addresses.
Posted Mar 7, 2011 5:44 UTC (Mon)
by dlang (guest, #313)
[Link] (4 responses)
I also agree that just releasing one modified tree instead of a series of patches is not an issue
where I have an issue is with them releasing source code to some people, but only under the condition that they don't share it with anyone else. yes, the source that's available as patches to customers is available in other forms (as part of the modified tree), but the very idea of giving source code to someone and having a limitation that restricts that person from distributing the source code is at least against the spirit of the GPL, and may very well be against the letter as well
Posted Mar 7, 2011 5:50 UTC (Mon)
by foom (subscriber, #14868)
[Link] (2 responses)
Well..I think really that *is* the main issue. That's what started this whole conversation after all.
It may not be illegal or "against the spirit of the GPL" to just release the modified source rather than a git repo or set of patches, but it's not very nice. The legality or spirit-of-gplness of releasing those broken out patches to customers only is actually kind of a distraction from that main issue...
Posted Mar 7, 2011 6:03 UTC (Mon)
by dlang (guest, #313)
[Link] (1 responses)
I also think that going down the road of requiring access to version control repositories that are used internally is a very bad idea.
think about the case where the source is distributed along with the binaries instead of being available for download separately. is the supplier requried to include a complete version control repository? what if that repository is using proprietary software? you could get into the situation where the source is being provided in the manner that the devlopers prefer to work with it, but the resulting files are completely useless to anyone who isn't willing to spend the money (and agree to the terms of service) of some proprietary software package. and to make things even more interesting, what if that VCS system only runs on windows?
you can't have it both ways. either the GPL does not require access to the VCS (in which case releasing one big patch, or a modified tree is not a problem), or it does (in which case the problems above can apply)
Posted Mar 7, 2011 12:54 UTC (Mon)
by foom (subscriber, #14868)
[Link]
I think it's a problem because other kernel developers are complaining about it making their life more difficult, and the reason for the change was indeed to make other people's life more difficult.
Posted Mar 7, 2011 13:54 UTC (Mon)
by tomcatsdb (guest, #73351)
[Link]
To be honest, I'm a bit on the fence myself here, but I think we're looking at it from the wrong angle, or at least we should consider what RH is doing with their terms. The areas of their terms of use you're mentioning here is basically "don't ape our service" language. Without it, someone could literally buy a single RHEL subscription, get the system updates, and mirror said updates for a charge to others w/o RH having any recourse against said organization.
Put another way, RH is saying that in order to continue to use their service (RHN updates + support), you can't compete with them by using their own work product. Technically, you're free to do with the code as you wish, but certain actions may result in you not having access to RH provided services in the future.
Does the GPL state that no matter what someone does with GPL based code, once a vendor ships it to an entity, the vendor is forced to continue a business relationship with the entity? Keep in mind the source for the GPL'd code is still available as SRPMS IIRC, so RH is still distributing source for anyone, including said entity, to download and compile for themselves. The entity just looses access to the value added services RH provides.
As I said, I'm a bit on the fence myself, but this is another perspective to consider,
Posted Mar 7, 2011 8:28 UTC (Mon)
by PaXTeam (guest, #24616)
[Link] (10 responses)
so are you saying that breaking up each translation unit into individual files of a single line then #include'ing them back would still satisfy the GPL? after all, that'd produce the same binary, be machine readable, etc. and according to you, it'd also be the preferred form for modification ;).
Posted Mar 7, 2011 19:46 UTC (Mon)
by vonbrand (subscriber, #4458)
[Link] (3 responses)
Clearly not, as nobody in their sane mind writes C code as a set on one-line files to be #included. But GPL also isn't meant to force anyone to (re)distribute each and every dead end, fixed bug, rewrite, and failed experiment in the code's history either (thanks $DEITY!).
Posted Mar 8, 2011 10:38 UTC (Tue)
by PaXTeam (guest, #24616)
[Link] (2 responses)
what does a sane mind have to do with the GPL and its 'preferred form for modification' clause? as the creator of a derived work, i can pretty much do 'whatever' i want to the 'source code'. say, i can split up all the files into one-liners, or i can go the other way as well, it's all within my rights to change the 'source code' any way i want (obviously i can't remove the GPL itself or anything else the GPL says). what we're talking about here is the form this changed work has to be distributed in. you (well, tomcatsdb) said that original sources + patches were not mandated by the GPL because (in his reading) the only requirement of the GPL here is the ability to build the distributed binary. my example derived work satisfies that criterion. if it doesn't, then you'll have to change your reading of this GPL clause. so which is it? ;)
Posted Mar 8, 2011 15:19 UTC (Tue)
by vonbrand (subscriber, #4458)
[Link] (1 responses)
If a bunch of #included oneliners is the preferred source form for you, you are wellcome to distribute that way. But you'll have to be able to prove the above when challenged... Note that GPL asks for you to distribute full source, and mark any changes you did. If you distribute original source and patches, you are complying with GPL with respect to the original source. As you don't distribute any patched stuff, that is all you need to do. GPL allows to patch the original (via your patches or by hand), so anyone who gets the package from you is in the clear too.
Posted Mar 8, 2011 16:34 UTC (Tue)
by PaXTeam (guest, #24616)
[Link]
so are you saying that RH's (their software developers') preferred form for modification is a single monolithic tree with no track of changes? because we know it's not the case therefore according to your own criteria they'd be violating the GPL when they distribute the monolithic tree.
> If you distribute original source and patches, you are complying with
this is what i thought too but RHEL6 doesn't have this in the srpm so if you think RH is in the clear when they're distributing a monolithic tree for RHEL6's kernel then so would i be with my one liners *regardless* of what form i use myself for development. so you see something doesn't compute here, you're basically contradicting yourself: you want me to justify my development method when i distribute one liners but you accept RH's monolithic tree even if that's not how they develop RHEL's kernel.
> As you don't distribute any patched stuff, that is all you need to do.
i lost you here. we're talking about someone (like RH) who took a GPL'd work and created a derivative ('patched' it) and distributed it in binary form and therefore has to provide the 'source code'. if the work is original and not derivative, there's nothing to talk about, the author does whatever he wants with his work.
> GPL allows to patch the original (via your patches or by hand),
i don't understand how this came up here, there is no question that you can patch a GPL licensed work (i.e., create derivatives of it) and there's no question that you can distribute the derivative work (per the GPL's conditions). what is in question is the *form* of the derivative work, in particular what the 'preferred form for modification' means. but you already established that it's the form that the author(s) of the derivative work themselves use, from which it follows that RH is in violation according to you as well.
Posted Mar 7, 2011 23:32 UTC (Mon)
by tomcatsdb (guest, #73351)
[Link] (5 responses)
So, let's say someone did try to do this, how does the GPL protect us? Well, the only feasible way this could be done would be with an automated script.
In this case, someone went from human-readable code -> "meta-c" code (using automated script) -> C compiler -> binary. The "source" chain still starts at the original unmangled C files. You could also argue that the organization that did this would have to release their mangling script too, since it's part of the required build materials. In short, it'd blow up on them in a bad way.
Posted Mar 8, 2011 10:59 UTC (Tue)
by PaXTeam (guest, #24616)
[Link] (4 responses)
no, he didn't, read my reply to him please ;).
> Well, the only feasible way this could be done would be with an automated script.
for my specific example yes, very likely, but i can imagine other transformations that i can pull off by hand and would still irk the casual programmer when looking at it. also, what if my transformations were done within an IDE? no scripts to distribute would exist then...
> In this case, someone went from human-readable code -> "meta-c" code (using automated script) -> C compiler -> binary
hold that right there. first, what exactly makes your "meta-c" code not human-readable (it's not 'meta', it's normal C btw)? second, the GPL has exactly zero mention of 'human', let alone 'human-readable'. where did that requirement come in?
> The "source" chain still starts at the original unmangled C files.
and? what does that have to do with the GPL's 'source code' distribution clause? not to mention that following your logic, RHEL6's source chain most likely started with some git tree (for the sake of discussion let's assume 2.6.32) and then it got mangled over time. yet we don't see the 'original unmangled C files' released. so as i said to vonbrand already, you either accept my proposed one-liner files or you don't accept RHEL6's current form of distribution. which is it? ;)
> You could also argue that the organization that did this would have to
first, the mangling script wouldn't help you much if you only had its output (i.e., what you'd want is a reverse script but the GPL doesn't require you to even create it). second, the mangling script, for all you know, is *not* part of the build process (you don't know what i do in my own environment, i may or may not use the mangled form for modifications myself, much like you're saying that we shouldn't care what form RH developers use as long as the released 'source code' compiles), the mangled files are perfectly compilable.
> In short, it'd blow up on them in a bad way.
much like it did for RH, on that we agree ;).
Posted Mar 9, 2011 23:59 UTC (Wed)
by tomcatsdb (guest, #73351)
[Link] (3 responses)
"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."
When someone checks out code from whatever revision control system they have, you end up with directories that have source files + project files for the IDE (if applicable), and other related files. You don't directly edit git, cvs, svn, or whatever, you work directly with source files in a directory structure. You modify those files. Even with something like clearcase's dynamic views, to the compiler and programmer, it's still a filesystem (source files + directories). A tarball of that file system contains the source code in the format (C / headers / makefiles, etc) that is used for making modifications and preparing derivative works.
"for my specific example yes, very likely, but i can imagine other transformations that i can pull off by hand and would still irk the casual programmer when looking at it. also, what if my transformations were done within an IDE? no scripts to distribute would exist then..."
Fine, if your coding style is such than ok, I have no problem if that's how you work internally. But be prepared to show that you're not obfuscating the code prior to releasing the source. So, if someone sues you for a GPL violation and during discovery it's shown through your revision control system that you work in a normal fashion then proceed to obfuscate the code then release source, you'll be in trouble. You went through a step to transform the source from it's preferred form for modifications to something useless for the recipient of your source. As far as the IDE goes, it'd be the same thing. One of two things happens in the IDE case:
1) The IDE writes screwy source files but presents them to the programmer in an understandable format (in which case a receiver of the source could just use the same IDE).
or
2) The IDE has an obfuscate function which translates the source away from anything understandable so its no longer the preferred form for making modifications, which is in direct violation of the GPL section quoted above.
By the way, since RH is _NOT_ obfuscating their source, you've created a strawman here.
The thing you're failing to address is that there is a difference between version control and the actual sources. git, svn, cvs, etc are _not_ source code. They are repositories _for_ source code. Let me turn this around and present you with an argument:
To justify _your_ position, you need to prove than I can't download a kernel release (in source tar ball format) and make modifications to that source. Keep in mind that this is the method kernel.org used for years prior to git. Were they violating the GPL? If not, then how can RH be in violation for doing the exact same thing?
"hold that right there. first, what exactly makes your "meta-c" code not human-readable"
Ok, so remember way back when C++ code was translated to C code then that code was compiled (there were quite a few compilers that did this)? You, being the programmer, started and worked on the normal C++ code. The machine took over after this point doing the translations to C and went on from there. I'm not going to pretend that I can understand that C code, and I surely can;t ship that and claim it's the "source" fo rthe program. Your example is similar in nature. There is a starting point in the process that a person edits and works with source files (C / C++ / IDL files, project settings, etc). Past that point is where the source code ends. That's the clear line in the sand. Sure the translated C is readable in one way (I can see the characters), but it's not readable in terms of comprehension and all but useless for modifying.
I realize full well it's still C code, but in your example, it went from a normal format that people can read and follow to a syntactically correct (for C), but incomprehensible format, thus my "meta" term.
"second, the GPL has exactly zero mention of 'human', let alone 'human-readable'. where did that requirement come in?"
That's exactly why the "preferred form of the work for making modifications to it" language in the GPL exists. To modify the code, you need to be able to read and understand it. Deliberately obfuscated code fails this requirement and is thus against the GPL. This requirement also protects against the application vendors sending downstream users printed hard-copies, screen captures of an IDE, or other methods of source distribution that can't be worked with for the purposes of modifying and preparing derivative works. The GPL was very well crafted in this regard.
"and? what does that have to do with the GPL's 'source code' distribution clause? not to mention that following your logic, RHEL6's source chain most likely started with some git tree (for the sake of discussion let's assume 2.6.32) and then it got mangled over time."
Wrong. RHEL6's kernel source started as exactly that: source code. It might have come out of a version control system, but it's _NOT_ the version control itself. Modifications to source files happen over time, versions get committed back to a control system, but the _source code_ that's being modified is still the C and associated files. You keep trying to tie the versioning system and source code together and that's where your logic fails.
"so as i said to vonbrand already, you either accept my proposed one-liner files or you don't accept RHEL6's current form of distribution. which is it? ;)"
Your logic is flawed for the reasons outlined above, so I can both reject your proposed one-liner files as being against the GPL and accept RH's current distribution as being GPL compliant.
"i may or may not use the mangled form for modifications myself, much like you're saying that we shouldn't care what form RH developers use as long as the released 'source code' compiles), the mangled files are perfectly compilable."
Wrong again. Version control != source code. The RHEL folks probably edit in emacs or vi... who knows, but they're modifying files (C, headers, makefiles, etc), not directly editing git. Once you appreciate the difference, you'll see that the hypothetical situation you're describing and what RH is doing is completely different. RH provides the tarball for their kernel just like a full source download from kernel.org. They aren't obfuscating the source or coming anywhere near that, which is what your hypothetical situation is all about. What RH _is_ doing is restricting access to the version control system. These are two different things, one of which is prohibited by the GPL, one of which is not. Show me anywhere in the GPL where revision control system is mentioned. At best, there is the language which says to illustrate the changes. Since, IIRC, there is a single large patch that is released along with the complete tarball for their kernel versions, RH meets this obligation as well.
Yes this is a PR nightmare, but no, it's not a GPL violation.
If someone wants to be angry over the policy change, then fine. But let's at least be reasonable about what there is to be angry over. Let's discuss real issues (effects on the community, transparency in the development process or whatever) rather than fabricating scenarios that just aren't there.
Posted Mar 10, 2011 23:37 UTC (Thu)
by PaXTeam (guest, #24616)
[Link] (2 responses)
this is where you are wrong. you consider *only one* kind of modification (one where you add your own original work to create a derived work, although in reality even in this case one prefers to see the history leading up to the work you're modifying, but let's not digress), whereas there are *other kinds* of modifications where said format is *not* the preferred form. think of simple things as reverting a specific change (you need to know what that change was, why it was done, etc), or fixing a bug introduced in a specific change (again, you need to know what change was, why it was done, etc) or extracting a specific change because you want to study it for whatever reason, or you want to port it to another kernel tree, etc (again, you need to know what the change was, etc).
> Fine, if your coding style is such than ok, I have no problem if that's how you work internally.
great, so you agree that whatever the author of the work uses is prime candidate for 'preferred form for modification'. then you must agree that what RH distributes in the RHEL6 sprm is *not* the preferred form since they're not sending such monolithic tarballs around when their own developers communicate with each other during development.
> You went through a step to transform the source from it's preferred form
and now you're contradicting yourself. you have to make up your mind and decide *whose* preferred form is the one meant by the GPL. seemingly the author and the recipient of the derived work can have wildly contradicting ideas about what 'preferred' means and you've now argued both views so it's time to settle on one. so, does the author or the recipient dictate the 'preferred form for modification'? if it's the author then you can't call my one-liner (or whatever) transformation useless, since it's what i use. if it's the recipient then you can't call the RHEL6 srpm preferred as seemingly it doesn't satisfy many people. so which is it?
> By the way, since RH is _NOT_ obfuscating their source, you've created a strawman here.
they're obfuscating what i and many other people consider 'preferred form for modification'. you're still trying to cling to some 'common sense' definition of 'source code' whereas for good reasons the GPL gives a definition of it for its use in the license, you cannot arbitrarily reinterpret it. you must instead interpret 'preferred form for modification' and *everyone* agrees that the RHEL6 srpm is *not* the preferred form for modification, exactly because the details of their changes are completely lost. and whatever explanation you come up for this you'll also have to explain why the RHEL5 srpm has a different 'preferred form for modification' than RHEL6. after all you and they can't have it both ways.
> The thing you're failing to address is that there is a difference between version control and the actual sources.
i never once mentioned version control.
> To justify _your_ position, you need to prove than I can't download a
easy. please extract all the fixes for all the CVEs they have in RHEL6.
> Keep in mind that this is the method kernel.org used for years prior to
prior to git there was bitkeeper, and the patches sent to the mailing lists. but it's all irrelevant, see next.
> Were they violating the GPL? If not, then how can RH be in violation for doing the exact same thing?
you're mixing up the rights of the authors of the original work (Linus has the copyright on the collective work and individuals have copyrights on their respective contributions) vs. those of the derived work (RH's modifications to some state of the Linus tree). authors of the original work can pretty much do whatever they want, authors of the derived work are bound by the GPL.
> Wrong. RHEL6's kernel source started as exactly that: source code. It
you make no sense here. what is the 'version control itself'? i never said anything related in fact, i said that the RHEL6 kernel started its life as some specific point in the Linus git tree (i recall it's 2.6.32, give or take). that specific point means a set of files/directories obviously. but *that* set of files/directories is *not* distributed in the RHEL6 sprm, only its mangled version, contrary to your own expectation.
> You, being the programmer, started and worked on the normal C++ code.
so if i can understand the cfront output then what? am i in the clear? since when does skill level enter the GPL? right, it does not.
> Your example is similar in nature. There is a starting point in the
yeah, clear as mud. 'source code' is not defined that way in the GPL. it's defined as 'preferred form for modification'. there's *no* mention of anything like 'starting point', 'person edits X', 'works with source files' (did you just make it a recursive definition now?), etc. please stick to what the license says, not what you wish it said.
> Sure the translated C is readable in one way (I can see the characters),
not readable by whom? remember the choice above you have to make. *whose* preferred form are you arguing for here? it looks like again that you're trying to take the recipient's view as 'preferred form' but then RH is in trouble as the RHEL6 srpm is anything but the preferred form according to many people (also 'comprehension' and stuff is not part of the GPL, you just made it up).
> That's exactly why the "preferred form of the work for making
that language does exist in the GPL indeed, 'human-readable' does *not*. your point being?
> To modify the code, you need to be able to read and understand it.
this is the crucial part. *whose* ability to read/understand 'source code' defines what the acceptable form is? it seems that you argued once for the author and many times for the recipients, so i take it the latter is what you're really trying to defend (but then RH is violation for the RHEL6 kernel, so you're in a bind here). but even if we accept this stand there's still trouble: *which* recipient? people have different skill levels, people have different agendas (one can deliberately keep complaining until *his* demands are met, etc), so what now? do we need to take a poll or something to decide what 'preferred' means?
> Deliberately obfuscated code fails this requirement and is thus against the GPL.
define obfuscation. make sure it doesn't require a world-wide poll to decide.
> This requirement also protects against the application vendors sending
you're wrong, the paragraph about the 'source code' and its 'preferred form for modification' has nothing whatsoever to do with the medium for distribution. what does talk about this are 3.a and 3.b in that they mandate a machine-readable form, but that's not under discussion here as RH is in the clear, they do provide a machine-readable form.
> Your logic is flawed for the reasons outlined above, so I can both
you have yet to give a single valid reason, so no, you haven't proved my statement wrong yet.
> Wrong again. Version control != source code.
i don't know where this strawman came from, i wasn't talking about version control at all.
> The RHEL folks probably edit in emacs or vi... who knows, but they're
for derived works and distribution it's irrelevant what an individual does in his privacy. what matters is what happens when he *communicates* (well, distributes) his derived work. RH developers don't send around entire linux tarballs but mere patches instead when they do development, therefore that pretty much defines *their* preferred form for modification. now of course you still have to make up your mind whether the modus operandi of the authors of the derived work matters or not, but whatever way i look at it, patches are preferred by both authors and recipients.
> RH provides the tarball for their kernel just like a full source
RH distributes a derived work, kernel.org does not (well, speaking of the Linus tree). not to mention that kernel.org distributes not only a tarball but a git tree with full history of the kernel. what did you try to say here again?
> They aren't obfuscating the source or coming anywhere near that, which
they're obfuscating their changes in the derived work.
> What RH _is_ doing is restricting access to the version control system.
another strawman? i never once mentioned access to their internal version control system. as you noted, the GPL doesn't even mention such.
> Since, IIRC, there is a single large patch that is released along with
then you should download the RHEL6 sprm and look at it yourself. there is no such thing as a 'single large patch' in it. according to you then they're in violation.
Posted Mar 12, 2011 4:52 UTC (Sat)
by tomcatsdb (guest, #73351)
[Link] (1 responses)
The act of adding a new file, removing a file, changing a line of code, regardless of the purpose, is a modification. Viewing extraneous information, historical or otherwise, is not modifying the source, hence it is out of scope of the GPL. The history is data about the work you're modifying, not the work itself. Note that when people distribute a compiled GPL application + source in tarball format on the same media, this has historically satisfied the conditions of the GPL. Your assertions would make every one of these distributions against the GPL. In addition, distributing the changesets or diffs from a previous version are not sufficient, however the complete source to the binaries as shipped is. From the GPL V2 FAQ (See: http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html)
---
Q: I want to distribute binaries, but distributing complete source is inconvenient. Is it ok if I give users the diffs from the standard version along with the binaries?
A: This is a well-meaning request, but this method of providing the source doesn't really do the job.
A user that wants the source a year from now may be unable to get the proper version from another site at that time. The standard distribution site may have a newer version, but the same diffs probably won't work with that version.
So you need to provide complete sources, not just diffs, with the binaries.
----
Other relevant quotes:
----
... No, you must supply the source code that corresponds to the binary. Corresponding source means the source from which users can rebuild the same binary.
... No matter how you distribute the source, the sources you provide must correspond exactly to the binaries. In particular, you must make sure they are for the same version of the programnot an older version and not a newer version.
---
Note that in all cases, historical data is not required, just the source to the binary as shipped. If you still wish to debate this point, pick it up with the FSF. They are the authoritative voice on what the GPL requires and their FAQ spells it out in exactly the terms I originally used.
Now then, this does lead back to the question of your test case of obfuscated code. Others have discussed this in various places (google "gpl obfuscated code"), and the answer most agreed on is what I stated: The purpose of the GPL is to allow recipients to distribute the application (plus source) in original and/or modified form. Going through a GPL work and obfuscating the source to make it useless to a recipient goes against the purpose of the license. The reason why I stated that it does matter how you code i simple: badly written code / poorly documented code is not against the GPL. So if you did work in that fashion, ie you aren't intentionally attempting to make the code unreadable to the recipient, you'd be in the clear. Automating a obfuscation step prior to the release is translating it from the preferred form for modifications to a bunch of files useless for the recipient aside from running make on. Thus your example is not GPL compliant.
The rest of your paragraph details the reasons why someone would want to modify a file, but this is irrelevant as far as GPL compliance goes. Again, you are attempting to combine the source code with the history of that code. These are two different things as supported by the wording of the GPL as well as the FSF's GPL FAQ. If you can find an authoritative source to support your position, feel free to post it here.
"great, so you agree that whatever the author of the work uses is prime candidate for 'preferred form for modification'. then you must agree that what RH distributes in the RHEL6 sprm is *not* the preferred form since they're not sending such monolithic tarballs around when their own developers communicate with each other during development"
... Really? Here you equate the internal method for a developer obtaining the source to the source itself. You keep doing these kinds of things and its still as wrong as it was the first time. Your example hypothetical situation deals with modifications to the source files themselves. It makes no mention of how those files are passed around internally. That is the difference between the real world situation of what RH is doing and your example. Internal communications have absolutely _NOTHING_ to do with GPL compliance.
"and now you're contradicting yourself. you have to make up your mind and decide *whose* preferred form is the one meant by the GPL."
No, I haven't. My position has been clear. It's supported by the FSF's FAQ. The only thing that I could not find with a few seconds of googling was the FSF providing an official position on obfuscated code. There is a difference between poor programming and willful, or in your case, automated obfuscation which I think would be relevant to a GPL violation lawsuit... Regardless, since RH is _NOT_ obfuscating the "source code" (as defined by the FSF), interesting as this side discussion is, it's irrelevant to the situation at hand. The rest of your paragraph builds on the false assertion that I've contradicted myself, fails to take into account the qualifications I've clearly made, and attempts to equate source code obfuscation to not shipping historical data.
"hey're obfuscating what i and many other people consider 'preferred form for modification'. you're still trying to cling to some 'common sense' definition of 'source code' whereas for good reasons the GPL gives a definition of it for its use in the license, you cannot arbitrarily reinterpret it."
I'm reinterpreting the GPL? Your idea of what "source code" constitutes goes far beyond anything the GPL states. But don't take my assertion for it, go back and read the FSF GPLv2 FAQ. Diffs are not sufficient for GPL compliance, but complete source for the binary is. "source code" is defined _explicitly_ as "not an older version and not a newer version" but the exact version used to make the executable. Historical development data is _NOT_ relevant to GPL compliance. Period. If it was, then CDs with just the binary and tarball of the source would be against the GPL. Those forms of distribution have been cleared by the FSF numerous times.
Yes people may be unhappy, as they no longer have a convenience provided by RH. Historically RH went well above and beyond what was required by the GPL. They're cutting that back. In either case, what matters here are the sources / scripts etc used to build the binary, which is what is defined by the GPL as the corresponding source code. Regardless of how the sources were packaged, the recipient got a source tree that they can make, and no, the files are not obfuscated. In the end, both RHEL5 and RHEL6 srpms provided a kernel source tree for the binary kernel RH shipped. If the RHEL 5 srpms had extra info, so be it. You keep trying to stretch the GPL to cover areas beyond the actual source code. That is the failure in your position. The RHEL5 srpms went beyond what the GPL requires, the RHEL6 srpms trimmed it back. Both are in compliance with the GPL.
"i never once mentioned version control."
But you keep saying RH needs to provide data that can only come out of a version control system.
"easy. please extract all the fixes for all the CVEs they have in RHEL6."
From the GPL v2 FAQ, previous or newer versions are not relevant to GPL compliance. Aside from that, you're asking for a specific modification that relates to historical data, on a binary that when built by you, was never distributed by RH. Hence they have absolutely zero obligation to support the request you're asking for. As an additional thing, you didn't address my point: Prove I can't open a C file from the kernel tree, change it, and build the resulting modified work. Prove I can't add a new module. Is it machine readable code that can be compiled? Why yes it is. Is it the complete source to the version as shipped by RH, well yes, it is. Do these conditions satisfy the GPL, according the the FSF FAQ, yes they do.
"you're mixing up the rights of the authors of the original work (Linus has the copyright on the collective work and individuals have copyrights on their respective contributions) vs. those of the derived work (RH's modifications to some state of the Linus tree). authors of the original work can pretty much do whatever they want, authors of the derived work are bound by the GPL."
Now this is an easy one. There is no magical divide here. Guess what: RH is in the same boat as any other contributor or distributor. Anyone who distributes a binary build of the kernel is bound by the GPL. This is the key component. RH is not under any obligation to provide sources for a binary they did not distribute.
RH plays the role of both contributor (the employees that RH pays to do the kernel work are making the contributions on behalf of RH) and distributor. The obligations for a distributor are to ship the source for the binary they distributed. RH does this. Now then, as a developer, RH internally builds, tests, and works on numerous bugs, but unless they distribute those binaries to an external entity, they are not bound by the GPL for those versions. They can expose that information or not, it's their choice, but not a GPL requirement.
"you make no sense here. what is the 'version control itself'? i never said anything related in fact,"
The version control system would be git, or bitkeeper, or whatever. The historical development data for a code base comes from a version control system. You keep saying stretching the definition of source code to include historical development data based on a completely twisted reading of the "preferred form" phrase in the GPL which contradicts the GPLv2 FAQ, as well as contradicting the simple fact that the GPL is triggered for a specific binary released. The development history behind the code is irrelevant to the terms of the GPL as explicitly stated by the FSF. Sure it's nice to have, but not required.
"that specific point means a set of files/directories obviously. but *that* set of files/directories is *not* distributed in the RHEL6 sprm, only its mangled version, contrary to your own expectation."
I never said RH had to distribute vanilla kernel sources, now did I. The only thing I stated regarding historical data, was that I think RH does provide a bulk "here's all the changes" patch, but I could be wrong on that point. Its a moot point though.
"so if i can understand the cfront output then what? am i in the clear? since when does skill level enter the GPL? right, it does not."
No, because that wasn't where you, being the programmer, made your changes. But you're illustrating my point. Obviously delivering the C code version of the C++ wouldn't satisfy the GPL. It's the same reasoning I'm using to justify why your (completely irrelevant to the situation RH is in) hypothetical code obfuscation example fails GPL compliance.
"yeah, clear as mud. 'source code' is not defined that way in the GPL. it's defined as 'preferred form for modification'. "
Omission of the next sentence in the GPL is your downfall: "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." By the way, the kernel is an executable, hence this clarification applies. Oddly enough, it's exactly what I've been saying. You can't selectively quote a single sentence out of the GPL and twist it all to heck to fit your personal agenda or worldview. You accuse me of reinterpreting the GPL when your own ideas about what a single sentence means goes against the FSF GPL FAQ and the very next sentence in the GPL itself.
"please stick to what the license says, not what you wish it said."
Please read more than one sentence of the license.
Your next paragraph is more of the same flawed logic. Read the license again as it applies to executables. Oh, thats right, it fits exactly what I said. You keep trying to wedge in a division between what the recipient of the code and the author expects based on your non-applicable hypothetical situation. No such division exists. People are crying foul about the RH policy change and trying to argue every possible negative against what RH is doing. I'm fine with that so long as those arguments are based on something real, not an imaginary GPL violation.
"you're wrong, the paragraph about the 'source code' and its 'preferred form for modification' has nothing whatsoever to do with the medium for distribution. what does talk about this are 3.a and 3.b in that they mandate a machine-readable form, but that's not under discussion here as RH is in the clear, they do provide a machine-readable form. "
So you're arguing a PNG screen cap is fine then? It's machine readable, but not the preferred form for modifications. People have tried to pull stunts like that in the past, hence the language in the GPL to prevent such nonsense. Aside from that, source code as defined for an executable is stated directly after the preferred form language, which, again supports what I've been saying.
"i don't know where this strawman came from, i wasn't talking about version control at all."
Because the data you are asking RH to provide comes out of their revision control system. The source code and its history are two different things. Your entire argument against RH boils down to a lack of that history.
The next few paragraphs equate internal distribution methods to making modifications on the source. But one thing you stated:
"or derived works and distribution it's irrelevant what an individual does in his privacy. "
I agree with this 100%. Guess what: RH developers are part of the same corporate entity. They can pass whatever they want around however they want around and it matters absolutely zero to RH's obligations under the GPL. See the GPL and the GPL FAQ for support of this.
"RH distributes a derived work, kernel.org does not (well, speaking of the Linus tree). not to mention that kernel.org distributes not only a tarball but a git tree with full history of the kernel. what did you try to say here again?"
This is wrong. Linus, kernel.org, or anyone really, is technically distributing a derived work from someone else at this stage, since the copyrights aren't assigned to a central entity. There is no central owner of the Linux source tree's copyrights.
"they're obfuscating their changes in the derived work."
No, they aren't. The C is as readable as the next bit of code in the kernel. You equate no internal revision history to source obfuscation which is yet another failure in your position.
I had read somewhere that they were doing monolithic patches, rather than individual patch sets. If it's the full source to the binary w/o patches in there, then according to the authoritative voice (FSF) RH is still fine. As I said, it was the only thing that may matter, and based on the clarifications provided by the FSF in their FAQ, seems to be a non-issue.
With this post, I'm bowing out of this topic. I think we're both fairly set in our positions on this one. While I don't agree with your logic, the debate did raise an important point that AFAIK isn't directly addressed in FLOSS licensing: obfuscated code in a Open Source project.
Posted Mar 13, 2011 11:40 UTC (Sun)
by PaXTeam (guest, #24616)
[Link]
one last comment, as you seem to keep misreading the GPL: 'source code' != 'complete source code'. the sentence using the second term does *not* define 'source code', it defines 'complete source code' using the definition of 'source code' given in the previous sentence and i didn't mention it because it's irrevelant for the discussion: before we can talk about 'complete source code' we have to know what 'source code' is. apparently anything that compiles and a human can read in a normal text editor is good enough for 'source code'.
Reasoning behind the "preferred form" language in the GPL
Reasoning behind the "preferred form" language in the GPL
Reasoning behind the "preferred form" language in the GPL
Reasoning behind the "preferred form" language in the GPL
Reasoning behind the "preferred form" language in the GPL
Reasoning behind the "preferred form" language in the GPL
Reasoning behind the "preferred form" language in the GPL
Reasoning behind the "preferred form" language in the GPL
Reasoning behind the "preferred form" language in the GPL
Reasoning behind the "preferred form" language in the GPL
> you are wellcome to distribute that way.
> GPL with respect to the original source.
> so anyone who gets the package from you is in the clear too.
Reasoning behind the "preferred form" language in the GPL
Reasoning behind the "preferred form" language in the GPL
> release their mangling script too, since it's part of the required build
> materials.
Reasoning behind the "preferred form" language in the GPL
Reasoning behind the "preferred form" language in the GPL
> (C / headers / makefiles, etc) that is used for making modifications and
> preparing derivative works.
> for modifications to something useless for the recipient of your source.
> kernel release (in source tar ball format) and make modifications to
> that source.
> git.
> might have come out of a version control system, but it's _NOT_ the
> version control itself.
> The machine took over after this point doing the translations to C and
> went on from there. I'm not going to pretend that I can understand that
> C code, and I surely can;t ship that and claim it's the "source" for the
> program.
> process that a person edits and works with source files (C / C++ / IDL
> files, project settings, etc). Past that point is where the source code
> ends. That's the clear line in the sand.
> but it's not readable in terms of comprehension and all but useless for
> modifying.
> modifications to it" language in the GPL exists.
> downstream users printed hard-copies, screen captures of an IDE, or
> other methods of source distribution that can't be worked with for the
> purposes of modifying and preparing derivative works. The GPL was very
> well crafted in this regard.
> reject your proposed one-liner files as being against the GPL and accept
> RH's current distribution as being GPL compliant.
> modifying files (C, headers, makefiles, etc), not directly editing git.
> download from kernel.org.
> is what your hypothetical situation is all about.
> the complete tarball for their kernel versions, RH meets this obligation
> as well.
Reasoning behind the "preferred form" language in the GPL
Reasoning behind the "preferred form" language in the GPL