The /bin/true Command and Copyright | Hacker News Reader

true Command and Copyright

trillian.mit.edu

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 bug-coreutils@gnu.org

I love commands with pesky names.

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

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".

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

You'll notice the slight difference with `true`.

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.

Yes your are surely right. But what about GNU guys' bint/true implementations copyright message? :)

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.

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.

I am aware. Still rather amusing however.

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.

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"?

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.

Reminds me of Oracle licensing the Java Hello World: http://docs.oracle.com/javase/tutorial/getStarted/applicatio...

  # (c) 2012 me
  #
  # The following comment is tried to be copyrighted
  # by me. Do not misue!
  #
  
  awesome

# Can I use derived works?

Yeah, super awesome!!

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).

This is an interesting idea. If John Cage composes a song that is all silence, can't that be copyrighted?

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?

Idea for GNU's /bin/true new option: --false, that would make it exiting with 1.

That might be a little too confusing. But --true and --false options would be right at home in a /bin/bool command.

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...)

"So if you use blank lines in any of your files, you are in blatant violation of AT&T's copyright claim."

WRONG!

For fun, if you are running OS X 10.7:

    codesign -d -v /usr/bin/true

Aha, 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

and CentOS 6:

    $ 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

The signature size explains (part of) the larger delta on OS X, but left me wondering, so:

    ~/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

Curious!

    ~/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.

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:

    $ 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

Reply on news.ycombinator.com