| |||||||||||||
Preferred form for whom?Preferred form for whom?Posted Mar 9, 2011 11:01 UTC (Wed) by dwmw2 (subscriber, #2063)Parent article: Red Hat and the GPL
Obfuscated source code, are a bit more of a gray areabut not much. Those kinds of actions should be seen as clear attempts to circumvent the GPL requirements. But that's not at all what Red Hat is doing.Isn't it? When coupled with a clear attempt to dissuade customers who do have access to the patches from disseminating them further, how could it be interpreted differently? The lack of patches from the SRPM is not just a benign side-effect of some other change in the development process; it seems clear that it is intentional, and done in order to avoid releasing those patches to the public. The tarball that Red Hat is releasing may not be the preferred form for the Red Hat kernel developers to use, but that is not part of the requirement.Isn't it? The GPL requires that the source be distributed in the "preferred form of the work for making modifications to it". The GPL is silent on whose preference is relevant here, and what they should have to do to prove that they really prefer things the way they claim. It's not reasonable for a distributor to claim that their preferred form is precompiled assembly code, nor for a recipient to claim that they prefer the code to be distributed with full hardware documentation and the email address, phone number or ICBM co-ordinates of the hardware designer (although the latter is certainly true in many cases). I only really see one reasonable interpretation of the "preferred form" clause it has to be "the form which is agreed by consensus, among experts in the field, to be the preferred form for modifying the work". Is there any other sane interpretation? (Or, as I suppose is more to the point, is there any other interpretation which is likely to be accepted in court?)
And Red Hat's kernel engineers are a representative sample of the experts in this particular field. I think their preferences are exactly part of the requirement, aren't they? So, what is the general consensus on the preferred form for modifying a work? In the case of an "upstream" work, tarballs are certainly fine. But where the work is a fork or modification of an existing project, the situation is very different. Just go and talk to any competent open source developer about how to distribute that kind of code, and she will tell you that distributing a simple tarball of your modified version is ABSOLUTELY NOT the preferred form. Nor is it even close. I've done a lot of work on porting Linux to embedded devices where the device manufacturer has "had a go" at porting it for themselves, and has given us their attempts as a starting point. Back in the early years of this century, we regularly used to get tarball releases like that. Trust me, if you had heard the language we used as we went through these abominations, trying to work out what the hell was in there (e.g. 2.4.14 + rmk1 + np3 + random other patch sets before they even started to make their own changes), you would not be trying to make an argument that a monolithic tarball could possibly be the "preferred form of the work for making modifications to it."
(Log in to post comments)
Preferred form for whom? Posted Mar 9, 2011 11:42 UTC (Wed) by paulj (subscriber, #341) [Link]
Amen to this. Having been a software maintainer myself (including in a large corporate setting), pristine upstream base-line + patches (as fine-grained as possible) are quite obviously the preferred form for maintaining corporately supported versions of free software projects. Anything else leads to significant inefficiencies and hair-pulling.
It used to be you'd check in actual tarball + patch files into an SCM (RedHat did this - perhaps still do; Sun did this with its SFW consolidation). However, current SCMs are now so good at examining history (git particularly) you can afford to check in the patched sources.
The interesting question then is, does that affect the preferred form requirement? If the patches used to be directly a source input to your build process (and hence clearly covered by the GPL), if having access to those patches is important to be able to maintain (i.e. modify further) that code base, if then by some technicality the build process no longer works on the patches to what extent are the patches no longer preferred for the purposes of the GPL?
Preferred form for whom? Posted Mar 9, 2011 20:37 UTC (Wed) by vonbrand (subscriber, #4458) [Link] Nope, that is just the typical way forks that intend to track upstream are handled internally.
Preferred form for whom? Posted Mar 9, 2011 20:41 UTC (Wed) by dwmw2 (subscriber, #2063) [Link] Because we "typically" do things the way we don't prefer to?
Preferred form for whom? Posted Mar 9, 2011 23:12 UTC (Wed) by rahvin (subscriber, #16953) [Link]
What you prefer is not how the GPL is defined.
The definition of preferable form if not defined in the license it is defined by the creator of the licenses intent, verified through statements or writings. If that is not conclusive the court will create it's own definition.
As the creator of the GPL defined preferable form numerous times in public writings and speeches that last step will never be necessary and the GPL's author's intent is not in question. RMS has stated several dozen times that the clause you are citing was to prevent the paper source code exploit. Since Redhat is not distributing source code by printing it out, the issue is null.
Preferred form for whom? Posted Mar 10, 2011 1:30 UTC (Thu) by branden (subscriber, #7029) [Link]
You're confusing the paragraph defining source code with clause 2b), which comes two paragraphs earlier:
" b) Accompany it with a written offer, valid for at least three
The above is wholly sufficient to eliminate the paper copy loophole.
I told you originalism was bad exegetics. It promotes muddled thinking. Primarily, it encourages one to sublimate one's own views into the minds of historical personages and pretend there is no difference.
If you think the U.S. courts of law are bound, through either law or tradition, to treat RMS as an oracle, you are mistaken. They are entirely within their discretion to accept him as an expert on the intended meaning of the GNU GPL--or not--and to give his pronouncements as little or as much weight as they please.
Preferred form for whom? Posted Mar 10, 2011 3:11 UTC (Thu) by branden (subscriber, #7029) [Link]
There's a typo in the above; I quoted 3b), not 2b).
But 3a) is even more squarely on point:
" a) Accompany it with the complete corresponding machine-readable
That's what closes the source-printed-on-paper loophole. Not the "preferred form of the work for making modifications to it."
Put differently, if you're right about the "preferred form" wording being the cause of the elimination of the paper loophole, then the "medium customarily used for software interchange" language becomes redundant and therefore meaningless.
Ask an attorney (I'm not one), and they will tell you that there are standard rules of construction that courts use when interpreting legal documents that strive *not* to create redundancies or rob language of meaning.
Preferred form for whom? Posted Mar 11, 2011 1:00 UTC (Fri) by rahvin (subscriber, #16953) [Link]
Your right, I've confused the two clauses. But that doesn't change the arguement. The GPL is a software license. It's commonly handled in the US under precedents and written law that differs materially from Contract law in only a few circumstances.
Anyway, when brought before a Judge it's the plain language of the license that matters. Where that plain language is ambiguous and the parties don't agree on the intent the court is obligated to consider extrinsic evidence including the intent of both parties at the time the agreement was executed (good luck on that). It's important that both parties know each other intent or have made available their intent in some way otherwise their intent becomes ambiguous and you move to the next step. Baring that knowledge the Judge is obligated to turn to the creators of the agreement. Baring that there are many other sources of extrinsic evidence that can be examined. Baring that it's up to the Judge to try to find an equitable solution to the disagreement.
My main point all along is that RMS has defined what every single one of the clauses in the GPL are for, what they mean and what exploit of the agreement they are meant to prohibit. Baring some exchange of intent between the licensee and the licensor those statements are the highest value source the Judge is going to find explaining the intent of the GPL license. There may be other information that adds to the information available but to argue that isn't the basis for the agreement is ignoring the entire history of how the GPL came about and why it was created. RMS is directly responsible for the GPL, through his work that agreement was created and when you sign on to use that agreement, unless you state otherwise, you are agreeing to those terms and the reasons they exist.
My secondary point is that there are probably as many work flows and preferred forms of source code as there are developers. Baring any clear statements of intent from a developer what does a licensee have to rely on other than the plain language of the agreement based on RMS's definition of what the agreement means? I'll argue that there is nothing wrong with changing that meaning, but you need to write your own agreement and call it something other than the GPL because if your intent and interpretation differs from RMS, you aren't using the General Public License.
RMS has defined preferred form, that's the definition that applies baring the use of a different license.
Preferred form for whom? Posted Mar 11, 2011 9:51 UTC (Fri) by PaXTeam (subscriber, #24616) [Link]
> [...]you are agreeing to those terms and the reasons they exist.
unless those reasons are explicitly spelled out in the license, no, you can't possibly be agreeing to them. what you do agree to is what's in the license, nothing more, nothing less.
> RMS has defined preferred form, that's the definition that applies
you keep mentioning his definition/interpretation, where is it?
Preferred form for whom? Posted Mar 11, 2011 18:14 UTC (Fri) by rahvin (subscriber, #16953) [Link] unless those reasons are explicitly spelled out in the license, no, you can't possibly be agreeing to them. what you do agree to is what's in the license, nothing more, nothing less.If the licensor hasn't made his definition of preferred form (if it's different than the GPL definition) available to the licensee at the time the license is executed the extrinsic evidence available to the court will be considered. The best of that evidence is the statements by the FSF and RMS on what the GPL means and why they wrote it, after all they are essentially the legal team that crafted the license. To legally demonstrate any other interpretation you would have to prove that the licensee was aware of some alternative interpretation at the time of license AND prove that the GPL definition is ambiguous. Whatever your preference is (and most people will have different preferences) is not necessarily what the licensee interprets when he draws a license. The problem I have with this discussion is that people are pulling a single sentence out of the license and trying to reinterpret that sentence however they want without regard to the agreement or it's history. There are numerous places within the GPL where the preferred form is defined implicitly although not directly. 3. B. Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,The reference to preferred form, in my opinion, is a direct reference back to the paper copy exploit section and the binary source exploit section. Although the language could be a little clearer I don't think there is any doubt that the preferred form is machine readable source code on a medium typically used for software interchange. How that source is arranged as long as it's not obfuscated is beyond the license agreement. It would be absolutely silly to assume that whatever the licensee interprets to be their preferred form is the form the licensor has to comply with. There is absolutely no doubt that the vanilla with patches and comments method is far more useful. But the license only requires that you be provided the source code in a manner that is editable and machine readable. As far as providing quotes of RMS's speeches I have better things to do with my time. I've seen him discuss this and the methodology they went through when they created the agreement (basically trying to figure out how a naughty licensee will try to exploit the license to prevent free use of the source). I'm sure a paralegal can dig up plenty of references to RMS's and the FSF's intent when the GPL was drafted. Maybe at some point he'll weigh in on the issue but I doubt he will. If you want to pursue this line though you need to consider that there are probably more projects using the unified tarball than there are projects that are providing vanilla, patches and comments. I think RedHat's move will complicate development of the kernel. But I also believe it's a necessary move if RedHat has any intention of responding to Oracle's attempts to destroy them. And I also believe RedHat could address the concerns by giving the concerned developers access to the information that's now missing. And I believe that if they fail to address this issue it could hurt them more than it helps. But I don't believe this is a GPL violation and I think it's a dramatic situational reinterpretation of the GPL and is something that could scare a lot of companies away from GPL. Just imagine for a moment that anyone that uses the software can redefine "preferred form" however they would like and what that would do to the community.
Preferred form for whom? Posted Mar 11, 2011 22:35 UTC (Fri) by PaXTeam (subscriber, #24616) [Link]
> If the licensor hasn't made his definition of preferred form (if it's different than the GPL definition) [...]
ok, i think i see where your thinking went astray. you keep mentioning this 'GPL definition' of 'preferred form'. thing is, it does *not* exist. really, look at the GPLv2 (the license of linux) and see for yourself. what the GPL does define there is the 'source code', in terms of 'preferred form for modification'. it does *not* further elaborate on just what this 'preferred form' is. this is the entire reason for these discussions here because different people have quite different (or even contradictory) ideas about 'preferred form'.
> The reference to preferred form, in my opinion[...]
see, that's your own opinion only, noone seems to share it. and for good reason, that sentence in section 3.b does not define 'preferred form for modification'. really, if the license wanted to further elaborate on that term, it should and would have done so explicitly, like it already does for other terms where the license authors saw it necessary to be precise (whether they achieved that or not is another question but let's not digress). as to what your highlighted sentence was about see this thread somewhere else where others explained it. it's most definitely not about the 'preferred form for modification' term.
> Although the language could be a little clearer I don't think there is
the GPL does *not* contain the word 'obfuscation'. where did you pull that requirement from? and what does it mean? what is considered 'obfuscation'?
> It would be absolutely silly to assume that whatever the licensee
i've seen people argue the exact opposite view in defense of RH here, but let see, if i take your view then it's bad news for RH as their *own* 'preferred form' is clearly sending patches around among their own developers, not entire tarballs as in the RHEL6 srpm. you know, not unlike what they currently distribute in the RHEL5 kernel srpm. how do you explain that two very different forms can both be preferred at the same time?
> But the license only requires that you be provided the source code in a
somewhere above you said it must not be 'obfuscated'. now you say it does not matter as long as the 'source code' is 'editable' (another word not present in the GPL, i don't know where you're getting these from ;). what does that mean? does it have to be in ASCII? 'cos your editor may not do EBCDIC, or whatever i invent for my own 'preferred form'. what if i translate everything into some intermediary representation and do my modification on that, what am i supposed to distribute then? certainly my own tools are mine and not affected by the GPL, so what will you do with that form then? really, instead of inventing new terms not present in the GPL, you should stick to its language and acknowledge where it is ambiguous.
> As far as providing quotes of RMS's speeches I have better things to do with my time.
it's just that you seemed very confident that he had precisely explained 'preferred form'. but it's not important at all, what really matters is the copyright holders' opinion, not his.
> But I also believe it's a necessary move if RedHat has any intention of
paying customers of RH have access to the patches in question (one wonders why they exist if they're not the preferred form for modification, but let's not digress) and so does Oracle (how do you think Sun servers are certified to run RHEL?).
> Just imagine for a moment that anyone that uses the software can
i don't need to imagine anything, i just need to look at the past decades and see what people preferred and did not complain about. i'm sure you know it as well and apparently it didn't scare anyone.
Preferred form for whom? Posted Mar 9, 2011 12:56 UTC (Wed) by pbonzini (subscriber, #60935) [Link]
> The GPL requires that the source be distributed in the "preferred form of
> the work for making modifications to it". > ... > where the work is a fork or modification of an existing project, the > situation is very different.
Note that the GPL is incompatible with licenses that mandate distribution of forks as a patch or series of patches (like the gnuplot license).
Preferred form for whom? Posted Mar 9, 2011 14:57 UTC (Wed) by dwmw2 (subscriber, #2063) [Link] Note that the GPL is incompatible with licenses that mandate distribution of forks as a patch or series of patches (like the gnuplot license).No, the mere fact of requiring that modified sources be distributed in base+patch form rather than as a monolithic tarball is not what makes the gnuplot licence incompatible with the GPL. If you are shipping GPL-based code and, like the gnuplot authors, you want to insist on that behaviour, all you need to do with is add a clarifying note stating explicitly what we all know, which is that "where you distribute a modified form of the software, the preferred form for modifications is the original upstream code base, plus your patches to it." In the gnuplot case, it is other clauses which impose additional restrictions that are incompatible with the GPL. For example the requirement to distribute the patches with the binaries, while the GPL only requires you to provide sources on demand. And the requirement to provide your name and address when you ship a modified version, etc.
Preferred form for whom? Posted Mar 9, 2011 17:25 UTC (Wed) by pebolle (guest, #35204) [Link]
> And Red Hat's kernel engineers are a representative sample of the experts in this particular field. I think their preferences are exactly part of the requirement, aren't they?
Well, look at what the FSF says about Free Software [0]:
I'd say it's no coincidence the FSF only focuses on users here. It seems one of the FSF's goals is to eliminate the barriers between users and the other parties usually involved in software (ie, vendors and developers). The FSF goal is that everyone can be user, vendor and developer of the software they use (if they wish).
So if the discussion of the meaning of "preferred form" should go into this much detail - which I actually think it shouldn't - one should not focus on a very specific group, such as kernel developers, but at users in general. So then the question should be: what is the "preferred form" for, well, almost anyone using computers?
Preferred form for whom? Posted Mar 9, 2011 18:19 UTC (Wed) by dwmw2 (subscriber, #2063) [Link] So then the question should be: what is the "preferred form" for, well, almost anyone using computers?If we accept your premise that we should concentrate on users rather than developers, then the answer is simple. The preferred form of source is no source at all; it just confuses them.
Preferred form for whom? Posted Mar 9, 2011 19:05 UTC (Wed) by pebolle (guest, #35204) [Link]
> If we accept your premise that we should concentrate on users rather than developers, then the answer is simple. The preferred form of source is no source at all; it just confuses them.
No, the answer is almost any reasonable form that allows the user to (at first) "study", (later) "change", and (perhaps, eventually) "improve" the software. (These terms are from the quote I used in my previous post.) The fact that source code will likely just confuse most people using computers (at first, I'd say) is no reason to concentrate on (in this case) kernel developers when interpreting "preferred form".
Preferred form for whom? Posted Mar 9, 2011 20:08 UTC (Wed) by dwmw2 (subscriber, #2063) [Link] It's not just kernel developers. Absolutely anyone with any experience of open source software development will know that dealing with a modified version of an upstream project is painful if you just have a tarball. You absolutely need to see the changes.
|
|||||||||||||