gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/09/88)
In article <5776@megaron.arizona.edu> lm@megaron.arizona.edu (Larry McVoy) writes: >you may reimplement the idea contained in the code and further more, you may >do so by sitting down with the, say, unix code as your guide. You could not >copy the code but you could look at the code to see how they did it. That might be true of copyright but it's definitely not true for UNIX source, which is protected as a "trade secret". Read your license.
boyd@basser.UUCP (06/09/88)
In article <302@eagle_snax.UUCP> geoff@eagle_snax.UUCP writes: >-- >Geoff Arnold, Sun Microsystems | "We didn't set out to kill anyone" But, ``we'' did implement NFS. Those ``creds'' & YP. I laughed till I was sick. Security?? Is there any with UDP/IP? Do the NFS servers _know_ who requested the service? I don't think they do, do they? Boyd Roberts boyd@basser.cs.su.oz boyd@necisa.necisa.oz ``When the going gets wierd, the weird turn pro...''
andrew@frip.gwd.tek.com (Andrew Klossner) (06/10/88)
[] "I was told ... that you can't copy code but you may reimplement the idea contained in the code and further more, you may do so by sitting down with the, say, unix code as your guide. You could not copy the code but you could look at the code to see how they did it." With regard specifically to Unix, you were told wrong. Unix source code is protected primarily by trade secret law, and (recently) secondarily by copyright law. In theory, at least, you agreed to uphold AT&T's Unix trade secrets before you were given access to the source code; if you didn't, the entity that gave you access is at fault. (In my case, I agreed as part of signing my new-employee agreement, which includes wording in which I agree to abide by all company contracts.) Trade secret law explicitly prohibits using the secrets in the sort of "reverse engineering" that you describe. Whether copyright law prohibits this is a much more murky question. You could argue that the resulting new code is a "derived work" and the property of the copyright holder of the original code. You could also argue that it isn't. -=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP] (andrew%tekecs.tek.com@relay.cs.net) [ARPA]
ruth@mks.UUCP (ruth) (06/16/88)
I am posting in response to your message concerning UNIX compatible versions of Crypt. MKS advertises the MKS version of the Enigma and DES crypt command in several MKS products (MKS Toolkit, MKS Vi, MKS Trilogy). At MKS we make this claim of UNIX compatibility without the need of UNIX licensing because we have created this software entirely by ourselves working from first principles. We found a useful source of information is the Bell Labs Tech. Journal vol 63, no 8, part 2, which is entitled "File Security and the UNIX Crypt Command" by Reeds and Weinberger. This article served as a starting point for our efforts. MKS had to do considerable tuning of parameters until the development team established the exact values for some of the tables. MKS has implemented two levels of compatibility in crypt: 1) the MKS Toolkit commands login and passwd use encrypted passwords (and in fact the whole /etc/passwd) that is compatible with crypt(3) 2) The MKS Toolkit (and other products) crypt command has both UNIX crypt(1) command rotor machine compatibility and industry standard DES encryption. Ruth Songhurst Vice President Business Services Mortice Kern Systems Inc. (519) 884-2251