Re: GPL versions mismatch.
In message heciro$o0...@ger.gmane.org, Raúl Sánchez Siles rasas...@gmail.com writes Anthony W. Youngman wrote: In message he7933$tg...@ger.gmane.org, Raúl Sánchez Siles rasas...@gmail.com writes From what you've said, I think the way forward is apparent. As you surmise, accepting GPL v3 contributions isn't possible with the current project status saying the project licence is v2. Actually, I think you COULD accept v3 contributions, but to do so you'd need to change the project licence to v3. ...Or to v2+, if I understood correctly. No. In that case you're granting permissions that the author didn't grant. Think about it ... You're given a load of code that is licenced v3+ plus OpenSSL exemption. You then put it into a v2+ project ... BIG NO NO. You've just gone and told all your recipients they can distribute as per GPL v2 - something the v3 author did NOT give you permission to do! This brings me a question: if the code is already GPLv2+, who is to take the decision of stating that the whole project is GPLv2+?. If each contributor agreed that the code is already GPLv2+, why shouldn't the project already be considered GPLv2+? No reason why not. BUT there is a further copyright to be considered - the compilation copyright. I'm not sure whether that's its official name, but think of a book of verse. The poets own the individual copyrights to the poems, the publisher owns the copyright to the book. The compilation copyright in this project is, therefore, owned by the project maintainer. Within the constraint that it must be a subset of the licences on the code, he can choose whatever licence he thinks fit, and he has said the compilation is v2. If he wishes to change it to v2+ he can, because that is still a subset of the licences on the code. And any recipients can pull code out of the project (including pulling ALL the code :-) and distribute that under v2+, too. So it would make sense for the project maintainer to change the project licence to v2+. (Or v2/v3 if he's a bit wary of +, like Linus.) You said that your authors at the moment are a bit chary about moving to v3, but you think it's a good idea. What's actually probably a good idea then is to say that All new contributions must be v2+ or v2/v3, in preparation for a move to v3. (Or BSD, or some other GPL-compatible (both versions) licence.) I think I got this: there can't be any GPLv3 code in the project if the project license is either GPLv2 or GPLv2+, right? Correct. Because the v2 licence on the project grants rights that the authors did NOT grant on the code. v2 is NOT a subset of v3. If I'm right, this means, that no GPLv3 code will ever be able to be used, and this includes link, unless the license is moved to GPLv3, is this right again? Correct. Because v2 is NOT a subset of v3. In this case, what happens to those embedded or linked code which is GPLv1+, for instace? No problem. Because v2 (and v3) ARE proper subsets of v1+ (note the PLUS in there :-) That doesn't alter the project's current v2 status. It DOES stop a developer throwing a spanner in the works by contributing some new v2-only code which will prevent you from relicensing. And it makes clear to developers where you are planning to go. Ok, now it's turn to convince them about the move. Cheers, Wol Thanks again for the supporting effort. -- Raúl Sánchez Siles -Proud Debian user- Linux registered user #416098 -- Anthony W. Youngman - anth...@thewolery.demon.co.uk -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL versions mismatch.
Anthony W. Youngman wrote: In message he7933$tg...@ger.gmane.org, Raúl Sánchez Siles rasas...@gmail.com writes From what you've said, I think the way forward is apparent. As you surmise, accepting GPL v3 contributions isn't possible with the current project status saying the project licence is v2. Actually, I think you COULD accept v3 contributions, but to do so you'd need to change the project licence to v3. ...Or to v2+, if I understood correctly. No. In that case you're granting permissions that the author didn't grant. Think about it ... You're given a load of code that is licenced v3+ plus OpenSSL exemption. You then put it into a v2+ project ... BIG NO NO. You've just gone and told all your recipients they can distribute as per GPL v2 - something the v3 author did NOT give you permission to do! This brings me a question: if the code is already GPLv2+, who is to take the decision of stating that the whole project is GPLv2+?. If each contributor agreed that the code is already GPLv2+, why shouldn't the project already be considered GPLv2+? You said that your authors at the moment are a bit chary about moving to v3, but you think it's a good idea. What's actually probably a good idea then is to say that All new contributions must be v2+ or v2/v3, in preparation for a move to v3. (Or BSD, or some other GPL-compatible (both versions) licence.) I think I got this: there can't be any GPLv3 code in the project if the project license is either GPLv2 or GPLv2+, right? If I'm right, this means, that no GPLv3 code will ever be able to be used, and this includes link, unless the license is moved to GPLv3, is this right again? In this case, what happens to those embedded or linked code which is GPLv1+, for instace? That doesn't alter the project's current v2 status. It DOES stop a developer throwing a spanner in the works by contributing some new v2-only code which will prevent you from relicensing. And it makes clear to developers where you are planning to go. Ok, now it's turn to convince them about the move. Cheers, Wol Thanks again for the supporting effort. -- Raúl Sánchez Siles -Proud Debian user- Linux registered user #416098 -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL versions mismatch.
Anthony W. Youngman wrote: In message he2uoo$om...@ger.gmane.org, Raúl Sánchez Siles rasas...@gmail.com writes The other thing is (I don't know OpenSSL) is that the GPL is incompatible with OpenSSL (which is likely) or is OpenSSL incompatible with the GPL? If it's the GPL which won't let you link to OpenSSL, then add an OpenSSL exemption to v3. As far as I know, this is not possible, in other words, incompatible. This is discussed here: Well, if that's the case, then GPL v2 plus OpenSSL exemption is also impossible :-) Bear in mind I said that it's the AUTHORS who dictate terms. If they say it's okay to link to OpenSSL, then it's okay. End of. (What the GPL says is IRRELEVANT) If all the code is licenced v2+ plus you can link to OpenSSL, then the project can relicence to v3 plus you can link to OpenSSL. You opened my eyes. I was totally misleaded about the incompatibility between GPLv3 and OpenSSL. Well, it's true that they are incompatible, same as with GPLv2, as you stated. For any strange reason I thought GPLv3 was such, that the exception to link against OpenSSL was not possible to apply, or at least it was not possible without messing around GPLv3 in such a way that it would become naked. I now see that exception can be added painlessly. According to this, I started searching with a better criteria and I got to this two options: [1] GPLv2+ and [2] GPLv3. As you can see both add the OpenSSL exception [1] https://trac.vidalia-project.net/browser/vidalia/trunk/LICENSE [2] http://qt.gitorious.org/qt-labs/mobile-demos/blobs/master/LICENSE.GPL3 At the end of the day, the question is is the GPL the problematic licence?. If it is, then the authors can grant *permissions* over and above the GPL. And it seems to me that they have. This is clear now. :) Only that at first I was frightened that authors needed to tailor its own license, which I clearly see it's not needed (besides discouraged) I've just looked at those two links, and all they appear to say to me is that the OpenSSL licence is incompatible with the PURE GPL v*2*. They also say that it may be compatible with v3. ACK. I assume that the idea was probably that GPLv2 was the best fit framework for the project. It would clarify some things for me. I also think that it may have stopped being the best framework for the project, because please correct me if I'm wrong, it would prevent accepting GPLv3 contributions. This would clash with the need of GPLv2 for the openssl issue. There could be other points which I fail to see and which I appreciate hearing. Besides I'm not sure I understand your latter paragraph, specially the part: then your way forward will be logically apparent. Although I understand that only code authors can change license and the best fit framework theory. From what you've said, I think the way forward is apparent. As you surmise, accepting GPL v3 contributions isn't possible with the current project status saying the project licence is v2. Actually, I think you COULD accept v3 contributions, but to do so you'd need to change the project licence to v3. ...Or to v2+, if I understood correctly. You'll need to confirm this for yourself, but what you've said to me makes me think the following: 1) All the code is v2+, so changing the project licence to v3 is NOT a problem. Only that authors are reluctant to such a /big/ change right now, it'd need some discussion and time. But there's not really much motivation in the move so far. 2) The OpenSSL problem is that the GPL v2 does not permit linking to OpenSSL. But all the authors have granted the OpenSSL-exception, so there is no problem linking with OpenSSL (and OpenSSL may be compatible with v3, but seeing as the authors have granted an exception that's irrelevant). So if you WANT to change the project licence to GPL v3 plus the OpenSSL exception there is no problem whatsoever. You can just go ahead and do it RIGHT NOW! if you wish. I'll push towards it, yes. To re-iterate, your authors have said you can link to OpenSSL, so what the GPL (whatever version) says is irrelevant as far as linking to OpenSSL is concerned. Where I think you've got confused with the GPL is adding/subtracting permissions. The GPL is an all or nothing proposition - you can't grant SOME of the GPL rights and not others and call it GPL'd. But if you grant ALL the GPL rights, there is nothing to stop you granting MORE rights on top of the GPL rights (such as the link to OpenSSL right :-) You look right, it's only I need to arrange correctly my thoughts about permission/rights and related concepts. Cheers, Wol _Big_ thanks. -- Raúl Sánchez Siles -Proud Debian user- Linux registered user #416098 -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact
Re: GPL versions mismatch.
Anthony W. Youngman wrote: In message 200911172213.59167.rasas...@gmail.com, Raúl Sánchez Siles rasas...@gmail.com writes Hello: [...] This is how licences are currently arranged in KVIrc: · Project license: GPLv2 adding openssl exception. · Source files in project: almost all GPLv2+, plus a small leftout amount with miscellaneous licenses. Maybe I'm just misleaded but I think it's somewhat confusing having a project license different to each of the project source. Ideally I would use GPLv2+ for everything, i.e., project and source files. The point is that GPLv2+ is IMHO perfectly valid for those source files, but not for the project due the fact that it links against OpenSSL. Even if upstream would be willing to relicense project under GPLv3, they wouldn't be able due to OpenSSL license incompatibility. Then relicence under v2 OR v3. In a way, that's better, anyway (take note that if upstream *does* have any v2-only code, they'll need to deal with it before they can actually relicence to include v3). No GPLv2 code at sight. The other thing is (I don't know OpenSSL) is that the GPL is incompatible with OpenSSL (which is likely) or is OpenSSL incompatible with the GPL? If it's the GPL which won't let you link to OpenSSL, then add an OpenSSL exemption to v3. As far as I know, this is not possible, in other words, incompatible. This is discussed here: http://www.fsf.org/licensing/licenses#OpenSSL http://lists.debian.org/debian-legal/2007/11/msg00244.html [...] What do you think about this situation? what do you think would be the best or simplest solution? You have to bear in mind that the source file licences are whatever the authors say they are. NOBODY ELSE can change the licence - the GPL does not authorise relicencing. Fully agreed. The project maintainers have presumably said v2 compatibility is required for all submissions, therefore the project licence is v2-only. They haven't (THEY CAN'T) impose a v2-only licence, all they've said is that the only licence guaranteed to work as a whole is v2-only. Once you've got your head round the fact that only the code AUTHORS (or rather, owners) can change the licences, and that the project licence is simply the largest proper subset of the individual licences, then your way forward will be logically apparent. Whether you like that way or not is neither here nor there. I assume that the idea was probably that GPLv2 was the best fit framework for the project. It would clarify some things for me. I also think that it may have stopped being the best framework for the project, because please correct me if I'm wrong, it would prevent accepting GPLv3 contributions. This would clash with the need of GPLv2 for the openssl issue. There could be other points which I fail to see and which I appreciate hearing. Besides I'm not sure I understand your latter paragraph, specially the part: then your way forward will be logically apparent. Although I understand that only code authors can change license and the best fit framework theory. I'd like to stress that my intention is simplifying the amount of licenses present in the project, if possible, this is to say, eventually simplify debian/copyright file. Cheers, Wol Thank you very much for this answer and your point of view. Regards, -- Raúl Sánchez Siles -Proud Debian user- Linux registered user #416098 -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL versions mismatch.
In message he2uoo$om...@ger.gmane.org, Raúl Sánchez Siles rasas...@gmail.com writes The other thing is (I don't know OpenSSL) is that the GPL is incompatible with OpenSSL (which is likely) or is OpenSSL incompatible with the GPL? If it's the GPL which won't let you link to OpenSSL, then add an OpenSSL exemption to v3. As far as I know, this is not possible, in other words, incompatible. This is discussed here: Well, if that's the case, then GPL v2 plus OpenSSL exemption is also impossible :-) Bear in mind I said that it's the AUTHORS who dictate terms. If they say it's okay to link to OpenSSL, then it's okay. End of. (What the GPL says is IRRELEVANT) If all the code is licenced v2+ plus you can link to OpenSSL, then the project can relicence to v3 plus you can link to OpenSSL. At the end of the day, the question is is the GPL the problematic licence?. If it is, then the authors can grant *permissions* over and above the GPL. And it seems to me that they have. I've just looked at those two links, and all they appear to say to me is that the OpenSSL licence is incompatible with the PURE GPL v*2*. They also say that it may be compatible with v3. I assume that the idea was probably that GPLv2 was the best fit framework for the project. It would clarify some things for me. I also think that it may have stopped being the best framework for the project, because please correct me if I'm wrong, it would prevent accepting GPLv3 contributions. This would clash with the need of GPLv2 for the openssl issue. There could be other points which I fail to see and which I appreciate hearing. Besides I'm not sure I understand your latter paragraph, specially the part: then your way forward will be logically apparent. Although I understand that only code authors can change license and the best fit framework theory. From what you've said, I think the way forward is apparent. As you surmise, accepting GPL v3 contributions isn't possible with the current project status saying the project licence is v2. Actually, I think you COULD accept v3 contributions, but to do so you'd need to change the project licence to v3. You'll need to confirm this for yourself, but what you've said to me makes me think the following: 1) All the code is v2+, so changing the project licence to v3 is NOT a problem. 2) The OpenSSL problem is that the GPL v2 does not permit linking to OpenSSL. But all the authors have granted the OpenSSL-exception, so there is no problem linking with OpenSSL (and OpenSSL may be compatible with v3, but seeing as the authors have granted an exception that's irrelevant). So if you WANT to change the project licence to GPL v3 plus the OpenSSL exception there is no problem whatsoever. You can just go ahead and do it RIGHT NOW! if you wish. To re-iterate, your authors have said you can link to OpenSSL, so what the GPL (whatever version) says is irrelevant as far as linking to OpenSSL is concerned. Where I think you've got confused with the GPL is adding/subtracting permissions. The GPL is an all or nothing proposition - you can't grant SOME of the GPL rights and not others and call it GPL'd. But if you grant ALL the GPL rights, there is nothing to stop you granting MORE rights on top of the GPL rights (such as the link to OpenSSL right :-) Cheers, Wol -- Anthony W. Youngman - anth...@thewolery.demon.co.uk -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL versions mismatch.
In message 200911172213.59167.rasas...@gmail.com, Raúl Sánchez Siles rasas...@gmail.com writes Hello: The couple of guys maintaining KVIrc package this is, Kai and me, reckoned recently of a GPL version mismatch between the licence intended to apply to the whole project and the version which each source file is licensed under. We overlooked this problem for some time until the definite notice was given by Eugene Lyubimkin when we request sponsorship from him. Upstream guys have been quite receptive with our license requests, but we are not very fond of license stuff and we are not sure how to hint them. This is how licences are currently arranged in KVIrc: · Project license: GPLv2 adding openssl exception. · Source files in project: almost all GPLv2+, plus a small leftout amount with miscellaneous licenses. Maybe I'm just misleaded but I think it's somewhat confusing having a project license different to each of the project source. Ideally I would use GPLv2+ for everything, i.e., project and source files. The point is that GPLv2+ is IMHO perfectly valid for those source files, but not for the project due the fact that it links against OpenSSL. Even if upstream would be willing to relicense project under GPLv3, they wouldn't be able due to OpenSSL license incompatibility. Then relicence under v2 OR v3. In a way, that's better, anyway (take note that if upstream *does* have any v2-only code, they'll need to deal with it before they can actually relicence to include v3). The other thing is (I don't know OpenSSL) is that the GPL is incompatible with OpenSSL (which is likely) or is OpenSSL incompatible with the GPL? If it's the GPL which won't let you link to OpenSSL, then add an OpenSSL exemption to v3. There is work in progress to remove OpenSSL related code, but this will take time. Meanwhile we'd like to provide some more uploads, and advice upstream about licensing. There is also the option of considering GPLv2 for all, but KVIrc links against Qt4 and I'm not sure how this move would affect in this case. What do you think about this situation? what do you think would be the best or simplest solution? You have to bear in mind that the source file licences are whatever the authors say they are. NOBODY ELSE can change the licence - the GPL does not authorise relicencing. The project maintainers have presumably said v2 compatibility is required for all submissions, therefore the project licence is v2-only. They haven't (THEY CAN'T) impose a v2-only licence, all they've said is that the only licence guaranteed to work as a whole is v2-only. Once you've got your head round the fact that only the code AUTHORS (or rather, owners) can change the licences, and that the project licence is simply the largest proper subset of the individual licences, then your way forward will be logically apparent. Whether you like that way or not is neither here nor there. Thanks a lot, Cheers, Wol -- Anthony W. Youngman - anth...@thewolery.demon.co.uk -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
GPL versions mismatch.
Hello: The couple of guys maintaining KVIrc package this is, Kai and me, reckoned recently of a GPL version mismatch between the licence intended to apply to the whole project and the version which each source file is licensed under. We overlooked this problem for some time until the definite notice was given by Eugene Lyubimkin when we request sponsorship from him. Upstream guys have been quite receptive with our license requests, but we are not very fond of license stuff and we are not sure how to hint them. This is how licences are currently arranged in KVIrc: · Project license: GPLv2 adding openssl exception. · Source files in project: almost all GPLv2+, plus a small leftout amount with miscellaneous licenses. Maybe I'm just misleaded but I think it's somewhat confusing having a project license different to each of the project source. Ideally I would use GPLv2+ for everything, i.e., project and source files. The point is that GPLv2+ is IMHO perfectly valid for those source files, but not for the project due the fact that it links against OpenSSL. Even if upstream would be willing to relicense project under GPLv3, they wouldn't be able due to OpenSSL license incompatibility. There is work in progress to remove OpenSSL related code, but this will take time. Meanwhile we'd like to provide some more uploads, and advice upstream about licensing. There is also the option of considering GPLv2 for all, but KVIrc links against Qt4 and I'm not sure how this move would affect in this case. What do you think about this situation? what do you think would be the best or simplest solution? Thanks a lot, -- Raúl Sánchez Siles -Proud Debian user- Linux registered user #416098 signature.asc Description: This is a digitally signed message part.
