Derivative/collective works and OSL

[Chuck Swiger]

On Feb 7, 2005, at 10:38 AM, David Dillard wrote:
>> As far as the computer or the end-user running the compiled
>> program is concerned, source-code comments are invisible,
>> non-functional, and have no meaning or impact on the behavior
>> of the program.
>
> I'm not talking about comments, I'm talking about function names, 
> variable
> names, class names, etc.  All of which have no meaning to a computer, 
> but
> hopefully have great meaning to a developer.

Modern object formats like ELF encode function names, variable names, 
class names, source code file name and line # information, and more 
into the symbol table (SHT_SYMTAB), dynamic relocation information 
(SHT_HASH, SHT_DYNAMIC, etc) and other sections (SHT_NOTE).

Even if you strip debugging information out, you will still have 
information all external symbols and all dynamicly relocatable entry 
points.

[ ... ]
>> And just how would this compiler preprocessor work?  Would it
>> not extract the contents of the tarball precisely as I'd said
>> above...?
>
> Exactly.  Which is why saying that "you can't compile a tarball" has 
> no real meaning.  Thus, why go there?

I was responding to the comment "...and if when compiled it is still a 
collective work, then it is not derivative of any of the works 
contained in the tarball."

I make a distinction between what the compiler toolchain does and what 
the compiler itself (cc1) does.  The C preprocessor makes 
transformations to source code (macro expansion, resolving #include 
references, conditional compilation, etc) which change the input source 
code into a format which the compiler proper can handle.

If cpp can untar or unzip compressed source files, fine, but the 
compiler proper doesn't see that as input.

>> There are filesystems out there which compress files
>> transparently to the user, and decompress the data when the
>> file is accessed.  The fact that an compressed file has a
>> different sequence of bits on disk than an uncompressed file
>> is a matter of packaging: the contents of the file remain the
>> same.  Tar, zip, and other archive formats used for source
>> code are lossless, so you can get the original contents back
>> exactly.  Even with the comments, too.  :-)
>
> At the user level this is true.  But it has to go thru a transformation
> process.  Read those disk sectors directly and the contents of the 
> file are
> not the same (please keep in mind that I work for a company that does 
> things like that in products ;-)).

Indeed you do.  :-)

If we compare reading the disk sectors before and after defragmenting a 
filesystem, one would discover that lots of them have changed.  Have we 
changed the contents of any the files by doing so?  Or is the 
transformation process of defragging a disk completely transparent...?

-- 
-Chuck