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

Red Hat and the GPL

Red Hat and the GPL

Posted Mar 9, 2011 10:49 UTC (Wed) by paulj (subscriber, #341)
Parent article: Red Hat and the GPL

I'd like to restate my comments on earlier points. These points are speculative/exploratory, however I do think it's important for the community to be careful about ceding to a narrow interpretation of the GPL mostly out of respect for a friend. The friend may be trust-worthy and generally do the right thing, but others may not be.

Firstly, re "preferred form". The article makes the claim that RedHats' preferred form is not a factor for the GPL, but I can not find anything in the GPLv2 text to back this up. Surely the distributor's preferences for the form to work on *would* be a major factor in deciding whether the released source meets the "preferred form for modifications" criteria of the GPL? This part of the article seems very weak and poorly substantiated (if not outright wrong).

It used to be that RedHats' source for the kernel was a src.rpm with a base kernel and a series of patches, which was the source input to the build process for the kernel binary rpm. To me, it's fairly clear the GPL's definition of "source" would require that original src.rpm to be released, rather than any intermediate, auto-generated form with all the patches collapsed. However, it could be their process is now different and there no longer is such a "split patches" src.rpm. It could be their processes now are to build directly from the head of a git tree, in which case RedHat may be fine as this significantly decouples the history from the build process, and history is not source - though their reputation in the community may still suffer.


(Log in to post comments)

Red Hat and the GPL

Posted Mar 9, 2011 10:54 UTC (Wed) by gevaerts (subscriber, #21521) [Link]

How do you modify source? Do you edit patches, and then apply them as part of the building process, or do you edit the actual source and generate the patches as part of your change management process?

The way I see it, the GPL talks about "the preferred form of the work for making modifications to it", *not* about "the preferred form of the work for tracking changes", or "the preferred form for storing the work"

Red Hat and the GPL

Posted Mar 9, 2011 11:31 UTC (Wed) by paulj (subscriber, #341) [Link]

This isn't about editing patches directly (which, btw, is perfectly possible and something many maintainers of software projects will have done). This is about the sources which RedHat use for the kernel RPM. The process literally /did/ used to be about patches:

1. the src.rpm was created from an RPM spec file, which specified as input various files, including a base Linus kernel tarball and a bunch of patches.

2. the kernel binary RPM was built from this src.rpm.

RedHat maintainers literally did check in *patches* to CVS, as the source of their kernel src.rpm. Under this process, the patches clearly *are* part of the source for the build. (Note src.rpm is a reversible process, so the src.rpm file and the unpacked files are equivalent, i.e. step 2 could skip creating the actual src.rpm file - the point is the source consisted of patches).

Now, some of this has clearly changed - they're using git. It could they're now using git to apply patches to a kernel tree and building directly from that (as airlied seems to indicate), in which case it seems unlikely the history is covered by the GPL. However, if the start of the build process still works on a patch list, then that would still seem to be source and should be released.

Red Hat and the GPL

Posted Mar 9, 2011 12:58 UTC (Wed) by gevaerts (subscriber, #21521) [Link]

It has changed, yes, and I agree that patches are nicer for other people to look at what's changed, and it is indeed possible to edit patches if you really want to, but I still claim that most (if not all) of the actual modifications were done on a fully patched tree. That there were (or possibly still are) separate processes to split out those patches is interesting from a maintenance and documentation point of view, but I really don't see how that makes the patches the preferred form for modifications.

Red Hat and the GPL

Posted Mar 9, 2011 13:17 UTC (Wed) by paulj (subscriber, #341) [Link]

Evidence for base+patches being the preferred form:

1. RedHat used this form for maintaining (in the sense of humans doing the work) the source of their kernel RPMs

2. RedHat *still* have, at least, processes using this form, if not humans

3. Other corporates *also* have preferred this form (e.g. Sun)

It'd be interesting to know whether or not RedHat still internally are using the base+patches src RPM form for doing maintenance work. Your comment seems to suggest this is a possibility. In which case, RedHat really ought to be releasing the base+patches. It's really hard to argue the base+patches are NOT the preferred form if that's what you're using internally to maintain & build the distributed binary RPMs..

Red Hat and the GPL

Posted Mar 9, 2011 13:35 UTC (Wed) by gevaerts (subscriber, #21521) [Link]

I think talking about "the preferred form" is misleading, because there is not one single preferred form.

I can think of the "preferred form for making modifications", the "preferred form for long-term maintaining the code", and the "preferred form to understand the history of the code".

In my opinion these are rather different.

You seem to be talking about the last two, but the GPL explicitely talks about the first.

Red Hat and the GPL

Posted Mar 9, 2011 13:59 UTC (Wed) by paulj (subscriber, #341) [Link]

Talking about the "preferred form of the work for making modifications to it" is not misleading, it's the crux of the matter - this is the actual text of the GPL! Maintaining a work requires making modifications. Indeed, affording end-users the ability to maintain the software on their devices, even if the vendor has lost interest, was a prime motivation in formulating the GPL.

Red Hat and the GPL

Posted Mar 9, 2011 20:43 UTC (Wed) by sepreece (guest, #19270) [Link]

Yes, but *whose* preferred form for making modifications? What matters, in the context of the intent of the license, is what would be preferred by a downstream modifier, NOT the preference of the entity distributing the source code.

Doesn't seem, to me, to be a question that has a single answer.

Red Hat and the GPL

Posted Mar 9, 2011 13:14 UTC (Wed) by Los__D (guest, #15263) [Link]

Any of this does not change that the preferred form for making modifications is pure source, not patches.

How they track their changes and how they store the result of those changes does not matter at all.

You modify the source, not the patches.

Red Hat and the GPL

Posted Mar 9, 2011 13:24 UTC (Wed) by ewan (subscriber, #5533) [Link]

Actually, a common pattern for modifying the RHEL kernel RPM is by ading or removing patches in the RPM spec file. Which is why people prefer it to have split patches.

If people actually preferred a monolithic tarball no-one would be objecting to this, and Red Hat wouldn't be talking about how this change is actually intended to make life harder for downstream users of the code.

Given that this is explicitly about obstructing Oracle et al it's clear that Red Hat are under no illusions that this form is actually preferred by anyone - if it were they wouldn't be doing it.

Red Hat and the GPL

Posted Mar 9, 2011 14:01 UTC (Wed) by Los__D (guest, #15263) [Link]

And a common pattern for modifying a binary is by running it through a HEX editor, which is completely irrelevant, just like common patterns for modifying RPMs.

Again, the preferred form for making modifications is the raw source, not patches. The preferred form for tracking modifications might be patches, but this (again) is irrelevant.

Red Hat and the GPL

Posted Mar 9, 2011 14:16 UTC (Wed) by ewan (subscriber, #5533) [Link]

completely irrelevant, just like common patterns for modifying RPMs

We're talking about the source code for a binary RPM. The preferred form of the source for the RPM is all that matters.

Again, the preferred form for making modifications is the raw source

That's a non-sequitur. Clearly what is required is 'the source'. The entire intent of the 'preferred form for modification' wording is to address the question of what counts as 'the source'. I think everyone agrees that a tarball of machine generated pre-processor output is not 'the source', even though it can be compiled to a binary.

If you have a build system that starts with a single tarball and works from there then that single tarball may indeed be 'the source'. If you have a build system that starts from a pristine upstream tarball and a pile of patches, then it's reasonable to say that the pristine upstream tarball and the pile of patches together form 'the source'.

It appears Red Hat's build process does still involve a pristine upstream and a pile of patches since they're making the patches available to customers. If that's the case, then the collapsed single tarball is just as much a machine-generated intermediate stage as pre-processor output would be.

Red Hat and the GPL

Posted Mar 9, 2011 14:50 UTC (Wed) by Los__D (guest, #15263) [Link]

The engineers checks out the source, makes modifications (!!!!) to the checked out source, and checks in their changes.

How they store their changes it does not matter.

This seems to be another case of "I don't like, I better try to twist reality to my preferences".

Red Hat and the GPL

Posted Mar 9, 2011 15:18 UTC (Wed) by ewan (subscriber, #5533) [Link]

The engineers checks out the source, makes modifications (!!!!) to the checked out source, and checks in their changes.

Apparently not in the case of the RHEL kernel they don't. If what you're suggesting was actually true there would be no list of separate patches to supply to customers. And there is.

Red Hat and the GPL

Posted Mar 9, 2011 15:52 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

No, it's a git tree. There's infrastructure to generate SRPMs by turning each code-changing commit into a separate patch, but the canonical source that we develop against is git and not the SRPM.

Red Hat and the GPL

Posted Mar 9, 2011 16:00 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

Incidentally, you can check this by grabbing the beta RPM from ftp://ftp.redhat.com/redhat/rhel/beta/6/source/SRPMS/kern... - the presence of patches like "redhat-tagging-2-6-31-50-el6.patch" that have

diff --git a/redhat/Makefile.common b/redhat/Makefile.common
index 53c2115..f11b488 100644
diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
index c4017cf..b44bcf6 100644

as their sole contents should be a give away that the patch generation is automated!

Red Hat and the GPL

Posted Mar 9, 2011 22:56 UTC (Wed) by jone (guest, #62596) [Link]

great! .. where's the git tree location that we can checkout?

Red Hat and the GPL

Posted Mar 9, 2011 16:12 UTC (Wed) by avik (guest, #704) [Link]

We do not in fact develop against canonical source.

Red Hat and the GPL

Posted Mar 9, 2011 17:09 UTC (Wed) by ewan (subscriber, #5533) [Link]

OK, now that's interesting. When paulj says <i>"RedHat maintainers literally did check in *patches* to CVS, as the source of their kernel src.rpm"</i>, is that something that used to be the case, but isn't any more, or has it never been the case?
<p>
Fundamentally it seems to me that the purpose of the 'preferred form' language is to stop distributors of GPLed code from distributing in a form designed to make life harder than it need be for downstream consumers. In this specific instance people from Red Hat management have been making statements that this change was specifically intended to do just that, as a means of competing with Oracle, Novell etc.
<p>
If the reason for the change is that the canonical source used to be a pristine Linus kernel and a bunch of patches, and now it isn't because you've moved to git, then there wouldn't be any GPL concerns. But if that's all that's happened then it might have helped if someone had just said so, rather than bringing competition into it.

Red Hat and the GPL

Posted Mar 9, 2011 17:11 UTC (Wed) by ewan (subscriber, #5533) [Link]

Oops. Formatting fail - sorry.

Red Hat and the GPL

Posted Mar 9, 2011 17:20 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

The majority of packages in RHEL are managed in CVS (like Fedora until very recently), but the kernel is developed against git now. Patches are sent to mailing lists and applied to the git tree, and the SRPM is then generated from that. In the process of generating that SRPM it's possible to turn each git commit into a separate patch (as was done in the beta release, and as is done in 5) but the development base is the git tree and not the SRPM.

Red Hat and the GPL

Posted Mar 9, 2011 17:26 UTC (Wed) by ewan (subscriber, #5533) [Link]

OK, so to be absolutely clear, is it fair to say that the change is a technical result of the move to git, which meant that the 'split out patches' version no longer happened 'naturally' (as it were), and is not a management inspired artificial change intended to make things more difficult for competitors like Oracle?

Red Hat and the GPL

Posted Mar 10, 2011 10:31 UTC (Thu) by pbonzini (subscriber, #60935) [Link]

The combined reading of the parent comment, and the CTO's press release, will give you the answer.

Red Hat and the GPL

Posted Mar 9, 2011 17:30 UTC (Wed) by paulj (subscriber, #341) [Link]

So, previously the source of the kernel RPMs was a src.rpm of pristine+patches. Now the source is a git tree, with an intermediate step of a src.rpm with a collapsed history.

So then we're back to dmw2's point, at what point does a change in the build processes that happens to result in the released sources throwing away a lot of useful information go from being benign to one that is deliberately trying to obfuscate the source input to that build process so as to evade the GPL? Particularly when the system apparently still has the capability to generate the uncollapsed src.rpm, but it's not done with the express purpose to frustrate rebuilders?

Red Hat and the GPL

Posted Mar 9, 2011 17:34 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

Back when people sent patches directly to Linus and he just released tarballs, was he violating the GPL?

Red Hat and the GPL

Posted Mar 9, 2011 17:44 UTC (Wed) by paulj (subscriber, #341) [Link]

See my reply to vonbrand about engineers' often incorrect tendency to reason about legalities in purely technical terms. In your case, I'd say "no" for a number of reasons (intent, that being the normal and preferred practice, implied consent of the patch submitter, etc). But IANAL...

Red Hat and the GPL

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

As the (predominant) copyright holder in the Linux kernel, no.

You cannot violate the copyright license in your own work.

Red Hat and the GPL

Posted Mar 9, 2011 22:47 UTC (Wed) by Los__D (guest, #15263) [Link]

Errrrr, he incorporated other peoples work. That his own part of the combined work was larger is not really relevant.

Red Hat and the GPL

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

And how was this in *any* way responsive to paulj's questions?

Red Hat and the GPL

Posted Mar 9, 2011 23:21 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

I don't think historical precedent shows that the preferred form for modifying GPLed works is the full set of data contained within a revision control system - during the bitkeeper era you were unable to obtain most of the kernel metadata without agreeing to onerous license conditions, but nobody at the time seemed to argue that this was a GPL violation and I note that Debian didn't stop distributing the kernel during that period. Is there an argument to be made that the preferred form for modification includes individual patches if that's the way the maintainers work? I honestly don't know. Have we held anyone to that standard in the past? Absolutely not, and so I don't think it's terribly useful to start talking about "evading the GPL" when the result is equivalent to things that we've accepted as GPL-compliant in the past.

Red Hat and the GPL

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

Even though I'm unhappy with Mr. Edge's article for several reasons, I am glad LWN published squarely on this subject, because I am learning something important: Red Hat kernel engineers are not as upset about this development as I had assumed based on second-hand reports in previous LWN discussions. I appreciate having my misconceptions punctured.

At any rate, you are baffled because you are arguing against a straw man.

"The full set of data contained within a revision control system" is not what is being asked for.

What is being asked for is the delta between the upstream source code as Red Hat retrieved it, and each patch made to it at the level of atomicity the engineers working with it find most appropriate.

Because that was Red Hat's standard operating procedure in the kernel SRPMS domain for, literally, years.

(I'd say that a one-liner description of each patch would be de rigueur as well, but I get the impression that most kernel hackers would be content with one of git's inscrutable hexadecimal identifiers. If that really is good enough for the community, then it's good enough for me.)

To tie this in to the other discussion we're having (and for the edification of those eating popcorn while we argue), the .spec approach of specifying a base tarball (possibly more than one, it's been a while since I've built an RPM) and an arbitrary number of patches was one of the RPM package format's few advantages over DEB (particularly in the domain of source management).

Debian developers recognized that as a deficiency many years ago, and took steps to ameliorate. Doogie's Build System (dbs) was one such effort, such that the .diff.gz didn't really patch any of the original directories anymore, but just created a debian/ directory as it always does, and then included a debian/patches directory which contained the itemized patches which had to be applied to the source as part of the package build process.

There were other initiatives along these lines. Ultimately, the problem was solved at the right level, by extending the Debian source package format to allow for multiple .diff.gz files. These may still be kept few in number, but as long as the engineering equivalent of a debian/patches directory exists (many source packages use quilt) identifying the discrete patches applied, Debian packages are meeting the same standard as the Red Hat Linux kernel SRPMS of the recent past.

Sadly, my knowledge of the history of innovations in Debian source package management trails off at about five years ago. I'd much appreciate an active member of the project chiming in to bring the discussion up to date and correct any misstatements I've made.

The fact that our knowledge of developer-friendly ways to package and distribute source code has increased, and those improvements have spread and become common practice, tells you something important: our community evolves. Our expectations evolve. We learn how to do things better. The GNU GPL is vague on this for precisely the right reason: preferences among developers change with time. What was the preferred form for modification 20 years ago might not be good enough today.

When a major figure in the FLOSS community like Red Hat Software takes a deliberate step backward in engineering quality like this, and thumbs its nose at its fellows (even if they only "mean" to inconvenience less sympathetic firms), people notice, and recognize it for what it is--a conscious refusal to abide by current best practices for delivering source code in the preferred form for modification.

That Red Hat Software played a significant role in advancing those very best practices to the high level they are today makes it poignantly sad and ironic that they are betraying their legacy.

Red Hat and the GPL

Posted Mar 10, 2011 10:38 UTC (Thu) by pbonzini (subscriber, #60935) [Link]

> Red Hat kernel engineers are not as upset about this development as I had
> assumed based on second-hand reports in previous LWN discussions. I
> appreciate having my misconceptions punctured.

Of course some of them are, apparently enough to be willing to leak internal (and occasionally false) information about the change. Others are not, others consider it a sad but justified move. You'll find the whole panorama, as expected in a relatively large population.

Red Hat and the GPL

Posted Mar 10, 2011 10:00 UTC (Thu) by paulj (subscriber, #341) [Link]

First off, you're not exactly comparing like with like. You're trying to create an equivalence between kernel development processes and vendor kernel package maintenance processes. It's pretty clear these two processes are not entirely the same, because they've been significantly different in the past at RedHat and - despite any move to git at RedHat - they likely still are not the same. The preferences of developers in one mode may differ from those working in the other. The GPL does not specify exactly what "preferred form" is, no doubt quite deliberately, as it may vary from situation to situation.

The developers of one project can quite legitimately prefer to work on tarballs without history, while those of another may prefer to have the history. The *same* developers may follow two different processes, even working on nominally the same codebase, according to whether they're developing features for upstream or whether they're working on maintaining their employers supported package. That's certainly been my experience at another vendor, and you may have had the same experience too at your employer.

To be clear, there is a difference between "the sources for the Linux kernel" and "the sources for a vendor kernel package". It's an undeniable fact that, say, a RedHat kernel RPM was built using files that are not and (almost certainly) never will have equivalents in the stock Linux sources.

Further, I'm not sure there is much direct historical precedent. In the past, distributors built their packages from pristine+packages because SCMs weren't good enough. So, for package sources, for want of an SCM that could keep changes distinguished, the preferred form became pristine sources + patches. That this way of collating sources for packages became established at multiple distributors - including non-Linux ones - strongly suggests it was industry wide best-practice. I'd be amazed at anyone who tried to argue that wasn't the case. For me, such wide practise is somewhat equivalent to a preference, though you'd presumably disagree. However, in recent times SCMs have become much better. Git and mercurial (git especially) have changed how we can work and made it viable to move information that was previously kept in explicitly separate files in the sources of the package off into the history data of the SCM.

I have a lot of sympathy for RedHat. They've done and continue to do great things for free software. I do think it's legitimate to ask though, when a vendor deliberately tries to withhold information that was previously part of the sources they released for a package, at what point they cross a line. Maybe RedHat have not, but the discussion is still worthwhile.

Red Hat and the GPL

Posted Mar 10, 2011 11:24 UTC (Thu) by dwmw2 (subscriber, #2063) [Link]

"Back when people sent patches directly to Linus and he just released tarballs, was he violating the GPL?"
It's important to remember that there is a clear distinction between upstream, and a modified version or fork.

Tarballs are a perfectly sane way for upstream releases to happen.

But I think that every competent open source developer, when they're not trying to twist things to make a point, will agree: When releasing a modified code base which is based on some upstream project, it is definitely preferable to release that in the form of original + patches, rather than as a monolithic tarball of the whole damn mess.

Red Hat and the GPL

Posted Mar 10, 2011 12:47 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

It's also preferable for an upstream maintainer to provide new releases in a manner that allows people to bisect patch history. I don't understand the distinction you're drawing.

Red Hat and the GPL

Posted Mar 10, 2011 14:43 UTC (Thu) by paulj (subscriber, #341) [Link]

The distinction he was drawing is pretty widely understood really, embodied fairly concretely as it is by the difference between the sources distributed by Linus for the Linux kernel (upstream) and those distributed by RedHat as the sources for the kernel RPM previously (to choose one example amongst many). It's not hard to grasp really. ;)

Red Hat and the GPL

Posted Mar 10, 2011 18:48 UTC (Thu) by martinfick (subscriber, #4455) [Link]

To make this argument you'd have to be able to define upstream, which I suspect that you cannot actually do in a satisfactory way. Red Hat in many ways is acting as an upstream for their long term kernels.

Red Hat and the GPL

Posted Mar 9, 2011 23:03 UTC (Wed) by rahvin (subscriber, #16953) [Link]

One of the most dishonest parts of this entire debate is to ignore the history of the GPL and why that clause exists and then turn around and redefine it using whatever method you prefer. This is no different than people in the US redefining what the US constitution means with Today's usage while completely ignoring the debate and use when the measures were enacted.

This clause exists in the GPL to prevent some company from sending you a printed book of source code. I find it extremely dishonest to start arguing about an individual persons interpretation of this clause without consideration of that history or the reason it exists. You simply can't be willy nilly redefining intent however you like and examining this in a vacuum.

Any court of law that finds the GPL language ambiguous is going to go back and read the history of the clause and what it was intended to mean. That simple review can be conducted with a Google search that points out RMS defined this clause as trying to prevent the paper copy exploit. Any other description of this clause is disingenuous at best and this debate should have never made it past that cursory review.

Red Hat and the GPL

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

Originalism is bad exegetics in constitutional law, and it's bad exegetics here.

Red Hat and the GPL

Posted Mar 10, 2011 3:03 UTC (Thu) by ewan (subscriber, #5533) [Link]

This clause exists in the GPL to prevent some company from sending you a printed book of source code.

No, it doesn't. The GPL deals with that using the "on a medium customarily used for software interchange" language. The specification that the source be the 'preferred form for modification" is a separate requirement, and is about what does and does not count as 'source', not about the media via which it is delivered.

Red Hat and the GPL

Posted Mar 18, 2011 18:48 UTC (Fri) by mishad (guest, #69757) [Link]

Agreed.

To know for sure we'd have to ask the GPL's original authors, but my reading of it was that the term was added to ensure that the right to produce modified works could be meaningfully exercised. In particular, it was to preclude distribution of "source" that was obfuscated (e.g. variable names changed, no whitespace, no comments, replace control structures with equivalent gotos) or which was already compiled (e.g. as "binary blobs" which form part of the resulting program/work).

I don't think anyone was thinking about VCSen back then.

Red Hat and the GPL

Posted Mar 9, 2011 16:04 UTC (Wed) by Los__D (guest, #15263) [Link]

That's funny, I can export a whole list of patches to the program I'm working on, even though I have never used patches to create and modify that program; I made the changes required directly to the source, and committed those changes as they were done.

And again, it doesn't really matter how Red Hat package those changes. The modifications originally (in all probability) was done to the checked out source.

- In simple cases, someone might have opted to do the change directly to an existing patch, but that is hardly the norm.

Red Hat and the GPL

Posted Mar 9, 2011 17:22 UTC (Wed) by paulj (subscriber, #341) [Link]

If you're developing a code-base, yes, you don't need anything but the source code.

OTOH, if you're maintaining a code-base, adding patches temporarily (or not) while tracking an upstream, then it's more convenient to work with a system that allows you to easily distinguish between each change, relative to the upstream. E.g. a pristine tarball + patches, or a git tree.

I've worked on both developing an upstream code-base and maintaining a supported version of that same code-base, at a big distributor/vendor, and we used both methods, as appropriate. For the supported, released binaries - they were built from pristine+patches, and that's what got released as the source (just as RedHat used to).

Red Hat and the GPL

Posted Mar 9, 2011 14:05 UTC (Wed) by clugstj (subscriber, #4020) [Link]

I had tried to make this exact point in an earlier article. The "preferred form for making modifications" is NOT a pristine source and a large group of patches. RedHat (and anyone else) is fully within the GPL by doing what they are now doing. There is much bitching now only because they used to do something else which some people had become dependent upon.

Red Hat and the GPL

Posted Mar 9, 2011 14:59 UTC (Wed) by vonbrand (guest, #4458) [Link]

If you look at how git works, you will see that it nowhere handles patches, only blobs containing actual file contents at a point in time. So asking for patches as the "way in which Red Hat does their work" is total nonsense.

Red Hat and the GPL

Posted Mar 9, 2011 17:38 UTC (Wed) by paulj (subscriber, #341) [Link]

You're making the standard engineers mistake of considering that boundaries defined by technicalities in one field map to boundaries in the legal world. They don't. Judges are juries are often perfectly free to gloss over non-legal technicalities, and even take things like human intent into consideration.

(Another common example of such a mistake is thinking that GPL derivation status can be washed away by adding technical boundaries like shared libraries or network sockets).

Red Hat and the GPL

Posted Mar 9, 2011 20:33 UTC (Wed) by vonbrand (guest, #4458) [Link]

I'm quite aware that legal and technical worlds are apart. But that doesn't make that to distribute source "in the preferred form for modification" you have to create new artifacts (patches) that arguably aren't that useful for direct modification. Sure, said patches help in reconstructing the history and (via attached comments) the motivation for changes that have been made. But GPL looks forward (build on what you have got) not backwards (go scrounge around in the history of the code) and even less considers creating chimaeras out of applying a random subset of the changes that got the code as it is today. Perhaps that was a mistake in drafting the GPL, take that up with the appropiate people.

Red Hat and the GPL

Posted Mar 9, 2011 20:20 UTC (Wed) by vonbrand (guest, #4458) [Link]

Taking this to an extreme, my preferred form for hacking on random code is a running XEmacs with a buffer open on each file. Do I have to distribute that somehow? That in the course of working on some piece of code I use (for convenience, for speeding up compilation, or any other random reason) some particular representation does not make that automatically useful for others (some people I respect use vim ;-), and thus not necesarily "preferred". So that/if Red Hat uses/used a SRPM with broken out patches at some point is wide off the mark: They have to distribute the complete source with with to rebuild the binaries, nothing more.

Red Hat and the GPL

Posted Mar 18, 2011 18:55 UTC (Fri) by mishad (guest, #69757) [Link]

> Taking this to an extreme,

The law doesn't do that -- judges interpret contracts "reasonably" not as what they might mean if taken to extremes.

> They have to distribute the complete source with with to rebuild the binaries,

Yes.

> nothing more.

Not quite -- they also need to identify their changes:

GPL v2 $2 (a): You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change

Distributing "base + patches" is arguably one way to do that. "Base + monolithic-patch" might be another. Simply adding a note in the file header is also OK.


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