The death of copyright in software
rjack
Components, Inc., 387 F.3d 522 (6th Cir. 2004)” reveals the over-reach
of Linux operating system authors when claiming GPL license control over
most of the functional source code contained in the Linux operating
system. Likewise the Free Software Foundation’s gcc compiler and
libraries are without much in the way of copyright protection:
“In the computer-software context, the doctrine means that the elements
of a program dictated by practical realities--e.g., by hardware
standards and mechanical specifications, software standards and
compatibility requirements, computer manufacturer design standards,
target industry practices, and standard computer programming
practices--may not obtain protection. Id. (citing case examples); see
Sega Enters., 977 F.2d at 1524 ("To the extent that a work is functional
or factual, it may be copied."); Brown Bag Software v. Symantec Corp.,
960 F.2d 1465, 1473 (9th Cir.1992) (affirming district court's finding
that "[p]laintiffs may not claim copyright protection of an ...
expression that is, if not standard, then commonplace in the computer
software industry"). As "an industry-wide goal," programming
"[e]fficiency" represents an external constraint that figures
prominently in the copyrightability of computer programs. Altai, 982
F.2d at 708.” Lexmark International, Inc. v. Static Control Components,
Inc., 387F.3d 522 (6th Cir. 2004).
Some practical realities iterated in Lexmark, supra, that eliminate
copyright protection for computer source code are:
1) hardware standards
2) mechanical specifications
3) software standards
4) compatibility requirements
5) computer manufacturer design standards
6) target industry practices
7) standard computer programming practices
8) functional efficiencies
If you strip the /*comments*/ from the Linux kernel and driver code
you are left with functional code that is written to comply with various
Unix, Posix, ANSI and IEEE industry standards and specifications. The
expressive form of the source code is controlled by the specifications
of various semiconductor manufacturers. If not implemented to comply
exactly with the semiconductor hardware specifications and standards
then the code is totally useless. This relegates most of the kernel code
to “utilitarian function”. What is creative about writing bytes to
semiconductor ports? Original creativity is suppressed by standard
computer programming practices, software and hardware standards.
Look also at the “Bash” shell. Word play for “Bourne again shell”.
The Bash shell was written to *mimic* features in many other Unix shells:
“This is Edition 2.5b, last updated 15 July 2002, of The GNU Bash
Reference Manual, for Bash, Version 2.05b.
Copyright (C) 1991-2002 Free Software Foundation, Inc.
Bash contains features that appear in other popular shells, and some
features that only appear in Bash. Some of the shells that Bash has
borrowed concepts from are the Bourne Shell (`sh'), the Korn Shell
(`ksh'), and the C-shell (`csh' and its successor, `tcsh'). The
following menu breaks the features up into categories based upon which
one of these other shells inspired the feature… ”.
So what is creative and original about copycatting the functionality of
other Unix shells?
Microsoft is keenly aware of the almost total lack of copyright
protection in software. That is what drove them into their current
process patent seeking frenzy.
The Free Software Foundation likewise has been driven by the same reason
to its utterly ridiculous assertions of patent control with many
non-existent rights in a copyright license. GPL fans have generated ten
times more FUD than has Microsoft concerning software licensing.
Stefaan A Eeckels
rjack <rjack@com> wrote:
> So what is creative and original about copycatting the functionality
> of other Unix shells?
The way in which it is done. Most novels deal with relationships
between people, but that doesn't mean that they cannot be covered
by copyright.
And in any case, copyright is not about the ideas, but about the
specific expression of those ideas.
You can write a POSIX compliant shell that shares not one line of code
with another POSIX compliant shell. You can write a C++ compiler that
is structurally completely different from another C++ compiler, and
there will be little doubt that both are protected by copyright.
In the case of drivers, that must call specific routines in the OS and
perform specific hardware manipulations, two implementations might be
so close to each other as to be indistinguishable, in which case their
would be no way to claim copyright infringement (unless, I suppose,
there is hard evidence that one of the parties did indeed copy the
code of the other).
Most (business) programs implement some kind of standard (or
pre-defined process). Surely you don't want to suggest that Payroll
programs cannot be copyrighted?
--
Stefaan A Eeckels
--
Life itself is a misery and nobody can tell what can be of it.
Those that can tell what can be of it are those who cannot tell
us because they are far from us (dead). -- Very profound scam
Alexander Terekhov
Stefaan A Eeckels wrote:
[...]
> structurally
Once again (albeit different link):
http://www.groklaw.net/articlebasic.php?story=20040715212732854
<quote>
Altai has been viewed as a landmark decision as it incorporates
many traditional principles of copyright law into a single
analytical framework seemingly suitable for computer software.
However, when honestly applied, the abstraction-filtration-
comparison test eliminates protection for computer programs by
entirely filtering out not only the individual elements of
computer programs such as software objects but also the
compilation of selection and arrangement expression that is the
program's structure, since both are designed with efficiency in
mind.
[...]
It is more appropriate to consider the software objects of a
computer program as analogous to the gears, pulleys, and levers
of a mechanical invention, as by its very nature, the design of
computer software is intended to optimize functionality by
making a program run faster, use less memory, or be easier for
the programmer to modify. When viewed as a collection of
software objects combined in such a way as to optimally perform
various tasks, the design of computer software closely
resembles the design of functional devices protected by patent
law rather than the non-functional, non-literal elements of
creative authorial works protected under copyright law.
</quote>
regards,
alexander.
--
"I can change the rules."
Herr Prof Eben
http://www.linux.com/blob.pl?id=796772290d97058074d8c909e3dde1eb
rjack
> On Wed, 30 May 2007 13:51:34 -0500 rjack <rjack@com> wrote:
>
> You can write a POSIX compliant shell that shares not one line of
> code with another POSIX compliant shell. You can write a C++ compiler
> that is structurally completely different from another C++ compiler,
> and there will be little doubt that both are protected by copyright.
First review some of the factors iterated in the Lexmark decision that
disqualifies computer source code for copyright protection:
1) HARDWARE STANDARDS
2) MECHANICAL SPECIFICATIONS
3) SOFTWARE STANDARDS
4) COMPATIBILITY REQUIREMENTS
5) COMPUTER MANUFACTURER DESIGN STANDARDS
6) TARGET INDUSTRY PRACTICES
7) STANDARD COMPUTER PROGRAMMING PRACTICES
8) FUNCTIONAL EFFICIENCIES
You may write one C++ compiler in Forth and another in Python but a
large element of the compiler source code is dictated by the very
exacting specifications of the target processor’s instruction set
[HARDWARE STANDARDS]. Another element of the source code is dictated by
the very exacting C++ Language Specification [SOFTWARE STANDARDS]. A
language compiler is a very functional, rule driven program by its very
definition.
“In the computer-software context, the doctrine means that the elements
of a program dictated by practical realities—e.g., by hardware standards
and mechanical specifications, software standards and compatibility
requirements, computer manufacturer design standards, target industry
practices, and standard computer programming practices—may not obtain
protection. Id. (citing case examples); see Sega Enters., 977 F.2d
at 1524 (“To the extent that a work is functional or factual, it may be
copied.”); Lexmark International, Inc. v. Static Control Components,
Inc., 387F.3d 522 (6th Cir. 2004).
Run your C++ compiler code through the
“abstraction-filtration-comparison” test in the hands of an expert
witness in court and your source modules look like Swiss cheese with
VERY large holes. If the programmer’s comments have been stripped (very
likely) and trivial obfuscation steps have been applied, your copyright
protection is virtually non-existent.
With respect to computer source code the copyright is in the context.
Your best hope for copyright protection is to print your compiler code
on glossy paper and frame it as a work of art and not to claim
protection for use as a functional program.
rjack
Stefaan A Eeckels
rjack <rjack@com> wrote:
> Run your C++ compiler code through the
> “abstraction-filtration-comparison” test in the hands of an expert
> witness in court and your source modules look like Swiss cheese with
> VERY large holes. If the programmer’s comments have been stripped
> (very likely) and trivial obfuscation steps have been applied, your
> copyright protection is virtually non-existent.
If you strip out all the distinguishing characteristics, it's pretty
obvious that on the remainder you cannot get copyright protection. If
you strip the distinguishing stuff out of the typical novel, the result
is no longer copyrightable either (e.g. Woody Allen's appreciation of
War and Peace: "It's about Russians", or a reduction of Romeo and
Juliet to "Boy meets girl, they fall in love, families don't want
them to marry", etc). If you reduce the number of notes you look at to
three or four, every piece of music is a copy of every other piece of
music.
It's obvious that you cannot claim copyright protection on fragments of
code that anyone would write substantially the same because these
fragments are determined in their expression by the hardware or
other external influences.
But only an idiot without knowledge about programming can argue that
because a program performs the same well-defined function as another
program (i.e. compiling 'C' code or performing an FTP transfer) its
internal structures and algorithms have to be so similar as to be
indistinguishable "after applying trivial obfuscation".
Using your overly broad approach you could equally claim that love
stories cannot be copyrighted, or that pictures of the Eiffel tower
cannot be copyrighted because when you strip off all the distinguishing
characteristics (framing, lighting, etc) they are pictures of the
exact same object. But the reality is that every photograph is
copyrighted, no matter how similar or trivial the subject. You're free
to make your own picture of the scene, but you're not free to copy
someone else's picture. The same applies to source code.
What the Lexmark case is about is that similarity between those parts of
the code that are so determined by the function to be performed cannot
be used in court as proof of copyright infringement. Quite obviously it
does not mean that you can lift sections out of the gcc source code and
use them in your own compiler because "there is only one way in which a
compiler can be written" and hence you can do with the gcc code as you
please.
--
Stefaan A Eeckels
--
The one thing IT really needs to outsource is the freakin' clueless
managers that don't understand that there are more possibilities than
chaos on the one hand and the reduction of alternatives to zero on the
other. -- Richard Hamilton in comp.sys.sun.hardware
John Hasler
> If you strip out all the distinguishing characteristics, it's pretty
> obvious that on the remainder you cannot get copyright protection.
I think that you two may be talking somewhat at cross-purposes. AFC
removes the _unprotected_ elements. Yes, your compiler will look like swiss
cheese after AFC: it will be full of holes where the unprotected elements
have been removed, but the the bulk of the code will remain.
As you note, every work contains unprotected elements, but most works still
consist mostly of protected stuff.
--
John Hasler
jo...@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA
Alexander Terekhov
John Hasler wrote:
[...]
> cheese after AFC: it will be full of holes where the unprotected elements
> have been removed, but the the bulk of the code will remain.
If at all, nothing really interesting from engineering perspective
(only sort of moronic ways to express "hello world" int main, so to
speak).
regards,
alexander.
rjack
> On Thu, 31 May 2007 20:19:17 -0500
> But only an idiot without knowledge about programming can argue that
> because a program performs the same well-defined function as another
> program (i.e. compiling 'C' code or performing an FTP transfer) its
> internal structures and algorithms have to be so similar as to be
> indistinguishable "after applying trivial obfuscation".
Idiot? Hmmmmmm....
What would be your description for a person who first read Lexmark:
"[S]ee Sega Enters., 977 F.2d at 1524 (“To the extent that a work is
functional or factual, it may be copied.”)"; Lexmark International, Inc.
v. Static Control Components, Inc., 387F.3d 522 (6th Cir. 2004).
And then claimed "... a program performs the same well-defined function
as another program..." obtains copyright protection?
rjack
Stefaan A Eeckels
rjack <rjack@com> wrote:
> Stefaan A Eeckels wrote:
> > On Thu, 31 May 2007 20:19:17 -0500
>
> > But only an idiot without knowledge about programming can argue that
> > because a program performs the same well-defined function as another
> > program (i.e. compiling 'C' code or performing an FTP transfer) its
> > internal structures and algorithms have to be so similar as to be
> > indistinguishable "after applying trivial obfuscation".
>
> Idiot? Hmmmmmm....
Do you claim that there is only one way to write an FTP client (or
server), a 'C' compiler, or any program that performs a well-defined
function?
I would be interested in your argumentation, as it would, mean that
once a program performs a well-defined function it cannot be improved.
Back in the eighties I wrote an interpreter that implemented a
well-defined language. The second release was an order of
magnitude faster because I went from a pure interpreter to an
incremental compiler, but the interpreted language didn't
change one jot.
Would you maintain that both versions were identical "after applying
trivial obfuscation"?
--
Stefaan A Eeckels
--
The only statistics you can trust are those you falsified yourself.
-- Winston Churchill
rjack
> On Sat, 02 Jun 2007 20:04:19 -0500
> rjack <rjack@com> wrote:
> Would you maintain that both versions were identical "after applying
> trivial obfuscation"?
I never claimed any such thing.
Here's part of my initial post in this thread:
*****************************************************************
“In the computer-software context, the doctrine means that the elements
of a program dictated by practical realities--e.g., by hardware
standards and mechanical specifications, software standards and
compatibility requirements, computer manufacturer design standards,
target industry practices, and standard computer programming
practices--may not obtain protection. Id. (citing case examples); see
Sega Enters., 977 F.2d at 1524 ("To the extent that a work is functional
or factual, it may be copied."); Brown Bag Software v. Symantec Corp.,
960 F.2d 1465, 1473 (9th Cir.1992) (affirming district court's finding
that "[p]laintiffs may not claim copyright protection of an ...
expression that is, if not standard, then commonplace in the computer
software industry"). As "an industry-wide goal," programming
"[e]fficiency" represents an external constraint that figures
prominently in the copyrightability of computer programs. Altai, 982
F.2d at 708.” Lexmark International, Inc. v. Static Control Components,
Inc., 387F.3d 522 (6th Cir. 2004).
Some practical realities iterated in Lexmark, supra, that eliminate
copyright protection for computer source code are:
1) hardware standards
2) mechanical specifications
3) software standards
4) compatibility requirements
5) computer manufacturer design standards
6) target industry practices
7) standard computer programming practices
8) functional efficiencies
*****************************************************************
I claim that virtually *all* non-comment computer source code intimately
involves one or more of the above factors.
The Copyright Act is contradictory. Sec. 101 Definitions says:
A "computer program" is a set of statements or instructions to
be used directly or indirectly in a computer in order to bring
about a certain result.
Sec. 102(b) Says:
(b) In no case does copyright protection for an original work of
authorship extend to any idea, procedure, process, system, method
of operation, concept, principle, or discovery, regardless of the
form in which it is described, explained, illustrated, or embodied
in such work.
Thirteen Federal Circuit Courts of Appeal can't figure out what the
"idea-expression dichotomy" means.
The Lexmark decision was in the Sixth Circuit which is highly respected
on copyright matters by the other Circuits. The Lexmark Court went to
great length to explain what was *not* copyrightable in computer
programs. What's left after the AFC test is a form of vaporware.
Long ago in Baker v. Selden, 101 U.S. 99 (1880) the Supreme Court
explained that while a book *describing* a bookkeeping system is worthy
of copyright protection, the underlying method described is not.
Unfortunately lines of computer source code not only *describe* an idea
-- by definition they directly or indirectly *control* the hardware that
implements the idea's objective as well.
rjack