The /bin/true Command and Copyright (1990) | Hacker News Reader

true Command and Copyright (1990)

trillian.mit.edu

125 pointstosh55 comments

This is really silly. Not fun or interesting at all. Gnu coreutils wants all the command line utilities to respond to --help and --version. The version number is that of the coreutils package, if your ls is Gnu ls, it'll say the same number too:

    [2] g@alpha (0)$ /bin/true --version
    true (GNU coreutils) 8.26
    Copyright (C) 2016 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.
    
    Written by Jim Meyering.
    [3] g@alpha (0)$ ls --version
    ls (GNU coreutils) 8.26
    Copyright (C) 2016 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.
    
    Written by Richard M. Stallman and David MacKenzie.
    [4] g@alpha (0)$

WRT AT&T true(1), well they probably were required to put a header in a certain format in every source file, and they put that in this one to. Probably the implementor just copied from a template and left it like that. Also I don't beleive they manually edit the years in copyright notices, one usually has a script to do that.

> Gnu coreutils wants all the command line utilities to respond to --true and --version. The version number is that of the coreutils package,

You meant to say --help and --version.

Yes, thanks.

> Also I don't beleive they manually edit the years in copyright notices, one usually has a script to do that.

It's not clear if you're referring to the copyright notices displayed to the user, or the copyright notices embedded in the source code. In the former case: I have been told to programmatically print $CURRENT_YEAR in a program's displayed copyright notice, which I refused to comply with. After all, someone running the program 200 years in the future should be able to determine that the copyright has long since expired.

At the rate things are going, nothing since Mickey Mouse will ever again have expired copyright, as lawmakers will keep extending the copyright term.

Well, think about us in Europe who have a chance to have a sane copyright reform one day.

There is a lot of space between (1) a copyright notice, (2) a valid copyright, and (3) a valid claim against a third party for copyright infringement. On (1), authors can attach copyright notices to their work, but it isn't necessary to secure their copyright interests, nor is it sufficient to make the work protectable. On (2), validity will depend on whether the work is protectable expression and whether or not the expression merges with the idea. On (3), there are a whole host of defenses to infringement including Fair Use and a de minimis defense (copying is so small it doesn't matter).

Here, I'd expect that an expression of an empty program would merge with the idea of an empty program, which would make it not copyrightable. Of course, that doesn't stop someone from putting a copyright notice on it anyway.

This is entirely the right way to see things.

I'd like to emphasize that a copyright notice' purpose is to serve as evidence, should a copyright claim be made. As you said, it is neither necessary nor sufficient to establish a copyright. There's no harm in putting a copyright notice on uncopyrightable material. With that understanding, including a copyright notice just makes sense.

If you're AT&T you have two options. You can tell your engineers to just always include the copyright notice, or you can ask your engineers to understand copyright law well enough to decide whether the notice is called for. The decision is pretty obvious.

EDIT: Ohh, there is a third option. You can pay lawyers to review every code file.

From a strictly legal perspective I suspect /bin/true (or at least AT&Ts implementation) do not live up to the law's requirements of originality and expressiveness.

Considering that they were the copyright holders for unix at the time, and that this 'default interpreter processing'/ return code mechanism was part of the kernel/userland interface, I'm not so sure that's the case..

not to defend AT&T over unix, as a BSD guy..

My guess is that the copyright is for the whole body of work, and not just for the single file. The copyright notice in the single file is probably not a requirement from a legal standpoint and is merely indicative.

These days most IDEs automatically add a copyright/license default text to the top of each new file. It makes sense to instruct software engineers to follow a simple copyright rule rather than expecting them to play JDs and keep up with all the standards and developments in what was at the time (and still is) quickly changing copyright laws.

I find the man pages descriptions of both true and false zen like and have wanted to make t-shirts out of them for years. On Ubuntu, the man page copyright is claimed by FSF, can I make a shirt?

Only if you provide the source code for the shirt upon request

It's provided on the shirt itself (self-evident), so it should be fine to distribute copies of the shirt.

The GPL also requires providing a copy of the license.

Put it on the back of the shirt.

You could include it on the care instructions tag in tiny tiny print.

Problematic if you wear the shirt in public and allow someone to take your picture. You must provide them a copy too or your license to wear the shirt is revoked.

> ... your license to wear the shirt is revoked.

Well, you have 30 days time to comply.

No no, the source code for the shirt. You know, the code you compiled into fabric and stitching.

Is it under GPL, or under GFDL? If the latter, you probably have to include a rant by Richard Stallman about the magic of Free Software on the back of the shirt (GFDL has clauses to force you to reproduce… well, that).

It's more interesting that they incremented the version of the script. Apparently modifying comments justifies increasing the minor version.

After having seen a comment addition cause a bug[1], I appreciate the effort.

1) really damn weird compiler bug was all we could think of

The number is placed there automatically by some old version control system (probably SCCS or RCS) and is incremented on every commit. The commits were likely just adding a new year to the copyright line.

"@(#)true.sh 1.6 93/01/11 SMI" /* SVr4.0 1.4 */

is an sccs id.

Anecdotally (wasn't there at the time): sccs was more common everywhere before RCS because sccs was part of all unix (e.g including BSD UNIX).. it was encumbered as part of the UCB USL suit and rcs use grew after that, then cvs, then svn, then git

That's the version of coreutils, not that of true. Try:

    (/bin/true --version; ls --version; cat --version) | grep coreutils

all will be the same.

What's even more interesting is to see how much code is needed in the GNU true.

http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/true...

4 includes, 3 ifdefs or define blocks, the whole thing is 80 lines, more than half of it code!

Looks like most of the code is processing the arguments.

It is. -h, -v

--help, --version. Short options are not recognized.

Since those are just for argument parsing, should we not also include the extra code that the kernel run in order for proper execution? With that we can even include additional stuff like apparmor adding code to protect against exploits in True.

I suspect that each invocation to True, regardless of implementation, spend in average a large amount of unnecessary cpu instruction for practically every OS.

By comparison, OpenBSD's version:

  /*      $OpenBSD: true.c,v 1.1 2015/11/11 19:05:28 deraadt Exp $        */

  /* Public domain - Theo de Raadt */

  int
  main(int argc, char *argv[])
  {
        return (0);
  }

Which is, actually, far too large due to the standard library, program state initialization, and stack frame management. If there's ever a practical use for code golf, this is probably it. /bin/true should be a bare minimum ELF executable with no stack or heap that does nothing except immediately make the system call to terminate.

As mentioned in the article:

" This can be done with an empty file that's marked executable, and that's what it was in the earliest unix system libraries. "

    $ uname -sr
    OpenBSD 6.1
    $ install -m 755 /dev/null /tmp/muhtrue && /tmp/muhtrue && echo yup 
    yup

not sure why it was ever switched.. probably the 'return 0;' version is cheaper than a shell fork? hmm..

She’ll forks are expensive. Very expensive.

Of course the system could have special cased a zero length executable file.

*shell forks

Well this code might do exactly what you just said.

Everything depends with which compiler flags you build this code. I know for sure there are MSVS flags to build this program with no runtime and other things with just return asm op in it.

Most likely nobody uses /bin/true (/usr/bin/true).

Executing true without the pathname will run the shell embedded function.

Needing a program that returns true comes up more often than just shell scripting. For example, maybe a system reports an event by launching a named executable. Specifying /bin/true is the equivalent of redirecting that event to /dev/null.

http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm...

But it implements true and false!

This is thought to be because of GNU Coding Standards: https://www.gnu.org/prep/standards/standards.html#Reading-No...

They wanted GNU implementers to be careful not to copy (even through their recall) AT&T UNIX implementation, but to do compatible solutions in different way. This allowed them to keep safe footing legally through the time when the original UNIX source code's copyright status wasn't clear. The point of the GNU project is to create independent UNIX compatible operating system.

The BSD implementations are often referred in this discussion, but regarding them, you've got to keep in mind that it is continuation of the original UNIX source tree, after it's copyright status was clarified (https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc....).

I was hoping this would also go into whether AT&T actually acted to enforce this copyright, as copyright covers "The work" and "significant subsets", but will not cover things like newlines. For that kind of content (as well as "int i= 0" and the like) there is both prior art, and the claimed-copied content cannot be used to identify the work, and where in that work, the line would have been lifted from.

The article seems mostly about the fact that AT&T intentionally added a copyright notice in their otherwise empty program's comment block, in an era that predates the era of widespread availability of software and copyright wars. Which is honestly not really all that surprising.

> The article seems mostly about the fact that AT&T intentionally added a copyright notice in their otherwise empty program's comment block, in an era that predates the era of widespread availability of software and copyright wars. Which is honestly not really all that surprising.

This page was likely written exactly because of the 'era of widespread availability of software and copyright wars' - e.g. the statement:

"One of the fun examples among all the copyright fuss"

combined with the edit dates (90,93) seem to me to indicate this was written exactly as a response to the UCB vs USL suit..

https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc.....

as well as the 'unix wars'

https://en.wikipedia.org/wiki/Unix_wars

There is essentially no downside to overclaiming, whether in copyrights or patents. Worst consequence is wasting several dozen bytes.

So you could say that the algorithm for "should I claim any given intellectual property right?" is the one implemented by /bin/true.

I recall last I looked at Solaris, it was far bigger than that. Microsoft was even in there (due to Xenix.)

Random thought: it's pretty absurd to claim copyright on an empty program, but if this behavior was sufficiently innovative, could one patent an empty program?

Patentable subject matter under U.S. law consists exclusively of "any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof". 35 USC 101. So, a program may implement a patented process or it may be a piece of a patented machine, but it won't be patentable in itself.

I love seeing pieces of history like this, thank you for sharing it.

> I've pointed this out publicly on numerous occations, in various technical forums, since the early 1980's. So far I haven't heard a word from any AT&T lawyers. Anyone have any idea why they are ignoring such a violation?

Ah, one of those people.

Those people who point out absurdities that almost everyone wants desperately to ignore?

Imagine what a wonderful world it would be if someone took lawyers to task for every absurdity!

We'd have to do the same for developers. A program that does nothing is an absurdity. The equivalent function, `id`, is an absurdity. I'm sure I could think of more if I tried.

ninjedit: I understand that they are a logical consequence of a reasonable way of doing things; my point is that law is basically the same (you could argue that a law is unreasonable, but a seemingly absurd law is not prima facie unreasonable).

Reply on news.ycombinator.com