[Discussioni] Re: gnuvox (era: Informazione pubblica: bene comune)

[simo]

On Wed, 2006-07-05 at 10:34 +0200, Nicola A. Grossi wrote:
> simo Scrive: 
> 
> 
> > Io, come parte
> > del comitato A, ne ho fatto un'analisi abbastanza approfondita e secondo
> > me per come e' scritta e' inefficace e probabilmente piu' dannosa che
> > produttiva. 
> 
> Questa analisi si può leggere da qualche parte? 

Segue un estratto di una prima analisi fatta da me e revisionata da
Andrew Tridgell, in realta' successivamente ho arricchito i miei
argomenti a voce durante le conferenze, ma direi che qui c'e' buona
parte di quel che penso sul paragrafo 3 del draft 1.


Paragraph 3

This paragraph is the most controversial in this section.  The central controversy could be summarized 
as “should the TiVo series2 be an acceptable use of GPL software?”. Some people (most notably Linus 
Torvalds) have given a clear “yes” to this, while others agree that the GPL should take a strong stand on 
these  types   of  techniques,  to  ensure  that  software   cannot   just  be  read,  but   can  also  be   used   after 
modification.
There is also considerable concern that the wording may inadvertently catch common uses of GPL 
software that are not intended to be caught. If the wording could be tightened to make the scope clearer 
that would be good.
The wording “codes necessary to install and/or execute the source code” received some comments. 
Could change to “object code” or just delete “the source code of” leaving “execute the work”.  It makes 
no sense to execute the source of many works. This may also be read as implying that no codes to 
execute the Object Code are necessary which would defeat the whole paragraphs intention.
Some   comments   are   concerned   that   the   “necessary   to   install”   wording   might   preclude   uses   in 
environments which do not have normal installers (such as some embedded environments) or on write 
once read many devices like a ROM. This point is also inflexible, it is conceivable that the installation 
or execution of code is blocked only by the default machine BIOS (or other mechanism) but that this 
mechanism can be easily bypassed by a firmware upgrade or other change to the apparatus. Some 
wording that allows not to release private encryption keys if there is a “reasonable way to modify the 
default machine behavior so that the code can be installed and executed, as long as such method does 
not void the warranty” would make the situation clearer). See comments 447, 944 (ex. 3). 
There is legitimate concern over the words: “perhaps modified by you” and “except as altered by your 
modifications”.   It   is   really   easy   to   interpret   the   text   to   say   that   you   are   required   to   release 
encryption/authorization codes required by the original work, but NOT for a modified work. 
The previous three concerns may be addressed with a change of the text in the following way:
        “Complete Corresponding Source Code also includes any encryption or authorization codes 
necessary to install, on upgradeable hardware devices, or execute any work based on this source code in 
the recommended or principal context of use, such that all functionality of the work may be preserved”.
Comment 658 asks for "all circumstances" to be changed to "all circumstances and for all potential 
users" to cover a possible interpretation that the “all circumstances” applies only to the existing user.
In the quite large “release all your keys” argument, besides clear misunderstandings of the provision, 
there can be devised a couple of legitimate concerns.
The phrase “It also includes any decryption codes necessary to access or unseal the work's output.” may 
be actually interpreted to require the release of personal private or shared encryption keys. The text can 
be modified to state “It also includes any decryption codes necessary to access or unseal the work's 
output by whoever is the intended receiver of the output”. Another option is to remove this phrase as it 
is easily circumvented by placing the keys in a hardware device so that the user “has” the key even if he 
can't know them. In the end given the current development of multimedia file formats there is the 
legitimate concern that such provision may make it impossible to develop compatible GPLv3 software 
like mplayer, xine, totem, etc ... and that may harm the free software community more than the good it 
may bring.
Another legitimate concern about this point is the fear that a third party may use the signature of a 
binary or binary package to enable restrictions, so that the original author may be somehow forced to 
release their own keys.
This concern in fact reveals a weakness in these provisions which is: “who” is in charge to release said 
codes ?
Our interpretation is that only the distributor of a combined “hardware” + “software” device can be 
really affected by these provisions. There is a clean scenario where these obligations can be possibly 
circumvented, if that scenario is realistic perhaps this provision may fail to hit the very target they have 
been conceived to address, and that will render them not only useless but perhaps harmful for the 
unintended consequences on legitimate uses of the software.
The scenario is the following:
    1. Vendor A and B team up under the cover to provide hardware and software as different entities.
    2. Vendor A sells the hardware with an embedded proprietary software loader and verifier. This 
        appliance just connects to Vendor B web sites and download the GPLv3 software, verifies it 
        with the Vendor B signature and deny to execute any software that is not signed by Vendor B.
    3. Vendor B provides the software as is, and make it available to anyone, and makes it so that it 
        can be executed on any platform without  requiring to verify the signature
Vendor A is not distributing the GPLv3 program, so it can't be requested to release any key, Vendor A 
does not even have the Vendor B private signing key. Vendor B distributes a perfectly functional Object 
Code, in all of it's components, in fact it can be run on any platform without any change. It is unlikely 
that you can ask for his own private keys when asking for the complete source code as Vendor B is 
officially not aware of what Vendor A does and it is not willingly preventing any use of the code.
In the case the GPLv3 is intended to require Vendor B to release it's private keys the license will 
become a real Trojan Horse because anyone will be able to build up a system that uses third party 
signatures to force them to release their private keys. This is not acceptable, as these keys may have 
been used to encrypt private communications and such a provision may be easily constructed to destroy 
the Privacy of any communication based on Public/Private keys encrypting/signing mechanism.
This problem need to be addressed properly or defeat in preventing this kind of use of GPLv3 software 
should be recognized.
Issue 881 gathers most of the comments that refer to this paragraph.


E' un po' denso perche' ho copiato e incollato, ma credo sia comprensibile.

Simo.