Reasoning behind the "preferred form" language in the GPL [LWN.net]

Reasoning behind the "preferred form" language in the GPL

Posted Mar 7, 2011 5:44 UTC (Mon) by dlang (✭ supporter ✭, #313)
In reply to: Reasoning behind the "preferred form" language in the GPL by tomcatsdb
Parent article: Commitment to Open (Red Hat News)

I agree that the lack of a git tree is not an issue.

I also agree that just releasing one modified tree instead of a series of patches is not an issue

where I have an issue is with them releasing source code to some people, but only under the condition that they don't share it with anyone else. yes, the source that's available as patches to customers is available in other forms (as part of the modified tree), but the very idea of giving source code to someone and having a limitation that restricts that person from distributing the source code is at least against the spirit of the GPL, and may very well be against the letter as well

(Log in to post comments)

Reasoning behind the "preferred form" language in the GPL

Posted Mar 7, 2011 5:50 UTC (Mon) by foom (subscriber, #14868) [Link]

> I also agree that just releasing one modified tree instead of a series of patches is not an issue

Well..I think really that *is* the main issue. That's what started this whole conversation after all.

It may not be illegal or "against the spirit of the GPL" to just release the modified source rather than a git repo or set of patches, but it's not very nice. The legality or spirit-of-gplness of releasing those broken out patches to customers only is actually kind of a distraction from that main issue...

Reasoning behind the "preferred form" language in the GPL

Posted Mar 7, 2011 6:03 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]

I disagree. i don't think there is any problem with having the SRPMs not take the time to apply patches when used.

I also think that going down the road of requiring access to version control repositories that are used internally is a very bad idea.

think about the case where the source is distributed along with the binaries instead of being available for download separately. is the supplier requried to include a complete version control repository? what if that repository is using proprietary software? you could get into the situation where the source is being provided in the manner that the devlopers prefer to work with it, but the resulting files are completely useless to anyone who isn't willing to spend the money (and agree to the terms of service) of some proprietary software package. and to make things even more interesting, what if that VCS system only runs on windows?

you can't have it both ways. either the GPL does not require access to the VCS (in which case releasing one big patch, or a modified tree is not a problem), or it does (in which case the problems above can apply)

Reasoning behind the "preferred form" language in the GPL

Posted Mar 7, 2011 12:54 UTC (Mon) by foom (subscriber, #14868) [Link]

Well, I don't really believe the GPL requires it, but I still think it's quite poor for RH to do this. Just because something isn't litigable doesn't mean you have to like it.

I think it's a problem because other kernel developers are complaining about it making their life more difficult, and the reason for the change was indeed to make other people's life more difficult.

Reasoning behind the "preferred form" language in the GPL

Posted Mar 7, 2011 13:54 UTC (Mon) by tomcatsdb (guest, #73351) [Link]

I think the issues you raise are more on point here if we're going to discuss GPL things.

To be honest, I'm a bit on the fence myself here, but I think we're looking at it from the wrong angle, or at least we should consider what RH is doing with their terms. The areas of their terms of use you're mentioning here is basically "don't ape our service" language. Without it, someone could literally buy a single RHEL subscription, get the system updates, and mirror said updates for a charge to others w/o RH having any recourse against said organization.

Put another way, RH is saying that in order to continue to use their service (RHN updates + support), you can't compete with them by using their own work product. Technically, you're free to do with the code as you wish, but certain actions may result in you not having access to RH provided services in the future.

Does the GPL state that no matter what someone does with GPL based code, once a vendor ships it to an entity, the vendor is forced to continue a business relationship with the entity? Keep in mind the source for the GPL'd code is still available as SRPMS IIRC, so RH is still distributing source for anyone, including said entity, to download and compile for themselves. The entity just looses access to the value added services RH provides.

As I said, I'm a bit on the fence myself, but this is another perspective to consider,