Slashdot Mirror
Does A Software License Cover Patches?
Sanity asks: "Recently a discussion came up in my company concerning how a modification to a piece of GPL code could be distributed without its authors being forced to place it under the GPL. It seemed to me that if I created a patch to a piece of software (which can be viewed as an algorithm which modifies some source code in a particular way) then I would have the right to put this patch under whatever license I liked. I contacted RMS about this and predictably he claimed that the patch would fall under the GPL -- yet this view implies that software licenses are much more powerful than many people instinctively might think -- and if true, has some frightening implications."
"OK, so I do require the original code to generate this patch, but (assuming the patching software I use is efficient) the patch will not contain any of the original GPL code. The thing is that if this were possible it would render the GPL largely useless. What if I created a patch manually, writing a sophisticated computer program which modified code. Would this program itself fall under the license of the code it modifies? Clearly not -- but where is the line drawn here? Surely this is a Pandora's Box of problems, and it concerns the GPL at a fundamental level."
The big question here is: "How large does a patch need to be before the patched version becomes its own program?" and there really isn't an easy answer to that. It stands to reason that if a program can be patched at the source (not binary) level, then it contains enough of the original code to still be considered a derived work. But would such a definition stand under intense scrutiny?
Frac asks: "I'm thinking about creating a Quake 3 mod. Like LAME, I intend to GPL my patch, so anyone who wants to derive a mod from mine needs to open up their source code. However, the more I think about this, the more I realize that it's not possible to GPL a patch, or license a patch that doesn't agree with the orginal source code in question. In fact, if patches can be GPL'ed, the GPL itself will be open to violation and loopholes.
If someone can creat a GPL'ed patch to a non-GPL'ed source code, why can't someone else creat a, say, artistic license patch that patches the GPL'ed patch? Although GPL virtually prohibits people from adding code that isn't GPL'ed itself, what gives LAME the right to apply GPL to the ISO Dist10 mp3 encoder source code?
I think this is an issue that someone needs to straighten out. If patches can be applied under a license, there's nothing to stop e.g. Sun from coming out with a SCSL patch for the Linux kernel."
For some extremely stange reason hacker who can understand most convoluted perl or C code can't understand simple wording of GPL and Copyright Law. For that reason these topics are rehashed again and again.
Sanity, none is forcing you to do anything. Don't you think you would be bound by honor to respect the wishes of the original author no matter what the law says? That said, you do not have to license the patch with GPL, XFree style license or any other GPL compatible license can be used. Whole work (patch+original) would still be covered by GPL.
Frac, you can simply add a clause in your program stating that it is permissible to link with QuakeIII or whatever non free code you need to use in your project. However be careful! You can't use any other GPL code by other authors in your program if you do this. If you use plain GPL, licensing terms will be nonsensical and no one will be able to satisfy them and rebistribute your program.
I mean, seriously, if there's a potential hole in the license, why doesn't the license change to plug the hole? It won't grandfather, but it will prevent this debate from being carried mercilessly into the future.
Change the GPL, effective a certain date.
According to the CONTU Final Report, which is generally interpreted by the courts as legislative history, ``the right to add features to the program that were not present at the time of rightful acquisition'' falls within the owner's rights of modification under section 117.
Note that, since it's not copyright infringement for you to apply a patch, it's also not copyright infringement for someone to give you a patch. For example, Galoob's Game Genie, which patches the software in Nintendo cartridges, does not infringe Nintendo's copyrights. ``Having paid Nintendo a fair return, the consumer may experiment with the product and create new variations of play, for personal enjoyment, without creating a derivative work.'' Galoob v. Nintendo, 780 F. Supp 1283 (N.D. Cal. 1991), affirmed, 22 U.S.P.Q.2d 1587 (9th Cir. 1992). See also Foresight v. Pfortmiller, 719 F. Supp 1006 (D. Kan. 1989).
I guess you could do a binary patch -- but I think you'd have a pretty hard time claiming that /nothing/ in the resulting binary was from the original code.
In other words, this is pretty much a mute point.
--
-- Slashdot sucks.
Assuming you could interpret the GPL so that you could release the patch under a different license, how would you distribute the resulting binary?
The original code is still GPL'ed, and that requires that you make available the sources that were used to build the binary. So anyone who wanted to distribute the program you build would *have* to be able to redistribute either your patch or the patched code. Maybe you could give the patch to people, but you'd have to tell them that they can't redistribute the binary they build unless you give permission to distribute the patch too.
My point is that even if you can distribute a non-GPL patch to GPL code (and I don't think you can), it isn't much use. Your new licensing conditions would have to say that the licensees can't redistribute, and you'd have to enforce that, or you and the licensee are both in violation of the GPL.
Sounds like you're tilting at windmills here.
--Jim
1) GPL covers DISTRIBUTION not modification. You are free to modify your own copy AT WILL
.sig: Join AMSAT
2) You are not free to distribute the MODIFIED FORM of a GPL'ed work, except under GPL.
3) The question of whether you use DIFF or PATCH to generate changes is irrelevant. A GPL'ed program may be used to generate non-GPL'ed works, like The Great American Novel (or Great Asian OS). In the case of DIFF, the 'source code' is just data, just another textfile.
4) Unlike GPL, many licenses contain language to forbid the processes (e.g. reverse engineering) required to create your own patches, or forbid unauthorized alteration. (This is a gray area. The interpretation and enforceability of such language is subject to the time, place, laws, and other details.)
5) IF you have the right to modify your own copy, you may use a program to automate the process. It can even ship on the same CD. (There is no code apartheid! GPL and non-GPL'ed source/binary often exist on the same media.)
6) A court may look askew at "mix your own" boot CD's that say "Do you agree to our license?" and then automatically install/modify in one apparent step. Then again, it may not. That's for a judge to decide. Whether something legal is 'effectively' something illegal is one of the slipperiest issues in law. Often judges allow obvious circumventions (going around a one-way street to get to the other end is allowed; while training your parrot to shoot your wife isn't)
7) "clean room" code writing *does* exist, whether you can 'imagine' it or not. Given that, the actual code that is patched into the original may owe nothing to GPL code, outside of the general art of programming. If diligent 'clean room' can be documented, even identical code can be deemed to be 'coincidence' not infringement. So don't rely on commonality of code (or your imaginings) to protect your license.
8) Most users don't care. They don't read licenses. They certainly don't base their purchase decisions on that stuff.
9) It's awfully easy for a lot of people to insist on their right to do something, and fume at others for doing it, in the same sentence. Being a hacker doesn't entitle you to drawback-free solutions. In fact, hackers need to understand the need and ubiquity of compromises. If you don't get that, I hope I never see your code, much less install it on my machine.
10) AFAIK, GPL has not been proofed in the courts. Even if it was, licenses get broken (it happens), and when they are provebly broken, the result is usually a settlement, not eternal damnation. After all, licenses exist for commercial purposes, not theological ones.
My new
If you can go to bed, knowing you did a valuable thing today, you're very lucky. If you can't... it's not bedtime
But a patch is NOT derivative! It doesn't matter one bit how dependent is upon the original. It is the equivalent of marginalia.
:-)
However, the *USE* of the patch in its intended manner will create a derivation of the original.
Like references, I think that this is something overlooked by copyright law. In my non-legal opinion, it would make sense to me to treat patches as separate and distinct works, but that the result of applying the patch would be a derivative. Thus one could have an MPL patch for a GPL program, whose result would be a GPL derivative, but one could also have a GPL patch for a MPL program that would be unusable unless the patch's author granted you a waiver to apply it
A Government Is a Body of People, Usually Notably Ungoverned
US Code, Title 17:
GPL, Section 0: GPL, Section 2:- a patch to a GPLed program is based on the program
- therefore the patch is a derivative work of the program
- the GPL requires that derivative works that are distributed be licensed under the GPL
- the patch must be GPLed if distributed
QE FUCKING DThe only reason the lawyer's answer is 'it depends' is because a lawyer is paid to take a side and 'maybe' it to death.. Then a judge decides which lawyer is closer to what side of the gray area.
You cannot imagine how mistaken this is. The lawyer answers the question posed to him, and very, very rarely is any interesting legal question clear. This derives from the very nature of law (and the limitations of language), and not from any commercial desire of the attorney.
----
I tell a joke, probably more humerous to lawyers who have lived it:
I went to law school, and being a quick study, discovered that our professors weren't at all concerned with the answers we derived -- they wanted our analysis (issue spotting). Accordingly, they didn't give a damn about the answers, it was the questions!!!
I clerked for a firm the summer after my second year, and being a quick study, discovered that clients didn't give a damn about the questions we raised, but merely wanted the answers.
And then, being a good clerk, I went to the library, only then to discover the great truth of the law: there are no answers.
-----
I stated that this question was gray not because of any passion for one result over another, and certainly not because anyone was paying me to "maybe it to death." Trust me, subject to my prior qualifications, this is a maybe.
As I understand it, the way the GPL works is that the author first copyrights their work, making it illegal for anyone else to distribute or modify it. Then the author offers a licence (the GPL) which, if the user accepts it, allows the user to distribute and modify the software under the terms of the licence.
The licence is somewhat restrictive as to what types of modification are allowed. Specifically, you may not modifiy a GPLed program *AT ALL*, unless the resultant work would be covered under the GPL.
Assuming that it would be possible to create a patch that was not derived work of GPLed code, it would still be illegal to apply the patch if the resultant work was not GPL covered.
So, creating a non-GPLed patch for GPLed code would be legal but completely useless.
-- The act of censorship is always worse than whatever is being censored. Always.
It seemed to me that if I created a patch to a piece of software (which can be viewed as an algorithm which modifies some source code in a particular way) then I would have the right to put this patch under whatever license I liked.
What hogwash. A "patch" is not "an algorithm for changing code." A patch is derived work.
Derived work comes from the fact that you had access to the original code, and you changed the original code to do something new, or to fix something that was a problem. The "patch" itself is derived work because you derived how the patch worked from examining and mulling over the existing code--that's what is ment by a "derivitive" work.
Now if you built a tool like diff or patch--that's a new algorithm. But you didn't build diff or patch, did you?
I contacted RMS about this and predictably he claimed that the patch would fall under the GPL -- yet this view implies that software licenses are much more powerful than many people instinctively might think -- and if true, has some frightening implications."
Frightening to who? Someone who wants to steal someone else's hard work and misappropriate it?
As much as I disagree with rms on a number of basic issues, on this it's pretty clear that the intellectual property behind a particular piece of code often represents months or years of work--and is a very valuable thing. The author has the right to see that his code and hard work is used in a way which is consistant with his goals--be it to give back to the community through the GPL or to make money.
To think that you "instinctively" believe that the restrictions of the GPL is counter to how you believe you should be able to rip off someone else's IP (and hard work) is to instinctively believe that there is no intrinsic value in the software you received under the GPL license. That is, it's to instinctively believe the hard work the other programmers put into this product are worthless.
Just because you get the source code does not immediately mean you get to "disrespect" the programmer who, through his good graces, allowed you to see his/her code on his/her terms.
Clearly not -- but where is the line drawn here? Surely this is a Pandora's Box of problems, and it concerns the GPL at a fundamental level."
It's only a "pandora's box" to someone who doesn't have a clear grasp of IP issues, or to someone who doesn't have any respect for the hundreds or thousands of man-hours that went into a piece of code.
If you examine someone else's code and make changes to it, the patches make a derived work. And unless you are a friggen' psychic, the patches themselves were derived by comparing the derived work you built against the original GPL'ed code, so are themselves inherently GPL'ed. (I have never seen a patch that wasn't derived by running 'diff' against the modified (GPLed) and unmodified (GPLed) code.)
A program that automatically makes changes to a program does not have to be GPLed. However, it's results against a GPLed program is GPLed. And unless your program is psychic and able to create diffs without even receiving a GPLed program as input, the patches are again GPLed as the patches were undoubtedly created by running 'diff' (or the equivalent) against the program's input (GPLed) and output (GPLed), and thus is also GPLed as well.
I think the confusion comes when some twit thinks that he has the inherent god-given right to look at anyone's source code. That ain't true. You receive permission to examine the code through the GPL license. And according to the GPL, in exchange for permission, you must keep all derived works to the original work GPLed as well.
Once you understand that, and understand as well that just because you have someone's source code doesn't mean you inherently have the right to disrespect him by doing whatever you feel like to the code (in essense, ripping off the original programmers), then perhaps you'll grasp the fact that it's intellectually dishonest to claim that your patch is not GPLed because you ran 'diff' against your (necessarly GPLed) derived work.
Again, unless you happen to be bloody psychic and are able to create a derived work of the original work without ever examining the original.
If someone can creat a GPL'ed patch to a non-GPL'ed source code, why can't someone else creat a, say, artistic license patch that patches the GPL'ed patch? Although GPL virtually prohibits people from adding code that isn't GPL'ed itself, what gives LAME the right to apply GPL to the ISO Dist10 mp3 encoder source code?
If the GPL says it can, and if the other license permits it, there is no reason why a derived work of an opensourced work cannot be "closed" into a GPL lock.
For example, if someone releases a piece of code under the BSD license, there is nothing in the BSD license that prevents you from placing the derived code under a different license, so long as you continue to give Berkeley it's due on all your printed matter. (I think Berkeley has changed their license, but I haven't looked it up lately.) That's what allows people to take BSD licensed code and close it up as a proprietary system: they're free to relicense their derivitive works any way they see fit.
The BSD license (and other, similar licenses) permit you to relicense derivitive works under any system you wish, including the GPL.
The GPL is different, however: it's designed to keep the software open by forcing all derived works to be licensed under the GPL as one of the terms of the license itself. That is, in exchange for the right to review GPLed code, you must GPL your changes as well. That's why you cannot release a patch of GPLed code under BSD.
Some people may whine about how the GPL prevents them from doing this or that. I also wouldn't trust those people to house-sit as they may steal your china and silverware.
Consider this:
/first/ for a relicensing of the codebase, and /then/ they could redistribute the patch (since then it would be for a codebse (their codebase) that had the correct license).
/force/ them to go and ask for a relicensing of the codebase to distribute a patch that was under a license differing from the original codebase.
If [distributed] patches to any source base, were by definition required to be under the same license as the source base they apply to, that would force people who wanted to "hijack" the system to actually go and negotiate with the owners/maintainers of the codebase,
For example, some company could not then take the Linux codebase, write a humongous whomping patch under a proprietary license, and then sell a proprietary, closed Linux with the patch under their closed license. They would first have to go to Linus and say "Hey, we would like to RELICENSE your codebase". If that was OK, then they could actually distribute the patch because now the patch would conform to the codebase they had relicensed. It would
There is probably leeway here in terms of compatible licensees. Probably it would be fine to distribute a patch under any official Open Source license for code bases under other official Open Source licenses.
It's 10 PM. Do you know if you're un-American?
Since you wrote your code, you can distribute your patch under any license you wish, including multiple licenses simultanously.
So if you were to write patches for the gcc, you could distribute them under any license you wished.. If you wanted to distribute them with GCC, you would have to offer to distribute them under the GPL. But you still retain copyright for your patches and you could license them as-is under any number of licenses you wished... (Say, you create a big patch to GCC that lets one super-optimize a program. You distribute those patches with GCC so you have to offer them under the terms of the GPL. BUT, if a commercial compiler vendor also wants to use them, you can license your patches and code to them TOO with whatever terms you wish. Or you can incrementally reimplement the rest of GCC until you have a functioning version that contains no GPL-licensed code in it. If you do this, then since you own the copyright for the entire program, the GPL doesn't apply. (Example: Berkely reimplementing those last pieces of BSD to get it out from under AT&T's thumb.)
So overall, the GPL is not unfair. You always posess your patch and your own code. Copyright prohibits you from distributing THEIR code with your patchs/code.... unless you you satisfy the terms of the license. (the GPL/NPL/MPL/QPL...).
This is false.. You always posess your own code. See my other posts for details..
The GPL is not a software license. By copyright law, you have no permission to distribute the origional program or any derivative/patched work. The GPL is the only thing which gives you that right. You can distribute your patches any way you see fit with whatever license. You cannot distribute a patched program unless you are allowed to.. Which means satisfying the GPL.
You can license the patch under any license you wish. IANAL
What the GPL says is that you cannot distribute the origional program unless you supply source code. Nor can you distribute modified copies of the program unless you supply source code.
So if you have a patch, you could distribute a patch under whatever license you want. Proprietary for example.. But you cannot distribute the origional program which the patch applies to unless you also license the patch under the GPL.
I could make a patch to gcc and distribute it under the terms that if you use it you must give me your firstborn son. What I cannot do is distribute the patched version of gcc.
[Minor subtle point about the GPL] Copyright law gives me no rights to distribute gcc in any case (patched or unpatched). The GPL is the only thing that gives me the right to distribute it. By satisfying the clauses from the GPL, I gain permission to distribute it. So thus the GPL is actually MORE free than standard copyright. Because if the software is under normal copyright you'd have no rights to distribute the software or any modified copies at all. This is also why its different from a shrinkwrap software license. A shrinkwrap software license covers the USE of the software, not the distribution, which is what the GPL covers. (Though the software companies would like to claim that they are the same; you have to COPY a software into memory in order to use it. Therefore the license gives you the right to COPY it into memory. Or you can look at a shrinkwrapped license as contract.) This is also why the GPL is fairly safe under copyright law.
To get back on topic... You can make a patch and distribute it under any license.. But you cannot distribute that patch with GCC as a derivative work without permission from the copyright holder, or satisfying the terms of the GPL. Because the only way you can get permission to distribute GCC is by being willing to give full source code.
Of course, a patch alone is useless without the software which it is to patch.
So my opinion is that you would be subject to the terms of the GPL if you distributed patched binaries, if you distributed the stock GCC (and source code) and a binary-patcher. Or if you put the patch (with source code, but no rights to redistribute) and GCC on the same CD.
But one could reasonably claim that ANY patched program is a derivative work of the origional, no matter by what means its patched. (As the patch is useless without the program.. And the program is a seperate work before being patched.)
Because of this reason, I'd also say that distributing your patch and a script to download GCC off of the web might be in violation of the letter of the license.
I also note that all of these restrictions apply if you distribute a patched version publically. The GPL explicitly allows you to keep modified copies in-house. (So I could patch GCC and compile propreitary software all year, sell that software, and not have to give the source to my modified version.. But I cannot distribute the modified GCC binary or source code publically without satisfying the GPL.)
This all is IANAL, but that subtle point about how the GPL applies is important. The GPL is not a shrinkwrap license, it is a license giving you more permission than copyright. You have no permission to distribute the origional software unless you satisfy the terms of the GPL, and for a patch to be useful, it must be distributed with the program itself.
Good patches need to include some of the original code to be able to apply with context.
...To me they sound like they are a dirivitive work. You get the original source and produce a work, in this case your patch, that was dirived from the original program. The patch may not contain *any* code that was from the original program but it was dirived from that GPLed source.
That's why it's called a patch - no?
and that's the crux of the matter. The very concept of patch should preclude it from being licensed in any other way than that which the program is itself licensed. Look at it from the perspective of " what is a patch?".
We are all willing to accept that a patch is a forced change in an application for the purpose of correcting software defects (ie: Bugs) or for the purpose of enhancing the functionality. This means that what a patch really does is move the program to a point that would have been the original release in the first place- had the information prompting the patch been known ahead of time.
In other words, when an application is written the developer(s) writing it obviously didn't/don't know everything and do the best job possible to make the application solid/stable and fit for it's purpose. If it was known about *insert some condition causing problems* they would have put the code in to deal with it originally beforehand and never needed a patch.
Since a patch replaces components (in some form or another) it is really a direct replacement. Thus the only conclusion is that a patch needs be released under the same license as the original application; or (if possible, which it doesn't seem to be under GPL) the entire application is relicensed under the "new" license used by the patch.
IMHO (and IANAPatentL) it would have to be large enough to work outside of the parent body.
Without the original code, the patch is meaningless: you can't run it by itself, whereas you can run the parent program. Of course there's the situation where the patch exists to repair the parent program, but I assert that that "flavor" of patches are the least likely to have any claim to their own license.
Modules/plug-ins are a different story. They are not necessary, per se, but enhance an existing program. I could see users agreeing to licensing terms for a plug-in (although I might opt out most of the time, but that's just me).
Pretty good idea, but you would need to salt the hash to ensure that one couldn't try a series of probable lines and match the hashed result with the known hashes. Moreover, you wouldn't probably need to include the line number and file name in the hash to prevent multiple occasions of the same line from confusing the patch. Perhaps this could be included as a part of the salt.
Look - so you come up with some way to
apply a patch that doesn't contain any of the
original source code. (Get's around that
particular arguement.) But - what is the
end result after a patch is applied. It is
without arguement a derivative work covered by
the original codes' license. Further - I choose
to distribute this NEW derivative work under the
original terms of the original code. We're back
to GPL'd code.
If you have some silly license that doesn't allow
the result to be distributed under GPL - no-one will apply said patch. So then the arguement becomes irrelevant!
Have you compiled your kernel today??
/* Put on Aspestos Suit */
/* Begin Gripe */
I hate to nitpick (especially on a casual discussion forum such as slashdot), but why must so many users on slashdot, such as yourself, frequently insist on using the adjective 'said' out of proper context? Granted this particular discussion has some legal orientation, but, in general, outside of legal documents and business contracts, the adjective 'said' is simply unnecessary. Worse yet, such language needlessly detracts from clarity and coherance. While I can understand typos, gramatical errors, and the like as a result of inattention and/or less than perfect education, the use of 'said' is obviously an intentional act, and I think most people should know better.
/* End Gripe */
/* Remove Aspestos Suit */
That being said, I basically agree with your statements, even though i'm far from a GPL/RMS cheerleader. If someone wants to design/build/code something, they're free to dictate its terms of use. You simply have a choice to use it or not use it. So long as that licensing/agreement/patent/copyright doesn't restrict you from indepedently developing something on your own (e.g., not conceptual patents, like the "one click" stuff), there isn't a defensible argument against it. This goes for both propietary and Open Source'ish licenses. Sure, you can bitch to the owners and try to get them to change it; baring that, create your own, make your own license, and shutup!
In other words, I'll defend GPL's right to preserve its integrity, just as I'll defend propietary products that don't want to Open Source, and I needn't agree with either specific application of it. So while "bitching" and attacking RMS's reasoning may be appropriate, forcibly breaking or weasiling around the license is not.
The better world is one where each license and school of thought is allowed to play itself out, rather than allowing either school (read: propietary or "open") to dictate to the other.
Most licenses cover derivative works, and patches are usually derivative.
License is not copyright, however, so just because your work falls under a shared license does not mean you give up copyright to it. You may be asked to share that copyright, however. (See Apache Project)
A better question would have included the topic of binary plug-ins, which are sort of special case patches. In that case, you usually keep both license and copyright exclusive to the author.
There's plenty of info about this on the web, and it varies from project to project. There is no single answer for all licenses.
--
blue
i browse at -1 because they're funnier than you are.
The truth is always far more interesting. At first, the question must be more carefully fleshed out. If put too broadly, such as, "if I distribute this patch without licensing it under GPL, could I lose a lawsuit," the answer could go either way, depending upon the particular facts, the particular patch, how it is distributed and what the end-users do with it?
At the end of the day, a mere patch to existing code is probably more likely than not going to constitute a derivative work, subject to a claim of copyright infringement for its creation or distribution unless authorized by the author. From where can that authority be found? Probably not in the GPL, which limits distribution of derivative works unless they are narrowly licensed. That frames some of the issues.
There are others. The end-user will put the entire package together in some way, thereby creating a new derivative work. Was this authorized, even if the former was not? Here, the argument is stronger for the prospective defendant, but still unclear. If it is unauthorized, then the distributor of the patch will likely be subject to a claim of contributory infringement, raising a plethora of new issues.
The long and the short of it is that the practice would be highly suspect, and subject to a host of claims, the analysis of which requires ALL the facts, ALL the code and ALL the circumstances of its distrubtion, even to begin to list the legal issues.
I don't see patches (as such) to be a loophole through which GPL can be avoided, and tend to agree with RMS on this point. (Mark this -- this is an unusual confluence). On the other hand, I could not begin to suggest that a bright line rule that "no patches are free of GPL's heredity rules" either.
My general concerns are that GPL's hereditary principles are "too much and not enough," embracing content that makes it very difficult to have open source communities built around some kinds of works (such as monolithic images, qua Smalltalk), but leaves hypertechnical tricks such as those suggested here in some cases in the gray.
But if you think more deeply about it, that's probably just fine. Those who dig around in the penumbra will never have a clear answer to their questions, and it is more often the problem of the derivative-work-maker than the original author that the DWM's rights to the derivative work are suspect. Someday it may be worth litigating, but this is not a problem in practice, at least not for the free software community at large.
So, I conclude that its in the gray, probably the dark gray, that its probably a losing argument depending on the facts.
I also conclude that the doubt created by these circumstances is adequate -- someone who wants to live on the interstices of the SPIRIT of the GPL should have at most marginal "hope" that their conduct is legal. In practice, their ability to do harm thereby is limited by risk-averse users and shunning by the community at large. Let them whine about how they are "technically" in compliance, knowing that they probably haven't a legal prayer, and let them wonder whether they are right or wrong when they have to shave themselves the following day.
Sorry, its the lawyer's answer, but it is at least the truth: it depends.
IAAL, and my take on this, without deep analysis, would be that patches perform either or both of two primary functions: 1) software maintenance and bug fixing, 2) enhancements to code functionality. Therefore from a legal perspective the patched code is not a seperate code but in copyright terms it is a derivative work and as such subject to the terms of the primary licence - GPL, community Licence, whatever, and it is that that will almost always govern the patched code, not any separate or modified licence, assuming the primary licence handles derivative works properly. This will particularly apply if the primary licence makes reference to maintenance releases. To be capable of licence on its own terms, separate from the initial code, it would have to provide separate functionality as well, and in this case it would be a derived program not a patch. If the patch amounts to a new program, there may be a clash in copyright claims if a new licence is used. The bottom line is that a patch *may* be capable of being separately licenced *if* there is no clash with the primary licence but it will not affect either the use of the pre-patched program, it *may* not be applicable to the patched program either, and it will definately apply to the patch alone but that would probablt useless in practical terms. The premise of this article is an misunderstanding of copyright law. If you believe that you can take someone elses work, change it with a few patches and re-release under a new licence, open or closed source, you are mistaken - big time. And, as for a patch licence, what use is a separate licence for a bug fix?
"OK, so I do require the original code to generate this patch, but (assuming the patching software I use is efficient) the patch will not contain any of the original GPL code.
Good patches need to include some of the original code to be able to apply with context. If you don't include the original code the patch will not be able to apply on anything but the exact same version of the program.
As for the legality of those patches. To me they sound like they are a dirivitive work. You get the original source and produce a work, in this case your patch, that was dirived from the original program. The patch may not contain *any* code that was from the original program but it was dirived from that GPLed source.
OTOH This means that if you get a GPLed program and make a new program dirived from the original source you still have to use the GPL licence even if you have completely replaced every single part of the program, right?
For this we will probably need a court case to figure it out. And the GPL hasn't been tested in court anyway AFAIK. Perhaps that mod to Quake will go to court...