Re: RFH: GPLv3
For that matter, I doubt the FSF would answer either. But this is simpler; the FSF publishes the releases, so anyone can compare what they got with what the FSF published, and then ask the distributor do you hold the copyright for these differences? But many companies won't even let their technical people LOOK at software until the licensing is clear, so that's often not practical. Why would you trust Microsoft, that won't even let you see the code, and won't idemnify you, but you wouldn't trust a Free Software vendor, who will let you see the code, and might even be willing to idemnify you? Seeing the code doesn't make you sure that you know what it's IP status is, unfortunately. I thought Microsoft did indemnify, but I just looked at current EULA's and they don't anymore. So that's a good quesion!
Re: RFH: GPLv3
If A obtains software from the FSF and distributes it to B, who distributes it to C who, in turn, distributes it to D, there is a license between A and the FSF, B and C, C and B, and D and C. If it were so and any of them infringes on the license, then all downstream users would have their licenses at risk. This situation would be akin to sub-licensing. But this is not how the GPL works. As I said, the purpose (and need!) for those licenses is so that you can know that what you are getting IS GPl'ed software: each is certifying to the person they gave it to that there is no other IP involved.
Re: RFH: GPLv3
[EMAIL PROTECTED] (Richard Kenner) writes: Seems simple: the COPYING file contains the conditions, and all files have the same as well. And it's all directly from the copyright holder. Except quite often it ISN'T direct from the copyright holder. E.g., a RedHat or Debian distribution. Different story, I'm interested in the direct case. Some statement that can be viewed in the context of a contractual relationship between the parties. It seems it doesn't apply in my country in this case, a contract requires conditions of contract known to both parties at the time of making the agreement. -- Krzysztof Halasa
Re: RFH: GPLv3
Laurent GUERBY wrote:
On Thu, 2007-07-12 at 17:11 +0200, Basile STARYNKEVITCH wrote:
[...] Still, I do believe that almost all my distant colleagues from
CEA http://www.cea.fr/ (notably compiling their numerical
code for e.g. nuclear, astronomical or thermodynamical numerical
computations) will find funny a version number change
from 4.2 to 4.2 only for the compiler license change. Most of them
don't care about GPLv2 vs GPLv3 for the compiler,
they just want to compile their (sadly proprietary) numerical code (in
Fortran or C++).
IMHO the only persons who really care about GPLv2 vs GPLv3 are
open-source enthusiasts (and active open-source
contributors). [...]
I hope your employer follows industry standard practice of caring *a
lot* about licensing issues for all the software they use. You're
greatly mistaken if you think only compiler hackers look at software
licences, lawyers and management have they say here (at least
in the organisations I know).
Of course CEA's lawyers do care about GPL and know it quite well (the CECILL license http://cecill.info/ which in my
limited understanding is an adaptation of GPL to french law originated at CEA INRIA CNRS).
But the developer use a compiler (perhaps GCC) to produce a binary (which might
be the object of a commercial contract).
Unless there is a new point in GPLv3 which affects (i.e. changes) the legal status of a binary produced by GCC (I
understood and hope that not, and this would be against the spirit of free software, and might perhaps even be illegal -
e.g. Microsoft don't have any rights on the documents written with Word) I don't see the point.
Most of my distant collegues probably don't even compile GCC but uses it (in a binary form) from some distribution. This
is probably the case for most GCC users.
Very few compilers (even proprietary) have strange licenses affecting the legal status of the produced binary (and I am
not sure the license of the compiler matters here). The only exceptions I heard of are some (eg prolog or lisp)
compilers with an explicit runtime license (usually per binary sold or transfered) for their runtime library.
AFAIK the only equivalent in GCC is libgcc (and perhaps libstdc++) which is not under GPL (ie has an exception clause
which covers the common case of a proprietary binary).
My point is still that most GCC users don't compile the compiler and don't seem touched by the GPLv2 - GPLv3 license
change, provided they can do whatever they (or their management) wants with the binary produced by GCC.
Of course if the GPLv3 said clearly that the user have limited rights on the binary produced by GCC that would be very
different (and GCC user base would almost vanish!).
So I still think that a version number change from 4.2.x to 4.3.y for only GPLv2 - GPLv3 license transition in the
compiler itself (not in the produced binaries) would be an annoyance.
What most GCC users care most is the legal right to use the produced binaries by the GCC compiler. It is not about the
compiler's license, provided this license is compatible with the practice of compiling proprietary software.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet | mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: RFH: GPLv3
Hi Krzysztof, I hope the COPYING or similar file will contain the licence text under which the code is distributed? Actually the plan is to create a new file - COPYING_v3 - which will contain the GPL version 3 and then change the copyright header in source files over to say version 3 (or later) and have them refer the reader to the COPYING_v3 file. Files which remain under the GPL version 2 will then not need to be changed to refer the reader to some file other than COPYING. Cheers Nick PS. I am also going to be creating a COPYING.LIB_v3 file, although I am not sure if it will be needed just yet.
Re: RFH: GPLv3
I'll start this by pointing out that (like Robert), I'm not an attorney. But both of us have been familiar with GPL and related copyright issues for well over a decade. When you post a patch to the mailing list, or apply it to a branch, you are acting as an agent of FSF. You previously assigned your rights to the patch to the FSF. (If you have not assigned your rights, then your patch will not be applied to the branch, so it doesn't matter.) The FSF decides what licenses to apply to a patch. It's not at all unclear what point the license applies: at the moment FSF has said that all patches applied after August 1 are covered by GPLv3. That seems confused. First of all, when I post a patch to a mailing list, it would seem to me that I am clearly doing so as an individual. I don't see any way at all that I could be viewed as an agent of the FSF. I might not even KNOW ABOUT the FSF, for example. As to whether a person APPLYING a patch is acting as an agent of the FSF, I'm not sure about that and I was trying to figure that out. But then I realized that it doesn't matter. Let's go through the exact steps a patch takes and try to understand what its copyright status is at that time. For simplicity, let's say I'm patching one of the few public-domain files so we can ignore the issue of the patch being a derived work for now. And let's also assume that my patch has protectable content. The instant I first write down the patch, I have created a copyrighted work with me as the copyright holder. What are the copying rights of that work? Since I haven't established any, it can't be copied. I now work on, debug, test, and refine the patch. None of those change its copyright status. Now I post it on the GCC list. I have an assigment on file that assigns my changes to GCC to the FSF. You could argue that such an assignment means that the changes were assigned to the FSF when they were first written, but I don't think that's the proper interpretation. I think the assignment gives the terms of any patch that I CHOOSE to assign to the FSF and we all understand that the act of posting such a patch indicates the making of such a choice. But whichever is the case, at the time I post the patch, its copyright is owned by the FSF. But what are the terms under which that can be copied? I haven't set them. The FSF hasn't even SEEN the patch, so it hasn't set them! You can't say there's some default that applies to posted patches because, for example, some are GPL and some are LGPL. However, the assignment agreement gives minimum terms that the FSF must follow should it later distribute it (I do not believe that posting on the list, something that *I've* done, is distribution in the sense of the assignment agreement). Let's call those terms the mini-GPL. My view is that, in the absence of any other identifiable document that would establish terms, those are the terms. Now what happens when the patch is applied? The person applying the patch (often its author) is verifying (on BEHALF of the FSF, but not necessarily as its agent) that the legal status of the patch is acceptable for the file its being applied to. Whatever the license of that file, the mini-GPL is compatible with it (the meaning of compatible is as in the GPL), so the patch can be safely applied. You might argue that as part of that application process, the person applying it is acting as an agent of the FSF and choosing a license to be used for the patch itself. I disagree. For one thing, there is no legal basis for that person to be taking such an action as the agent of the FSF. For another, there is no REASON to take such an action, so, in law, once should not have presumed that it has occurred. This means that the act of applying a patch does not change its copyright status. You have it backward: the base source doesn't determine the license status of the patch; the patch determines the license status of the source. The most restrictive license applies. Read the GPLv3. You're missing the point and making an irrelevant statement, though your statement that the most restrictive license applies is certainly correct. I was talking about the state of the patch BEFORE it's posted and well before it's applied to an official source file. The point I was trying to make is that a patch rarely is like the above: namely that it doesn't derive from any other work. More normally, you obtain a patch by modifying some file. That modification creates a derived work to which the original license applies. Let's revisit the example above. I take a file which, for the purpose of this example will be GPLv2. I modify that file to fix some bug. That file remains GPLv2 because its a derived work of a GPLv2 file and nobody has changed its license condition (I COULD HAVE changed it to GPLv3, since everybody has that right by the GPL, but I chose not to). After I get everything working, I make the patch. This time, though, the
Re: RFH: GPLv3
At the very least, the file headers are a clear representation as to what license the file is under, and IMO a reasonable person would expect to be able to rely on such a representation. Actually, this is a good point. While the FSF may declare that all patches after Aug 1 are GPLv3, unless they take affirmative action to assert the copyright and license, courts may determine that they waive rights under these. Especially if a reasonable person would expect copyright statements to be correct. I don't know if the above is true or not (it's not as clear as you think and the result could well depend on the jurisdiction), but don't see why we need to debate it since the FSF is certainly planning to take the affirmative action you refer to!
Re: RFH: GPLv3
Actually, this is a good point. While the FSF may declare that all patches after Aug 1 are GPLv3, unless they take affirmative action to assert the copyright and license, courts may determine that they waive rights under these. Especially if a reasonable person would expect copyright statements to be correct. Note that the issue, in practice, isn't what the FSF distributes but what a third party (RedHat, Apple, AdaCore, etc) distributes. In such a case, the recipient can't rely on ANY statements of copyright status in the files for ANY purpose. For all they know, there's some (e.g.) Sun-copyrighted code in there that was put there by the careless action of the third-party. What needs to happen in such a case is that the third-party warrants to the people they distribute to that the copyright and license are as they claim and indemnifies the recipient against any claim to the contrary. In order to do that, the third party has to be quite sure of what the story is!
Re: RFH: GPLv3
[EMAIL PROTECTED] (Richard Kenner) writes: The problem isn't convincing somebody it's *different*, but to convince them that there's a reason the license is what it supposedly says it is! Seems simple: the COPYING file contains the conditions, and all files have the same as well. And it's all directly from the copyright holder. Now the copyright holder says the licence is not what the COPYING file and individual files say, but rather it's a new licence which wasn't mentioned anywhere at all. It's critical to understand that copyright and license agreements in files have *no legal significance whatsoever* except *possibly* to try to establish what was in the mind of the author. What is significant then? It's likely true that if they FSF were to distribute software in the sense of mailing somebody a CD and there was no license on paper, you could *probably* indeed rely on the license within the CD as being definitive. What the difference between a CD and, for example, FTP or CVS etc? True, but irrelevant, as I said in my previous email: a patch is a derived work of the file it patches, so there's not much real meaning in talking about the license status of a patch in isolation. I don't. -- Krzysztof Halasa
Re: RFH: GPLv3
Actually, the two patches don't have different copyright or licenses, given your description. It's really not possible to un-know the original GPLv3 patch and create an identical GPLv2 from scratch. The second patch is clearly and directly derived from the first. You are assuming here that the patch ITSELF has some license that's applied to it irrespective of the file it was derived from and I don't see the legal basis for such a claim.
Re: RFH: GPLv3
Richard Kenner wrote: Actually, this is a good point. While the FSF may declare that all patches after Aug 1 are GPLv3, unless they take affirmative action to assert the copyright and license, courts may determine that they waive rights under these. Especially if a reasonable person would expect copyright statements to be correct. One of the changes in copyright law since the Berne convention is that copyright holders do NOT have to take affirmative action to assert copyright (no more need for (c) 1997 bla bla statements to establish the copyright, though they still a good idea), so I am afraid the above may represent wishful thinking on what you would LIKE the state of affairs to be. This is actually quite a general problem. Suppose you are writing a book on the second world war, and you come across an old photograph with no attribution. You can't just use it without checking to find the original source, since it could still be copyrighted. I know of at least one case where a publisher had published a old photo of this kind (used to be quite safe to do so in practice if there was no indication of copyright on the photo) in a textbook, and had to pay up when the heir of the photographer noticed it. As for waiving rights, in many European countries there are severe limitations on waiving copyright moral rights even if you want to. We investigated in France and found that it is quite difficult to actively put copyrighted artifacts into the public domain. So bottom line, don't assume anything, and cover all bases. Just so things are clear, my comment about the license statements in files not being legally required or even very relevant was NOT meant to suggest not bothering with getting them correct. I think we should definitely strive to get all copyright and license statements up to date and accurate. It may also be good to have a separate clear license statement in addition to the notices in the files.
RE: RFH: GPLv3
On 16 July 2007 14:01, Richard Kenner wrote: Actually, this is a good point. While the FSF may declare that all patches after Aug 1 are GPLv3, unless they take affirmative action to assert the copyright and license, courts may determine that they waive rights under these. Especially if a reasonable person would expect copyright statements to be correct. Note that the issue, in practice, isn't what the FSF distributes but what a third party (RedHat, Apple, AdaCore, etc) distributes. I have a question, which may be germane to some of this discussion: Who is the distributor when I download from the public svn repository on sourceware.org? The FSF or RedHat? One thing which hasn't been emphasised enough in this discussion is that the version of the GPL under which a file is licensed according to its header does not govern how *you* may receive that file, nor place any obligations on the person distributing that file to you: it places obligations on (and grants corresponding rights to) you in any *further* act of distribution. (The obligations on the person distributing it to were governed by the terms in the copy which was distributed to them; for instance, they could receive it with at your discretion GPL v2 or later in, and convert that to GPL v3 before passing it on to you; at that point, their distribution of the file is governed by the gplv2 licensing terms under which it was offered to them and that they accepted when they received the file under those terms, whereas your future distribution of that file is governed by the gpl v3 terms on which it was offered to you. There's an off-by-one 'generation effect' here when changes are made). It occurs to me that not just copyright law is relevant here. Plain old contract law comes into it too, and if it were the case that the FSF declared that a bunch of the sources were GPL v3, but did not edit the headers; and if someone downloads those files from the repository (assuming that counts as the FSF distributing it) or from the GNU ftp site (which almost certainly counts as such), a court might very well rule that the text in each header saying You may at your discretion distribute this under GPLv2 or later actually constitutes a binding offer-to-license the receipient to redistribute under those terms. (In much the same way as if you put up a leaflet dispenser saying please take one you can't then go and accuse someone of stealing if they take one, even if you had said elsewhere that nobody was allowed to take one and the sign on the dispenser was incorrect.) cheers, DaveK -- Can't think of a witty .sigline today
Re: RFH: GPLv3
Seems simple: the COPYING file contains the conditions, and all files have the same as well. And it's all directly from the copyright holder. Except quite often it ISN'T direct from the copyright holder. E.g., a RedHat or Debian distribution. It's critical to understand that copyright and license agreements in files have *no legal significance whatsoever* except *possibly* to try to establish what was in the mind of the author. What is significant then? Some statement that can be viewed in the context of a contractual relationship between the parties. It's likely true that if they FSF were to distribute software in the sense of mailing somebody a CD and there was no license on paper, you could *probably* indeed rely on the license within the CD as being definitive. What the difference between a CD and, for example, FTP or CVS etc? Passive vs. active. If I send you a CD, I'm affirmatively doing something. And it's normally because I've gotten a request for it. So there's a contractual relationship between us and the license becomes part of that contract so it's unambiguous what claim is being made. If you go out and access an FTP or CVS server that I have, I might be aware of you after the fact, but I certainly wasn't *before* the fact. It's much harder to argue that a contractual relationship exists between us (that's why when you download software from many sites, you have to explicitly check a box acknowleging the license terms, either at download or installation time, but GNU software normally doesn't do that). It's important to keep in mind that a license is not a declaration of some sort but is rather a *contract* between two parties talking about the terms that one party is laying out for the other about usage of the software and sometimes other things relevant to the sale (such as usage of data from a database obtained via the software). Although Robert and I got into an disagreement over exactly to what extent the license stands alone (and we are still continuing that discussion), the important point to keep in mind is that a license is not merely a statement of copying conditions, but a *contract* between two parties, which is normally signed (or at least acknowleged) by both parties. If X sends Y some software, Y must presume that software is copyrighted and ask X for the license under which they can copy (i.e., use) that software. Y can't simply look inside that software, find that it claims it's copyrighted by party Z (the FSF) and has a file COPYING that purports to be the license. That *isn't* the license. The license would be a contract between X and Y (not Y and Z or X and Z) saying under what terms Y may copy the software it received from X. Normally what happens is that X says something like this is free software and the license is what's in the file COPYING. Y may choose to accept this or may demand that X indemnifies it is that statement isn't true. You might say this isn't relevant is X is Z (e.g, the FSF). But it is. Let's suppose that the software in question accidentally has something that infringes the copyright of some third party, S. That third party now comes after you. Unless it's clear that there's some sort of indemnification agreement with X as part of the contract, you're in trouble.
Re: RFH: GPLv3
Richard Kenner wrote: Actually, the two patches don't have different copyright or licenses, given your description. It's really not possible to un-know the original GPLv3 patch and create an identical GPLv2 from scratch. The second patch is clearly and directly derived from the first. You are assuming here that the patch ITSELF has some license that's applied to it irrespective of the file it was derived from and I don't see the legal basis for such a claim. Your patch, once accepted by the FSF, becomes their property, and the FSF, not you, determines the license the *patch* will be covered by. They can, if they wish, decide that every patch will be covered by GPLv3. They can, if they wish, decide that some patches will be covered by GPLv3 and others by GPLv2. They can use whatever scheme that they wish to decide which license to apply to the patch, including schemes which ignore the license of the original source. One person can't develop the same identical patch, as you posit, from similar sources, and claim that they were independently derived. A derivative work is clearly covered by the same version of GPL which the original was covered by. This is why there are clean room implementations of proprietary software -- to prevent just the copyright contamination which you describe. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
RE: RFH: GPLv3
I have a question, which may be germane to some of this discussion: Who is the distributor when I download from the public svn repository on sourceware.org? The FSF or RedHat? I don't think anybody knows. For most purposes, it doesn't matter. If there were a situation where you felt the need to sue the distributor for some reason, I suspect what would happen is that you'd sue both and let the courts figure it out. One thing which hasn't been emphasised enough in this discussion is that the version of the GPL under which a file is licensed according to its header does not govern how *you* may receive that file, nor place any obligations on the person distributing that file to you: it places obligations on (and grants corresponding rights to) you in any *further* act of distribution. Correct. It occurs to me that not just copyright law is relevant here. Plain old contract law comes into it too, and if it were the case that the FSF declared that a bunch of the sources were GPL v3, but did not edit the headers; and if someone downloads those files from the repository (assuming that counts as the FSF distributing it) or from the GNU ftp site (which almost certainly counts as such), a court might very well rule that the text in each header saying You may at your discretion distribute this under GPLv2 or later actually constitutes a binding offer-to-license the receipient to redistribute under those terms. A court could well make such a ruling, but I'd guess that it would be overridden on appeal because copyright law (as Robert points out) overrides contracts. However, if you could show that the FSF did this purposely in order to obtain gain at your expense, you might have a tort claim, but that would be very hard to prove such a claim.
Re: RFH: GPLv3
You are assuming here that the patch ITSELF has some license that's applied to it irrespective of the file it was derived from and I don't see the legal basis for such a claim. Your patch, once accepted by the FSF, becomes their property, and the FSF, not you, determines the license the *patch* will be covered by. They can, if they wish, decide that every patch will be covered by GPLv3. They can, if they wish, decide that some patches will be covered by GPLv3 and others by GPLv2. They can use whatever scheme that they wish to decide which license to apply to the patch, including schemes which ignore the license of the original source. Yes, they certainly *can*. But my question is whether they *have* and if so, who has done it and when. I've seen no evidence of any assertion ever of what license applies to a *patch*. One person can't develop the same identical patch, as you posit, from similar sources, and claim that they were independently derived. A derivative work is clearly covered by the same version of GPL which the original was covered by. Yes, sure, but the independent claim can clearly be made. Suppose I write a sed script to do an edit to a file. I do not look at two files, one of which is GPLv2 and one is GPLv3, but instead run the script on both of them and run diff to get a patch. There's no question that each of the resulting patches is covered by different versions of the GPL (by your last sentence). They are clearly independent because there was no possible vehicle for contamination (I didn't look at the files). But if they end up as identical, we now have two identical patches that have difference licenses. This is why there are clean room implementations of proprietary software -- to prevent just the copyright contamination which you describe. Yes, but we're talking about *patches* here, where the underlying license derives from the file being patched, not the patch itself. There's a big difference!
Re: RFH: GPLv3
Dave Korn wrote: On 16 July 2007 14:01, Richard Kenner wrote: Actually, this is a good point. While the FSF may declare that all patches after Aug 1 are GPLv3, unless they take affirmative action to assert the copyright and license, courts may determine that they waive rights under these. Especially if a reasonable person would expect copyright statements to be correct. Note that the issue, in practice, isn't what the FSF distributes but what a third party (RedHat, Apple, AdaCore, etc) distributes. FSF determines the minimum level of the GPL license, not RedHat. I have a question, which may be germane to some of this discussion: Who is the distributor when I download from the public svn repository on sourceware.org? The FSF or RedHat? FSF. One thing which hasn't been emphasised enough in this discussion is that the version of the GPL under which a file is licensed according to its header does not govern how *you* may receive that file, nor place any obligations on the person distributing that file to you: it places obligations on (and grants corresponding rights to) you in any *further* act of distribution. The GPL does places the same requirements on distributors. (The obligations on the person distributing it to were governed by the terms in the copy which was distributed to them; for instance, they could receive it with at your discretion GPL v2 or later in, and convert that to GPL v3 before passing it on to you; at that point, their distribution of the file is governed by the gplv2 licensing terms under which it was offered to them and that they accepted when they received the file under those terms, whereas your future distribution of that file is governed by the gpl v3 terms on which it was offered to you. There's an off-by-one 'generation effect' here when changes are made). You are correct, someone can increase the level of the copyright. But it's unlikely that any distributor would do this, nor is it particularly relevant to the current discussion. The problem is the taint provisions of the GPL, such as GPLv3 Section 5(c). It occurs to me that not just copyright law is relevant here. Plain old contract law comes into it too, and if it were the case that the FSF declared that a bunch of the sources were GPL v3, but did not edit the headers; and if someone downloads those files from the repository (assuming that counts as the FSF distributing it) or from the GNU ftp site (which almost certainly counts as such), a court might very well rule that the text in each header saying You may at your discretion distribute this under GPLv2 or later actually constitutes a binding offer-to-license the receipient to redistribute under those terms. (In much the same way as if you put up a leaflet dispenser saying please take one you can't then go and accuse someone of stealing if they take one, even if you had said elsewhere that nobody was allowed to take one and the sign on the dispenser was incorrect.) There's no contract. This seems to be a common confusion, which FSF has tried to dispel. A contract requires two (or more) parties to come to an agreement. GPL is a license. The GPL is not a contract. There isn't even an implied contract. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFH: GPLv3
Richard Kenner wrote: You are assuming here that the patch ITSELF has some license that's applied to it irrespective of the file it was derived from and I don't see the legal basis for such a claim. Your patch, once accepted by the FSF, becomes their property, and the FSF, not you, determines the license the *patch* will be covered by. They can, if they wish, decide that every patch will be covered by GPLv3. They can, if they wish, decide that some patches will be covered by GPLv3 and others by GPLv2. They can use whatever scheme that they wish to decide which license to apply to the patch, including schemes which ignore the license of the original source. Yes, they certainly *can*. But my question is whether they *have* and if so, who has done it and when. I've seen no evidence of any assertion ever of what license applies to a *patch*. It is source, covered by the copyright assignment. The assignment, if I recall correctly, says that the FSF will distribute the source under license. One person can't develop the same identical patch, as you posit, from similar sources, and claim that they were independently derived. A derivative work is clearly covered by the same version of GPL which the original was covered by. Yes, sure, but the independent claim can clearly be made. Suppose I write a sed script to do an edit to a file. I do not look at two files, one of which is GPLv2 and one is GPLv3, but instead run the script on both of them and run diff to get a patch. There's no question that each of the resulting patches is covered by different versions of the GPL (by your last sentence). They are clearly independent because there was no possible vehicle for contamination (I didn't look at the files). But if they end up as identical, we now have two identical patches that have difference licenses. This is tedious. The result of a sed script is not a creative work. This is why there are clean room implementations of proprietary software -- to prevent just the copyright contamination which you describe. Yes, but we're talking about *patches* here, where the underlying license derives from the file being patched, not the patch itself. There's a big difference! I was talking about patches -- copyrightable creative works which may be assigned and licensed. You appear to be talking about something else. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFH: GPLv3
On Jul 13, 2007, Michael Eager [EMAIL PROTECTED] wrote: Alexandre Oliva wrote: On Jul 13, 2007, Robert Dewar [EMAIL PROTECTED] wrote: See, I'm not diminishing the importance of licensing issues, I'm just saying it's legally irresponsible to sit back and *not* even watch what's going on in the development of the license Everybody's been watching. The license has changed many times. No. Many have been participating. And those could influence the outcome, at least to some extent. Of course the major features of GPLv3 were non-negotiable for the FSF, and these have been clear and unchanged in principle all the way from the beginning. But a number of other significant legal issues, as well as the details on how to accomplish the needed features, were up for discussion and the participants could see how their input was taken into account. As for those who sat back, relaxed and watched, it was their choice. The invitation to participate was open to all, and those who didn't want to waste time, as you put it, back then, have set themselves up to waste time and lag behind now. There's been on-going conflict between FSF and Linux. How is that even relevant? And then, the FSF took into account the opinions from a number of major Linux developers who refused to participate in the open development process. Not when they requested the removal of major features that the FSF deemed necessary, of course. As if some external contributor would post patches to remove support for a major OS and then complain that our process isn't open because we didn't agree with the rationale for the patch and thus didn't accept the patch. There's been widely publicized conflicts about about DRM, and Novell/Microsoft, patent license and other issues. All the way from the beginning, for most of these (Novell/Microsoft came up later, for obvious reasons). That's 18 months with only one addition to the feature list. Some people are advocating that patches be under GPLv2+, to enable earlier releases with backports to remain in GPLv2. Since GPLv2 has weaker defenses for users' freedoms than GPLv3, against those who might wish to impose restrictions on these freedoms, GPLv2-compatible patches would enable backports into more weakly-defended releases. The weaker defenses stem mainly out of uncertainty as to the extent of no further restrictions. Let's tone down the high falootin' rhetoric about defending freedoms and discuss the pragmatic issues of how to manage licenses in a real world with real companies and real lawyers and real concerns. The discussion started 18 months ago, and you were welcome to participate all the way back then. Why bring up these issues only now? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RFH: GPLv3
Robert Dewar wrote: Michael Eager wrote: GPL is a license. The GPL is not a contract. There isn't even an implied contract. You really are NOT a lawyer (or at least I would presume that from what you are writing). Much of the above is just WAY off! I am not a lawyer, but there is still no contract. No parties to the supposed contract, no consideration, no meeting of the minds. It's a license. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFH: GPLv3
On Jul 13, 2007, Joel Sherrill [EMAIL PROTECTED] wrote: OTOH there are a number of non-FSF entities that have committed morally and/or legally to providing long-term support for gcc directly and/or OSes that ship with a gcc. I really believe these people need guidance from the FSF on what to do. Long-term support shouldn't be a problem; you can keep on supporting it under GPLv3. Now, if someone committed to offering support under one particular version of the GPL, even though GCC has always been released under GPLv#+, and GPLv3 has been in the radar for at least 2 years now, this may have been an unfortunate commitment. I suppose the FSF might be willing to help, even though AFAICT it's under no obligation to do so. I suggest getting in touch with [EMAIL PROTECTED] if/when you need guidance. As for permission to use a patch under GPLv2, I can't tell whether it would be easier to get permission for use under GPLv2 from the original contributor or from the FSF. I suppose it would depend on the contributor. I shall point out that I don't speak for the FSF, and I don't even speak for FSFLA in this or even in most matters. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RFH: GPLv3
Note that the issue, in practice, isn't what the FSF distributes but what a third party (RedHat, Apple, AdaCore, etc) distributes. FSF determines the minimum level of the GPL license, not RedHat. Yes, sure. However, the issue here is not what the license actually *is*, but how one is to *know* what it is. If I get something directly from the FSF, I can have *some* degree of confidence that the text in the files actually corresponds to that license. If I get it from party X, there's no way that I can know whether or not party X modified the text in the file so that it no longer reflects the proper license. One thing which hasn't been emphasised enough in this discussion is that the version of the GPL under which a file is licensed according to its header does not govern how *you* may receive that file, nor place obligations on the person distributing that file to you: it places obligations on (and grants corresponding rights to) you in any *further* act of distribution. The GPL does places the same requirements on distributors. Yes, but please re-read the above very carefully! If I obtain GPLv2 software, relicense it as GPLv3 (which I can do), and then distribute it to you, the terms of the GPL that apply to *me* is v2 (since that's the license I obtained the software with), but you must follow the terms of GPLv3 (since that's the license *you* got). A contract requires two (or more) parties to come to an agreement. Exactly. GPL is a license. The GPL is not a contract. There isn't even an implied contract. A license is a form of a contract. Look at nolo.com, a site aimed at giving legal advice to laypeople. They define license as A contract giving written permission to use Indeed a key issue in using the GPL is what establishes the legal relationship necessary to the contract.
Re: RFH: GPLv3
Alexandre Oliva wrote: The discussion started 18 months ago, and you were welcome to participate all the way back then. Why bring up these issues only now? You seem to miss the point: It isn't whether I have issues with the GPLv3; I don't, for the most part. The question is whether corporations will adopt the GPLv3 without review by their legal departments, and how long that review will take, and what the consequences of this is. My opinion, which I've said before, is that the great majority of corporations will not accept the GPLv3 without legal review and that this will take many months. The concern which I raised is not about the GPLv3. It is in the policy decisions which FSF makes about applying patches to source which was previously released under GPLv2. This is not something which the FSF disclosed in the past. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFH: GPLv3
You really are NOT a lawyer (or at least I would presume that from what you are writing). Much of the above is just WAY off! I am not a lawyer, but there is still no contract. No parties to the supposed contract, no consideration, no meeting of the minds. Yes, that's right, which is why I and others are trying to tell you that the file COPYING doesn't constitute a license (which *does* require a meeting of the minds). The actual license is often word-for-word identical, but it is provided in a context in which there *is* such a relationship between the parties. If no such relationship exists, you have no legal right to use the software. This is a VERY subtle part of the law; please don't presume you understand it unless you've studied it.
Re: RFH: GPLv3
Richard Kenner wrote: A license is a form of a contract. Look at nolo.com, a site aimed at giving legal advice to laypeople. They define license as A contract giving written permission to use A contract requires parties who come to an agreement. Further it requires consideration. Neither are present in the GPL. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFH: GPLv3
That is the point. The FSF, at this time, has said that as of August 1 all patches are GPLv3. No, they did not. As far as I know, they said all *releases* are GPLv3. You want to mix two different things and call them the same. The only part which matters is the creative changes. Wrong. A patch is a combined work, part a derived work from the file patches and part the creative change. We have to concern ourselves with the intellectual property issues of *both* of those parts.
Re: RFH: GPLv3
On Jul 13, 2007, Michael Eager [EMAIL PROTECTED] wrote: Upgrade the license of every project implied that this would be effective for future releases, not retroactive. Just to be clear, the FSF can't and won't withdraw the GPLv2, or revoke any licenses granted through earlier releases. Any software ever released under GPLv2 remains available under GPLv2, and anyone who receives such software copyrighted by the FSF receives from the FSF a license for that software, and the license is GPLv2. What's changing is that, from a certain point on, the FSF does not intend to release new software under GPLv2+, but rather under GPLv3+. There's no distinction between new major releases or old release branches in this regard: they're all new software, otherwise there'd be no real point in a new release, right? Once release branches are upgraded to GPLv3+, then patches based on it, being derived works and by the terms of the GPLv3+, must be under GPLv3+ as well. So, when you backport it to a tree that says GPLv2+, the end result is GPLv3+. No one is suggesting that any defenses be weakened. Only that source currently available under GPLv2 continue to be available under that license. This can't and won't change. Only new patches and releases can be actually affected by the license upgrade. Code ever released under GPLv2+ will remain available under GPLv2+ forever. It's just that, as soon as you combine that with code under GPLv3+, the combination becomes GPLv3+. That's why the re-release of 4.2.1 under GPLv3+ I suggested the other day is meaningless from a copyright standpoint (although IANAL), it would just be signaling intent that further releases be under that version of the license. Companies will not upgrade to GPLv3 until they have reviewed it. It was released ~2 weeks ago. It's clearly been in a state of flux for many months, up until the release date. Did you actually compare the final release with the last-call draft? Maybe you should, and then reasses the state of flux. The question is whether companies who are currently releasing source under GPLv2 will be prohibited from releasing the code under GPLv2 if they do something as innocuous as apply a publicly posted patch. If the patch is under GPLv3+ and the code base is GPLv2+, then they can release the code under GPLv3+, but not GPLv2. And if it were innocuous, why would one be applying the patch in the first place? Try a pragmatic approach, rather than a dogmatic approach. Personally, I consider the FSF's move very pragmatic as a way to spread the GPLv3 defenses as widely as possible as quickly as possible. Nobody is forced to take the license upgrade right away, but those who don't will face a growing maintenance cost, which is an economic incentive for the upgrade. Neat, isn't it? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RFH: GPLv3
A contract requires parties who come to an agreement. Further it requires consideration. Neither are present in the GPL. Of course software licenses have consideration: one party is getting to use software and the other party is giving the conditions (very roughly speaking) under which that software can be used.
Re: RFH: GPLv3
Richard Kenner wrote: You really are NOT a lawyer (or at least I would presume that from what you are writing). Much of the above is just WAY off! I am not a lawyer, but there is still no contract. No parties to the supposed contract, no consideration, no meeting of the minds. Yes, that's right, which is why I and others are trying to tell you that the file COPYING doesn't constitute a license (which *does* require a meeting of the minds). This is very tedious. A license does not require the meeting of minds. The actual license is often word-for-word identical, but it is provided in a context in which there *is* such a relationship between the parties. If no such relationship exists, you have no legal right to use the software. Despite the lack of a relationship with anyone at FSF, many people do download GPL software an use it, in accord with the license. They have a legal right to use the software. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFH: GPLv3
On Jul 13, 2007, Geoffrey Keating [EMAIL PROTECTED] wrote: If there's a situation where 'silent' license upgrades can occur, where even just one file in a release might be GPLv3, or any other situation where the license is not clear, then to me that software is unusable. This applies to subversion as well to releases in tarballs. I'm pretty sure the FSF has no intention of misguiding people into accidentally distributing software under a license they don't mean to. The license of each and every release ought to be clearly marked, and it's our duty as GCC maintainers to ensure that this holds true for all GCC releases. However, it is also your duty as an employee of the company you work for to keep its code base in alignment with the legal policies of the company. This means, among other things, not integrating patches under licenses that the company hasn't accepted. So, when there's doubt as to which license applies to a patch, you'd better figure that out before integrating the patch. And, in the mean time, work with the legal department to reduce the overhead this is going to create for you, by adding GPLv3 to the set of licenses approved for your employer's version of GCC. As far as surprises go, I would point out that the new C++ front-end was not a surprise to anyone following GCC development, but that doesn't mean that everyone was ready to use it on their code the day that 4.0.0 was released. In fact I think not everyone is ready to use it even today, two years after the release, and that's the kind of timescale to be thinking about when considering GPLv3 adoption. And what do these people do? They stick to old releases that didn't have these features. And this often means being unable to backport changes and fixes, because they depend on these new features. There's really no difference in this case, except that in one case it's a technical matter while in the other it's a legal matter. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RFH: GPLv3
Richard Kenner wrote: A contract requires parties who come to an agreement. Further it requires consideration. Neither are present in the GPL. Of course software licenses have consideration: one party is getting to use software and the other party is giving the conditions (very roughly speaking) under which that software can be used. No, no, no. A consideration is an exchange of value. It's part of a contract. A license is not a contract. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFH: GPLv3
Folks, could you please take this insanely long thread out of the list? It has stopped being on-topic for a long while now. Thanks.
Re: RFH: GPLv3
Folks, could you please take this insanely long thread out of the list? It has stopped being on-topic for a long while now. Actually, it has turned up one question that I think we do need the answer to. What, precisely does the FSF want done by July 31? There are releases SVN files, and patches that have license implications. As I understand it, the FSF has said All releases after July 31 need to be GPLv3. Please make sure that the status of all files and patches are consistent with that goal. Has it said anything else about those files explicitly?
Re: RFH: GPLv3
[EMAIL PROTECTED] (Richard Kenner) writes: Despite the lack of a relationship with anyone at FSF, many people do download GPL software an use it, in accord with the license. They have a legal right to use the software. A license is not between the user of the software and the FSF, but between the user and who he got it from. My TiVo contains FSF-copyrighted software and I got a license to use it from TiVo, not the FSF. This is important to understand! If A obtains software from the FSF and distributes it to B, who distributes it to C who, in turn, distributes it to D, there is a license between A and the FSF, B and C, C and B, and D and C. There is *not* normally a license between D and the FSF. None of this is typically important to the end user, but that is the legal structure. From GPLv2, similar wording in GPLv3, emphasis added by me: 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license *from the original licensor* to copy, distribute or modify the Program subject to these terms and conditions.
Re: RFH: GPLv3
On Jul 15, 2007, Brooks Moses [EMAIL PROTECTED] wrote: Thus, I think there's a reasonable argument to be made that distributing a GCC with some file headers saying GPLv2 or later and some saying GPLv3 or later is violating the license. Why would it be? They're evidently compatible, since you can release them all under GPLv3+. Similarly, it's never been a copyright violation that we ship say libiberty/bsearch.c under the modified BSD license along with a whole lot of GPLv2+ code. Thus, I think it's reasonably critical that _all_ file headers be updated, quickly, to match the state of intended license for the files that include them. This is nice for informative purposes, but unless there are changes in them that are GPLv3+ only while the file still says GPLv2+, the change is likely irrelevant. FWIW, IANAL. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RFH: GPLv3
Richard Kenner wrote: This is very tedious. Indeed it is. I'm going to respond to this and your next message simultaneously and then refer you to a text on contract law. A license does not require the meeting of minds. Yes, it does, since it's a contract. But a meeting of minds is just a fancy way of saying that all the parties agree to its terms. And they clearly do. There's no interaction. There's no evidence of any communication, let alone any evidence of an agreement. You cannot even identify the parties. Of course software licenses have consideration: one party is getting to use software and the other party is giving the conditions (very roughly speaking) under which that software can be used. No, no, no. A consideration is an exchange of value. It's part of a contract. A license is not a contract. A license is a contract. Consideration is an exchange of *things* of value. The thing need not neccessary be tangible. For example a contract between two companies who each agree to link to the other on their website has consideration even though nothing of tangible value changes hnds: the link is of value to the receiving company and in exchange for receiving that value, it provides the reciprocal value. I've said above what the consideration for a software license is. There's no exchange of value. A license (such as the GPL) grants a permission for someone to do something under specified conditions. It's unilateral -- the receiving party is anonymous. Agreement to abide by the conditions of the license is (a) not a meeting of the minds, it's a condition of the license, and (b) it's not a valuable consideration, again it is a condition of the license. I'm done with this discussion. It's not going anywhere. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFH: GPLv3
From GPLv2, similar wording in GPLv3, emphasis added by me: 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license *from the original licensor* to copy, distribute or modify the Program subject to these terms and conditions. Sorry I never noticed that and I stand corrected on that part. However, as a practical matter, you can't know that that provision applies unless you FIRST have a license with the person who distributed the software to you and that's the main point here.
Re: RFH: GPLv3
On Jul 16, 2007, [EMAIL PROTECTED] (Richard Kenner) wrote: A contract requires parties who come to an agreement. Further it requires consideration. Neither are present in the GPL. Of course software licenses have consideration: one party is getting to use software and the other party is giving the conditions (very roughly speaking) under which that software can be used. This doesn't appear to be enough consideration to establish a contract. http://www.gnu.org/philosophy/enforcing-gpl.html by Eben Moglen, FSF legal counsel Licenses are not contracts: the work's user is obliged to remain within the bounds of the license not because she voluntarily promised, but because she doesn't have any right to act at all except as the license permits. http://papers.ssrn.com/sol3/papers.cfm?abstract_id=936403 SAPNA KUMAR, Duke University - School of Law Attorneys have attempted to construe the GPL as a contract. If the contract model worked, it would provide the most protection to agreements made under the GPL. But there is no way to interpret the license such that the consideration requirement is met. Though the GPL is not a contract, it is enforceable. The Copyright Act does not require the formation of a contract in order for an author to enforce her rights against a copyright infringer. Likewise, a licensee is protected if the licensor breaches and the licensee relied on the license to her detriment. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RFH: GPLv3
On Jul 16, 2007, [EMAIL PROTECTED] (Richard Kenner) wrote: the issue here is not what the license actually *is*, but how one is to *know* what it is. I guess if you have any doubts as to the license the distributor wants you to believe to be applicable, you can (i) ask the copyright holder, You can't ask the copyright holder because you need the representation of the distributor as to who the copyright holder actually is! This is a key point. If you give me a file that purports to be a modified version of GCC, how do I know who else, if anybody, might have a copyright claim on that version? That's why I need a license agreement with you: to know exactly what the terms of use of the software are. If you warrant to me that software is copyrighted by the FSF under the terms of GPLv2 and I rely on that claim, it turns out to be false, and I get harmed (e.g., sued for copyright or patent infringement), I can come after you for damages.
RE: RFH: GPLv3
On 16 July 2007 18:51, Michael Eager wrote: I'm done with this discussion. It's not going anywhere. That would have been just a tad more impressive if it wasn't at the end of a long stretch of self-justification. As it was, it comes across more like trying to have the last word and then shut out everyone else's point-of-view than it does like graceful compliance with a polite topicality request. I too have further opinions on the matter, but Diego asked nicely if we would drop it, and I will. Without expecting to get to have the last word. cheers, DaveK -- Can't think of a witty .sigline today
Re: RFH: GPLv3
On Jul 14, 2007, Michael Eager [EMAIL PROTECTED] wrote: Krzysztof Halasa wrote: Michael Eager [EMAIL PROTECTED] writes: Unfortunately, as I understand it, this is not the case. If you apply a GPLv3 patch to a previously GPLv2 branch after August 1, then this entire branch, and all files in it, magically and silently becomes GPLv3. (This is unless FSF agrees with Mark's proposal to dual license patches.) I hope the COPYING or similar file will contain the licence text under which the code is distributed? Not until someone updates the txt. Which should happen quickly, but if someone applies a GPLv3 patch to a previously GPLv2 branch, the entire branch becomes GPLv3, whether the COPYING file was updated or not. And distributing a program (be it a file or a huge collection of files) under GPLv3 without a copy of GPLv3 would amount to copyright infringement, should the distribution be performed by anyone but the copyright holder. IANAL. 4. [...] provided that you [...] give all recipients a copy of this License along with the Program. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RFH: GPLv3
Dave Korn wrote: On 16 July 2007 18:51, Michael Eager wrote: I'm done with this discussion. It's not going anywhere. That would have been just a tad more impressive if it wasn't at the end of a long stretch of self-justification. As it was, it comes across more like trying to have the last word and then shut out everyone else's point-of-view than it does like graceful compliance with a polite topicality request. Sorry you interpret this as self-justification. There was none. I too have further opinions on the matter, but Diego asked nicely if we would drop it, and I will. Without expecting to get to have the last word. I had stopped responding, but kept receiving email with CC'ed to the list. Again, I'm done with this. Feel free to have whatever last words you wish. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFH: GPLv3
On Jul 13, 2007, Marcus Meissner [EMAIL PROTECTED] wrote: GPLv3+ code is however incompatible to GPLv2+ code, so it warrants a major version bump. Not quite. GPLv2 code is incompatible with GPLv3, and vice-versa, but GPLv2+ is compatible with GPLv3+ and vice-versa, the result of the combination being GPLv3+. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RFH: GPLv3
On Jul 16, 2007, [EMAIL PROTECTED] (Richard Kenner) wrote: Let's revisit the example above. I take a file which, for the purpose of this example will be GPLv2. I modify that file to fix some bug. That file remains GPLv2 because its a derived work of a GPLv2 file and nobody has changed its license condition (I COULD HAVE changed it to GPLv3, since everybody has that right by the GPL, but I chose not to). After I get everything working, I make the patch. And since the FSF released the file it is based on under GPLv2+, if you release your patch, presumably a copyrightable derived work, it must be released under GPLv2 or, at your option, any later version. But it WAS independently developed! Let's suppose the purpose of the patch was to change all occurences of function1 to function2. That patch has no protectable content, so the question of what license the PATCH ITSELF has is irrelevant. If the patch is not a copyrightable work, discussing its copyright license is like asking how much wood would a woodchuck chuck if a woodchuck would chuck wood? :-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RFH: GPLv3
On Jul 16, 2007, Michael Eager [EMAIL PROTECTED] wrote: The question is whether corporations will adopt the GPLv3 without review by their legal departments, and how long that review will take, and what the consequences of this is. I don't dispute that. What I'm saying is that those most concerned should have got involved in the process to become acquainted of the license early and not take a hit at the time of the widely-forecasted license upgrade. No matter how long we were to delay the relicensing on how many branches, there'd still be those who'd sit back, wait until the relicensing was around their corner and start complaining we need more time then. IOW, how many times do you want us to have a discussion like this? My opinion, which I've said before, is that the great majority of corporations will not accept the GPLv3 without legal review and that this will take many months. They shall balance that delay with their engineering needs, and if they find a need to blame someone for the delayed adoption, it should be on whoever made the decision to wait until the last minute before starting the license review. The concern which I raised is not about the GPLv3. It is in the policy decisions which FSF makes about applying patches to source which was previously released under GPLv2. This is not something which the FSF disclosed in the past. Erhm... To me it's pretty clear that, once a code base is upgraded to GPLv3+, patches applied to it become available under GPLv3+. If they are or become available under other licenses, they can still be used under these other licenses. Surely you wouldn't expect the FSF to enable anyone to merge anything back into a GPLv2 code base just because the code base was released under GPLv2+, right? This would amount to releasing everything under GPLv2+, giving up the stronger defenses the FSF wants to be able to use for new code. Now, given that earlier code is already available under licenses that don't have these defenses, people can still use that code, as long as they don't use it along with code under GPLv3+, that does enjoy the stronger defenses. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RFH: GPLv3
On Mon, 2007-07-16 at 08:42 +0200, Basile STARYNKEVITCH wrote: Laurent GUERBY wrote: I hope your employer follows industry standard practice of caring *a lot* about licensing issues for all the software they use. You're greatly mistaken if you think only compiler hackers look at software licences, lawyers and management have they say here (at least in the organisations I know). Of course CEA's lawyers do care about GPL and know it quite well (the CECILL license http://cecill.info/ which in my limited understanding is an adaptation of GPL to french law originated at CEA INRIA CNRS). [...] Very few compilers (even proprietary) have strange licenses affecting the legal status of the produced binary (and I am not sure the license of the compiler matters here). The only exceptions I heard of are some (eg prolog or lisp) compilers with an explicit runtime license (usually per binary sold or transfered) for their runtime library. [...] I guess you've not often been involved with proprietary compiler EULA analysis, to quote one widely used (if not the most widely used) proprietary compiler user deployment guide: http://msdn2.microsoft.com/EN-US/library/aa985617(VS.80).aspx Note: Redistributing debug VC++ programs is not permitted by the EULA. You can only do this for testing purposes internally. See the EULA for Visual Studio 2005. And internal can be quite complex to define wrt copyright law in some corporate setups. A clear message from the FSF on the importance of the licensing change through versions numbers will make the life of lots of GCC users in the corporate world much simpler. Laurent
Re: RFH: GPLv3
On Jul 16, 2007, [EMAIL PROTECTED] (Richard Kenner) wrote: On Jul 16, 2007, [EMAIL PROTECTED] (Richard Kenner) wrote: the issue here is not what the license actually *is*, but how one is to *know* what it is. I guess if you have any doubts as to the license the distributor wants you to believe to be applicable, you can (i) ask the copyright holder, You can't ask the copyright holder because you need the representation of the distributor as to who the copyright holder actually is! This is a key point. You look for copyright notices, ask the holders whether they own all of that, ask the distributor who owns any other bits. If they don't know or won't tell, they're up for contributory infringement, and if you can show you got their word and took their word, you might very well be able to transfer all the liability to them. Not that you might keep on distributing the code that some copyright holder didn't authorize; you might have to collect damages from the unlawful distributor for this. If you give me a file that purports to be a modified version of GCC, how do I know who else, if anybody, might have a copyright claim on that version? When you receive a copy of Microsoft Windows from a reseller on a street corner, how do you know who else, if anybody, might have a copyright claim on it? That's why I need a license agreement with you: If the redistributor doesn't have any copyright claims on the file, you can ask for a contract, an agreement, a warranty promise, whatever you ask for and they agree to give you, but it's not going to be a copyright license. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RFH: GPLv3
You look for copyright notices, ask the holders whether they own all of that, ask the distributor who owns any other bits. If they don't know or won't tell, they're up for contributory infringement, No, they're not because you have no contractual relationship with them. Back when NYU was distributing public versions of GNAT, if somebody was to ask AdaCore are the file in there that say they have your copyright really yours, AdaCore would most certainly decline to answer and say we have no idea what NYU is distributing: yes, they got it from us originally, but we have no idea if they modified it. Why should they say more? What's in it for them? Same thing if you went and asked FSU about the files that have their copyright. For that matter, I doubt the FSF would answer either. If some large defense contractor got a copy of GCC from a subcontractor and wanted to verify with the FSF that this was really GCC, do you think the FSF would take the time to do a comparison to answer the question? I doubt it! And since they have no obligation to do anything, they can't be held liable for not doing it. Indeed it would be unreasonable for them to take the time to inspect the sources in question to verify that everything that's claimed to be there's really is. When you receive a copy of Microsoft Windows from a reseller on a street corner, how do you know who else, if anybody, might have a copyright claim on it? Why do you think that Microsoft goes to so much trouble to protect their CD's with things like holograms? Precisely to help provide an answer to this question. But even with that, if it's somebody on a street corner, you really DON'T know that it isn't counterfeit and might infringe somebody else's copyright. If it's in a reputable store and it looks like undamaged Microsoft packaging, you have much more reason to trust it. If the redistributor doesn't have any copyright claims on the file, you can ask for a contract, an agreement, a warranty promise, whatever you ask for and they agree to give you, but it's not going to be a copyright license. I'm not sure what a copyright license means. A software license is a contract that states under what terms you can use copyrighted software. That's exactly what you'd be getting from the redistributor. If it were pure GPL software, the license would just be a copy of the GPL along with a statement that everything in it is subject to the GPL.
Re: RFH: GPLv3
On Jul 16, 2007, [EMAIL PROTECTED] (Richard Kenner) wrote: You look for copyright notices, ask the holders whether they own all of that, ask the distributor who owns any other bits. If they don't know or won't tell, they're up for contributory infringement, No, they're not because you have no contractual relationship with them. Err, sorry, yes, what I wrote was a mess and completely unclear. The they above was the distributor, not necessarily the copyright holders, and the distributor would be up for contributory infringement should they include code from third parties without permission. You're of course right as to (no) obligations of the original copyright holder. They might as well charge for the service, but refusal to do so would obviously not amount to contributory infringement, since the contributory infringement would be on the distributor who added code without authorization from its copyright holder. For that matter, I doubt the FSF would answer either. But this is simpler; the FSF publishes the releases, so anyone can compare what they got with what the FSF published, and then ask the distributor do you hold the copyright for these differences? When you receive a copy of Microsoft Windows from a reseller on a street corner, how do you know who else, if anybody, might have a copyright claim on it? Why do you think that Microsoft goes to so much trouble to protect their CD's with things like holograms? Precisely to help provide an answer to this question. But even with that, if it's somebody on a street corner, you really DON'T know that it isn't counterfeit and might infringe somebody else's copyright. If it's in a reputable store and it looks like undamaged Microsoft packaging, you have much more reason to trust it. Why? How do you know who else, if anybody, might have a copyright claim on it? Why would you trust Microsoft, that won't even let you see the code, and won't idemnify you, but you wouldn't trust a Free Software vendor, who will let you see the code, and might even be willing to idemnify you? I'm not sure what a copyright license means. A copyright license is a permission from a copyright holder to perform acts that require permission from copyright holders. A software license is a contract that states under what terms you can use copyrighted software. A license is not a contract. A license (permission to do something) can be part of a contract. You're probably thinking license agreement or license contract. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RFH: GPLv3
On Jul 16, 2007, [EMAIL PROTECTED] (Richard Kenner) wrote: A license is not between the user of the software and the FSF, but between the user and who he got it from. My TiVo contains FSF-copyrighted software and I got a license to use it from TiVo, not the FSF. GPLv2: 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the ^^ Program subject to these terms and conditions. This is important to understand! Indeed ;-) If A obtains software from the FSF and distributes it to B, who distributes it to C who, in turn, distributes it to D, there is a license between A and the FSF, B and C, C and B, and D and C. If it were so and any of them infringes on the license, then all downstream users would have their licenses at risk. This situation would be akin to sub-licensing. But this is not how the GPL works. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RFH: GPLv3
Robert Dewar wrote: One could of course just take a blanket view that everything on the site is, as of a certain moment, licensed under GPLv3 (note you don't have to change file headers to achieve this, the file headers have no particular legal significance in any case). I'm going to pull a Wikipedia and call citation needed on that parenthetical claim. At the very least, the file headers are a clear representation as to what license the file is under, and IMO a reasonable person would expect to be able to rely on such a representation. Thus, I think there's a reasonable argument to be made that distributing a GCC with some file headers saying GPLv2 or later and some saying GPLv3 or later is violating the license. The FSF is allowed to violate their own license, since they hold the copyrights, but nobody else is -- thus, a corrolary to that argument is that an exact copy of such a GCC is not redistributable unless the redistributor fixes the file headers. That would be bad. And, regardless of whether one accepts that argument, if I were to pull a file with a GPLv2 header out of a GPLv3-licensed svn and give an exact copy of it to my friend, I would have to remember to tell her that the file isn't licensed under what it says it's licensed under. That's also not good. Thus, I think it's reasonably critical that _all_ file headers be updated, quickly, to match the state of intended license for the files that include them. - Brooks
Re: RFH: GPLv3
Brooks Moses wrote: Robert Dewar wrote: One could of course just take a blanket view that everything on the site is, as of a certain moment, licensed under GPLv3 (note you don't have to change file headers to achieve this, the file headers have no particular legal significance in any case). I'm going to pull a Wikipedia and call citation needed on that parenthetical claim. Well the obvious citation is the copyright statutes themselves, probably not a bad idea to read them! At the very least, the file headers are a clear representation as to what license the file is under, and IMO a reasonable person would expect to be able to rely on such a representation. Well certainly it is good policy for headers to reflect the copyright and licensing situation, and of course we aim at that, that goes without saying. But no you cannot rely on this information, and a blanket copyright statement is a way of making sure that no possible case can arise in which someone says but I thought this was still under the v2 GPL. Then you work hard to make ALL headers reflect the new status. Thus, I think there's a reasonable argument to be made that distributing a GCC with some file headers saying GPLv2 or later and some saying GPLv3 or later is violating the license. No, the position of the FSF (and it is a perfectly reasonable one) is that if a file header says GPLv2 or later, it is essentially a multiple distribution under all versions, so redistributing it as GPLv3 only is fine. it is nice if you do this to change the header, but there is nothing anywhere that requires this. The FSF is allowed to violate their own license That's a nonsense concept, there is no such thing as a license between party A and party A, so the notion of violating it is meaningless. Actually the whole notion of violating a license is a confused one. The violation is of the copyright, the license merely gives some cases in which copying is allowed. If you copy outside the license you have not violated the license, you have simply infringed the copyright, and the license is irrelevant. And, regardless of whether one accepts that argument, if I were to pull a file with a GPLv2 header out of a GPLv3-licensed svn and give an exact copy of it to my friend, I would have to remember to tell her that the file isn't licensed under what it says it's licensed under. That's also not good. Thus, I think it's reasonably critical that _all_ file headers be updated, quickly, to match the state of intended license for the files that include them. I don't think anyone disagreed with this, so no need to argue against non-existent disagreement! - Brooks
Re: RFH: GPLv3
Come on, if the FSF (the copyright holder) distributes a program, and if the included licence says GPLv2+, then the licence is GPLv2+ and you'll have a really hard time trying to convince anyone that it's different. The problem isn't convincing somebody it's *different*, but to convince them that there's a reason the license is what it supposedly says it is! It's critical to understand that copyright and license agreements in files have *no legal significance whatsoever* except *possibly* to try to establish what was in the mind of the author. It's likely true that if they FSF were to distribute software in the sense of mailing somebody a CD and there was no license on paper, you could *probably* indeed rely on the license within the CD as being definitive. But if there's some random file floating around that somebody claims was copied from a site that somebody else claimed was maintained by the FSF and you start relying on a notice in *that* file as definitively saying what the license is, you're on *much* shakier legal grounds and most attorneys would not be comfortable with it. BTW: the copyright holder is free to take a GPLv3 patch and release it under GPLv2 (and any other licence). True, but irrelevant, as I said in my previous email: a patch is a derived work of the file it patches, so there's not much real meaning in talking about the license status of a patch in isolation.
Re: RFH: GPLv3
Richard Kenner wrote: At what point in this process, and by what mechanism, does a patch become a GPLv2 patch or a GPLv3 patch. I'd argue that the patch itself has no such status at all: as of the time it's posted, its copyright is owned by the FSF, but that's all that's happened. The assignment agreement obligates the FSF that all distribution of the patch should be under GPL-like terms, but it's completely unclear as to at what point those terms apply. For one thing, there are multiple possible licenses even ignoring the v2 vs. v3 issue: GPL, LGPL, GPL+exception, etc. Yes, I think that this analysis is exactly correct So if you see a patch posted on an FSF mailing list, what copyright license status does that patch have? My feeling is that as a practical matter, it's irrelevant since the patch is a derived work from some file and the license that applies to that file trumps any that might be viewed by some mechanism as applying to the patch in isolation. If I'm patching an LGPLv3 file, then my patch is a derived work from that file and so is also LGPLv3. End of story. Seems like the right approach Now, suppose I apply it to the GPLv2 version of the file. One could argue that such file is now GPLv3 and I think that'd be correct. But since the parts of the file being patched are identical, the patch is indistinguishable from one that's derived from GPLv2 text. This strikes me as a VERY murky legal areas. Right, that does seem murky, which is why I suggested the blanket statement, that removes any possible murk.
Re: RFH: GPLv3
You asked if COPYING would be updated. The answer is not necessarily. The COPYING text may say GPLv2+, but if there has been a GPLv3 patch applied to the branch, then the entire branch is GPLv3. I struggle to believe this. Afaik a bunch of code is released under a license, and nothing has the power to magically change that license. If someone applies a GPLv3 patch to some GPLv2 code and releases the whole under the GPLv2, then that person has broken copyright law and the release is invalid (because the GPLv3 code has been released without a license), but the rest of the GPLv2 code is still GPLv2. Or have I missed something here? It sounds to me like the syntactic mischief Microsoft is playing when it calls the GPL viral (note, I'm not suggesting that you are making mischief, just that the implication is similar)! No, you're correct, but what's meant by the entire branch is GPLv3 doesn't mean that somehow the license status of the code changed, but that the entire branch can now only be distributed under GPLv3. I think this misses a point: FSF is a copyright assignee, and I don't know how that relates to holding, but the person who wrote the patch is free to dual-license without reference to the FSF. So as a completely fabricated example: say in 6 months Richard Kenner makes a patch to (GPLv3) mainline for a bug, and you want that patch to improve a GPLv2 product that you're maintaining for one of your customers. You are free to ask Richard to release that patch to you under GPLv2, and Richard is free to grant that request. It's actually not that simple. First of all, under the assignment, I don't *automatically* have the right to distribute the patch under any license I choose, but have to request it. From an ancient version of assign.changes: Upon thirty days' prior written notice, the Foundation agrees to grant me non-exclusive rights to use the Work (i.e. my changes and enhancements, not the program which I enhanced) as I see fit; (and the Foundation's rights shall otherwise continue unchanged). Secondly, the patch is usually not just a standalone entity, but a derived work from the file that was patched. I don't have authority to change *that* license.
Re: RFH: GPLv3
Richard Kenner writes: Richard Now, suppose I apply it to the GPLv2 version of the file. One could argue Richard that such file is now GPLv3 and I think that'd be correct. But since the Richard parts of the file being patched are identical, the patch is indistinguishable Richard from one that's derived from GPLv2 text. This strikes me as a VERY murky Richard legal areas. I believe this scenario is exactly RMS's expectation if someone other than the original author copies / backports a patch from a GPLv3 file. David
Re: RFH: GPLv3
At the very least, the file headers are a clear representation as to what license the file is under, and IMO a reasonable person would expect to be able to rely on such a representation. Well, all I can say to this is that (with my AdaCore hat on) I had a discussion with somebody in the purchasing department of a major US defense contractor last week who seemed like a quite reasonable person to me and quite rightly was *not* willing to rely on any such representation in the file. I think I was, however, able to point her to something that she *could* rely on. These sorts of discussions happen quite often and are one of the main barriers towards commercial acceptance of GPL software. And, regardless of whether one accepts that argument, if I were to pull a file with a GPLv2 header out of a GPLv3-licensed svn and give an exact copy of it to my friend, I would have to remember to tell her that the file isn't licensed under what it says it's licensed under. That's also not good. Yes, but it's precisely because you might have done that that people are not willing to just rely on statements in files. Thus, I think it's reasonably critical that _all_ file headers be updated, quickly, to match the state of intended license for the files that include them. I don't think you'll get any disagreement on that statement, but that doesn't mean that such an update has any *legal* significance.
Re: RFH: GPLv3
Actually the whole notion of violating a license is a confused one. The violation is of the copyright, the license merely gives some cases in which copying is allowed. If you copy outside the license you have not violated the license, you have simply infringed the copyright, and the license is irrelevant. Well, yes and no. In the current situation where the license usually isn't a signed agreement between the parties, that's correct. However, if two companies sign a license agreement for some software, that agreement is a contract between the companies and is enforceable as a contract. What you (correctly) point out is that the more usual enforcement is as a copyright infringement because that has statutory damages and the license violation would have actual damages. However, it's not at all hard to come up with scenarios where the license contained limitations that would not be permitted by copyright law and violation of such would produce provable damages that would exceed statutory copyright damages and such would be enforceable.
Re: RFH: GPLv3
Richard Kenner wrote: Actually the whole notion of violating a license is a confused one. The violation is of the copyright, the license merely gives some cases in which copying is allowed. If you copy outside the license you have not violated the license, you have simply infringed the copyright, and the license is irrelevant. Well, yes and no. In the current situation where the license usually isn't a signed agreement between the parties, that's correct. However, if two companies sign a license agreement for some software, that agreement is a contract between the companies and is enforceable as a contract. What you (correctly) point out is that the more usual enforcement is as a copyright infringement because that has statutory damages and the license violation would have actual damages. Not the right analogy, the right analogy is a shrink wrapped license e.g. from Microsoft, such licenses just
Re: RFH: GPLv3
Richard Kenner wrote: Actually the whole notion of violating a license is a confused one. The violation is of the copyright, the license merely gives some cases in which copying is allowed. If you copy outside the license you have not violated the license, you have simply infringed the copyright, and the license is irrelevant. Well, yes and no Well I disagree with your analysis, but anyway neither of us are attorneys (though I am a legal expert in copyright and license matters), and it is pointless to argue such issues here, since they are really not germane in any case to the fundamental issue of how to handle the transition.
Re: RFH: GPLv3
Richard Now, suppose I apply it to the GPLv2 version of the file. One could Richard argue that such file is now GPLv3 and I think that'd be correct. Richard But since the parts of the file being patched are identical, the Richard patch is indistinguishable from one that's derived from GPLv2 text. Richard This strikes me as a VERY murky legal areas. I believe this scenario is exactly RMS's expectation if someone other than the original author copies / backports a patch from a GPLv3 file. But I'm even worried about the case where the *original* author does it. So I developed a patch from a GPLv3 file. I now go back and develop the same patch from the GPLv2 file, which has all relevant parts identical. The resulting patches are identical. Making the claim that these two identical things done by the same person in the same way have different copyright statuses might be legally correct, but as a practical matter seems absurd since there's no way to tell them apart as they're identical. This is a very bizarre situation!
Re: RFH: GPLv3
At 06:33 AM 7/15/2007, Robert Dewar wrote: Richard Kenner wrote: Actually the whole notion of violating a license is a confused one. The violation is of the copyright, the license merely gives some cases in which copying is allowed. If you copy outside the license you have not violated the license, you have simply infringed the copyright, and the license is irrelevant. Well, yes and no Well I disagree with your analysis, but anyway neither of us are attorneys (though I am a legal expert in copyright and license matters), and it is pointless to argue such issues here, since they are really not germane in any case to the fundamental issue of how to handle the transition. Agreed -- especially since, on reflection, what I said and what I intended to say were not quite the same thing. Apologies to all for the noise. - Brooks
Re: RFH: GPLv3 and release version numbers
On Thu, 2007-07-12 at 10:21 -0700, Mark Mitchell wrote: David Edelsohn wrote: Let me try to stop some confusion and accusations right here. RMS *did not* request or specify GCC 4.3.3 following GCC 4.2.2. That was a proposal from a member of the GCC SC. The numbering of the first GPLv3 release was not a requirement from RMS or the FSF. I don't particularly have a dog in the version number fight. I think it's potentially surprising to have a bug fix release contain a major licensing change -- whether or not it particularly affects users, it's certainly a big deal, as witnessed by the fact that it's at the top of the FSF's priority list! But, if there's a clear consensus here, I'm fine with that. I think it's useful to look at what other members of the free software world are doing and if we take SAMBA they're bumping the version number: http://news.samba.org/announcements/samba_gplv3/ [...] To allow people to distinguish which Samba version is released with the new GPLv3 license, we are updating our next version release number. The next planned version release was to be 3.0.26, this will now be renumbered so the GPLv3 version release will be 3.2.0. To be clear, all versions of Samba numbered 3.2 and later will be under the GPLv3, all versions of Samba numbered 3.0.x and before remain under the GPLv2. [...] I don't know about other big projects (many projects don't have branches), but there's some value for free software users about being consistent across projects on this point. Laurent
Re: RFH: GPLv3
Richard Kenner wrote: Unfortunately, as I understand it, this is not the case. If you apply a GPLv3 patch to a previously GPLv2 branch after August 1, then this entire branch, and all files in it, magically and silently becomes GPLv3. This is the key point, I think: what, PRECISELY, is a GPLv3 patch. I think everybody has assignments that predate GPLv3. The assignment I signed (and I think the current assignments) don't even mention the GPL at all, let alone a particular version of it! So one of us writes a patch and posts it on that list. The copyright status of that patch is that it's assigned to the FSF, which then can decide what license agreement to apply to it. But, as a matter of practice, no FSF individual is involved in the process of having that patch be applied to the sources: it's checked in by the person who wrote it (after possible approval, but not change, by some other person). At what point in this process, and by what mechanism, does a patch become a GPLv2 patch or a GPLv3 patch. I'd argue that the patch itself has no such status at all: as of the time it's posted, its copyright is owned by the FSF, but that's all that's happened. The assignment agreement obligates the FSF that all distribution of the patch should be under GPL-like terms, but it's completely unclear as to at what point those terms apply. For one thing, there are multiple possible licenses even ignoring the v2 vs. v3 issue: GPL, LGPL, GPL+exception, etc. When you post a patch to the mailing list, or apply it to a branch, you are acting as an agent of FSF. You previously assigned your rights to the patch to the FSF. (If you have not assigned your rights, then your patch will not be applied to the branch, so it doesn't matter.) The FSF decides what licenses to apply to a patch. It's not at all unclear what point the license applies: at the moment FSF has said that all patches applied after August 1 are covered by GPLv3. So if you see a patch posted on an FSF mailing list, what copyright license status does that patch have? My feeling is that as a practical matter, it's irrelevant since the patch is a derived work from some file and the license that applies to that file trumps any that might be viewed by some mechanism as applying to the patch in isolation. If I'm patching an LGPLv3 file, then my patch is a derived work from that file and so is also LGPLv3. End of story. If you signed an assignment of copyright, the copyright to the patch belongs to FSF. The status is clear and the license is whatever FSF says it is. You have it backward: the base source doesn't determine the license status of the patch; the patch determines the license status of the source. The most restrictive license applies. Read the GPLv3. This is the GPL taint provision. Otherwise I could take the eager-cc compiler (currently consisting of only main()) and patch it with all of gcc, and poof, all that patched code takes on the license of the original source. Not what you want and, coincidently, not what the GPL requires. So I think the discussion of a GPLv3 patch being applied to a GPLv2 file and affecting the license of that file is somewhat backwards: the file's license affects the patch and not vice-versa. Nope. Read the GPL. Where this gets tricky is indeed in a backport. Let's suppose I have two files that differ only into which license applies. Suppose I start with the GPLv3 version and develop a patch for it. That patch is a derived work from GPLv3. When I apply it to the GPLv3 version of the file, nothing changes. Now, suppose I apply it to the GPLv2 version of the file. One could argue that such file is now GPLv3 and I think that'd be correct. But since the parts of the file being patched are identical, the patch is indistinguishable from one that's derived from GPLv2 text. This strikes me as a VERY murky legal areas. Sorry, it isn't at all murky. If the original patch was covered under GPLv3, no matter how similar it might be to one which hypothetically might have been created under a different license, it remains GPLv3. It's not whether the patch is indistinguishable, its that it was not independently developed. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFH: GPLv3
Brooks Moses wrote: Robert Dewar wrote: One could of course just take a blanket view that everything on the site is, as of a certain moment, licensed under GPLv3 (note you don't have to change file headers to achieve this, the file headers have no particular legal significance in any case). I'm going to pull a Wikipedia and call citation needed on that parenthetical claim. At the very least, the file headers are a clear representation as to what license the file is under, and IMO a reasonable person would expect to be able to rely on such a representation. Actually, this is a good point. While the FSF may declare that all patches after Aug 1 are GPLv3, unless they take affirmative action to assert the copyright and license, courts may determine that they waive rights under these. Especially if a reasonable person would expect copyright statements to be correct. Thus, I think there's a reasonable argument to be made that distributing a GCC with some file headers saying GPLv2 or later and some saying GPLv3 or later is violating the license. The FSF is allowed to violate their own license, since they hold the copyrights, but nobody else is -- thus, a corrolary to that argument is that an exact copy of such a GCC is not redistributable unless the redistributor fixes the file headers. That would be bad. And, regardless of whether one accepts that argument, if I were to pull a file with a GPLv2 header out of a GPLv3-licensed svn and give an exact copy of it to my friend, I would have to remember to tell her that the file isn't licensed under what it says it's licensed under. That's also not good. Yes, the situation seems chaotic and confusing. Not a good thing. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFH: GPLv3
* Robert Dewar: One could of course just take a blanket view that everything on the site is, as of a certain moment, licensed under GPLv3 (note you don't have to change file headers to achieve this, the file headers have no particular legal significance in any case). In Germany, they are significant in some contexts. For instance, if you distribute software with GPL headers to someone, and the receiver uses them in accordance with the GPL, you will face a very tough time in court when you try to claim copyright infringement by the receiver because--surprise, surprise--the files weren't actually licensed under the GPL. This is called venire contra factum proprium in German legalese, and I'm sure similar no-nonsense provisions exist in many jurisdictions. (Of course, a third party can still successfully claim copyright infringement.)
Re: RFH: GPLv3
Richard Kenner wrote: Richard Now, suppose I apply it to the GPLv2 version of the file. One could Richard argue that such file is now GPLv3 and I think that'd be correct. Richard But since the parts of the file being patched are identical, the Richard patch is indistinguishable from one that's derived from GPLv2 text. Richard This strikes me as a VERY murky legal areas. I believe this scenario is exactly RMS's expectation if someone other than the original author copies / backports a patch from a GPLv3 file. But I'm even worried about the case where the *original* author does it. So I developed a patch from a GPLv3 file. I now go back and develop the same patch from the GPLv2 file, which has all relevant parts identical. The resulting patches are identical. Making the claim that these two identical things done by the same person in the same way have different copyright statuses might be legally correct, but as a practical matter seems absurd since there's no way to tell them apart as they're identical. This is a very bizarre situation! Actually, the two patches don't have different copyright or licenses, given your description. It's really not possible to un-know the original GPLv3 patch and create an identical GPLv2 from scratch. The second patch is clearly and directly derived from the first. There might be a claim that someone else could develop the GPLv2 patch based on the GPLv2 sources, not looking at your patch or any GPLv3 sources, in which case it would be either coincidence if they happened to be identical, or a requirement of the context. But this second patch is really irrelevant to the discussion at hand. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFH: GPLv3
One could of course just take a blanket view that everything on the site is, as of a certain moment, licensed under GPLv3 (note you don't have to change file headers to achieve this, the file headers have no particular legal significance in any case). Given the July 31 deadline, that's essentially what's being done: any file with a date before August 1, 2007 is GPLv2 and any after is GPLv3. This is one of the reasons why I don't see the version number change as so significant.
Re: RFH: GPLv3
Rob Brown [EMAIL PROTECTED] writes: So, could there be a simultaneous release of gcc under GPLv2 and GPLv3, identical in all respects except for the license? How could that be useful? That v2(+) version would already be v3 if the user wanted so (due to the or later clause). Use any licence you want but don't mess with version numbers or the branches (including closing) for purely political, not technical reasons. -- Krzysztof Halasa
Re: RFH: GPLv3
Richard Kenner wrote: One could of course just take a blanket view that everything on the site is, as of a certain moment, licensed under GPLv3 (note you don't have to change file headers to achieve this, the file headers have no particular legal significance in any case). Given the July 31 deadline, that's essentially what's being done: any file with a date before August 1, 2007 is GPLv2 and any after is GPLv3. This is one of the reasons why I don't see the version number change as so significant. This would be a desirable situation. Unfortunately, as I understand it, this is not the case. If you apply a GPLv3 patch to a previously GPLv2 branch after August 1, then this entire branch, and all files in it, magically and silently becomes GPLv3. (This is unless FSF agrees with Mark's proposal to dual license patches.) As I understand the current situation, knowing the version number will not tell you whether the code is licensed under GPLv2 or GPLv3. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFH: GPLv3
Michael Eager wrote: Unfortunately, as I understand it, this is not the case. If you apply a GPLv3 patch to a previously GPLv2 branch after August 1, then this entire branch, and all files in it, magically and silently becomes GPLv3. (This is unless FSF agrees with Mark's proposal to dual license patches.) As I understand the current situation, knowing the version number will not tell you whether the code is licensed under GPLv2 or GPLv3. That's why I suggested a simple rule that ALL software on the site is GPLv3 after a certain date, so you don't have to know the version number or anything else, just the date on which you access the site, and if you are GPLv3 allergic, then the simple rule is not to take ANYTHING off the site after that date. This is really much the easiest rule.
Re: RFH: GPLv3
Robert Dewar wrote: Michael Eager wrote: Unfortunately, as I understand it, this is not the case. If you apply a GPLv3 patch to a previously GPLv2 branch after August 1, then this entire branch, and all files in it, magically and silently becomes GPLv3. (This is unless FSF agrees with Mark's proposal to dual license patches.) As I understand the current situation, knowing the version number will not tell you whether the code is licensed under GPLv2 or GPLv3. That's why I suggested a simple rule that ALL software on the site is GPLv3 after a certain date, so you don't have to know the version number or anything else, just the date on which you access the site, and if you are GPLv3 allergic, then the simple rule is not to take ANYTHING off the site after that date. This is really much the easiest rule. I understood your suggestion. This amounts to telling companies that they cannot upgrade their tool chains to newer versions, or even pick up patches to old versions, until they (and/or their legal departments) approve GPLv3. This seems unnecessary. If you are trying to make GPLv3 more easily adopted by companies, then this is not the way to do it. On the other hand, perhaps I should simply agree with you. I'll get more business supporting private tool chain development. I have contracts with corporations to upgrade their software. I regularly encourage them to contribute to the open source repositories and sometimes they agree, although it usually takes a while to convince them (management and legal departments) that there is a benefit to this and no risk to their IP rights. Converting previously released software to a license which they have not yet evaluated will close these conversations. Rather than move to later versions of the tools and being more involved with the open source community, they will stay with their existing privately supported tool chains. I'll get more work to fix problems which are already fixed in later releases, but which are off limits until the legal department gives it's OK. Once a corporation decides that their current version of gcc is good enough and decides that they will not upgrade, there will be little reason for management to press their legal department to evaluate or approve GPLv3. My experience is that for every company which is actively using and developing gcc and contributes to the open source community, I talk with many other companies who do gcc development and follow the GPLv2 completely, but do not submit their patches to the open source repository. There are a number of reasons for this, including inertia, caution, secretiveness, etc. I'd rather not give them another reason. The result is that there are many private forks of gcc and other development tools. You may think that do it my way or else is a winning negotiating tactic, but most of the companies I work with are quite happy to do things on their own. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFH: GPLv3
Michael Eager [EMAIL PROTECTED] writes: Unfortunately, as I understand it, this is not the case. If you apply a GPLv3 patch to a previously GPLv2 branch after August 1, then this entire branch, and all files in it, magically and silently becomes GPLv3. (This is unless FSF agrees with Mark's proposal to dual license patches.) I hope the COPYING or similar file will contain the licence text under which the code is distributed? -- Krzysztof Halasa
Re: RFH: GPLv3
Michael Eager [EMAIL PROTECTED] writes: Not until someone updates the txt. Which should happen quickly, but if someone applies a GPLv3 patch to a previously GPLv2 branch, the entire branch becomes GPLv3, whether the COPYING file was updated or not. Come on, if the FSF (the copyright holder) distributes a program, and if the included licence says GPLv2+, then the licence is GPLv2+ and you'll have a really hard time trying to convince anyone that it's different. BTW: the copyright holder is free to take a GPLv3 patch and release it under GPLv2 (and any other licence). -- Krzysztof Halasa
Re: RFH: GPLv3
Krzysztof Halasa wrote: Michael Eager [EMAIL PROTECTED] writes: Not until someone updates the txt. Which should happen quickly, but if someone applies a GPLv3 patch to a previously GPLv2 branch, the entire branch becomes GPLv3, whether the COPYING file was updated or not. Come on, if the FSF (the copyright holder) distributes a program, and if the included licence says GPLv2+, then the licence is GPLv2+ and you'll have a really hard time trying to convince anyone that it's different. You asked if COPYING would be updated. The answer is not necessarily. The COPYING text may say GPLv2+, but if there has been a GPLv3 patch applied to the branch, then the entire branch is GPLv3. BTW: the copyright holder is free to take a GPLv3 patch and release it under GPLv2 (and any other licence). FSF is the copyright holder. As of this time, they have said that they are not willing to release patches under GPLv2 for application to GPLv2 branches. Mark has a proposal which would allow for that. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFH: GPLv3
Krzysztof Halasa wrote: Michael Eager [EMAIL PROTECTED] writes: Not until someone updates the txt. Which should happen quickly, but if someone applies a GPLv3 patch to a previously GPLv2 branch, the entire branch becomes GPLv3, whether the COPYING file was updated or not. Come on, if the FSF (the copyright holder) distributes a program, and if the included licence says GPLv2+, then the licence is GPLv2+ and you'll have a really hard time trying to convince anyone that it's different. You asked if COPYING would be updated. The answer is not necessarily. The COPYING text may say GPLv2+, but if there has been a GPLv3 patch applied to the branch, then the entire branch is GPLv3. I struggle to believe this. Afaik a bunch of code is released under a license, and nothing has the power to magically change that license. If someone applies a GPLv3 patch to some GPLv2 code and releases the whole under the GPLv2, then that person has broken copyright law and the release is invalid (because the GPLv3 code has been released without a license), but the rest of the GPLv2 code is still GPLv2. Or have I missed something here? It sounds to me like the syntactic mischief Microsoft is playing when it calls the GPL viral (note, I'm not suggesting that you are making mischief, just that the implication is similar)! BTW: the copyright holder is free to take a GPLv3 patch and release it under GPLv2 (and any other licence). FSF is the copyright holder. As of this time, they have said that they are not willing to release patches under GPLv2 for application to GPLv2 branches. Mark has a proposal which would allow for that. I think this misses a point: FSF is a copyright assignee, and I don't know how that relates to holding, but the person who wrote the patch is free to dual-license without reference to the FSF. So as a completely fabricated example: say in 6 months Richard Kenner makes a patch to (GPLv3) mainline for a bug, and you want that patch to improve a GPLv2 product that you're maintaining for one of your customers. You are free to ask Richard to release that patch to you under GPLv2, and Richard is free to grant that request.
Re: RFH: GPLv3
Robert Dewar wrote: One could of course just take a blanket view that everything on the site is, as of a certain moment, licensed under GPLv3 (note you don't have to change file headers to achieve this, the file headers have no particular legal significance in any case). According to http://www.gnu.org/licenses/gpl-howto.html, the file headers are precisely the place to make the license grant. That at least would be clean, and anyone concerned with accepting GPLv3 stuff would simply know that as of this date and time, they should no longer download ANYTHING from the entire gnu.org site. That's actually not so terrible, you lose some users temporarily, but at least there is no misunderstanding. There would be gross misunderstanding! Placing everything on gnu.org under GPLv3 does nothing to affect all of its mirrors. So if I download gcc-4.2.0.tar.bz2 from ftp.gnu.org then it's GPLv3, but if I download it from any of the mirrors then it's GPLv2. Surely the aim of the process should be to eliminate gotchas as much as possible. Everyone has the responsibility to verify that they have a license before using someone else's code. How could I, as the recipient of a file which says GPLv2 etc at the top, know that it was downloaded from gnu.org and is actually really GPLv3?
Re: RFH: GPLv3
On Jul 12, 2007, Michael Eager [EMAIL PROTECTED] wrote: This would be chaotic. Acme Co's version of gcc-3.4 might be GPLv2 while MegaCorp's gcc-3.4 might be GPLv3. This is already true today. Even if MegaCorp doesn't make any changes to the code, the code is available under GPLv2+, which means they can license their compiler under GPLv3+, or GPLv3 only, at their choice. And this is a good thing. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RFH: GPLv3
On Jul 12, 2007, Benjamin Smedberg [EMAIL PROTECTED] wrote: Obviously the FSF can relicense any code they want to GPL3... that doesn't mean that this community couldn't decide to only accept patches to the GCC4.2 branch that are licensed under the GPL2+. This wouldn't change the fact that any upcoming release of GCC issued by the FSF ought to be under GPLv3. But yes, people could still backport patches into their own GPLv2 releases given the policy above. But having backporters ask for permission from the authors or from the FSF sounds like a good incentive for them to switch to GPLv3 to avoid the hassle. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RFH: GPLv3
On Jul 12, 2007, Mark Mitchell [EMAIL PROTECTED] wrote: 2. GCC 4.2.1 will be the last GPLv2 release. The FSF will permit backports from mainline to GCC 4.2.1, if necessary, to be downlicensed to GPLv2, as part of that release. 3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3. How about, after the 4.2.1 release, switch the branch to GPLv3 and then release 4.2.3, without any functional changes, under GPLv3? The skipped minor version number (to a .3, no less) and the quick succession of releases would probably hint at the license upgrade, and it would probably make the FSF happier with a GCC release under GPLv3 in a short time-frame. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RFH: GPLv3
Alexandre Oliva wrote: Anyone who had their heads in the sand for the past 18 months when GPLv3 was being publicly discussed and developed, or wasn't at the GCC Summit last year when I mentioned that the FSF would most certainly want to upgrade the license of every project whose copyright it held as soon as GPLv3 was ready, may indeed consider the license upgrade as a surprising new feature. Not surprising, but significant. I think you greatly underestimate the cost and difficulty of upgrading to a new license for many large corporate users. This means getting lawyers involved, and for sure you don't want them wasting time tracking an 18 month period in which the license keeps changing. So you typically would wait till the license change was definite. All the version number change does is signal the need for initiating this process. Many of these users are not the kind of people who jump to every new latest-and-greatest version quickly anyway. Now, why should we weaken our defenses I am at a loss to understand this rhetoric, all we are talking about is what version number to use, how does this weaken our defenses (what defenses? against whom?).
Re: RFH: GPLv3
On Fri, 13 Jul 2007, Alexandre Oliva wrote: One way to view it: the license is a feature. Therefore changing the license is changing a feature. Every release of GCC in the past decade (and then some) was GPLv2+. GPLv3 has always been one of the options. Anyone who had their heads in the sand for the past 18 months when GPLv3 was being publicly discussed and developed, or wasn't at the GCC Summit last year when I mentioned that the FSF would most certainly want to upgrade the license of every project whose copyright it held as soon as GPLv3 was ready, may indeed consider the license upgrade as a surprising new feature. But anyone who wanted to participate was welcome to do so, and GPLv3 shouldn't be a surprise for anyone who did, or even just watched it from a distance. Now, why should we weaken our defenses for the sake of those who didn't plan for something that could have been so easily forecast 18 months ago, and that was even planned to be finished 4 months ago? Heck, the last-call draft, published one month before the final release, was so close to the final release that non-insider lawyers who were on top of the process managed to emit solid opinions about the final license the day after it was released. It's those who didn't do their homework and didn't plan ahead for this predictable upgrade who should be burdened now, rather than all of us having to accept weaker defenses for our freedoms or facing additional requirements on patches or backports. It was all GPLv2+, and this means permission for *anyone* to upgrade to GPLv3+. The license upgrade path is the easy path, and that's by design. I was just suggesting a rationale for choosing a version number. Nick
Re: RFH: GPLv3
On Jul 13, 2007, Robert Dewar [EMAIL PROTECTED] wrote: This means getting lawyers involved, and for sure you don't want them wasting time tracking an 18 month period in which the license keeps changing. Yet somehow a number of large stakeholders not only tracked the license development over 18 months, but actually participated and influenced it so as to meet their interests. And they somehow didn't think of it as wasting time. See, I'm not diminishing the importance of licensing issues, I'm just saying it's legally irresponsible to sit back and *not* even watch what's going on in the development of the license that a bunch of software one is very clearly interested in, and then try to frame the moment when the development is completed and the license is to be adopted, as forecast throughout the process and as explicitly permitted by the licensing practice in place for almost two decades, as something unexpected, as a sudden major legal burden. So you typically would wait till the license change was definite. It seems to me that it would be saner to not only keep up with the developments of the license, but also get one's major customers aware of the upcoming changes, not creating false expectations as to licensing issues. We shouldn't hold back the upgrade just because some vendors *might* have failed to keep up on the legal front. Now, why should we weaken our defenses I am at a loss to understand this rhetoric, all we are talking about is what version number to use, how does this weaken our defenses (what defenses? against whom?). Some people are advocating that patches be under GPLv2+, to enable earlier releases with backports to remain in GPLv2. Since GPLv2 has weaker defenses for users' freedoms than GPLv3, against those who might wish to impose restrictions on these freedoms, GPLv2-compatible patches would enable backports into more weakly-defended releases. The weaker defenses stem mainly out of uncertainty as to the extent of no further restrictions. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RFH: GPLv3
On Jul 13, 2007, Nicholas Nethercote [EMAIL PROTECTED] wrote: One way to view it: the license is a feature. Therefore changing the license is changing a feature. Every release of GCC in the past decade (and then some) was GPLv2+. GPLv3 has always been one of the options. Anyone who had their heads in the sand for the past 18 months when GPLv3 was being publicly discussed and developed, or wasn't at the GCC Summit last year when I mentioned that the FSF would most certainly want to upgrade the license of every project whose copyright it held as soon as GPLv3 was ready, may indeed consider the license upgrade as a surprising new feature. But anyone who wanted to participate was welcome to do so, and GPLv3 shouldn't be a surprise for anyone who did, or even just watched it from a distance. Now, why should we weaken our defenses for the sake of those who didn't plan for something that could have been so easily forecast 18 months ago, and that was even planned to be finished 4 months ago? Heck, the last-call draft, published one month before the final release, was so close to the final release that non-insider lawyers who were on top of the process managed to emit solid opinions about the final license the day after it was released. It's those who didn't do their homework and didn't plan ahead for this predictable upgrade who should be burdened now, rather than all of us having to accept weaker defenses for our freedoms or facing additional requirements on patches or backports. It was all GPLv2+, and this means permission for *anyone* to upgrade to GPLv3+. The license upgrade path is the easy path, and that's by design. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RFH: GPLv3
Nicholas Nethercote wrote: One way to view it: the license is a feature. Therefore changing the license is changing a feature. Therefore what was going to be 4.2.2 should become 4.3.0. I certainly agree that the license is a feature, and a pretty important one for many users.
Re: RFH: GPLv3
On Thu, 12 Jul 2007, Michael Eager wrote: 3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3. What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4. This seems to confabulate the meaning of version numbers to now mean something about licensing. The difference between 4.2.1 and 4.2.2 would normally be considered a minor bug fix release, under this scheme of calling it 4.3.3, one would be misled to think that this is a minor bug fix for a non-existent minor release. The version numbering scheme correlating to functional changes is more valuable than any (IMO insubstantial) benefit of identifying the change in license version. One way to view it: the license is a feature. Therefore changing the license is changing a feature. Therefore what was going to be 4.2.2 should become 4.3.0. Nick
Re: RFH: GPLv3
Hi David, 2. Turn off public access to the code while changing license text in the source. This is not necessary. (I am assuming here that by public access to the code you mean access to the svn repository, not access to the various release tarballs). The repository sources are not an official release. They are part of the development process for future releases. Anyone using these sources should be aware of this and not expect them to remain constant. In particular, in the context of this discussion, no-one should expect that the mainline repository sources will all exist under the governance of just one version of the GPL. I will be as quick as I can in updating the mainline sources, but it is going to take me a couple of days. I am going to perform the upgrade in an incremental fashion as I do not have the bandwidth to perform a single pass commit of all of the sources. Cheers Nick
Re: RFH: GPLv3
Alexandre Oliva wrote: On Jul 13, 2007, Robert Dewar [EMAIL PROTECTED] wrote: So you typically would wait till the license change was definite. It seems to me that it would be saner to not only keep up with the developments of the license, but also get one's major customers aware of the upcoming changes, not creating false expectations as to licensing issues. We shouldn't hold back the upgrade just because some vendors *might* have failed to keep up on the legal front. I don't think the FSF should delay at all in moving its distributions to GPLv3. Do whatever version numbering is required to make it clear to users. The FSF can even go so far as to release no further GPLv2 patches. That is their right and they have no obligation to provide further support for older compilers. OTOH there are a number of non-FSF entities that have committed morally and/or legally to providing long-term support for gcc directly and/or OSes that ship with a gcc. I really believe these people need guidance from the FSF on what to do. --joel sherrill
Re: RFH: GPLv3
Robert Dewar wrote: Nicholas Nethercote wrote: One way to view it: the license is a feature. Therefore changing the license is changing a feature. Therefore what was going to be 4.2.2 should become 4.3.0. I certainly agree that the license is a feature, and a pretty important one for many users. There's a saying if you call a dog's tail a leg, how many legs does a dog have. Four. Calling its tail a leg doesn't make it one. Version numbers have been based on binary compatibility and interoperability between versions. Saying that license is an interoperability issue doesn't make it one. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFH: GPLv3
Alexandre Oliva wrote: On Jul 13, 2007, Nicholas Nethercote [EMAIL PROTECTED] wrote: One way to view it: the license is a feature. Therefore changing the license is changing a feature. Every release of GCC in the past decade (and then some) was GPLv2+. GPLv3 has always been one of the options. Anyone who had their heads in the sand for the past 18 months when GPLv3 was being publicly discussed and developed, or wasn't at the GCC Summit last year when I mentioned that the FSF would most certainly want to upgrade the license of every project whose copyright it held as soon as GPLv3 was ready, may indeed consider the license upgrade as a surprising new feature. Not everyone is a GCC developer. Upgrade the license of every project implied that this would be effective for future releases, not retroactive. Now, why should we weaken our defenses for the sake of those who didn't plan for something that could have been so easily forecast 18 months ago, and that was even planned to be finished 4 months ago? Heck, the last-call draft, published one month before the final release, was so close to the final release that non-insider lawyers who were on top of the process managed to emit solid opinions about the final license the day after it was released. It seems to me that it is the FSF which didn't forecast consequences well, and has now created a problem. No one is suggesting that any defenses be weakened. Only that source currently available under GPLv2 continue to be available under that license. It's those who didn't do their homework and didn't plan ahead for this predictable upgrade who should be burdened now, rather than all of us having to accept weaker defenses for our freedoms or facing additional requirements on patches or backports. It was all GPLv2+, and this means permission for *anyone* to upgrade to GPLv3+. The license upgrade path is the easy path, and that's by design. Companies will not upgrade to GPLv3 until they have reviewed it. It was released ~2 weeks ago. It's clearly been in a state of flux for many months, up until the release date. The question is not whether companies can upgrade past releases to GPLv3 voluntarily. That's a red herring. The question is whether companies who are currently releasing source under GPLv2 will be prohibited from releasing the code under GPLv2 if they do something as innocuous as apply a publicly posted patch. Try a pragmatic approach, rather than a dogmatic approach. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFH: GPLv3
Alexandre Oliva wrote: On Jul 13, 2007, Robert Dewar [EMAIL PROTECTED] wrote: See, I'm not diminishing the importance of licensing issues, I'm just saying it's legally irresponsible to sit back and *not* even watch what's going on in the development of the license Everybody's been watching. The license has changed many times. There's been on-going conflict between FSF and Linux. There's been widely publicized conflicts about about DRM, and Novell/Microsoft, patent license and other issues. It's been like watching a cat fight -- fur flying everywhere. No lawyer is going to spend his time trying to sort out the effect of the license until it is finalized. Some people are advocating that patches be under GPLv2+, to enable earlier releases with backports to remain in GPLv2. Since GPLv2 has weaker defenses for users' freedoms than GPLv3, against those who might wish to impose restrictions on these freedoms, GPLv2-compatible patches would enable backports into more weakly-defended releases. The weaker defenses stem mainly out of uncertainty as to the extent of no further restrictions. GPLv2 has been effective for many years. It doesn't stop being effective overnight. Let's tone down the high falootin' rhetoric about defending freedoms and discuss the pragmatic issues of how to manage licenses in a real world with real companies and real lawyers and real concerns. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFH: GPLv3
As a (non-developer) user, may I humbly submit a slightly different view: The change of license is an Event, which needs to be marked in concrete by a version number change. All future mainline development will be under the GPLv3. However, there are many people who (due to legal or commercial pressures, amongst others) are required to continue under GPLv2, and there doesn't seem to be a good pragmatic reason to actively penalise those people. I think that having one more GPLv2 release, and then all future releases under GPLv3, creates a discontinuity in the compiler between licenses which may be unhelpful because the first GPLv3 gcc will be technically different to the last GPLv2 gcc. This means that the decision about which to use will be a combination of license issues and technical issues. So, could there be a simultaneous release of gcc under GPLv2 and GPLv3, identical in all respects except for the license? The GPLv2 release will represent the best-quality compiler that the project can deliver, as a base for those who must continue to support it. The GPLv3 release will be the reference point for future development, and will be a known quantity in technical terms. The GPLv2 compiler could be gcc 4.2.1, and the GPLv3 compiler could be gcc 4.3.0. There is an issue that people have been hearing about the new functionalities that gcc 4.3 will have, but it shouldn't be too hard to market the concept that 4.3 is now a license change version, and 4.4 will be the compiler that 4.3 was going to be. Perhaps the simultaneous release could be done on July 31, which is iirc the FSF's deadline for GPLv2 releases. Extending the gcc 4.2.1 release date might allow some last-minute bug-fixes to make it in there. Compiler vendors etc will have an increased workload maintaining the separability of GPLv2 and GPLv3 code during the transition to the new license, and it would seem that the transition will take quite some time (years?), but I'm sure that they will develop procedures to make it manageable. Cheers, Rob Brown.
Re: RFH: GPLv3
On Fri, Jul 13, 2007 at 08:54:17AM -0700, Michael Eager wrote: Robert Dewar wrote: Nicholas Nethercote wrote: One way to view it: the license is a feature. Therefore changing the license is changing a feature. Therefore what was going to be 4.2.2 should become 4.3.0. I certainly agree that the license is a feature, and a pretty important one for many users. There's a saying if you call a dog's tail a leg, how many legs does a dog have. Four. Calling its tail a leg doesn't make it one. Version numbers have been based on binary compatibility and interoperability between versions. Saying that license is an interoperability issue doesn't make it one. GPLv3+ code is however incompatible to GPLv2+ code, so it warrants a major version bump. Ciao, Marcus
Re: RFH: GPLv3
Geoffrey Keating wrote: Speaking as an individual developer who nonetheless needs to follow his company's policies on licensing, I need it to be *absolutely clear* whether a piece of software can be used under GPLv2 or not. If there's a situation where 'silent' license upgrades can occur, where even just one file in a release might be GPLv3, or any other situation where the license is not clear, then to me that software is unusable. This applies to subversion as well to releases in tarballs. That's a good point. I think it would be a good idea to pick a clear point at which the gcc mainline on SVN will stop being GPLv2, and make sure that a tarball of its state immediately before that point is produced. (I guess that point is whenever the first license-change patch gets committed.) This should also be documented clearly on the GCC main page, I think. - Brooks
Re: RFH: GPLv3
Michael Eager wrote: Saying that license is an interoperability issue doesn't make it one. No, saying that is not what makes it so, that's true. However, the fact is that licensing *is* an interoperability issue, since it has to do with what units can be mixed together in a particular situation, which is what interoperability is about. If you mix one GPLv3 unit into a GPLv2 environment, you have a problem if you cannot tolerate GPLv3 licensing (e.g. because your lawyers have not got around to OKaying it, or worse because they have got around to not OKaying it). So it is really important to understand the circumstances in which GPLv3 is showing up. One could of course just take a blanket view that everything on the site is, as of a certain moment, licensed under GPLv3 (note you don't have to change file headers to achieve this, the file headers have no particular legal significance in any case). That at least would be clean, and anyone concerned with accepting GPLv3 stuff would simply know that as of this date and time, they should no longer download ANYTHING from the entire gnu.org site. That's actually not so terrible, you lose some users temporarily, but at least there is no misunderstanding.
Re: RFH: GPLv3
On 12 Jul 2007 04:37:20 -0500, Gabriel Dos Reis [EMAIL PROTECTED] wrote: Mark Mitchell [EMAIL PROTECTED] writes: | The GCC SC is still discussing a few of the finer points of the | transition to GPLv3. Thanks for the update! [...] | 3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3. | What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to | emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4. What a mess! (Sorry). Was the option of closing the GCC-4.2.x branch considered, instead of releasing GCC-4.2.2 as GCC-4.3.2? I agree, this looks like a mess (and it will definitely confuse users). Closing the branch would be an option, but the tricky question what happens if there are backports from mainline fixes to the (closed) branch as part of vendor releases remains. (Likewise for the 4.1 branch) I would definitely like to have a public statement from the FSF on this issue. I suppose backporting your own fixes is a no-brainer, as you don't lose the rights to re-license your own contributions, but without an official statement from the FSF there will be still a lot of confusion on this issue. | It has also not yet been decided whether backports of bug-fixes from | GPLv3 versions of GCC to older GPLv2 versions of GCC (e.g., GCC 4.1) We can make a final release from GCC-4.1.x and close it definitely. We should strive for some kind of mononiticy in terms of release series and licensing. We can just close the branch. Though I expect vendors to continue to need to maintain it for another 5+ years. Maybe we can get mutual agreement from contributors to re-license their contributions to currently active branches under GPL v2 as well and this way side-stepping the FSF on this matter. Richard.
Re: RFH: GPLv3
Hi Mark, Will someone (or someones) please volunteer to change the various files that mention GPLv2 to mention GPLv3 instead, to change the COPYING file in the gcc/ directory, and to look for other things that need to change? I volunteer. It has not yet been decided what to do about files that are part of run-time libraries and are covered by GPL/LGPL + exception. Therefore, no changes to to what ? :-) I assume that there is a missing part of that last sentence which reads these files will take place at the moment. I think however that a small change to such files may be necessary. If I change the contents of the COPYING file over to GPLv3, then I think that it might be wise to create a new file - COPYING_v2 - which contains the GPLv2 and which can be referred to in the copyright notice of files which are still under the GPLv2. It has also not yet been decided whether backports of bug-fixes from GPLv3 versions of GCC to older GPLv2 versions of GCC (e.g., GCC 4.1) will result in the patched compilers being GPLv3. If you have thoughts about that, you might wish to contact the FSF. This is what the FSF had to say when I raised this issue with them for the binutils project: : Since the previous releases were licensed under GPLv2 or later, all : maintainers need to do is upgrade their backport to GPLv3 or later -- : then they'll be able to incorporate patches that were never released : under GPLv2. Cheers Nick
Re: RFH: GPLv3
Mark Mitchell wrote:
The GCC SC is still discussing a few of the finer points of the
transition to GPLv3.[...]
Good!
Here is my initial opinion on some point you asked; but please ignore it if it
hurts somebody!
3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to
emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4.
I find this surprising and a bit confusing! My first reaction (maybe not enough thought) is that most users don't care
much about GCC source code, only about its functionality (making an executable from C or C++ source code). I am not very
sure that a minor change on the GCC source code license should affect so significantly the version numbering.
Maybe it might be simpler for every one to keep the 4.2.2 number the same, while putting an emphasis in its README or
release notes about license version change.
In other words, for GCC and most of its users, the main freedom of the 4 freedoms in GPL is the right to use the GCC
compiler to compiles one's own stuff (even proprietary code). AFAIK this stays the same in GPLv2 and GPLv3.
Even if the license is changing, the ordinary user will very probably be able to mix (e.g. link) her object code
compiled by gcc-4.2.1 and her object code compiled what you call gcc-4.3.3 and what I would prefer calling gcc-4.2.2
But I am not a lawyer, nor a free license guru, so feel free to ignore my initial feelings on this. Do what you feel
best and a big thanks for your work!
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet | mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: RFH: GPLv3
On 7/12/07, Basile STARYNKEVITCH [EMAIL PROTECTED] wrote: Mark Mitchell wrote: 3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3. What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4. I find this surprising and a bit confusing! My first reaction (maybe not enough thought) is that most users don't care much about GCC source code, only about its functionality (making an executable from C or C++ source code). I am not very sure that a minor change on the GCC source code license should affect so significantly the version numbering. I had the same reaction. A new major release of GCC implies new features and other technical enhancements, not just a new license. Just imagine the flood of user questions and complaints when they download GCC 4.3, expecting to find their favorite new feature that they were told would be in GCC 4.3, and all I got was this crummy new license. Shouldn't we at least have some carrot with this stick? Could we ask the SC to reconsider the change in the GCC major version numbering for GPLv3? Or, at the very least, explain why it is important to change the major version number for a mere license change? Why not just change the license on mainline for the GCC 4.3 release (whenever it happens), and leave GCC 4.2 as the last release series using GPLv2? - Doug
Re: RFH: GPLv3
Doug Gregor writes: Doug Could we ask the SC to reconsider the change in the GCC major version Doug numbering for GPLv3? Or, at the very least, explain why it is Doug important to change the major version number for a mere license Doug change? To avoid confusion among GCC users who do not expect a bug fix release to introuduce a new license. David
