| |||||||||||||
This means that anyone distributing GPL code is in violation of the GPLThis means that anyone distributing GPL code is in violation of the GPLPosted Mar 9, 2011 17:17 UTC (Wed) by southey (subscriber, #9466)Parent article: Red Hat and the GPL The preferred form argument sounds just plain silly as if you fail to provide the source code in all conceivable ways including different encodings (such as ansci vs unicode) then you must be in violation of the GPL V2 because someone needs something different (or just is being difficult like wanting a new tablet)! You should be arguing that Red Hat is providing foremost an executable not source code because RHEL is not Gentoo or some other distro that requires you to build from source. So Red Hat is correctly meeting the part of GPL v2 section 3 is For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable (my emphasis added). This says complete code not partial code so Red Hat is now fulfilling that requirement better than just distributing original source plus patches - especially if those patches lack complete instructions on modifying the original (such as dependencies). If RHEL sources contain valid copyright statements involving Red Hat, then Red Hat must be complying with Section 2. Unfortunately the GPL V2 (or V3) only specifies date not the format or standard for representation. So just the year alone is marginally valid date, even if it really means all days in the complete year. Also you can argue that a specific day (a more common usage) is inappropriate for something that involves many days of work as it includes finding and testing final changes. Also you forgetting one critical aspect in the Trading GPL rights for support part (which I tend to agree with): If Red Hat owns the copyrights of those changes (and it does contribute a lot to the kernel) then it can distribute those patches or code under whatever terms it likes! So for those parts that Red Hat, there is no GPL violation at all. Thus, Red Hat would be in violation of any changes that it does not own and, as you point out, any GPL rights are likely removed by the support agreement (as EULAs are apparently valid).
(Log in to post comments)
This means that anyone distributing GPL code is in violation of the GPL Posted Mar 10, 2011 11:15 UTC (Thu) by paulj (subscriber, #341) [Link]
No one discussing the preferred form has argued that it means distributors must provide whatever arcane form any user wants (and by extension, provide all possible arcane forms), other than those erecting straw-men. If that's what you believe some people have seriously argued that that is what preferred form means, then you likely have gone out of your way to misunderstand them.
This means that anyone distributing GPL code is in violation of the GPL Posted Mar 10, 2011 15:18 UTC (Thu) by southey (subscriber, #9466) [Link]
That's makes no sense - just see the comments where people wanting access to an actual git repository. The floppy drive and even the pure CD-ROM drive are essentially arcane, I still have essentially unused computers with these so I should be able to ask for source code on a floppy or cd-rom as that my 'preferred form' for those computers but I need online access for day to day computers.
I am not misunderstanding, just pointing out the stupidity of that line of argument because the GPL does not go into any definition of it. So if the 'preferred form' of source is patches, then we must always get the original plus all patches. Of course that means no distributed revision control systems such as git for distribution. (Yes I know git can create and apply patches but it is more correct just to push and pull.)
This means that anyone distributing GPL code is in violation of the GPL Posted Mar 10, 2011 15:57 UTC (Thu) by paulj (subscriber, #341) [Link]
Actually, the GPL does say you should be able to get source on a "medium customarily used for software interchange", which floppies may once have satisfied. Note that your individual situation doesn't alone determine it.
However, we're discussing a different part of the GPL.
If the preferred form were original plus patches, than that's indeed what would have to be distributed, as you say. I don't see how that means git can't be used though. Indeed, a git repository made available IS a form of distribution, just as much as placing a tarball in a folder accessible via HTTP is (some people have argued a git repo is "content storage", and hence somehow different to distribution, which seems an incorrectly restrictive view) - indeed, the git repository is a much BETTER form of distribution.
Another important point. Preferences are perfectly capable of changing, particularly as technology does. Just because 10+ years ago the vast majority of developers preferred to trade big tarballs of the source, with history restricted to a ChangeLog file, does not mean that they prefer it today. As the state of the art in SCMs changed, developers/maintainers now tend to use the likes of 'git pull' rather than ftp'ing a tarball from tsx-11 or sunsite (or buying a walnut creek CD set).
Just as floppies today almost certainly no longer meet the "custom medium" requirement because of change, even though they once did, so it is perfectly possible for source form requirements to evolve from tarballs to a git repo. The habits and expectations of GPL software developers/maintainers do not have to be static.
Note Carefully: Even if that were so, that does NOT mean all GPL projects would HAVE TO all switch from tarballs to (e.g.) git repos together. It's perfectly possible for different communities and different projects to have different standards for preferred forms of sources.
The problem with what RedHat have done is that it's difficult for anyone to argue with a straight face that kernel developers prefer not to have the history *today* (that Linus once distributed only tarballs is somewhat irrelevant, when he's been distributing full history with releases for at least a decade - note that the GPL does NOT require that the format for the history be itself in a non-proprietary format).
Note Carefully 2: No one person can say what the preferred form is. It presumably depends on consensus.
This means that anyone distributing GPL code is in violation of the GPL Posted Mar 10, 2011 16:37 UTC (Thu) by branden (subscriber, #7029) [Link]
Yes. This.
The "preferred form for modification" varies in time and space.
We know what the preferred form for the Linux kernel is because major distributors like Debian and--until recently--Red Hat supplied it.
This means that anyone distributing GPL code is in violation of the GPL Posted Mar 10, 2011 17:18 UTC (Thu) by paulj (subscriber, #341) [Link]
And can vary between upstream development and vendor packagers. Preferred form can be a tarball for one, and tarball+patches for the other, in theory.
Course, wrt Linux, if *all* the kernel copyright holders don't have a problem with packagers not distributing the history of their fork, then there's not a problem.
This means that anyone distributing GPL code is in violation of the GPL Posted Mar 10, 2011 21:39 UTC (Thu) by PaXTeam (subscriber, #24616) [Link]
> If Red Hat owns the copyrights of those changes (and it does contribute
> a lot to the kernel) then it can distribute those patches or code under > whatever terms it likes!
not exactly. if their changes are considered as derived work from linux, then the GPL controls what they can do with it (namely, distribute it under the GPL). for non-derivative works it's indeed their call. for the kernel specifically it's a somewhat grey area whether one can create a non-derivative work, see all the 'are binary only modules legal' discussions of the past decade or two. based on past RHEL versions (and the RHEL6 beta which did come with patches), the majority if not all of RHEL's modifications fall under the derived work category and therefore RH can distribute them only under the GPL.
|
|||||||||||||