<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
* simo wrote, On 28/09/06 01:06:
<blockquote cite="mid1159402013.18314.59.camel@localhost.localdomain"
type="cite">
<pre wrap="">On Wed, 2006-09-27 at 19:13 +0100, Niall Douglas wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 26 Sep 2006 at 22:54, Bjoern Schiessle wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
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.<br>
<blockquote cite="mid1159402013.18314.59.camel@localhost.localdomain"
type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">We all know what it means, it's just it's ambiguous. Under a tight
interpretation, it means you must disclose signing keys.
</pre>
</blockquote>
<pre wrap=""><!---->
No, only under a broad and tendentious interpretation.
</pre>
</blockquote>
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.<br>
<blockquote cite="mid1159402013.18314.59.camel@localhost.localdomain"
type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
replace SSL (+HTTP) with S/MIME (+SMTP)<br>
<blockquote cite="mid1159402013.18314.59.camel@localhost.localdomain"
type="cite">
<pre wrap="">
2nd you don't need a *special* password to unpack/read/copy the source
code. The SSL layer is transparent and accessible to anyone.
</pre>
</blockquote>
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.<br>
<blockquote cite="mid1159402013.18314.59.camel@localhost.localdomain"
type="cite">
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
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.<br>
<blockquote cite="mid1159402013.18314.59.camel@localhost.localdomain"
type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
Why not waiting till GPLv4 is out then?
If you see problems and want them fixed at least please file a bug :-)
</pre>
</blockquote>
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?<br>
<br>
Sam
</body>
</html>