Xref: utzoo comp.sources.d:5704 trial.misc.legal.software:17 Path: utzoo!attcan!uunet!aplcen!haven!adm!cmcl2!kramden.acf.nyu.edu!brnstnd From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.sources.d,trial.misc.legal.software Subject: Re: What documentation is fair/legal to use to develop clone software? Message-ID: <337:Jul2821:30:4090@kramden.acf.nyu.edu> Date: 28 Jul 90 21:30:40 GMT References: <70K&Z.&@splut.conmicro.com> <1990Jul24.005745.19262@murdoch.acc.Virginia.EDU> Organization: IR Lines: 81 In article mason@tmsoft.UUCP (Dave Mason) writes: > I am developing a clone of some major AT&T software (exactly *what* is a > secret for now). I obviously don't want the result legally > encumbered, as it is to be freely distributable (a la FSF or less > restrictive rules). > The question is: What can I base my knowledge on? The real question isn't what you can do, but what you can't. You have to worry about (among other things, and in order of difficulty) trademark law, copyright law, patent law, trade secret law, and contract law. Trademark law: Make sure that you don't use a trademarked product symbol or name without giving AT&T (or whoever owns the trademark) credit. You probably don't have many names to worry about. Copyright law: Unless you make copies of or derivative works from the AT&T manuals and code, you're safe. Asking someone else to do the dirty work is no good: you're liable for contributory infringement. Patent law: Almost certainly inapplicable. Don't worry about it. (Yet.) Trade secret law: You're not allowed to steal someone's secrets. So if AT&T uses some neat coding techniques that they're not telling anyone about, and if you sneak a look at code saying ``Trade secrets in here! Go away!'' and figure out those coding techniques, you're in trouble. Contract law: Whatever you've signed, you'd better obey. The easiest test for safety in cloning is whether you've looked at (or disassembled, or pried into) the original code. If you haven't, then you can't possibly be breaking copyright law or trade secret law. > Some answers: The X/Open manuals? The Posix manuals? The UNIX > manuals? The Bach book? Reading the .h files? The SVID? Fine. Information can only be protected by trade secret, and nothing you've listed is a trade secret. Anything you can legally read, you can legally learn from, and legally apply. (A particular *expression* of information is protected by copyright, but the information itself cannot be.) > Other > people reading the source & answering questions (this seems to be > breaking their trade-secret agreement with AT&T)? It is more likely that they signed a contract agreeing to respect the trade secret. In any case, they lose their license. > Me > reading the sources (I'm sure this is not kosher)? If you *don't* read the sources, your position is very difficult to attack, so I recommend taking that strategy. Reading the sources may not be a tort, but what happens if you subconsciously reproduce the same variable names in your code? The same function names? The entire original? It's safer not to. > To this point I have looked at > the X/Open & UNIX manuals & read the Bach book & very occasionally > looked at .h files. Fine. When I want to clone a program, I read the man page. Then I write the program, applying knowledge gleaned from books and other man pages. Then I rewrite the man page. As a last step, I often check that my program uses the same output format as the original, though in extreme cases this may violate copyright law. (Visual images are copyrightable.) > For example, suppose I were doing a STDIO? How would I know the > function names, valid parameters, binary values of #defined values > (such as _IOFBF, _IOLBF, _IONBF in setvbuff(3))? You read stdio.h. You hope that the Lotus decision and the proposed European copyright law don't stand up to criticism. > And the .h are > clearly copyrighted... Unless you copy them (or display them in public :-) ), this is irrelevant. ---Dan