SW copyright: source/object identical, & linking question.
Karsten M. Self
First: under US copyright law, are source code and object code
considered the identical work (different "translations", as it were), or
is object code considered a "derived work"? I would appreciate
statutory or case law citation if possible. Definition at 17 U.S.C. 101
seems to indicate no distinction.
Second: Is there any case law dealing with copyright WRT linking
libraries with source code?
Is there a distinction between source code and a binary executable which
has been statically linked with third-party libraries, as "different
works", possibly one as a derivative work of the other?
Is there a distinction between a statically linked and a dynamically
linked executable, both linked to the same third-party libraries, as
"different works" under copyright?
Is there a distinction between executables, either statically or
dynamically linked, which have the same source but are linked to
different libraries, as "different works" under copyright?
Is there a distinction between an executable, either statically or
dynamically linked, as a file on disk, and the same executable loaded
into RAM as an executing process, as "different works" under copyright?
In all cases, does a linked executable represent a derived work of the
source code, of the library, or both, or none?
I would very much appreciate an example of a license for a proprietary
(non "free software", GPLd, or otherwise publicly licensed) library,
which indicates copyright terms or specific license granted works which
link against the library. Checking available licenses (Microsoft VC++,
accompanying book), I find no specific mention of library linking
license terms.
TIA
--
Karsten M. Self (kms...@ix.netcom.com)
What part of "Gestalt" don't you understand?
Welchen Teil von "Gestalt" verstehen Sie nicht?
web: http://www.netcom.com/~kmself
SAS/Linux: http://www.netcom.com/~kmself/SAS/SAS4Linux.html
11:01pm up 31 days, 22:50, 4 users, load average: 1.71, 1.61, 1.48
Bruce Hayden
>
> Two questions concerning copyright as it applies to software.
>
> First: under US copyright law, are source code and object code
> considered the identical work (different "translations", as it were), or
> is object code considered a "derived work"? I would appreciate
> statutory or case law citation if possible. Definition at 17 U.S.C. 101
> seems to indicate no distinction.
I don't think that you are going to find such a cite. In any case,
I do believe that you could find a case where the source code was
protected by copyright, but not the object code. For example,
if you changed the variable names, and added comments, while this
may be a derivative work, it surely contains original expression,
yet the object code would be strikingly similar.
> Second: Is there any case law dealing with copyright WRT linking
> libraries with source code?
>
> Is there a distinction between source code and a binary executable which
> has been statically linked with third-party libraries, as "different
> works", possibly one as a derivative work of the other?
>
> Is there a distinction between a statically linked and a dynamically
> linked executable, both linked to the same third-party libraries, as
> "different works" under copyright?
I am not sure that the difference in linking would be sufficient
original expression to constitute separate works (and thus
qualify as derivative works).
> Is there a distinction between executables, either statically or
> dynamically linked, which have the same source but are linked to
> different libraries, as "different works" under copyright?
>
> Is there a distinction between an executable, either statically or
> dynamically linked, as a file on disk, and the same executable loaded
> into RAM as an executing process, as "different works" under copyright?
Probably not, esp. in view of 17 USC 117.
> In all cases, does a linked executable represent a derived work of the
> source code, of the library, or both, or none?
Probably not. Probably considered the original work. Derivative works
require additional original expression.
--
--------------------------------------------------------------------
The preceding was not a legal opinion, and is not my employer's.
Original portions Copyright 1998 Bruce E. Hayden,all rights reserved
My work may be copied in whole or part, with proper attribution,
as long as the copying is not for commercial gain.
--------------------------------------------------------------------
Bruce E. Hayden bha...@acm.org
Phoenix, Arizona bha...@ieee.org
===now operational again============>bha...@copatlaw.com
Bob Stock
>First: under US copyright law, are source code and object code
>considered the identical work (different "translations", as it were), or
>is object code considered a "derived work"? I would appreciate
>statutory or case law citation if possible. Definition at 17 U.S.C. 101
>seems to indicate no distinction.
The correct jargon is *derivative* work, and I don't think you're
going to find any court concluding that a machine compilation of
source into object creates a derivative work. Generally a derivative
work has to add some new component of creativity that that the
foundational work didn't have. It makes more sense to think of the
source and the object as two different versions of the same work, both
created by the same author(s) and both protected under copyright law.
"Both the source and object codes to computer software are also
individually subject to copyright protection. Johnson Controls, 886
F.2d at 1175; Midway Mfg. Co., 564 F. Supp. at 750-51."
NLFC, Inc. v. Devcom Mid-America, Inc., 45 F.3d 231, 234-35 (7th Cir.
1995).
Bob
Karsten M. Self
I'd like to clarify the question. I am trying to address the source,
object, object + libraries, and executing binary from the point of view
of copyright law.
As I see it, a computer program "a set of statements or instructions to
be used directly or indirectly in a computer in order to bring about a
certain result", can take several forms, each of which is a copy and/or
a derived work of one or more other works:
1. The source code as a hardcopy document, electronic file, or image in
memory.
2. Compiled source code, which may be standalone, or may include
standard library features either statically or dynamically linked, as an
electronic file.
3. The running executable in memory, which includes all machine code
generated from the original program source, plus any linked libraries.
Whether the libraries are statically or dynamically linked in the
compiled *file*, the library-derived machine code is commingled with the
program's own machine code in a single process space in the running
executable.
Mr. Hayden observes that a derived work would "require additional
original expression". While the mechanical act of linking to a library
might not be orignal or expressive, the contents linked to (and
commingled in a running executable) would almost certainly be found to
be original and expressive.
17 USC 117(1) (http://www.law.cornell.edu:80/uscode/17/117.shtml) allows
the making of another copy or adaptation of that computer program
provided
(1) that such a new copy or adaptation is created as an essential
step in the utilization of the computer program in conjunction with
a machine and that it is used in no other manner, or
It appears that 117 allows the executable image, and linking, but does
not address the issue of this instance of the original work being a
"copy" or an "adaptation".
I would suggest that this instance is allowed under 17 USC, but that a
determination of the nature of this instance as a copy or an adaptation
would require analysis specific to the particular case.
The next question is, in light of 17 USC 117(1), could any license or
other agreement legally restrict the conditions under which the "copy or
adaptation...created as an essential step in the utilization of the
computer program" may or may not be created, e.g.: restrictions on what
or what may not be added to the original work to create an "adaptation"
for the purpose of utilizing the program?
Bruce Hayden wrote:
>
> Karsten M. Self wrote:
> >
> > Two questions concerning copyright as it applies to software.
> >
> > First: under US copyright law, are source code and object code
> > considered the identical work (different "translations", as it were), or
> > is object code considered a "derived work"? I would appreciate
> > statutory or case law citation if possible. Definition at 17 U.S.C. 101
> > seems to indicate no distinction.
>
--
Karsten M. Self (kms...@ix.netcom.com)
What part of "Gestalt" don't you understand?
Welchen Teil von "Gestalt" verstehen Sie nicht?
12:41pm up 32 days, 12:30, 4 users, load average: 1.50, 1.56, 1.42
Carl Oppedahl
>Two questions concerning copyright as it applies to software.
>
>First: under US copyright law, are source code and object code
>considered the identical work (different "translations", as it were), or
>is object code considered a "derived work"? I would appreciate
>statutory or case law citation if possible. Definition at 17 U.S.C. 101
>seems to indicate no distinction.
It doesn't exactly answer your question, but the Copyright Office takes the
official position that registering a copyright in source code (with a source
code deposit) gives full registration protection under the Copyright Act to
the executable code and to everything that you see on the screen when you run
the program. See Copyright Office circular 61.
Karsten M. Self
First, registration of a work with the Copyright Office is not required
for copyright protection, it does affect the copyright owner's ability
to collect damages. It's also not the matter at issue. I mention this
for the benefit of others, Mr. Oppedahl is, I'm sure, quite familiar
with these matters.
Using the Copyright Office's deposit requirements
(http://lcweb.loc.gov/copyright/circs/circ61.pdf) as a guide to what
constitutes a work or a derived work under 17 USC, I note the following
passage:
Where an applicant is unable or unwilling to deposit source code,
he/she must state in writing that the work as deposited in object
code contains copyrightable authorship. the Office will send a
letter stating that registration has been made under its rule of
doubt and warning that it has not determined the existence of
copyrightable authorship.
It appears that the Copyright Office considers source and object code to
be identically the same work, but that object code does not represent a
"best edition"
(17 USC 101 and 408) of the work. "Best edition" is determined by the
Library of Congress (which operates the Copyright Office), not statute
(http://www.law.cornell.edu:80/uscode/17/):
The "best edition" of a work is the edition, published in the United
States at any time before the date of deposit, that the Library of
Congress determines to be most suitable for its purposes.
It is not clear to me that object code registration provides any less
legal protections than source code, only that the Copyright Office will
not grant a determination of copyrightable authorship.
408(b)(2) suggests that a best edition deposit is necessary...:
(b) Deposit for Copyright Registration. - Except as provided by
subsection (c), the material deposited for registration shall
include -
(2) in the case of a published work, two complete copies
or phonorecords of the best edition;
....except as provided by 408(c)(1):
The Register of Copyrights is authorized to specify by regulation
the administrative classes into which works are to be placed for
purposes of deposit and registration, and the nature of the copies
or phonorecords to be deposited in the various classes specified.
The regulations may require or permit, for particular classes, the
deposit of identifying material instead of copies or phonorecords,
the deposit of only one copy or phonorecord where two would
normally be required, or a single registration for a group of
related works.
In light of 408(c)(1), it appears to me that object code submission will
"permit, for particular classes, the deposit of identifying material
instead of copies or phonorecords".
In which case, object code is sufficient to secure full registration
protections, for the identical work as embodied in source code.
This still gets us back to the question of whether source and linked
object code are the same work, and whether the CO has sidestepped or
erred in resolving this issue.
--
Karsten M. Self (kms...@ix.netcom.com)
What part of "Gestalt" don't you understand?
Welchen Teil von "Gestalt" verstehen Sie nicht?
3:41pm up 32 days, 15:30, 4 users, load average: 1.49, 1.52, 1.54
Barry Margolin
>Probably not. Probably considered the original work. Derivative works
>require additional original expression.
When someone translates a work in prose from one human language to
another, is that considered "additional original expression?" I was under
the impression that this is one of the standard ways to create a
derivative work.
Perhaps it's considered original because the translator often needs to
decide the appropriate phrases to match the intent of the original, or in
the case of literary works may need to be clever to translate the style to
the new language.
But what if the translation were done mechanically by a computer? Would
the result be considered equivalent to the original, rather than a
derivative work? If not, why would the mechanical translation of a source
program to object code be treated differently?
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Burlington, MA
Bruce Hayden
> When someone translates a work in prose from one human language to
> another, is that considered "additional original expression?" I was under
> the impression that this is one of the standard ways to create a
> derivative work.
> But what if the translation were done mechanically by a computer? Would
> the result be considered equivalent to the original, rather than a
> derivative work? If not, why would the mechanical translation of a source
> program to object code be treated differently?
Very apt analogy, and I am not sure there is a good answer to this.
But note that any original expression added would belong to the
creator of the translator (or compiler in the case of software)
and not the user of the translator.
I'll have to think more on this, and am open to other ideas.
Karsten M. Self
> >require additional original expression.
>
> another, is that considered "additional original expression?" I was under
> the impression that this is one of the standard ways to create a
> derivative work.
>
> decide the appropriate phrases to match the intent of the original, or in
> the case of literary works may need to be clever to translate the style to
> the new language.
>
> the result be considered equivalent to the original, rather than a
> derivative work? If not, why would the mechanical translation of a source
> program to object code be treated differently?
Note too that this doesn't address the issue of compiling and linking,
but merely compiling.
Compiling plus linking both translates (compiles source to binary) and
adds new content (links shared library code to the binary code specified
in the program's own source).
I addressed this point in my response to Bruce's post.
--
Karsten M. Self (kms...@ix.netcom.com)
What part of "Gestalt" don't you understand?
Welchen Teil von "Gestalt" verstehen Sie nicht?
12:21pm up 33 days, 12:10, 3 users, load average: 1.07, 1.17, 1.22
Bruce Hayden
would take awhile to answer. Karsten here is trying to find
some lines here as to exactly when the source and object
code are considered the same work. In the past, it has been
accepted that they are. However, he makes some good points
based on the actual technology involved that there may be
some distinctions.
Karsten M. Self wrote:
>
> I thank Mr. Hayden for his input.
>
> I'd like to clarify the question. I am trying to address the source,
> object, object + libraries, and executing binary from the point of view
> of copyright law.
>
> As I see it, a computer program "a set of statements or instructions to
> be used directly or indirectly in a computer in order to bring about a
> certain result", can take several forms, each of which is a copy and/or
> a derived work of one or more other works:
>
> 1. The source code as a hardcopy document, electronic file, or image in
> memory.
Definately the same work.
> 2. Compiled source code, which may be standalone, or may include
> standard library features either statically or dynamically linked, as an
> electronic file.
The problem with statically linked libraries is that they are the
work of another (usually). However, at least in some/many of the
circuits, the copyright over the libraries may be very "thin".
This is because many such are almost exclusively functional.
To the extent that say that a COS routine is coded in a
certain way because that way is more efficient than other ways,
or is one of a very few ways of efficiently coding it, it can
be argued that that functionality should be filtered before
determining simularity, and thus expression for copyrightability.
Thus, for statically linked libraries, the added expression is
probably de minimis in many cases, and for all intensive
purposes, the source and object code in my estimation would
be considered the same.
The distinction with dynamically linked libraries is that they
don't actually become part of the module. Thus, you really
don't get into this debate, since there is no real difference
between source and object code in this situation.
> 3. The running executable in memory, which includes all machine code
> generated from the original program source, plus any linked libraries.
> Whether the libraries are statically or dynamically linked in the
> compiled *file*, the library-derived machine code is commingled with the
> program's own machine code in a single process space in the running
> executable.
See above. However, this time, the dynamically linked libraries
are probably treated like statically linked ones above.
> Mr. Hayden observes that a derived work would "require additional
> original expression". While the mechanical act of linking to a library
> might not be orignal or expressive, the contents linked to (and
> commingled in a running executable) would almost certainly be found to
> be original and expressive.
Not necessarilty - see above.
> 17 USC 117(1) (http://www.law.cornell.edu:80/uscode/17/117.shtml) allows
>
> the making of another copy or adaptation of that computer program
> provided
>
> (1) that such a new copy or adaptation is created as an essential
> step in the utilization of the computer program in conjunction with
> a machine and that it is used in no other manner, or
>
> It appears that 117 allows the executable image, and linking, but does
> not address the issue of this instance of the original work being a
> "copy" or an "adaptation".
I have always considered it a necessary adaptation, with that being
one of the primary uses of that phrase in the statute.
> I would suggest that this instance is allowed under 17 USC, but that a
> determination of the nature of this instance as a copy or an adaptation
> would require analysis specific to the particular case.
>
> The next question is, in light of 17 USC 117(1), could any license or
> other agreement legally restrict the conditions under which the "copy or
> adaptation...created as an essential step in the utilization of the
> computer program" may or may not be created, e.g.: restrictions on what
> or what may not be added to the original work to create an "adaptation"
> for the purpose of utilizing the program?
Possibly. However, you get into preemption here (17 USC 301).
Dr. Ram Samudrala
In misc.int-property Bruce Hayden <bha...@ieee.org> wrote:
>The problem with statically linked libraries is that they are the
>work of another (usually). However, at least in some/many of the
>circuits, the copyright over the libraries may be very "thin".
>This is because many such are almost exclusively functional.
>To the extent that say that a COS routine is coded in a
>certain way because that way is more efficient than other ways,
>or is one of a very few ways of efficiently coding it, it can
>be argued that that functionality should be filtered before
>determining simularity, and thus expression for copyrightability.
>Thus, for statically linked libraries, the added expression is
>probably de minimis in many cases, and for all intensive
>purposes, the source and object code in my estimation would
>be considered the same.
Much as I wish your view is right, statically linked libraries include
a lot more than just mathematical routines. In C, for example, you
have libc linked in which could include routines like printf(),
fgets(), scanf(), etc. Not sure if your de minimis rule holds still.
--Ram
email@urls || http://www.ram.org || http://www.twisted-helices.com/th
Our first ancestors, our Adams and our Eves, were endowed in a higher
degree than the animals of any other species with two precious facilities:
the power to think and the desire to rebel. ---Michael Bakunin
Karsten M. Self
>
> In article <36298A17...@ix.netcom.com>, kms...@ix.netcom.com wrote:
> >
> >
> >First: under US copyright law, are source code and object code
> >considered the identical work (different "translations", as it were), or
> >is object code considered a "derived work"? I would appreciate
> >statutory or case law citation if possible. Definition at 17 U.S.C. 101
> >seems to indicate no distinction.
>
> IP class that translations were deriv works...)
It might sway arguments down the road, particularly in terms of linking
a program work to a library, or a library work to a program.
I'd be inclined to agree with you, that a translation is a derived
work. However, for registration purposes, the Copyright Office allows
deposit of *either* source or object code (object code under "Rule of
Doubt"), to secure full copyright registration protections. The CO is
given the right to set deposit requirements for works of various types,
but the deposit requirements themselves are only guided, not fixed, by
statute (17 USC 407).
So, issue one is that the distinction doesn't appear to be clearly
addressed by the CO. Allowing deposit of object code, if object code is
a translation, would be like allowing deposit of the Japanese edition of
a John Grisham novel for both the English and Japanese language
copyright deposit requirements. I don't know that the latter is
allowable.
Issue two is to identify who the translator is of the object-code work.
Is it the original programmer? The person running the compiler? The
author of the compiler? The author(s) of the linked libraries (static
or dynamic)?
I could see arguments for the first or second choices. I'd hesitate to
give the inventor of a mechanical process authorship claims to outputs
of that process. The author(s) of linked libraries might be seen as
co-authors of a collaborative or collective work, but not translators.
We may be in need of a new (?) concept of non-human, non-intentional
translators -- and not just for issues of computer programs -- have you
visited Bablefish lately?
In sum, I see a problem in that there doesn't seem to be a clear legal
consensus on what the relationship between source and object code is, in
terms of copyright. They are clearly not identical, just as clearly
related. How closely? How much of a relationship is necessary for two
works to be "the same"?
--
Karsten M. Self (kms...@ix.netcom.com)
What part of "Gestalt" don't you understand?
Welchen Teil von "Gestalt" verstehen Sie nicht?
3:21am up 21:03, 7 users, load average: 0.36, 0.63, 0.56
Bruce Hayden
>
> Followups narrowed. Please reset followups if necessary.
> >Thus, for statically linked libraries, the added expression is
> >probably de minimis in many cases, and for all intensive
> >purposes, the source and object code in my estimation would
> >be considered the same.
>
> Much as I wish your view is right, statically linked libraries include
> a lot more than just mathematical routines. In C, for example, you
> have libc linked in which could include routines like printf(),
> fgets(), scanf(), etc. Not sure if your de minimis rule holds still.
I have not looked closely at libraries in quite awhile, but my
guess is that I/O libraries probably contain the most expression,
string manipulation less, and mathematical functions still less.
This is mostly conjecture, based on my estimation of what I expect
their length to be and the extent of the relevant literature.
The reason that I suggest that mathematical functions would
tend to have little protectable expression is that they tend
to be short enough that most of the routines can be attributed
to functionality, or to adopting a standard way of doing something.
Indeed, once you have constrained yourself by register conventions
and by using as fast a routine as you can find, then there isn't
that much room left for expression (IMHO), especially since in
object code such expressive elements as variable names and
comments are missing.
But you are correct I think that once you start in particular
linking in I/O routines, you are pretty well guaranteed that
you will find at least some protectable expression in the
linked library.
Bruce Hayden
> It might sway arguments down the road, particularly in terms of linking
> a program work to a library, or a library work to a program.
>
> I'd be inclined to agree with you, that a translation is a derived
> work. However, for registration purposes, the Copyright Office allows
> deposit of *either* source or object code (object code under "Rule of
> Doubt"), to secure full copyright registration protections. The CO is
> given the right to set deposit requirements for works of various types,
> but the deposit requirements themselves are only guided, not fixed, by
> statute (17 USC 407).
I think that you have identified the crux here. There is no real
requirement that the two be absolutely identical, rather a practical
requirement that you can get from the one to the other. In particular,
you can recompile and link and repeatably get from the source to the object.
> So, issue one is that the distinction doesn't appear to be clearly
> addressed by the CO. Allowing deposit of object code, if object code is
> a translation, would be like allowing deposit of the Japanese edition of
> a John Grisham novel for both the English and Japanese language
> copyright deposit requirements. I don't know that the latter is
> allowable.
Well, probably not, since unless you are using a given mechanical
translator, the English to Japanese translation is not deterministic,
especially if done by a person on such a large work.
A given compiler though will reliably translate a given source module
into the same object module as often as you try it. It is this
repeatability that in my mind is important.
> Issue two is to identify who the translator is of the object-code work.
> Is it the original programmer? The person running the compiler? The
> author of the compiler? The author(s) of the linked libraries (static
> or dynamic)?
As far as copyright goes, I am not sure I see the relevance. For all
of the above, an argument can be made that any expression introduced
by the compiler writer, library coder, or whoever, is licensed to
the user of the compiler and libraries.
> I could see arguments for the first or second choices. I'd hesitate to
> give the inventor of a mechanical process authorship claims to outputs
> of that process. The author(s) of linked libraries might be seen as
> co-authors of a collaborative or collective work, but not translators.
> We may be in need of a new (?) concept of non-human, non-intentional
> translators -- and not just for issues of computer programs -- have you
> visited Bablefish lately?
As noted above, I think that implied (or express) license is more
realistic as a solution to this problem.
> In sum, I see a problem in that there doesn't seem to be a clear legal
> consensus on what the relationship between source and object code is, in
> terms of copyright. They are clearly not identical, just as clearly
> related. How closely? How much of a relationship is necessary for two
> works to be "the same"?
No, not really. The purpose of registration of copyrights it
to be able to identify the registered work. The treating of
source and object as equivalent conforms to this, since you
can always recompile and relink your source to compare the
object code.
johnny...@hotmail.com
kms...@ix.netcom.com wrote:
> In sum, I see a problem in that there doesn't seem to be a clear legal
> consensus on what the relationship between source and object code is, in
> terms of copyright. They are clearly not identical, just as clearly
> related. How closely? How much of a relationship is necessary for two
> works to be "the same"?
The fact that source is mechanically translated with identical results each
time (assuming the same compiler) into object is clear indication that no
expression is added, and therefore that source and object are "the same." The
_literary_ translation of a Grisham novel into Japanese would certainly add
some expression - words would be chosen to fit the desired tone, pacing, etc.
- and thus be a derivative work. A _mechanical_ translation of the novel -
i.e. translating each word to the Japanese equivalent, whether by man or
machine, is closer to the line, but I'd call it "the same" since the new
material doesn't express anything new.
JS
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Karsten M. Self
>
> In article <36385AD0...@ix.netcom.com>,
> kms...@ix.netcom.com wrote:
>
> > In sum, I see a problem in that there doesn't seem to be a clear legal
> > consensus on what the relationship between source and object code is, in
> > terms of copyright. They are clearly not identical, just as clearly
> > related. How closely? How much of a relationship is necessary for two
> > works to be "the same"?
>
> The fact that source is mechanically translated with identical results each
> time (assuming the same compiler) into object is clear indication that no
> expression is added, and therefore that source and object are "the same." The
> _literary_ translation of a Grisham novel into Japanese would certainly add
> some expression - words would be chosen to fit the desired tone, pacing, etc.
> - and thus be a derivative work. A _mechanical_ translation of the novel -
> i.e. translating each word to the Japanese equivalent, whether by man or
> machine, is closer to the line, but I'd call it "the same" since the new
> material doesn't express anything new.
Compiling does (or can do) two things:
- it compiles source code to object code. This is translation.
- it links program source to shared libraries. This is a "combined
work" of sorts.
It's quite possible to arrive at different results by compiling the same
source on different platforms, with different compilers, with different
compiler options, or with different, but compatible, shared libraries.
From a literal standpoint, the sequence of bits'n'bytes in each case is
(or may be) different. These differences may be attributable to
translation (compiling) or shared content (linking). There can be
wildly different functional consequences of these differences. I'm
trying to establish how they are treated by copyright.
Karsten M. Self (kms...@ix.netcom.com)
What part of "Gestalt" don't you understand?
Welchen Teil von "Gestalt" verstehen Sie nicht?
4:11pm up 1 day, 9:53, 4 users, load average: 0.08, 0.04, 0.05
Geoffrey KEATING
> Dr. Ram Samudrala wrote:
> The reason that I suggest that mathematical functions would
> tend to have little protectable expression is that they tend
> to be short enough that most of the routines can be attributed
> to functionality, or to adopting a standard way of doing something.
> Indeed, once you have constrained yourself by register conventions
> and by using as fast a routine as you can find, then there isn't
> that much room left for expression (IMHO), especially since in
> object code such expressive elements as variable names and
> comments are missing.
I think you'll find that this is not the case. Even something as
seemingly trivial as a max(x,y) function, which returns the larger of
x and y, can be coded in several ways, which have different
performance and size characteristics and reflect different approaches
to the underlying data type; one basic choice, for instance, is
whether you divide program flow into two branches for x>y and x<=y, or
whether the max function is coded in some other way, say as
(abs(x-y)+x+y)/2. Something as complicated as a square root
function has literally hundreds of possible alternatives, many of
which are radically different algorithms, and you'll find an
substantial literature on it.
For string algorithms---say, a routine that simply copies memory from
one place to another---you also have many possible choices, on how (or
whether) you deal with caching, which instruction sequences you use,
and so on.
--
Geoff Keating <Geoff....@anu.edu.au>
Joe Lester
>Compiling does (or can do) two things:
>
> - it compiles source code to object code. This is translation.
> - it links program source to shared libraries. This is a "combined
>work" of sorts.
>
>
>It's quite possible to arrive at different results by compiling the same
>source on different platforms, with different compilers, with different
>compiler options, or with different, but compatible, shared libraries.
>
>From a literal standpoint, the sequence of bits'n'bytes in each case is
>(or may be) different. These differences may be attributable to
>translation (compiling) or shared content (linking). There can be
>wildly different functional consequences of these differences. I'm
>trying to establish how they are treated by copyright.
Umm, I'm a lawyer. The following comments reflect random thougts of
the moment, not legal advice. As a general rule, as previously
discussed, object code compiled from source is treated as if it were
the same work, not a translation, adaptation or derivative work.
In the US, the literal comparison of bits and bytes isn't the only way
to compare two different expressions under copyright principles.
Non-literal elements (for example, structure, sequence and
organization) may be considered as well. Some elements may not be
protectable at all. The rules, and methods for analysis, will become
clearer as serious software copyright cases are presented to the
Courts. But for now, we live with the reality that software code under
copyright is a relatively different beast from traditional works of
authorship going back to the invention of the printing press. See the
1997 article by Ron Katz, "Uncertainty Reigns in Software Cases" at
http://www.ljx.com/practice/computer/0512cpsoft.html.
When you refer to "shared content (linking)" are you saying the
resultant binary code is a combination that contains a substantial
portion of a pre-existing work? If so, then the resultant work may be
a derivative work based on the pre-existing work, as opposed to a
mechanical "same work" translation.
Joe Lester
St. Paul, MN
johnny...@hotmail.com
kms...@ix.netcom.com wrote:
> Compiling does (or can do) two things:
>
> - it compiles source code to object code. This is translation.
> - it links program source to shared libraries. This is a "combined
> work" of sorts.
>
> It's quite possible to arrive at different results by compiling the same
> source on different platforms, with different compilers, with different
> compiler options, or with different, but compatible, shared libraries.
>
> From a literal standpoint, the sequence of bits'n'bytes in each case is
> (or may be) different. These differences may be attributable to
> translation (compiling) or shared content (linking). There can be
> wildly different functional consequences of these differences. I'm
> trying to establish how they are treated by copyright.
My response was addressed to your initial source vs. object question and
didn't address the link step. It hasn't been that long since I wrote code
for a living, but for my purposes "object" implies unlinked stuff in or out
of a library and "executable" or "load module" implies linked stuff with
static or dynamic library links - agreed?
I don't understand why linking, whether static or dynamic, is any different
copyright-wise than compiling. While different implementations of a library
might give different results at execution time, that doesn't change the
expression of the source/object at all.
The best analogy I can think up is that in the UK "quite nice" means
something LESS than nice, but in the US "quite nice" means somthing MORE than
nice. A Grisham book with a critical bit of dialogue including "quite nice"
isn't seperately copyrightable for the US and UK meanings of the expression.
Similarly, source code linked with different libraries isn't seperately
copyrightable for the different functional consequences.
js
Bruce Hayden
> My response was addressed to your initial source vs. object question and
> didn't address the link step. It hasn't been that long since I wrote code
> for a living, but for my purposes "object" implies unlinked stuff in or out
> of a library and "executable" or "load module" implies linked stuff with
> static or dynamic library links - agreed?
>
> I don't understand why linking, whether static or dynamic, is any different
> copyright-wise than compiling. While different implementations of a library
> might give different results at execution time, that doesn't change the
> expression of the source/object at all.
Well, except that the libraries themselves may contain protected expression.
If they do, then you have a situation where the source code, and the
compiled source code contain the protected expression of party A,
while the library contains the protected expression of party B.
The linked version would thus contain the protected expression of
party's A & B.
> The best analogy I can think up is that in the UK "quite nice" means
> something LESS than nice, but in the US "quite nice" means somthing MORE than
> nice. A Grisham book with a critical bit of dialogue including "quite nice"
> isn't seperately copyrightable for the US and UK meanings of the expression.
> Similarly, source code linked with different libraries isn't seperately
> copyrightable for the different functional consequences.
Probably not, but not absolutely. If selection of the libraries
themselves was protected expression, then the result would be different.
But as I am having trouble coming up with a valid scenerio for this
to work, I think it unlikely to ever happen.
johnny...@hotmail.com
Bruce Hayden <bha...@ieee.org> wrote:
> johnny...@hotmail.com wrote:
> > I don't understand why linking, whether static or dynamic, is any different
> > copyright-wise than compiling. While different implementations of a library
> > might give different results at execution time, that doesn't change the
> > expression of the source/object at all.
>
> Well, except that the libraries themselves may contain protected expression.
> If they do, then you have a situation where the source code, and the
> compiled source code contain the protected expression of party A,
> while the library contains the protected expression of party B.
> The linked version would thus contain the protected expression of
> party's A & B.
Your point is well taken, but I'm having trouble understanding how it changes
the analysis of what actions are transformative of source code or otherwise
change the copyrights held by the source code author. To the extent A hasn't
violated the implied or express license she has to use B's libraries, there
doesn't seem to be any change in A's rights because B's stuff is linked.
Clearly, if C infringes (copies, creates derivatives, etc.) rights in the
executable, A & B seperately have standing to complain.
Perhaps Karsten's point here is that source/object that can be linked with
libraries to allow it to run under various OSs & GUIs should have multiple
sets of copyrights, since the visual displays might be distinctly
copyrightable on each platform. I don't think the various visual displays
are distinctly copyrightable _as to the source author_, but infringement of
the rights in the various platform executables would involve multiple sets of
rightsholders.
JS