Niall Douglas s_sourceforge@nedprod.com wrote:
They then go on to say that in their opinion, you can't write any wording which wouldn't have unintended consequences and therefore you should drop the attempt. That's going too far IMHO, but I do WHOLEHEARTEDLY agree that the wording is FAR, FAR too vague.
For example, as far as I understood revision 2, it COULD be incompatible with BSD licensing,
The BSD Licence allows you to do everything you want with the software even to use it with a licence which allows you nothing, so how could it be incompatible with the GPLv3?
COULD be incompatible with authentication signing keys (ie; this binary was made by me),
I can't see how you can read this assumption out of draft 2 of GPLv3?
Draf2 of GPLv3 says: "The Corresponding Source also includes any encryption or authorization keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances."
If you sign a program so that i know that the program comes from you i can "install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances." So you don't have to give me your signing key.
COULD be incompatible with permitting GPL v3 binaries to be transferred over a SSL connection etc.
If you transfer something over SSL from person A to person B than person B will be able to execute and/or modify the code as permitted by the GPL. So i don't see how it could be prohibited by GPLv3.
I would be interested to know how you came to such conclusions. Maybe you can quote some sections from draft2 of GPLv3 to back up your opinion?
And you know what happens next if the FSF doesn't stop? Yep, the kernel developer's own 'enhancement' of GPL v2.
I don't think so. I seems like the kernel hackers are quite happy with their licence (GPLv2) and remember, they would need the approval from all contributors to change the licence.
Cheers, Bjoern
On 26 Sep 2006 at 22:54, Bjoern Schiessle wrote:
They then go on to say that in their opinion, you can't write any wording which wouldn't have unintended consequences and therefore you should drop the attempt. That's going too far IMHO, but I do WHOLEHEARTEDLY agree that the wording is FAR, FAR too vague.
For example, as far as I understood revision 2, it COULD be incompatible with BSD licensing,
The BSD Licence allows you to do everything you want with the software even to use it with a licence which allows you nothing, so how could it be incompatible with the GPLv3?
It's more the other way round. In section 5.[2] it says:
b) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License must apply, unmodified except as permitted by section 7 below, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
Now that SHOULD read "You must license the entire work, as a whole, under THE TERMS OF this License to anyone who comes into possession of a copy". Otherwise it may be interpreted that any libraries under a FreeBSD license must be relicensed as GPL v3 if any GPL v3 code uses them.
It should be noted that v2 of the GPL uses precisely this clearer phrasing. Or perhaps a clarification that this does not need to apply to parts with a different license which doesn't require anything the GPL v3 does not permit (eg; no source release).
COULD be incompatible with authentication signing keys (ie; this binary was made by me),
I can't see how you can read this assumption out of draft 2 of GPLv3?
Draf2 of GPLv3 says: "The Corresponding Source also includes any encryption or authorization keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances."
If you sign a program so that i know that the program comes from you i can "install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances." So you don't have to give me your signing key.
Ah but that doesn't permit "all the same functionality" now does it! It means that if you were to run a signing authenticator, you'd get different functionality.
We all know what it means, it's just it's ambiguous. Under a tight interpretation, it means you must disclose signing keys.
COULD be incompatible with permitting GPL v3 binaries to be transferred over a SSL connection etc.
If you transfer something over SSL from person A to person B than person B will be able to execute and/or modify the code as permitted by the GPL. So i don't see how it could be prohibited by GPLv3.
Section 6.[3]:
The Corresponding Source conveyed in accord with this section must be in a format that is publicly documented, with an implementation available to the public in source code form, and must require no special password or key for unpacking, reading or copying.
One could interpret a SSL connection as a form of encrypted container. Therefore, transferring a file over it DOES require a special password or key for unpacking/copying. Of course, SSL connections generate a random once-off key per connection to which the user normally has no access.
Again, we know what is intended. The problem is, how precisely do you disambiguate an encrypted zip file from a SSL connection which copies it between computers? At a binary level there isn't really much difference between what is being copied and that which copies it. Again, we simply need clarification here.
And you know what happens next if the FSF doesn't stop? Yep, the kernel developer's own 'enhancement' of GPL v2.
I don't think so. I seems like the kernel hackers are quite happy with their licence (GPLv2) and remember, they would need the approval from all contributors to change the licence.
From what I understand, they're content but not happy. Improvements
would be useful. Most kernel developers don't like tivoisation either, it's just seeing how to stop it is hard and if you can instead ensure that code improvements are recontributed back to the community (which I think generally are), it's not a bad compromise.
Also, ultimately, there could be actually useful implementations of trusted computing. Hard to see them currently, but why rule them out entirely before we know for sure. Better wait another five years and then decide. In the meantime, software patents are far more of a problem.
On 27 Sep 2006 at 8:19, Stefano Maffulli wrote:
your statements are extremely important and deserve attention because GPLv3 cannot afford leaving ambiguity or generate incompatibility with what you say below.
See above.
For example, as far as I understood revision 2, it COULD be incompatible with BSD licensing, COULD be incompatible with authentication signing keys (ie; this binary was made by me), COULD be incompatible with permitting GPL v3 binaries to be transferred over a SSL connection
Can you please point out the precise wordings that in your opinion could lead to such incompatibilities? I couldn't see these problems (although I found others and submitted comments). Did you submit your comments?
No. I was waiting for draft 3 to see if they'd get fixed on their own. I'm not a fan of the GPL, everyone knows that, so I was doubting they'd take much notice.
Cheers, Niall
On Wed, 2006-09-27 at 19:13 +0100, Niall Douglas wrote:
On 26 Sep 2006 at 22:54, Bjoern Schiessle wrote:
Draf2 of GPLv3 says: "The Corresponding Source also includes any encryption or authorization keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances."
If you sign a program so that i know that the program comes from you i can "install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances." So you don't have to give me your signing key.
Ah but that doesn't permit "all the same functionality" now does it! It means that if you were to run a signing authenticator, you'd get different functionality.
You are confusing "different functionality" (of the GPLed program) with different output (of the signing authenticator). They are 2 different things, the GPLv3 draft obviously can only refer to the functionality of the GPLv3 program it covers.
We all know what it means, it's just it's ambiguous. Under a tight interpretation, it means you must disclose signing keys.
No, only under a broad and tendentious interpretation.
COULD be incompatible with permitting GPL v3 binaries to be transferred over a SSL connection etc.
If you transfer something over SSL from person A to person B than person B will be able to execute and/or modify the code as permitted by the GPL. So i don't see how it could be prohibited by GPLv3.
Section 6.[3]:
The Corresponding Source conveyed in accord with this section must be in a format that is publicly documented, with an implementation available to the public in source code form, and must require no special password or key for unpacking, reading or copying.
One could interpret a SSL connection as a form of encrypted container. Therefore, transferring a file over it DOES require a special password or key for unpacking/copying. Of course, SSL connections generate a random once-off key per connection to which the user normally has no access.
This is complete nonsense.
1st there is no way you can interpret an SSL connection as a container, as it is a mean. You never keep your file on your disk as a network trace of an SSL connection.
2nd you don't need a *special* password to unpack/read/copy the source code. The SSL layer is transparent and accessible to anyone.
3rd SSL is also publicly documented with an implementation available in source code form, so even if some silly person could conceive and convince someone that SSL is a container you have no problems under this license.
Again, we know what is intended. The problem is, how precisely do you disambiguate an encrypted zip file from a SSL connection which copies it between computers? At a binary level there isn't really much difference between what is being copied and that which copies it. Again, we simply need clarification here.
There is a big difference between the two, there is no need to clarify further. If you really want to be silly you can go down and require to include a whole dictionary with the license, to be sure each word meaning is really really really clear.
And you know what happens next if the FSF doesn't stop? Yep, the kernel developer's own 'enhancement' of GPL v2.
I don't think so. I seems like the kernel hackers are quite happy with their licence (GPLv2) and remember, they would need the approval from all contributors to change the licence.
From what I understand, they're content but not happy. Improvements would be useful. Most kernel developers don't like tivoisation either, it's just seeing how to stop it is hard and if you can instead ensure that code improvements are recontributed back to the community (which I think generally are), it's not a bad compromise.
Also, ultimately, there could be actually useful implementations of trusted computing. Hard to see them currently, but why rule them out entirely before we know for sure. Better wait another five years and then decide. In the meantime, software patents are far more of a problem.
I can't conceive any good use of trust computing that requires something like the tivoization. You need proof that something is what it it is, that doesn't mean preventing the user to run something else. If it is compulsory it's not ok, if the user can choose than it is ok. The GPLv3 draft does not restrict programs where the final user has choice.
No. I was waiting for draft 3 to see if they'd get fixed on their own. I'm not a fan of the GPL, everyone knows that, so I was doubting they'd take much notice.
Why not waiting till GPLv4 is out then? If you see problems and want them fixed at least please file a bug :-)
Simo.
On 27 Sep 2006 at 20:06, simo wrote:
"The Corresponding Source also includes any encryption or authorization keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances."
If you sign a program so that i know that the program comes from you i can "install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances." So you don't have to give me your signing key.
Ah but that doesn't permit "all the same functionality" now does it! It means that if you were to run a signing authenticator, you'd get different functionality.
You are confusing "different functionality" (of the GPLed program) with different output (of the signing authenticator). They are 2 different things, the GPLv3 draft obviously can only refer to the functionality of the GPLv3 program it covers.
Of course I know that! It's obvious to any normal, rational, sane human being!
However, the GPL is not an ordinary document. It's a LEGAL document. Legal documents are rules for lawyers to work around, and if there is ANY ambiguity then it's a BAD legal document.
To a judge - and let us remember that most judges are old, very technologically unaware and rather pedantic - to them, the difference between a program, its DLL's and the shell which runs it is virtually none. As an example, you try explaining why a program signed differently functions IDENTICALLY to an old person. They will surely say "but no, when you run it it shows different text on the screen. This is a difference".
We all know what it means, it's just it's ambiguous. Under a tight interpretation, it means you must disclose signing keys.
No, only under a broad and tendentious interpretation.
Which is the entire point of the legal profession!
One could interpret a SSL connection as a form of encrypted container. Therefore, transferring a file over it DOES require a special password or key for unpacking/copying. Of course, SSL connections generate a random once-off key per connection to which the user normally has no access.
This is complete nonsense.
1st there is no way you can interpret an SSL connection as a container, as it is a mean. You never keep your file on your disk as a network trace of an SSL connection.
So you're telling me that a network connection does not package up chunks of data into packets and unpack them on the receiving end?
I see no difference from a split RAR file commonly used on binary newsgroups. It's just a TCP/IP stack does the reassembly for you.
2nd you don't need a *special* password to unpack/read/copy the source code. The SSL layer is transparent and accessible to anyone.
Of course you do! Otherwise anyone could listen in to your data stream! Just because it's generated randomly during Diffie-Hellman negotation does not make it unspecial!
3rd SSL is also publicly documented with an implementation available in source code form, so even if some silly person could conceive and convince someone that SSL is a container you have no problems under this license.
Lawyers exist to FUD. Do you really want to dispute this?
Again, we know what is intended. The problem is, how precisely do you disambiguate an encrypted zip file from a SSL connection which copies it between computers? At a binary level there isn't really much difference between what is being copied and that which copies it. Again, we simply need clarification here.
There is a big difference between the two, there is no need to clarify further. If you really want to be silly you can go down and require to include a whole dictionary with the license, to be sure each word meaning is really really really clear.
That's not necessary. It's easiest just to drop the key disclosure requirement altogether. Far better actually to require that signing binaries can be bypassed by asking the user. For example, if I replace the flash image on a tivo box, I'd be okay with it flashing a light to say it's an unsafe image and then you have to press an extra button to make it go.
We're talking less than half a percent of tivo users here. Pressing an extra button every time they turn it on isn't the end of the world for power users.
Also, ultimately, there could be actually useful implementations of trusted computing. Hard to see them currently, but why rule them out entirely before we know for sure. Better wait another five years and then decide. In the meantime, software patents are far more of a problem.
I can't conceive any good use of trust computing that requires something like the tivoization. You need proof that something is what it it is, that doesn't mean preventing the user to run something else. If it is compulsory it's not ok, if the user can choose than it is ok.
Trusted computing doesn't necessarily deny choice. Much like nuclear weapons don't necessarily mean nuclear war. It may have use we can't see yet. I personally don't want a knee-jerk reaction.
No. I was waiting for draft 3 to see if they'd get fixed on their own. I'm not a fan of the GPL, everyone knows that, so I was doubting they'd take much notice.
Why not waiting till GPLv4 is out then? If you see problems and want them fixed at least please file a bug :-)
Ah, but in some ways I see the point of the GPL dying. In the long run, we are better off without the GPL at all. I'm just not sure when the GPL will outlive its usefulness.
Cheers, Niall
* simo wrote, On 28/09/06 01:06:
On Wed, 2006-09-27 at 19:13 +0100, Niall Douglas wrote:
On 26 Sep 2006 at 22:54, Bjoern Schiessle wrote:
Draf2 of GPLv3 says: "The Corresponding Source also includes any encryption or authorization keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances."
If you sign a program so that i know that the program comes from you i can "install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances." So you don't have to give me your signing key.
Ah but that doesn't permit "all the same functionality" now does it! It means that if you were to run a signing authenticator, you'd get different functionality.
You are confusing "different functionality" (of the GPLed program) with different output (of the signing authenticator). They are 2 different things, the GPLv3 draft obviously can only refer to the functionality of the GPLv3 program it covers.
But in my reading still requires the distributor to puts generous constraints on the use of the signing authenticator output if they retain the right to distribute.
We all know what it means, it's just it's ambiguous. Under a tight interpretation, it means you must disclose signing keys.
No, only under a broad and tendentious interpretation.
Lets not debate over ambiguous/broad-and-tendentious but consider how many people's ambiguous is your broad-and-tendentious - which surely is the point. And lets pray that one of them is not a judge - or, lets discuss it and see if it needs fixing.
1st there is no way you can interpret an SSL connection as a container, as it is a mean. You never keep your file on your disk as a network trace of an SSL connection.
replace SSL (+HTTP) with S/MIME (+SMTP)
2nd you don't need a *special* password to unpack/read/copy the source code. The SSL layer is transparent and accessible to anyone.
replace SSL (+HTTP) with S/MIME (+SMTP) and a per-recipient encryption with a key generated by the distributor, which key contains copyrighted data and trademarks in the accompanying signed-key certificate.
3rd SSL is also publicly documented with an implementation available in source code form, so even if some silly person could conceive and convince someone that SSL is a container you have no problems under this license.
Again, we know what is intended. The problem is, how precisely do you disambiguate an encrypted zip file from a SSL connection which copies it between computers? At a binary level there isn't really much difference between what is being copied and that which copies it. Again, we simply need clarification here.
There is a big difference between the two, there is no need to clarify further. If you really want to be silly you can go down and require to include a whole dictionary with the license, to be sure each word meaning is really really really clear.
I don't like your calling Niall silly. The point is (I thought) during the GPL3 draft process is that we need to explore ways in which other peoples future silliness will be upheld in law as a valid interpretation. Save your insults for those who thus overthrow the GPL3 when its too late, not those who try to find such "silliness" within the GPL3 during it's draft - unless you think the GPL3 wording is a done deal and you are merely preparing the way to publish a pre-decided wording.
No. I was waiting for draft 3 to see if they'd get fixed on their own. I'm not a fan of the GPL, everyone knows that, so I was doubting they'd take much notice.
Why not waiting till GPLv4 is out then? If you see problems and want them fixed at least please file a bug :-)
Or discuss them on an mailing list before submitting the bug, and then get insulted to hell till you feel disaffected, maybe, don't you think?
Sam
But in my reading still requires the distributor to puts generous constraints on the use of the signing authenticator output if they retain the right to distribute.
A signature key is not a authorization key. The key is not needed to use the program.
2nd you don't need a *special* password to unpack/read/copy the source code. The SSL layer is transparent and accessible to anyone.
replace SSL (+HTTP) with S/MIME (+SMTP) and a per-recipient encryption with a key generated by the distributor, which key contains copyrighted data and trademarks in the accompanying signed-key certificate.
You don't need a special password to use/copy/modify/distribute the program once it is unpacked.
Cheers.
Thank you Niall. Some of your comments expose bits of words that deserve being clarified.
On Wed, 2006-09-27 at 19:13 +0100, Niall Douglas wrote:
No. I was waiting for draft 3 to see if they'd get fixed on their own. I'm not a fan of the GPL, everyone knows that, so I was doubting they'd take much notice.
But if you don't raise your voice and open issues *now* draft 3 *could* (being highly hypothetical here, it's not likely to happen) be declared final and the process stopped because there are no open issues. So please submit these issues or at least check if others have already mentioned them and click simply on 'I agree'. It's a very simple step that will help us all having a good license. If nobody comments now, it will be late when the license will be declared final.
It's not true that comments are ignored. Just a simple example: the problem with distribution of binaries via torretn in draft 1 was pointed out not by Eben, nor RMS nor by anybody in the Committees but by the public comment process. Draft 2, point 6e (Conveying non-source using peer-to-peer) addresses the issue.
thank you stef
I decided to do some of the work for you, since I was already checking the state of my comment :)
On Wed, 2006-09-27 at 19:13 +0100, Niall Douglas wrote:
It's more the other way round. In section 5.[2] it says:
b) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License must apply, unmodified except as permitted by section 7 below, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
Now that SHOULD read "You must license the entire work, as a whole, under THE TERMS OF this License to anyone who comes into possession of a copy". Otherwise it may be interpreted that any libraries under a FreeBSD license must be relicensed as GPL v3 if any GPL v3 code uses them.
This comment has not been made yet and IMHO it is worth making.
Draf2 of GPLv3 says: "The Corresponding Source also includes any encryption or authorization keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances."
If you sign a program so that i know that the program comes from you i can "install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances." So you don't have to give me your signing key.
Ah but that doesn't permit "all the same functionality" now does it! It means that if you were to run a signing authenticator, you'd get different functionality.
I don't read it this way, but there are lots of comments around that bit of text which means that further clarifications are needed. I don't know what a 'signing authenticator' is so I cannot help further.
Section 6.[3]:
The Corresponding Source conveyed in accord with this section must be in a format that is publicly documented, with an implementation available to the public in source code form, and must require no special password or key for unpacking, reading or copying.
One could interpret a SSL connection as a form of encrypted container. Therefore, transferring a file over it DOES require a special password or key for unpacking/copying. Of course, SSL connections generate a random once-off key per connection to which the user normally has no access.
I agree with Simo: SSL is not a container. S/MIME is more interesting, but the recipient is supposed to have the key to decrypt the tar and do whatever the license allows him to do. But again, this is worth commenting on, because the S/MIME case can open different scenarios that I cannot notice now. There is a comment about this wording, but it is worth discussing it more deeply on http://gplv3.fsf.org/comments/gplv3-draft-2.html
cheers stef