Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy

2007-02-02 Thread Kevin B. McCarty
Don Armstrong wrote:

 Unfortunatly, there's not much that can be done to protect us from
 this latter case. If upstream wants to lie about which is the prefered
 form for modification, our choice is either to stop distributing or
 pony up when they sue us for violating their license and prove that
 they're lying. [But again, this is about determining which form is the
 prefered form for modification, not about what we do once we know what
 that is.]

If upstream sued Debian for violating their license for this reason,
wouldn't the onus of proof then be upon upstream to prove that they were
lying about what was their preferred form of modification?  Given that,
I'm not sure a judge would be very sympathetic to upstream's case ;-)

best regards,

-- 
Kevin B. McCarty [EMAIL PROTECTED]   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: GPLed software with no true source. Was: Bug#402650: ITP:mozilla-foxyproxy

2007-02-02 Thread Kevin B. McCarty
Evan Prodromou wrote:

 On Tue, 2007-30-01 at 11:54 -0800, Don Armstrong wrote:
 
 This refrain keeps getting repeated, but still no one has explained
 how distributing a form of the work which is _not_ the prefered form
 for modification satisfies section 3 of the GPL:
 
 So, I think we all readily admit that _some_ transformations on the
 original source (like compression) are acceptable. The distributed
 source code does not need to be bitwise identical with the source edited
 by the developer to be the preferred form.

s/compression/lossless compression/

 I think we'd all be pretty comfortable with some other transforms, like
 \r\n - \n line ending conversion or character set changes.

The commonality between these changes and lossless compression is that
all are 100% reversible, assuming one knows what transformation
operations have been performed.  (Well, the character set changes I
suppose depend on exactly what the original and final versions looked
like; UTF-8 - ISO 8859-1 is obviously not reversible if the original
was in Japanese.)

Stripping whitespace on the other hand is not reversible.  One may be
able to add whitespace back (e.g. with indent) but there is no
guarantee that the result is identical to the original version of the
file before whitespace stripping.

That said, personally (IANAL) I'd consider whitespace stripping to be a
non-issue.  After a change that is trivial for any downstream recipient
of the code to make (running the afore-mentioned indent), the
whitespace-stripped code is transformed into a Javascript file that is
functionally identical to the original even if not bit-for-bit
identical.  For most people, probably including upstream, the result
would be just as much a preferred form for modification as the true
original was.  On the other hand, transforming a UTF-8 Japanese document
to ISO 8859-1 would obviously *not* result in something that upstream
(or anyone else) would consider a preferred form for modification.

My main concern in the particular case of mozilla-foxyproxy would be (as
someone else mentioned) that comments in the code may have also been
stripped to save space.  I would consider redistribution of such
comment-stripped code to be a violation of the GPL in spirit as well as
in letter.

best regards,

-- 
Kevin B. McCarty [EMAIL PROTECTED]   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy

2007-02-02 Thread Don Armstrong
On Fri, 02 Feb 2007, Kevin B. McCarty wrote:
 If upstream sued Debian for violating their license for this reason,
 wouldn't the onus of proof then be upon upstream to prove that they
 were lying about what was their preferred form of modification?
 Given that, I'm not sure a judge would be very sympathetic to
 upstream's case ;-)

Yeah, in the case where there's a single copyright holder, it's a
pretty useless tactic. The problem only really comes into play when
there are multiple copyright holders. [Of course, that's the state of
a lot of works in Debian, but possibly not the one that originally
started this thread.]


Don Armstrong

-- 
I leave the show floor, but not before a pack of caffeinated Jolt gum
is thrust at me by a hyperactive girl screaming, Chew more! Do more!
The American will to consume more and produce more personified in a
stick of gum. I grab it.
 -- Chad Dickerson

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: GPLed software with no true source. Was: Bug#402650: ITP:mozilla-foxyproxy

2007-02-02 Thread Ben Finney
Kevin B. McCarty [EMAIL PROTECTED] writes:

 Evan Prodromou wrote:

 personally (IANAL) I'd consider whitespace stripping to be a
 non-issue.  After a change that is trivial for any downstream
 recipient of the code to make (running the afore-mentioned
 indent), the whitespace-stripped code is transformed into a
 Javascript file that is functionally identical to the original even
 if not bit-for-bit identical.

Careful with this. functionally identical is not what is needed; we
need the work *in the form that's preferred for modification*,
including all comments and other human-to-human communication. The
entire point of getting the source code is that it's what the *human*
needs as a programmer, not that it's functionally identical to the
original program.

In the case of whitespace stripping, specifically for ECMAscript (and
not, e.g., Python), the whitespace *can* be stripped and re-added. But
that doesn't mean that any change resulting in a functionally
identical version of the work satisfies the preferred form of the
work for making modifications to it test.

Hence I don't think it's helpful to ask whether what the recipient
receives is functionally identical. Source code is a communication
from one programmer to another, much more than it is a communication
from one programmer to a CPU.

-- 
 \   He who wonders discovers that this in itself is wonder.  -- |
  `\   Maurits Cornelis Escher |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: GPLed software with no true source. Was: Bug#402650: ITP:mozilla-foxyproxy

2007-02-02 Thread Kevin B. McCarty
Ben Finney wrote:

 Kevin B. McCarty [EMAIL PROTECTED] writes:

 personally (IANAL) I'd consider whitespace stripping to be a
 non-issue.  After a change that is trivial for any downstream
 recipient of the code to make (running the afore-mentioned
 indent), the whitespace-stripped code is transformed into a
 Javascript file that is functionally identical to the original even
 if not bit-for-bit identical.
 
 Careful with this. functionally identical is not what is needed; we
 need the work *in the form that's preferred for modification*,
 including all comments and other human-to-human communication. The
 entire point of getting the source code is that it's what the *human*
 needs as a programmer, not that it's functionally identical to the
 original program.

Yes, I should have been clearer.  By functionally identical, I meant
from the point of view of a person as well as of a machine.  I
completely agree with you that stripping comments is evil.  Likewise for
obfuscating variable names, removing whitespace that can't trivially be
put back, etc.

best regards,

-- 
Kevin B. McCarty [EMAIL PROTECTED]   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]