> David Brown wrote: > > And as I understand the LGPL, if you link staticly to an LGPL library, you > > have to release your source (as GPL or LGPL) - the LGPL is designed for > > dynamic libraries linked to closed source, which is fine for pc's and other > > "big" systems. For embedded systems (assuming you don't want to open-source > > your app), you have to stick to BSD or modified (L)GPL code, as used by the > > mspgcc library. > > You can fulfil your requirements for linking against a LGPL library by > releasing, on request by somebody you distributed the executable to, a > set of object files with symbol information so that they can relink them > against a modified version of the LGPLed library. In addition those > object files can be under whatever license you want including one which > does not allow redistribution. You also need to provide on request any > modifications you made to the LGPLed library in source form. You are > entitled to make a 'reasonable' charge for fulfilling the request. >
You are correct - I wasn't thinking of the "middle" option of releasing the object code with symbols. Of course, that is basically what "executables" are on bigger systems, with the final linking done dynamically by the loader. Just out of curiosity (I'm not trying to find ways around the (L)GPL), do you need to provide any sort of information (like details of the tools used and compiler flags) or additional files (like linker files) with the object files and (possibly modified) LGPL'ed library? It would be easy to arrange for the code to be linkable but unrunable if a specific linker control file (or options for the linker command-line) were not included - perhaps locating a particular symbol at a specific address, which is checked by start-up code. Or the code might require post-processing, such as the generation of a checksum which is stored at a specific address, and checked on start-up. > > There are also good reasons for using the modified GPL - it gives the > > library writers almost all of the advantages of the GPL, and users almost > > all the advantages of BSD-style licensing. What would be very useful would > > be if the FSF formulated a standard EGPL for embedded use, covering this > > situation and saving programmers from having to mess with the legal stuff. > > IMHO the MPL is ideally suited to this type of situation. It protects > the source files which you place under the MPL (including requiring that > modifications to them be disclosed) but does not place any requirements > on what you link them to or what you write in your advertising materials. > That would be the Mozilla Public License? That might well be a good solution - as far as I can see, it lies between the GPL and BSD - if you modify any MPL'ed files, or include MPL'ed code in one of your files, then that file must be MPL'ed, but it does not affect any other files included in the same program. Is that right? > -- > ------------ Alex Holden - http://www.linuxhacker.org ------------ > If it doesn't work, you're not hitting it with a big enough hammer > > > ------------------------------------------------------- > This SF.Net email is sponsored by: InterSystems CACHE > FREE OODBMS DOWNLOAD - A multidimensional database that combines > robust object and relational technologies, making it a perfect match > for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 > _______________________________________________ > Mspgcc-users mailing list > Mspgcc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > >
