| |||||||||||||
Reasoning behind the "preferred form" language in the GPLReasoning behind the "preferred form" language in the GPLPosted Mar 7, 2011 19:46 UTC (Mon) by vonbrand (subscriber, #4458)In reply to: Reasoning behind the "preferred form" language in the GPL by PaXTeam Parent article: Commitment to Open (Red Hat News)
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!).
(Log in to post comments)
Reasoning behind the "preferred form" language in the GPL Posted Mar 8, 2011 10:38 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]
> Clearly not, as nobody in their sane mind writes C code as a set on one-line files to be #included.
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? ;)
Reasoning behind the "preferred form" language in the GPL Posted Mar 8, 2011 15:19 UTC (Tue) by vonbrand (subscriber, #4458) [Link] 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.
Reasoning behind the "preferred form" language in the GPL Posted Mar 8, 2011 16:34 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]
> If a bunch of #included oneliners is the preferred source form for you,
> you are wellcome to distribute that way.
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.
|
|||||||||||||