Date: Wed, 10 Apr 1996 13:44:27 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: lenzi@cwbone.bsi.com.br (Lenzi, Sergio) Cc: ports@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Lesstif (motif compatible) package. Message-ID: <199604102044.NAA02340@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.91.960410102121.1459B-100000@lenzi> from "Lenzi, Sergio" at Apr 10, 96 10:24:55 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I have uploaded (in pub/FreeBSD/incoming) a package (lesstif.tgz) that is > a motif compatible window manager (with includes and libXm.a/libXm.so.0.36) > > I am using mwm program compiled within and seems to work OK. > > Waiting for any comments, You asked for comments; here are mine, for what they are worth: Lesstif is a clone Motif library, not a window manager. It is incomplete at this time (ie: not ready for prime time). It also has a number of outstanding non-technical problems (described in detail below). I believe Lesstif to be legally "at risk". It implements undocumented Motif interfaces that would require looking at a real Motif distribution's header files and namelisting a real Motif library (both of which have been discussed on the Lesstif list). Further, it is a Motif 1.x library implementation; many of those undocumented interfaces have been converted to documented interfaces in Motif 2.x. From the 2.x documentation, it is clear that only some of the _Xmt routines have been exported as Xmt_ routines, and even then, there have been interface changes -- meaning there is no legally usable public documentation of some of the interfaces that Lesstif implements. Further, Lesstif implements macros and manifest constant values that could only be implemented with knowledge of the OSF header files. Better, in my opinion, to not implement them and require code that is out of spec to be corrected (from my personal experience with a stub library and real header files built entirely from published documentation, the MOXftp code and the font handling in the "Motif toolkit" library from the book is the only publically available source code that uses promiscuous knowledge of Motif internals to subclass widgets). Admittedly, header files have been judged to be published documentation of interfaces in past court cases, despite Copyright and Non-publication notices in the header file body. One might successfully argue that library namelists and the structural information a library namelist presents in terms of module organization and call graph, and the functional call graph output from a trace of a program bot fall into the "published" category as well. But to do so will probably require a legal fund sufficient to fight a harrassment suit designed to put a potential competitor out of business. Better to adopt "clean room" techniques and document every source used to implement every interface that is implemented, and to make sure that those sources are in the form of published materials, preferrably textbooks and sample programs from publically distributed archives with at least one commercial distributor. Basically, I believe OSF is in a position to be able to shut Lesstif down if it becomes a threat to their sales. Remember that PARCPlace reimplemented a Motif library which OSF refused to allow them to certify. I would also note that the Lesstif list traffic indicates that the code is far from functional except in a small set of cases. There is no UIL support (like anyone cares about that, though), and much of the resource conversion and other code is lacking. Thats why the 0.36 version number. Finally, the LPGL relink restriction is not resolved in BSD by shared libraries because of non-interface changes to the libraries not being specifically excepted by the LGPL (which gives no regocnition to any type of shared library technology). It is possible to overcome these restrictions using an adaptation of ELF technology, but even Linux does not yet have the necessary code to avoid linking shared library data segments statically into a binary. In closing, let me state that I believe a public Motif implementation is a necessity because of standards compliance issues and that fact that all ratified standards should, in my opinion, be required to have publically available implementations to avoid the need to license code. Standards should *not* be ratified if they include proprietary technology (like Motif in specific, and CDE in general). A standard is a public trust. So I definitely agree with the Lesstif project's goals, even if I can't condone their methodology because of the corner-cutting taking them into areas which I believe to be legally risky. I certainly can't offer an alternative (at least not at this point), but I would advise caution when using Lesstif: the relink clause of the LGPL is more inmical to commercial distribution than the static linking distribution terms of OSF, without further technological enhancement to shared library implementations, and assuming no interface promiscuity (a libc or libcurses LGPL library, in fact, can not meet these requirements on a permannent basis -- and Motif is much more complicated). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604102044.NAA02340>