std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (11/10/88)
From: uunet!ames.arc.nasa.gov!sultra!dtynan (Der Tynan)
I have been wondering, for some time, about the status of the files in the
/usr/include directory. It would seem to me, that these files are the
property of AT&T, and as such, cannot be distributed without a licence.
In the context of POSIX, and the numerous 'public domain' efforts in
progress, one of the things I would like to see, is a list of the 'necessary'
files in these directories, and perhaps, public domain (or freeware) versions
of these files. Thus, people developing software (PD or otherwise), which
in some way or another, uses these definitions, can know what to expect. I
know that the (admittedly, rather old) copy of the POSIX document I have,
gives some vague definitions to some of the files (pwd.h, for example). It
doesn't really shed much light on what definitions can and cannot be used.
As an example, consider the following;
if ((ip->i_mode & IFMT) == IFDIR)
/* something */;
This is a fairly standard piece of code. When RMS et al, produce a CERTIFIED
AT&T-free kernel, it would seem to me, that this code CANNOT be included in
any of the utilities, because it is using AT&T definitions. I would appreciate
some clarification on this issue. If such code cannot be used in UN*X clones,
or lookalikes, then it will have to be replaced with macro's such as
if (isdir(ip))
/* something */;
It would certainly be nice to know that now, rather than two years down the
road.
- Der
--
dtynan@sultra.UUCP (Dermot Tynan @ Tynan Computers)
{mips,pyramid}!sultra!dtynan
--- God invented alcohol to keep the Irish from taking over the planet ---
[ The IEEE 1003.1 Full Use Standard is more clear about what parameter
files it requires. AT&T has expressed no objection to the use by 1003.1
of the information specified in that standard for those files (including
IFMT and IFDIR). Since the legal protection of AT&T code is as trade secrets,
it's hard to see how they could claim that those definitions qualify. -mod ]
Volume-Number: Volume 15, Number 22jpn@genrad.com (John P. Nelson) (11/12/88)
From: jpn@genrad.com (John P. Nelson) >I have been wondering, for some time, about the status of the files in the >/usr/include directory. It would seem to me, that these files are the >property of AT&T, and as such, cannot be distributed without a licence. While they fall under the copyright rules, they do NOT fall under the more restrictive "TRADE SECRET" rules, because they are available to the normal binary licensee. >As an example, consider the following; > if ((ip->i_mode & IFMT) == IFDIR) > /* something */; > >This is a fairly standard piece of code. When RMS et al, produce a CERTIFIED >AT&T-free kernel, it would seem to me, that this code CANNOT be included in >any of the utilities, because it is using AT&T definitions. Not quite. If the definitions of these macros is contained in the MANUALS (i.e. the SPECIFICATION), then anyone can recreate the header files from the specification without fear of infringing on AT&T's copyright. The same thing would NOT be true if it were to fall under the AT&T "trade secret" source contract. Of course, it would still be illegal to include verbatim copies of AT&T's header files. Therefore, UNIX clones are quite legally able to match the UNIX interface, since copyright only protects a particular EXPRESSION of an idea, not the idea itself. -- john nelson UUCP: {decvax,mit-eddie}!genrad!teddy!jpn smail: jpn@teddy.genrad.com Volume-Number: Volume 15, Number 27
henry@zoo.toronto.edu (11/16/88)
From: henry@zoo.toronto.edu >... one of the things I would like to see, is a list of the 'necessary' >files in these directories, and perhaps, public domain (or freeware) versions >of these files... There is a fundamental problem with this, in that those files can and often do contain implementation-dependent information. For example, <stdio.h> must contain definitions of the getc and putc macros, which are intimately tied to the implementation details of the rest of stdio. For another example, it's hard to imagine a portable version of <stdarg.h>, since its whole purpose is to cover up implementation details. >... Thus, people developing software (PD or otherwise), which >in some way or another, uses these definitions, can know what to expect... This is precisely what documentation, including standards, is supposed to tell you. (Admittedly, it doesn't always do this very well.) Henry Spencer at U of Toronto Zoology uunet!attcan!utzoo!henry henry@zoo.toronto.edu Volume-Number: Volume 15, Number 30