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."
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...