Return to BSD News archive
Newsgroups: comp.os.386bsd.questions Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!darwin.sura.net!sgiblab!sgigate!sgi!igor!jbass From: jbass@igor.tamri.com (John Bass) Subject: Re: 386BSD vs BSDI Message-ID: <1993Mar3.120727.11788@igor.tamri.com> Organization: DMS Design References: <1moeeuINNoo1@usenet.INS.CWRU.Edu> <1993Mar2.192941.8458@igor.tamri.com> <1n0mgmINNjat@ftp.UU.NET> Date: Wed, 3 Mar 93 12:07:27 GMT Lines: 84 In article <1n0mgmINNjat@ftp.UU.NET> sef@Kithrup.COM (Sean Eric Fagan) writes: >In article <1993Mar2.192941.8458@igor.tamri.com> jbass@igor.tamri.com (John Bass) writes: >*sigh* > >>The Net-2 bio.c file really >>say's it all ... they didn't even have the guts to do the job ... just >>deleted all the code and added a copyright to the remaining function >>prototypes. > >You cannot copyright an interface. And a function's name and arguments >is an interface, and, for the ones you picked out, need to be described >somewhere, so third-parties can add device drivers and the ilk. > >*sigh* Sorry Sean but I don't buy it ... device drivers have no business calling breada, bawrite ... etc. These routines are internal routines for supporting the AT&T file system & buffer cache design. The fact that the BSD filesystem is derived from the AT&T filesystem doesn't allow them the right start declaring what they want for internal interfaces. Ditto with TTY and a number of other code segments found in Net-2 and 386BSD. IF you take your argument to the limit .... every procedure prototype in a program becomes a defacto minor interface of some sort ... sorry ... I just can't buy into that argument. If true It would force people to start writing single procedure programs with go-to's just to protect themselves from this type of abuse. The major effort in the design of any program are the choices of how to subdivide it, what common internal functions to build on, and what supporting global variables and data structures to use. To allow anyone to come along and after the fact declare these critical design issues defacto public interface routines is beyond belief -- certainly AT&T in V7/32V did not. Most of us design and write programs with short and simple procedures ... Once you start allowing people this freedom there is NO real protection for software designs and implementations. If you take any major software project, delete the code body's in every procedure, and then have someone re-write each procedure ... you have the SAME program ... the same design since the contents of the code body are at that point as firm as the contents of a crossword puzzle matrix bounded by the restrictions of the supporting hints. This is certainly true in cases where the sources are provided (like AT&T did for UCB/CSRG) ... and it becomes even more serious if people are allowed to dissasemble/decompile your program and rebuild inside the framework you are suggesting are defacto interfaces. Simply not wanting to invent a new buffer cache design and modify the filesystem to use it ... is not a valid reason for UCB/CSRG attempting to place the internals of the AT&T design into public view. MINIX/LUNIX and many other OS's both before and after UNIX have managed to implement filesystems and caches with completely different internal designs ... it isn't like there is just one way to do this job. In fact, the very fact that LUNIX is POSIX conforming with a very different internal structure, makes it clear there are other ways to meet the API without cloning the internal design of UNIX. When I look at the sources of LUNIX it is hard to find any common internal reference points to the UNIX design, much less ANY internal procedures, data structures or code sequences that are common with UNIX internals. The issue is that, the internal details of this design ARE AT&T property and UCB/CSRG accepted the information under non-disclosure knowing that the design represented proprietary information disclosed as a trade secret. Yes UCB made major changes and additions to portions of the design, but that does not allow them the right to pick and choose what portions of the AT&T design they need to make public in order to save themselves the effort of redesigning the supporting and interfacing parts to provide a completely standalone design for use in other OS designs. I doubt that the community would accept someone slapping copyright on the result of deleteing the code body in every procedure for GNU C, C++, and EMACS, leaving the data declarations, structures, procedures and comments in place (removing the original copyright/copyleft and authorship credits) and calling the re-write of all the code body segments a new design free from copy???? or moral right of authorship. Is it really acceptable to allow UCB/CSRG do this to AT&T when most people I know would be mad as hell if someone did it to their pride and joy. As the previous person said ... slimy! ... slimy as hell... John Bass DMS Design