The /bin/true Command and Copyright(trillian.mit.edu)
trillian.mit.edu
The /bin/true Command and Copyright
http://trillian.mit.edu/~jc/humor/ATT_Copyright_true.html
13 comments
I think I remember an engineer I worked with in the past gleefully pointing to a preface page in an Intel handbook for a chip Intel designed that Intel had copyrighted the lowercase letter i.
(f recall correctly...)
(f recall correctly...)
"So if you use blank lines in any of your files, you are in blatant violation of AT&T's copyright claim."
WRONG!
WRONG!
Did AT&T actually tried to enforce this copyright? Because what I see is auto-generated header that is put to every shell script present on the system. Entertaining nonetheless.
After the "insert copyright headers in all files" edict is given, it isn't unusual to find empty files that are copyrighted. Config files placeholders in particular end up copyrighting the zero length file.
I worked at a company that didn't merely issue this edict, but attempted to enforce it technologically. Every file in every commit was checked for the presence of a prescribed style of copyright string (something along the lines of "Copyright (c) YYYY Acme Inc.").
For a lot of my time there, I was more operations than development. A lot of piddly-ass configuration files and other things no copyright could possibly exist for got copyright strings added just so I wouldn't have to remember to type "NO ACME COPYRIGHT" into every bloody commit message to bypass the hook.
For a lot of my time there, I was more operations than development. A lot of piddly-ass configuration files and other things no copyright could possibly exist for got copyright strings added just so I wouldn't have to remember to type "NO ACME COPYRIGHT" into every bloody commit message to bypass the hook.
One of the issues in the AT&T versus UC BSD lawsuit was that AT&T forgot to copyright many of their files. (This was before automatic copyright.) So they probably over-reacted and went out of the way to label everything.
Yes your are surely right. But what about GNU guys' bint/true implementations copyright message? :)
Try this with a GNU true binary: `strace /bin/true 2>&1 |wc -l`
;)
;)
That's the C runtime starting up and finishing. That amount of overhead is incurred by (nearly) any program; in fact, worse overhead is incurred using the Sun method of having an empty file, because you have to run the more complex /bin/sh (or equivalent) instead of just a trivial compiled program.
ltrace gives a better view of what the program itself (as opposed to the runtime) is doing.
ltrace gives a better view of what the program itself (as opposed to the runtime) is doing.
I am aware. Still rather amusing however.
The GNU /bin/true is almost certainly complex enough to qualify for copyright.
This is GNU's Appropriate Legal Notices as required by section 5d of the GPLv3:
An interactive user interface displays "Appropriate Legal Notices"
to the extent that it includes a convenient and prominently visible
feature that (1) displays an appropriate copyright notice, and (2)
tells the user that there is no warranty for the work (except to the
extent that warranties are provided), that licensees may convey the
work under this License, and how to view a copy of this License. If
the interface presents a list of user commands or options, such as a
menu, a prominent item in the list meets this criterion.Indeed: http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/true...
That's pretty clearly a non-trivial source file. Obviously a pointless one, but copyrightable. And it has the standard GNU copyleft blurb at the top.
That's pretty clearly a non-trivial source file. Obviously a pointless one, but copyrightable. And it has the standard GNU copyleft blurb at the top.
How can we know? A mere veiled threat of litigation is enough to make a lot of corporations cower in fear, and stop doing whatever generated the threat. Does merely threatening a suit constitute "enforcing the copyright"?
While looking for the GNU true source code I found that raganwald has blogged about this earlier. His conclusion seems sound: http://weblog.raganwald.com/2008/02/recursive-implementation...
The source code is in this Daily WTF thread: http://forums.thedailywtf.com/forums/t/3779.aspx
The source code is in this Daily WTF thread: http://forums.thedailywtf.com/forums/t/3779.aspx
Reminds me of Oracle licensing the Java Hello World: http://docs.oracle.com/javase/tutorial/getStarted/applicatio...
For fun, if you are running OS X 10.7:
codesign -d -v /usr/bin/trueAha, that helps explain the discrepancy of OS X 10.7:
$ ls -la /usr/bin/true /usr/bin/false
-r-xr-xr-x 1 root wheel 34240 Jul 20 2011 /usr/bin/false
-r-xr-xr-x 1 root wheel 34240 Jul 20 2011 /usr/bin/true
$ cmp -l /usr/bin/true /usr/bin/false |wc
8194 24582 114716
$ ls -la /bin/true /bin/false
-rwxr-xr-x. 1 root root 25144 Dec 7 14:51 /bin/false
-rwxr-xr-x. 1 root root 25144 Dec 7 14:51 /bin/true
$ cmp -l /bin/true /bin/false |wc
355 1065 4970
~/coreutils/src]$ ls -alrth true.c false.c
-rw-r--r-- 1 dvd staff 2.2K Jan 30 09:31 true.c
-rw-r--r-- 1 dvd staff 51B Jan 30 09:31 false.c
~/coreutils/src]$ cat false.c
#define EXIT_STATUS EXIT_FAILURE
#include "true.c"
And figuring out why that still results in such a large binary delta is over my head.
On OS X these binaries are fat binaries:
On OS X these binaries are fat binaries:
$ file /usr/bin/true
/usr/bin/true: Mach-O universal binary with 2 architectures
/usr/bin/true (for architecture x86_64): Mach-O 64-bit executable x86_64
/usr/bin/true (for architecture i386): Mach-O executable i386[deleted]
Alas, this is almost off-topic but I'll mention it anyway. This is part of the "Reporting Bugs" section of the GNU /bin/false command:
REPORTING BUGS
Report false bugs to [email protected]
For comparison, here is /usr/bin/false from my Solaris box:
$ cat /usr/bin/false
#!/usr/bin/sh
# Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T
# All Rights Reserved
# THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T
# The copyright notice above does not evidence any
# actual or intended publication of such source code.
#ident "@(#)false.sh 1.6 93/01/11 SMI" /* SVr4.0 1.3 */
exit 255
There are two things that should be note about copyright, which would have prevented AT&T or anyone else from actually enforcing any copyright on such simple files.
First, copyright does not protect ideas--it only protects the way an author expressed the idea. The closer the expression is to the minimal way to express the idea, the less likely it is to be copyrightable. In the case of the simple implementations of /bin/true and /bin/false, they are pretty darned close to minimal.
Second, if you have author X who produces a copyrightable work, and author Y who later independently produces a work that happens to be identical to X's work, but Y did not copy elements from X, Y is not infringing X's copyright.
This second case doesn't happen often. If someone were to decide to write a novel about boy wizards, and produced something identical to the first Harry Potter book, no one would believe that they did this without copying from Rowling. However, if the work is small enough, an identical independent work is believable.
In the case of the simple /bin/true and /bin/false, a defense that you didn't copy from AT&T would be believable. Even if you admitted you looked at the AT&T source or had it described to you, it would be believable that you produced your own expression of the idea of "a do nothing shell script" and a "shell script that exits with status 255".
First, copyright does not protect ideas--it only protects the way an author expressed the idea. The closer the expression is to the minimal way to express the idea, the less likely it is to be copyrightable. In the case of the simple implementations of /bin/true and /bin/false, they are pretty darned close to minimal.
Second, if you have author X who produces a copyrightable work, and author Y who later independently produces a work that happens to be identical to X's work, but Y did not copy elements from X, Y is not infringing X's copyright.
This second case doesn't happen often. If someone were to decide to write a novel about boy wizards, and produced something identical to the first Harry Potter book, no one would believe that they did this without copying from Rowling. However, if the work is small enough, an identical independent work is believable.
In the case of the simple /bin/true and /bin/false, a defense that you didn't copy from AT&T would be believable. Even if you admitted you looked at the AT&T source or had it described to you, it would be believable that you produced your own expression of the idea of "a do nothing shell script" and a "shell script that exits with status 255".
A couple of things,
As many know the #ident tag in 'C' code was used with SCCS (pre-cursor to git/svn/cvs/etc) to create a string in the 'binary' which identified the code. In shell scripts it just sat there.
The change in the ident string where it gets the 'SMI' is when the version was from 'Sun Microsystems Inc' (aka SMI).
The reason Solaris included it was because it was part of the 'merge' between SunOS and System V and Sun had permission to all of the AT&T copyrights with respect to UNIX once they became 'partners' (AT&T invested essentially a billion dollars in Sun).
As many know the #ident tag in 'C' code was used with SCCS (pre-cursor to git/svn/cvs/etc) to create a string in the 'binary' which identified the code. In shell scripts it just sat there.
The change in the ident string where it gets the 'SMI' is when the version was from 'Sun Microsystems Inc' (aka SMI).
The reason Solaris included it was because it was part of the 'merge' between SunOS and System V and Sun had permission to all of the AT&T copyrights with respect to UNIX once they became 'partners' (AT&T invested essentially a billion dollars in Sun).
But in reality, couldn't one argue that the copyright covers the name '/bin/true' and the empty file contents?
Or that the whole work is copyrighted, with a stamp on each file to remind you of that fact?