POSSIVEL SPAM-- Re: Binary-only firmware covered by the GPL?
A message that is not in the archive (sent off-list or not yet received): YBtoCC.A.e-C.5maaAB@murphy
@ 30/03/2004 14:09 : wrote Henning Makholm :
Quoted 9 lines
Scripsit Humberto Massa <[email protected]>
Quoted 5 lines
to modify the fw[], at least *legally* is MHO that any recipient/redistributor of the file _can_ and _must_ consider the file in *that* format as the preferred form for modification (pf4m) *and*, considering it the source code, follow the directions of the GPL in respect to modification and redistribution.
Quoted 7 lines
No, law does not work that way. The phrase "preferred form for modification" has a clear enough, if somewhat fuzzy, literal meaning, and one cannot *implicitly* make it mean something that directly contrast to the literal meaning. If nobody *actually* prefers the binary blob for modification, then the binary blob is *not* the preferred form for modification. That's irrespective of whether the copyright holder behaves inconsistently.
Things could be different between jurisdictions, here the doctrine says about the interpretation of contracts, licenses, and law: we obey (1) what is written (2) what is implied by what is written (3) what is derived from what is written via case law (4) what is derived from what is written via the doctrine in law. In that order, and respecting legislative hierarchies.
There is another fail in your reasons here: as I said before, it just _happens_ to happen that fw[] = {} *is* the source code. What we must decide is what to do in the cases where *we don't know*.
After all, what happens is somebody *actually* prefers the binary blob for modification? And, what happens if _the copyright holder_ actually prefers the binary blob for modification? No inconsistency here.
Quoted 7 lines
Quoted 5 lines
* the /status quo/ obtained by observation of the previous item prevails
_untilsomebodyproves_that the fw[] = {} is *not* the source code;
Quoted 7 lines
And Debian's approach to software freedom doesn't work that way either. We treat software as non-free and non-distributable unless and until we see good and self-consistent evidence that it is actually free and distributable. The "burden of proof", to the extent that expression applies, is always on the side that claims that the software in question is OK for Debian to distribute.
NOW you have a good argument. This mostly ends my line of reasoning. In debian: in dubio, non-free. This is not really nice, but it's OK. And I can live with that.
An addendum:
the DFSG does not define source code;
the GPL defines it as: "The source code for a work means the preferred form of the work for making modifications to it.";
the AFL goes further: "The term "Source Code" means the preferred form of the Original Work for making modifications to it and all available documentation describing how to modify the Original Work."; maybe a good definition of source code is something we are needing? in the case of the AFL, not only { 0x0... } could be ruled out as source code, but even some-unknown-dsp-asm-without-comments, too.
Signature · 1 line
br,M
The binary data stored in the .c source file is not the preferred source! If someone really needed to make a change under the current conditions, they would disassemble the binary blob and create a .??? source file. Make the change, and then create a new binary blob. At that point the .??? source file could be considered the preferred source file. Also, if the .c file needs to be maintained, it would be generated from the binary blob. So, the .c file would be derived from something else, it would not be modified by an editor.
I am not saying that someone would not be able to edit the .c file directly. Sure some geek just to prove a point. But it would be un-reasonable to assume the .c file would be the preferred source.
Guy
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Humberto Massa
Sent: Tuesday, March 30, 2004 12:45 PM
To: [email protected]
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: POSSIVEL SPAM-- Re: Binary-only firmware covered by the GPL?
@ 30/03/2004 14:09 : wrote Henning Makholm :
Quoted 9 lines
Scripsit Humberto Massa <[email protected]>
Quoted 5 lines
to modify the fw[], at least *legally* is MHO that any recipient/redistributor of the file _can_ and _must_ consider the file in *that* format as the preferred form for modification (pf4m) *and*, considering it the source code, follow the directions of the GPL in respect to modification and redistribution.
Quoted 7 lines
No, law does not work that way. The phrase "preferred form for modification" has a clear enough, if somewhat fuzzy, literal meaning, and one cannot *implicitly* make it mean something that directly contrast to the literal meaning. If nobody *actually* prefers the binary blob for modification, then the binary blob is *not* the preferred form for modification. That's irrespective of whether the copyright holder behaves inconsistently.
Things could be different between jurisdictions, here the doctrine says about the interpretation of contracts, licenses, and law: we obey
(1) what is written (2) what is implied by what is written (3) what is derived from what is written via case law (4) what is derived from what is written via the doctrine in law. In that order, and respecting legislative hierarchies.
There is another fail in your reasons here: as I said before, it just _happens_ to happen that fw[] = {} *is* the source code. What we must decide is what to do in the cases where *we don't know*.
After all, what happens is somebody *actually* prefers the binary blob for modification? And, what happens if _the copyright holder_ actually prefers the binary blob for modification? No inconsistency here.
Quoted 7 lines
Quoted 5 lines
* the /status quo/ obtained by observation of the previous item prevails
_untilsomebodyproves_that the fw[] = {} is *not* the source code;
Quoted 7 lines
And Debian's approach to software freedom doesn't work that way either. We treat software as non-free and non-distributable unless and until we see good and self-consistent evidence that it is actually free and distributable. The "burden of proof", to the extent that expression applies, is always on the side that claims that the software in question is OK for Debian to distribute.
NOW you have a good argument. This mostly ends my line of reasoning. In debian: in dubio, non-free. This is not really nice, but it's OK. And I can live with that.
An addendum:
the DFSG does not define source code;
the GPL defines it as: "The source code for a work means the preferred form of the work for making modifications to it.";
the AFL goes further: "The term "Source Code" means the preferred form of the Original Work for making modifications to it and all available documentation describing how to modify the Original Work."; maybe a good definition of source code is something we are needing? in the case of the AFL, not only { 0x0... } could be ruled out as source code, but even some-unknown-dsp-asm-without-comments, too.
Signature · 5 lines
br,M - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 7 lines · Humberto Massa
There is another fail in your reasons here: as I said before, it just _happens_ to happen that fw[] = {} *is* the source code. What we must decide is what to do in the cases where *we don't know*.
After all, what happens is somebody *actually* prefers the binary blob for modification? And, what happens if
_thecopyrightholder_actually prefers the binary blob for modification? No inconsistency here.
In fact, I was going to suggest that quite possibly, there really *is* no other option for source, because the target hardware doesn't have a functional enough toolchain, so hand-assembly really *is* the most reasonable thing.
That file isn't any worse than my early '80s Compiler Design class project (done the last year before lex/yacc became available for the class) - one file was a large 247x139x3 (or thereabouts) array of integers, encoding all the shift/reduce productions for a compiler for a Pascal subset that actually generated working (though painfully ugly) code for the IBM S/370 architecture. (The assignment was "Pascal subset plus your choice of one extension" - my teammate and I made the mistake of choosing "Fortran-style mixed-mode arithmetic", that array was literally 1/4 the size before we started that.)
"You are lost in a maze of tiny little shift/reduce productions, all nearly alike"
And yes, the two of us generated the whole table by hand. I admit we did finally break down and write some tools to verify that each line of the table did in fact have the right number of entries, and to add a column of zeros when the number of productions went up.
*Preferred* source format? lex/yacc input files. Did the source ever actually *exist* in that format? Nope... :)