| |||||||||||||
Yes, it would...Yes, it would...Posted Mar 12, 2011 10:56 UTC (Sat) by khim (subscriber, #9252)In reply to: Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution by danieldk Parent article: Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution
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".
(Log in to post comments)
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.
|
|||||||||||||