From: Bob F. <bfr...@si...> - 2003-11-19 18:25:25
|
On Wed, 19 Nov 2003, Daniel Rogers wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Bob Friesenhahn wrote: > | On Mon, 17 Nov 2003, John Cupitt wrote: > | > | > |>For curiosity, could someone explain the commercial objections to > |>LGPL (or suggest a link)? Libraries such as gtk are LGPL and they > |>seem to used commercially without problems (as far as I know). > | > | > | If the commercial use of LGPLed libraries targets operating systems > | that include the libraries (e.g. Linux includes Gtk), then there is > | reduced/little concern. If the library needs to be added to the > | environment (e.g. LCMS under Windows or even LCMS under Linux since > | LCMS is not yet standard under Linux) then the vendor takes the full > | responsibility for LGPL upon his self, including allowing the user to > | reverse-engineer his application. > > This is just plain wrong. reverse-engineering has nothing to do with > coverage under the LGPL. reverse-engineering is simply a protected > freedom (at least here in the united states). Reverse-engineering is not as protected as you claim. In fact, it is not really protected at all. Have you never heard of the DCMA (see http://www.eff.org/IP/DRM/DMCA/ for the continuing debate)? The DCMA can put you in jail. Also, the license for almost all commercial applications prevents reverse engineering (for obvious reasons). > | If LCMS is built into the application as a static library, then the > | vendor would need to provide either his proprietary sources, or > | pre-built objects corresponding to his sources, so that the user is > | able to re-link the application (as required by LGPL). > > This is only a partial truth. If LCMS is staticlly linked then you may > do the above or you can simply provide a version of your binary that is > dynamically linked to the same LCMS version that was staticlly linked. Not so. If a statically linked version is distributed, then it must comply with LGPL. The existence of a dynamically linked version does not alleviate the restrictions on the static version. For LGPL, each "program" is a seperate entity. > Note that you probably have to do this anyway (at least on linux), > simply because the standard C library on linux (glibc) is covered under > the lgpl. (And I'd like to see somebody get away without using that!!) LGPL does include provisions supporting a an existing shared library ("(1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, ..."). Obviously, this precludes static linking. Once LCMS becomes a standard component of operating systems, then the "already present" clause takes effect. I assume that "already present" would also apply if the user installed LCMS prior (and independent) of the dependent application. Obviously LCMS should be a standard component of every operating system. > For example, quake3 from id software provides a staticlly linked binary > and a dynamic one in the same directory when quake3 is installed. Sounds like a LGPL violation to me. The quake3 approach is not provided for by the LGPL license. The existence of a violation should not be used as evidence that it is correct to be a violator. > As for commerical implications, there are very few. All you really need > to do is provide the sources to the version of the lgpl libraries that > you use upon request (including glibc!) and provide a dynamiclly linked > version of your executable (which you will probably do anyway). In > practice, very few of your uses will actually ask for the sources, and > if you are wise, you can simply include a tarball of the lcms sources on > your installion cd. I agree that this is a reasonable avenue for many commercial applications. However, there are also many commercial applications which prefer static linkage since there are fewer things to go wrong, and the application vendor has more control. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |