Does A Software License Cover Patches? 202
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."
The law and Medievia MUD (Score:1)
That was a big part of the controversy over Medievia, since the author refused to credit the DikuMUD authors and accepted money in clear violation of the license. Of course, treating the Diku authors that way would have been entirely unethical even if it were legal, but that's a different issue.
Something else this example points out is that violating the license of authors who can't afford to sue you is a good way to generate publicity and success. Other than the licensing issue, there's nothing that would make Medievia stand out among the hundreds of other muds out there, yet I've seen more than 600 people logged in at once.
intellectual labor, not copying bits (Score:1)
It is not the physical act of copying characters.
If you download my GPL program, build , study, learn, modify , and then make the product of your intellectual effort available then you work must then also be GPL.
If thats not the way it is legally, it certianly is the way it should be morally.
I think that this position is most consistent with the notion that Free Software == Free Speech as well.
cliff
Re:intellectual labor, not copying bits (Score:1)
This is much different from adding some feature to an existing program and then trying some scam to get around the GPL.
But what about the resulting program? (Score:1)
I think the first question misss that even if the patch is distributed seperately a customer or client or whatever has to apply it. The resulting binary almost definetely falls under the GPL (remeber, the patch had to be applied and compiled - the sources were combined).
If, again *if* it is distributed, then the party at the receiving end is entitled to the complete source code for the resulting, GPL licensed, application since it was integrated with the patch and the program before distributing it.
-Peter
Re:Oh come on. (Score:1)
the BSD license lets you use code without redistributing source code. They have already taken all the parts of it they want
This issue is a hell of a lot simpler than that. (Score:1)
Basically a Linked program can be anything from a few bytes up to several megs. The rule of thumb is that If you require the source code to produce your patch then the patch must be GPLed too. If you can produce it simply by bending the binary then you haven't used the GPLed source code at all.
However if challenged you will be called upon to prove that. If there are any wealthy suckers on this board I have a bet for you.
Re:answer is obvious (Score:1)
the original code except the book publisher.
So if the original code is available under GPL
already - who's going to pay attention to the
patch?
Criteria for determine what is right (Score:1)
Law is law.
What is legal doesn't always mean what is right.
What is right doesn't always mean it necessarily conform strictly with legal term.
So when will it be okay to GPL something, and when will it be okay to "let go"?
It all boils down to the following criteria:
Will the enforcement be practical?
Will the enforcement be burdensome?
Will the enforcement be too far fetch?
Will the enforcement be flexible?
I am sure there are many other criteria one may have to think over in determining if something should be GPL or not.
But we must always remember - those of us who are writing codes in the open-source communities are writing the codes because WE LOVE TO SHARE WHAT WE HAVE TO THE WORLD, and not because we have to.
If someone start forcing me to do this or that, in order to conform to the "standard", then, the least I can do is to STOP CONTRIBUTING.
While some might say "so what?", for I am only an individual. There must be thousands more who will continue to write codes.
But then, I may be an individuals, the thousands of others _ARE_ individuals too. If something that causes me way too much troubles and ends up making me stop what I love to do, that very same something could have create the same sentiment to others as well - and they very well may stop contributing too.
In all due respect to RMS whomever, we are all human beings, and we can NOT thrive in an environment where EVERYTHING is either black, or white.
There must be SOME flexibility built in. That is, if someone writes a patch, or an extention to a GPLed program, that someone SHOULD have the right to determine if he wants to put his code under GPL or not.
Yes, I do understand that this may create a dangerous precedence - that Microsoft might even take this as their free ticket to produce a closed-source MS-Linux.
Even if Microsoft does that, the REAL open-source Linux will still lives on.
It is in some way comparable to the matter of censorship and freespeech.
In the arena of freespeech, there will be HATE speech. The only RIGHT way to counter the hate speeches is NOT to censor them, but to use your right of FreeSpeech in doing a point-to-point debate and to debunk their hate-speech as purely hateful trash.
Some people like to censor things that they don't like, and I am sure if there is a Microsoft-Linux, most of us will be very pissed.
But to BAN Microsoft from ever producing a closed-source MS-Linux will be the WRONG approach.
The right approach should be making the OPEN-SOURCE Linux even much better than the MS-Linux, and the heat-up competition will only mean that Linux (both open and close sourced) will getting better and better.
If someone wants to GPL his codes, we should thank him/her for his/her effort. But if someone decides that his/her code should NOT be under GPL, let the author be the final judge.
This is NOT the time to throw the whole legal books at people. The open-source movement does not have the luxury to antagonize and or scare off potential contributors. Throwing the book at them will only make them scared of the Open Source, and that is the one thing we should never do.
This is only my $0.02
There are other questions too (Score:1)
then use the ideas from that code to produce
a NON-GPL program but you were mentaly infected
by the GPL code would that program fall under GPL??
Something to think about
http://theotherside.com/dvd/ [theotherside.com]
Re:Patches are covered in license - (Score:1)
everyone go buy all of Modest Mouse's CDs. they kick ass.
--
bloo
Depends on how the patch was created (Score:1)
Re:for gods sake people, RTFM! (Score:1)
Patches USUALLY are based on the program they patch, and your perspective may be clouded by an incomplete experience with only such patches. Your logic seems sound for those cases (patches that are derived from the original), but it does not apply to cases where patches are not based on the program.
The RESULT of the patching, taken as a whole, can inherit only those rights derived from BOTH sources (the original the patch applied to, and the patch itself). For example, if the original does not grant a certain right, the patch cannot add on that right.
If the rights granted by the patch are mutually exclusive from the rights granted by the original (suppose the patch requires distribution in binary without source and the original requires distribution of source) then the result grants no rights whatsoever (null set).
GPL is safe in that a patch cannot add new rights (GPL is a license that essentialy denies a lot of rights, including denying the right to DISTRIBUTE with any rights changed). It can take some away, but that's just a deadend branch of the tree of distribution for said rights since distributing such a derived work isn't granted by GPL. However, a patch that is NOT derived from the original (and I have written such patches before) does not have to be licensed under GPL.
Therefore a patch with a license in conflict with GPL, and not derived from the original, can be distributed, and even applied, but the result most likely cannot be further distributed.
Is a patch derived from the original? (Score:1)
That has to be answered on a case by case basis. Most patches are because the usual way in the UNIX and OSS world is to edit a copy of the original, and generate the patch from a difference between original and the new work. That kind of patch is definitely derived from the original, and definitely must adhere to the rights granted by the original. GPL is clear on how derived works must be covered by the same license.
It is possible to generate a kind of patch that is not derived from the original. The singular case is a patch which deletes the entire original and replaces it with entirely new code. As long as that deletion is done in a way that has no prior knowledge of the original, then the license of the original clearly does not apply. The license of the patch would prevail.
If a patch is not derived from the original, but is written with the knowledge of the original, then this might be questionable (consider some of the reverse engineering cases). Context patches would have bits of the original so those don't fall under a non-derived patch. But would a patch that only identifies line or byte offsets, or file names, and provides replacement code, be a derived work? IMHO, the answer to that is no.
Given my previous opinion standing, if you took an original work, and a patch, and applied the patch, the rights you have in the result would be the set of rights that is in common in both sources. Since GPL gives no right to distribute with any rights other exactly the set granted by GPL, the resultant rights would be the null set unless the patch also was GPL.
Re:for gods sake people, RTFM! (Score:1)
A handwritten patch that doesn't include any context or other bits of the original is not derived from that work. It can modify it, and that result is derived from both, but this doesn't mean the patch must be derived from that work.
Re:for gods sake people, RTFM! (Score:1)
A compiler takes a work in the form of a source code program file, and produces an object code output file that can be (with maybe some other stuff added) executed in some way. The object code output is a derived work, but the compiler itself would not be considered derived from the input file just because it can do something with it, since it can also do stuff with anything else in the range of the language it compiles. Not all patch types are so simple as to have to be applied to one and only one. Indeed, a "patch" that totally deletes all the original code and inserts its own could be applied to just about any code and perform its intended function correctly. Why would this patch be any more a derived work than the compiler? At what point to you consider a patch to be a derived work? Where do you draw the line?
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
I am the GPL, thy license.. (Score:1)
I've personally been very turned off to the GPL by all this navel-gazing, and debates that make about as much sense as: how many angels can dance on the head of a pin? All this negativity about how you can't do this, or that - or what license is compatible with what other license is nuts, and very off-putting.
The fact that there's so much controversy and debate as to what the GPL does or doesn't allow kind of tells me that it's a poorly written license. Why people would be so hell-bent on cramming such an unclear and confusing piece of crap down other people's throats is beyond me.
It's sort of turned into some kind of weird religion, the stupid thing could just as well start of with: "I am the GPL, thy license..thou shalt have no other licenses before me!"
That sort of absolute, mind-warping, conform or else, everything I touch belongs to me attitide the GPL is putting out is going to be really drive people away.
Doesn't matter much (Score:1)
The only reason I can see to not distribute a patch under the same license as the original code is if you wanted people to be able to do anything with your patch itself, in which case a BSD style license on the patch might make sense. Of course if the licenses contradict each other, then you couldn't distribute the binary at all, so that isn't very useful, so in practical terms the licensce on the patch must be GPL compatible (ie allow modification, redistribution etc).
Re:Patches don't work well... (Score:1)
Which is how many? Sorry, but I think the idea that there is a particular number of lines of code that will trigger copyright laws is something you just imagined.
At the end of the day, whether something is derivative is a judgment to be made first by the people involved and if necessary by a court, either way taking into account all the facts of the case, it's not an exercise in mathematics.
Re:Patches don't work well... (Score:1)
Re:No matter what you wish, a patch is derived wor (Score:1)
There are fundamental differences between the GPL and a shrinkwrap commercial license, and they can be found in clause 5 of the GPL:
First, the GPL does not attempt to restrict your use of the program. Second, when you buy a commercial package, First Sale doctrine grants you certain rights including the right to use the program. If you download a GPL'd program, nothing automaticaly grants you the right to change it--copyright law restricts you from doing so without the permission of the author. The GPL describes the conditions under which the author grants you the rights to create and distribute derivative works. A shrinkwrap license (until UCITA passes) is an attempt by the company to convince you that by installing the software you are giving up rights which you gained when you and the software company agreed to exchange a product for money in the absence of any overriding contract at the point of sale.
These are two vastly different situations.
Re:you need libertarian software for that (Score:1)
I'm curious about your definition of "libertarian" as applied to free software licenses. I assume you intend to group (at least) the non-advertising BSD and X11 licenses as "libertarian free software" and the GPL as "non-libertarian free software." I see the distinction you want to draw--the X11 and GPL licenses have different aims, and try to protect different freedoms.
You seem to be classifying as "libertarian" only those licenses in which the author has given up his rights under modern copyright law to exclude others' use (the basis of property in general, and copyright in particular). Does your definition of libertarianism not include the right of author to control his work?
I ask, because the (modern) definitions I've seen generally do (although here's The Libertarian Case Against Intellectual Property Rights [freenation.org])
Re:intellectual labor, not copying bits (Score:1)
Interesting question but... (Score:1)
The result of this mini-poll, a resounding NO!
RMS is full of it on this one (Score:1)
See, for instance, BSD's ports.
Re:There is no hole in the GPL (related to Patches (Score:1)
The GPL covers both distribution and modification. Patching a source file is modifying it. You may not patch a GPL source file with a non-GPL patch.
Re:Patches not derivative - See Galoob v. Nintendo (Score:1)
This is a bad argument. The judge wasn't asked if the patches were derivative works, just if customers were allowed to apply the patches and create their own derivative work. I would expect that the right to apply the patch comes under the "fair-use" clauses. The right to create and distribute the patch is an entirely seperate issue.
Anyone know more about the case? All I saw from reading the WWW page was that the author took a narrowly specified decision about fair use and said it also applied to the distribution of the patch. If this is really what was said in the ruling is the crux of the question being asked today.
As I think about the problem, console games are never patched themselves, so everyone has the same version. Therefore, there is no need to include any original source in the patch, and the patch can be developed using clean room methods. Since reverse engineering is still legal (barely), Galoob gets away with the development and distribution. So, Nintendo tries to stop them by attempting to get a ruling saying that it was illegal to use, so it shouldn't be shipped.
However, Galoob's methods wouldn't work for GPL source patches, since they would include portions of the original source code, becoming derivative works, unless the patch was re-done in clean room fashion for each new release.
Jason PollockRe:Bin or source (Score:1)
--
Fourth law of programming: Anything that can go wrong wi
Re:Doesn't matter much (Score:1)
No, I think that it could apply to other scenarios, in which somebody wanted to restrict the users' freedom.
Let's consider when NeXT was developing their Objective C compiler. They based it on gcc, and wanted to make the compiler closed-source. As I understand it (and I'm not an authoritive source), Jobs tried to convince rms to allow the Objective C compiler to be closed-source. rms flatly disagreed.
Now, let's assume that he wanted to make this closed-source in order to make NeXT the superior Objective C development platform. (It was anyway, but that's irrelevant.) In this case, he wouldn't care if the NeXT owners had the source to the compiler; he just didn't want competitors to get ahold of it.
So, if this loophole were there (which is still under debate it seems), he could have distributed gcc along with this patch on the NeXT, with instructions to patch gcc and compile. Voila; he essentially ships a non-free improved gcc. IANAL, and these are my own opinions, not GNU's, RMS's, or Elvis's.
--
Fourth law of programming: Anything that can go wrong wi
Re:for gods sake people, RTFM! (Score:1)
At least thats my angle on BTK's statement.
mrbob
Re:for gods sake people, RTFM! (Score:1)
mrBoB
Re:My ass needs large patches of hot grits! (Score:1)
I don't get it.. the patch still has to be applied (Score:1)
Re:Oh come on. (Score:1)
I heard somewhere that the NT BSD stack was based on Linux (and very crappy)...until those benchmarks came along, and even Linus had to conceed.
Oh deary me.
Everything is based on something else...no doubt there are some (ex)BSD developers working at Microsoft.
Re:The end result is what counts me thinks (Score:1)
Is there anything to say that a patch must be compiled into the same object code as the main program, pre-link? If not, then one could distribute a patch as a
Re:Yes, it does... (Score:1)
Yea, that is why the calls in MS-DOS look like CP/M and Dave Cutler says that "NT is the chance to do VMS right".
Or Microsoft said "NT 3.1 will be a better Unix than Unix"
Or how Microsoft admitted that they took the Windows idea from Apple, but because Apple was sloppy with the contract to M$, they ended up loosing in court/settling out of court for the $150 million dollar payment in 1997.
Right, all that NEW technology.
Re:Patches don't work well... (Score:1)
There'll have to be some kind of a limit that eventually will be determined in court. Maybe it should be related to the function of the lines in question or something else. All code is very similiar and comparing two programs would result in rather large amount of matches. Programmers have a tendency to use similiar variable names(h,i,j,k,l, etc.. for loops) and same structures (hey, it's the programming language imposing these restrictions). Would these (even though unintentional) similiarities qualify as a violation of copyright laws?
What I had in mind originally when posting the comment were the copyright laws concerning the music industry. You can "borrow" a sequence of up to 10 seconds(or something like this, correct me if I'm wrong) without having to worry about lawsuits. Same (sometimes long) sequences of notes or chords do occur in a rather large amount of songs(they just sound better). It would only be logical that same kind of guidelines would apply to source code.
Re:Patches don't work well... (Score:1)
So suppose you make a mod to Quake. Include less code in your patch than it takes for copyright laws to be effective(or just use line numbers) and license the work using whatever license you want - as such it is not a derivative work. Distributing the patch should be allowed without a question with whatever license. You're merely distributing a way to modify something else. You're not violating the license of the original code in anyway as there is no original code involved.
Now, note that I didn't say anything about applying the patch or the end result - these should be different issues. If someone distributed the original work with the applied patch then there would be trouble. Incompatible licenses etc. would surely take someone to court but this need not be. As long as you distribute the original and the patch separately and let the end users do the patching and keep the result to themselves there shouldn't be issues.
There is one small issue that I'm aware of that could be a problem with the previous reasoning. If the original work is required in order to make the patch in the first case then should the patch be considered a derivative work. Even if the patch doesn't have anything from the original code and the original code is used more as a reference.
In my opinion no. Consider school books, for instance. Those are surely copyrighted and you are not even allowed to make copies of them but when you use the knowledge gained from them to create something it surely isn't considered a derivative work. Why should it be different for source code(essentially a cookbook for the resulting program)?
Patches - The topic (Score:1)
This makes the patch supplier a co-author of the program as well, no matter the size of the patch. If you accept patches for your GPL/LGPL program, you must get permission from everyone who provided patches in order to release the program under another license.
It may be that in court they would rule a particular patch too small and inconsequential to consider the person a co-author, but do you really want to risk that and possibly end up in court in the first place?
If you manage a GPL project that accepts patches, be sure to keep track and provide credit to all contributors. If you wish to change the license, make sure you speak to everyone who modified the code first.
Providing a program under the GPL with the intent of leeching off of the friendly help of other open source developers, with a future intent of screwing them over by making the program proprietary, is very selfish in the first place.
-- Twivel
Re:GPLed derivitive works. (Score:1)
You CAN however, distribute a patch under the GPL seperately from a program under another license. Then the end-user must patch the software before they use it. But that user cannot turn around and redistribute the consolidated(patched) code as a single package.
The GPL was very carefully designed to force code to stay GPL. That means GPL code cannot be included in non-GPL code and then redistributed.
Now, to reply to your question, for a non-GPL patch to work within the GPL, it must be compatible with the GPL. It cannot put other restrictions on the patch beyond those within the GPL.
-- Twivel
Re:There is no hole in the GPL (related to Patches (Score:1)
Say I write a program called widgets.c and release it under the GPL.
Someone else can release a widgets.c.patch and distribute it under the BSD licenses.
BUT! They must be distributed seperately. A user can download both widgets.c and widgets.c.patch, then combine them for his/her uses. But no-one can combine them and then REDISTRIBUTE them.
The GPL mostly covers distributing code, not using it.
This is important to note, because a "company" is considered by law to be the same as an indivitual (or end user). Microsoft could take Linux, modify it to their hearts desire, and use it internally without releasing their code changes. Richard Stallman has affirmed this and said it is not a concern.
-- Twivel
Re:Yes, it does... (Score:1)
Yes, it does... (Score:1)
One good thing... (Score:1)
There is one problem with GPLing a patch. To make any use of the patch the user has to take the extra step of getting the GPLed program. This *might* be anoying enough to reduce the usage of such tricks if they are found to be a legal way of getting past the GPL.
Re:for gods sake people, RTFM! (Score:1)
etc. derived works? I don't think anyone is going to steal GPL'd code until its quality improves and its coders become innovative.
Re:Moderate parent post _up_ [no text] (Score:1)
Re:Yes, it does... (Score:1)
you need libertarian software for that (Score:1)
Re:you need libertarian software for that (Score:1)
interesting question (Score:1)
the gpl app would have to be under the gpl.
but the app doing the patch wouldnt
likely have to be.
If i patch the origianl gpl code and distribute
binaries i would be required to distribute
the patched code but could keep
the patch itself to myself.
This could get really wierd...
lets say i patch a gpled app and distibute
binaries anyone that has the binaries
has a right to the source code as i compiled
it and has all the gpled rights and
responcibilities that go with it.
but i could keep the patch to myself or release
the patch under a different licence but once
its part of a gpled work its gpled.
lets say that my patch is actualy a
program in
itself it can either be ran as a seperate app
or as a patch to a gpl app.
I can release it stand alone under whatever
licence i want but the patch code put into a
gpled app is gpled.
So it seems i would have to duel licence it gpl and
other to allow it to be used to patch gpl code.
note: this might be totaly wrong but
from looking into licence issues this
is the conclusion I came too
and might get my butt
sued off if i tried it.
I've seen this before.... (Score:1)
This posting looks remarkably familiar. I'm struggling through with my slow modem connection to find the posting in a previous Slashdot discussion. I seem to recall an argument where the GPL was being enforced on a renegade trying to release binary patches to the Quake code NOT under the GPL. Help, someone with a faster connection?
Ron Gaw
Re:Patches don't work well... (Score:1)
As you said, it's never been tested in court, so it should be interesting to see how this goes over.
My opinion, since I know you all want to hear it, is that any time you do something to a program that directly affects the binaries, it becomes a part of that program, and is therefore under the same liscense as the original code. Besides, it's just common decency. After all, where would your code be without the original author's efforts?
Program with respect, decency, and regard for the original authors creative intentions. This is, after all, his/her baby.
If you are the original author, you can do whatever you like with the code, but treat mine as if it were my child. You wouldn't spank my child would you?
Re:Yes, it does... (Score:1)
Re:Yes, it does... (Score:1)
You can't tell me the average user wouldn't love to have MS and Linux functionality on the same platform for a low cost. Hardly vaporware.
Not that this will ever happen. MS has a history of embracing *new* technologies. Linux is based on technology from the dark ages of computing. Not flamebait, just a theory.
Yes, but what about Natalie? (Score:1)
I propose the GRITS (Generally Redistributable Information and Technology Software) Liscense. Despite the name, anything from actresses to boats can be released under this liscense.
This liscense clearly states that all derivatives of GRITS protected software will be released under a seperate liscense, the HOT (Honor Open Territory) liscense. The HOT liscense was divised specifically for this purpose, as a way of keeping people within the boundaries of the original liscense, while allowing them to creativly alter the opened source (hence, honoring the open territory). Hopefully, a second liscense will clear up any questions anyone has about additions/patches/mods to our hot young actresses.
We urge more developers to adopt the HOT/GRITS liscense as a way of clearing up confusion.
--
i know im gonna get moderated down for this
--
if it's questionable, it is bad for court (Score:1)
*This* is our topic: <i>we should probably modify GPL because the legality of a commercial patch is questionable</i>.
Otherwise we'd get the same discussions in court. See OpenDVD. See any court session. As long as something is questionable, the people who can pay the best lawyers have a good chance to win without being backed by any law whatsoever. Justice is nothing more than psychology. If we don't put this black on white, and that famous first GPL court test starts, and it is about patches, this might be overly dramatic.
Fill up this hole in the GPL!
It's... It's...
Idea? (Score:1)
Patches (Score:1)
A patch is always derivate, it's in its nature. Even if the patch itself contain 100% original code, what would the patch be if it wasnt for a program (derived from it)...? It wouldn't be a patch. The line is pretty clear. Anything that patches a GPLed program is a derivate work from that GPLed program and thus falls under the GPL itself. If the patch doesn't patch a GPLed program, and isn't derivate from one, then it isn't a patch anyway.
Re:Why is this being debated? (Score:1)
If there is a hole, GPL should be "fixed" to plug it. If there isn't a hole, perhaps the GPL should explicitly mention this -- i.e., to list how patches work.
Look it's very simple..... (Score:1)
I feel I need to clarify something... (Score:1)
Re:You could use hashing... (Score:1)
As for getting over multiple occasions of the same line - all these problems have isomorphic problems in the original patch, so we just have to do whatever patch does, only using hashes instead of explicit text. I'm not sure how it's solved there, but you can probably ask Larry Wall :)
A more interesting problem that has occured to me is that even the actual patch text of a line gives it explicitly - so we might actually have to use a sort of 'character-based patching' (i.e. something like "add the word 'i' after character 5") to avoid giving away anything that was in the original text.
Anyway, I think it has all become irrelevant because according to someone else's post, even this sort of patch is considered "derivative work" under the GPL. Ah well.
You could use hashing... (Score:1)
It's boils down to something like replacing "put '++i;' after 'if (p)'" to "put '++i;' after the line whose hash is 06A204EF". A proper hashing algorithm, like MD5, can give you both a very high certainty (as in, one in 2^128 or so) that you're patching the right line, but give away nothing about the original text (which could still be one of 2^infinity possibilities, any of which would be computantially impratical to find).
The interesting question is whether an MD5 of a portion of GPL code is considered itself GPL...
It's the kind of question that makes me want to just forget the whole issue and go to sleep.
It's simple. (Score:1)
If the license is not compatible with the GPL combining the works will result in an undistributable source, an undistributable binary, etc. Even placing the patch and original source in the same directory or related to eachother on an ftp site may constitute an infringement depending on the interpretation of packaging.
Of course, ianal, etc.
Simple, read the GPL and follow it's advice. (Score:2)
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.
Why is this being debated? (Score:2)
Change the GPL, effective a certain date.
Patches not derivative - See Galoob v. Nintendo (Score:2)
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).
What have you gained... (Score:2)
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.
--
How could you distribute the resulting binary? (Score:2)
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
Summary of 10 important facts (Score:2)
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
Re:Patches are covered in license - (Score:2)
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
Re: (Score:2)
Re:The lawyer's answer: "it depends" (Score:2)
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.
There is no hole in the GPL (related to Patches) (Score:2)
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.
No matter what you wish, a patch is derived work (Score:2)
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.
GPLed derivitive works. (Score:2)
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.
Proposal (Score:2)
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.
I hate to reply to my own post, but a few nits. (Score:2)
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...).
False. You are misinterpreting the GPL (Score:2)
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.
Its more subtle than that. (Score:2)
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.
Patches are extensions of the application (Score:2)
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.
A simple answer to a simple question... (Score:2)
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).
Re:You could use hashing... (Score:2)
The end result is what counts me thinks (Score:3)
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!
I hate to nitpick... (Score:3)
/* 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.
Patches are covered in license - (Score:3)
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
Re:The end result is what counts me thinks (Score:3)
Not true. For some people, the license is irrelevant. Software for these people is a means to end, not political idealogy or an interesting piece of technology.
Now, I don't think you could distribute a patch that doesn't include any original code unless it was specifically tied to one particular version. Plus, if someone edits the code at all, forget it. One added carriage return and it wouldn't work at all.
Distributing code under a different license is specifically denied, unless the license doesn't conflict with GPL in any way.
Section 7 states:
The lawyer's answer: "it depends" (Score:3)
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.
patch licences - a legal perspective (Score:4)
Patches don't work well... (Score:4)
"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...