Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution [LWN.net]

Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution

Posted Mar 12, 2011 9:21 UTC (Sat) by danieldk (guest, #27876)
Parent article: Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution

> I have been a bit amazed to watch that so much debate on this has happened around the words of preferred form of the work for making modifications to it from GPLv2§3. In particularly, I can't help chuckling at the esoteric level to which many people believe they can read these words.

People do, because it is terribly vague. A programmer is not a lawyer, but unless you can afford one, a programmer has to read some licenses at some point for new software projects. As a programmer, it is an interpretation one could easily fall for. After all, if I make my software available via git and ask people to fork and issue pull requests, isn't that the preferred form of making modifications to the software?

If one would add a clarification stating "the preferred form is a git repository forking from upstream", would this violate the GPL?

(Log in to post comments)

Yes, it would...

Posted Mar 12, 2011 10:56 UTC (Sat) by khim (subscriber, #9252) [Link]

Oh, sure it violates GPL. Many FSF projects use other VCS systems. The fact that there are git mirrors are irrelevant - they are not "canonical" and can go away at any time. This means such clarification will be "an additional restriction".

Yes, it would...

Posted Mar 12, 2011 12:37 UTC (Sat) by danieldk (guest, #27876) [Link]

I am not talking about existing software, but my own software.

Yes, it would...

Posted Mar 14, 2011 12:03 UTC (Mon) by mpr22 (subscriber, #60784) [Link]

You would certainly have the right to add such a clarification to the licence you apply to your own original work. Whether a court of law would find it to be an enforceable term of the licence in $JURISDICTION is a separate question in respect of which you would be well advised to consult a copyright lawyer for advice.

Oh, and telling people what VCS they should use would make you look like a control freak.

Yes, it would...

Posted Mar 15, 2011 0:01 UTC (Tue) by rahvin (subscriber, #16953) [Link]

I believe what the poster you were replying to was asking was if you add a definition of "preferred form" does it violate the no additional restrictions clause. Although in general your reply is accurate it doesn't appear to deal with that specific situation and the OP may feel you didn't answer their question.

I'd argue that preferred form is already defined by the license although I'm sure some will disagree based on the previous threads. From the minimal amount of legalese training I've had it's apparent to me that preferred form is already defined in the license, although indirectly. Whether clarifying some additional description of preferred form violates the no additional clauses would be as you say up to the courts of whatever jurisdiction the case is brought to trial. It would take some research on precedents in the US to draw any kind of conclusion on what the ruling would be in the US district courts.

Personally I believe you have a pretty good chance of the courts accepting that additional clarification as long as the licensee is aware of the clarification at the time of license. The key to that would probably adding the definition to the license but the FSF would probably tell you to stop calling it GPL if you did so. Therein lies the major complications of such an action.

Indirectly? Hardly.

Posted Mar 16, 2011 15:26 UTC (Wed) by khim (subscriber, #9252) [Link]

From the minimal amount of legalese training I've had it's apparent to me that preferred form is already defined in the license, although indirectly.

Actually it's not defined there - and this is by design. Times are changing and "preferred form" may change too. For example some systems don't allow you to work with source using text files (lots of BASIC, Logo or Smalltalk systems are like this), some people actually code programs without text files even if they can use them (see here, for example), etc. So no, "prefferred form" is not covered by license - and this is feature, not bug.

Still to try to extend "source code" term to mean "git repository contents" is really pushing it. You'll be going not against letter of the license but against many centuries of tradition. Even if you sign the contract which transfers you rights for some artistic creation to other person it rarely (if ever) includes your notes, drafts, etc. These are usually sold separately and are covered by different license. More often then not they are not sold at all, but rather kept private forever (okay, not really forever - usually till the death of author). To claim that "program source code" is unique in this regard you'll need some exceptional justification.

Indirectly? Hardly.

Posted Mar 16, 2011 23:24 UTC (Wed) by anselm (subscriber, #2796) [Link]

Surely the »preferred form for modifications« of a software package is whatever the upstream developers prefer to work with when making changes to the software package in question, not necessarily what the downstream recipients of the GPL'ed code would prefer to have. Given the choice, a developer from, say, Taiwan would quite probably »prefer« all the comments and identifiers in the source code to be in Chinese, but that doesn't mean you need to translate all your comments and identifiers if somebody from Taiwan asks you for a copy of the source code of your GPL'ed package.

In the case of kernel sources, the »preferred form for modifications« is presumably a patched, ready-to-compile source tree. So IMHO there is nothing wrong in principle with Red Hat shipping exactly that, for GPL compliance. Having access to a Git repository that has all the individual changesets and changelog entries is certainly a nice touch but it is by no means indispensable for what the GPL requires that recipients of the code be able to do, namely rebuild the binaries from the corresponding source.

Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution

Posted Mar 12, 2011 19:59 UTC (Sat) by iabervon (subscriber, #722) [Link]

In every project I've worked on, the preferred form for making changes is actually files in a filesystem. I've also seen projects where the preferred form is a particular IDE's configuration. Unless you've got a compiler that builds object files out of git and a build process that uses multiple commits to generate the output, git is the medium of transfer, not the form of the work.

That said, you may well have a build process that generates srpms out of git repositories. If you imagine a project whose goal is to package the Linux kernel, and whose developers work to produce a git repository with an "origin" branch and a HEAD, and, in addition to this git repository, they have a build system which produces packages containing an origin tarball, a set of patches, a changelog, and scripts to apply the patches, the git repository is part of their source. On the other hand, the project need not be under the GPL just because the kernel is, any more than the kernel being under the GPL requires compilers that compile it to be under the GPL. And the GPL doesn't mean that I can insist that RMS loan me his computer to work on gcc with.

To my knowledge, there are no distro-maintenance projects that actually function like that, in part because such a project would have a hard time finding a version control system that could handle it; to my knowledge, there aren't any version control systems that handle repositories as revision contents, without getting confused and trying to handle the revision contents of the repositories as the revision contents. In order to keep them straight, metaprojects either aren't stored in revision control, or they track patch series (possibly preparing commits using a version control system applied to the project they package, which may be a common resource or may be individual and not in any way official).