[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

The death of copyright in software

From: rjack
Subject: The death of copyright in software
Date: Wed, 30 May 2007 13:51:34 -0500
User-agent: Thunderbird (Windows/20070326)

The seminal decision “Lexmark International, Inc. v. Static Control
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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]