|
From: Christopher M M. <cm...@ve...> - 2001-10-25 02:15:56
|
Hi - I am copying this reply to one of the openvrml mailing lists, some one there might be better able to answer your question. Although I originally developed LibVRML97, which was used as the basis for OpenVRML, I am not actively involved in OpenVRML anymore. I am not clear on the licensing either, but for whatever it is worth, I was always supportive of commercial uses of the code (under the theory that any support of vrml was better than none). If it meets your needs you can still find older versions of libvrml97 around that are covered by BSD-style licenses. I *think* the intent of the LGPL is that as long as you make the OpenVRML sources available to your users, your changes to OpenVRML available to everyone, and your users are able to replace the OpenVRML DLL with any new or improved version of their choice, you are OK. But nobody pays me for legal advice. Good luck, Chris ----- Original Message ----- From: "Raphael Auf der Maur" <rm...@ii...> To: <cm...@ve...> Sent: Friday, October 19, 2001 7:09 AM Subject: OpenVRML in commercial software > Hello, > > I've a question regarding your great OpenVRML library which is under Lesser > GNU licence. > > I don't fully understand this licence, mainly paragraph 5. If I got it > right, it is allowed to use the library in commercial, not open-sourced > software as long as all modifications on the library are published and open > sourced too. But in paragraph 5 there are other restrictions mentioned. > > ----------- > "A program that contains no derivative of any portion of the Library, but is > designed to work with the Library by being compiled or linked with it, is > called a "work that uses the Library". Such a work, in isolation, is not a > derivative work of the Library, and therefore falls outside the scope of > this License. However, linking a "work that uses the Library" with the > Library creates an executable that is a derivative of the Library (because > it contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. Section 6 > states terms for distribution of such executables. When a "work that uses > the Library" uses material from a header file that is part of the Library, > the object code for the work may be a derivative work of the Library even > though the source code is not. Whether this is true is especially > significant if the work can be linked without the Library, or if the work is > itself a library. The threshold for this to be true is not precisely defined > by law. If such an object file uses only numerical parameters, data > structure layouts and accessors, and small macros and small inline functions > (ten lines or less in length), then the use of the object file is > unrestricted, regardless of whether it is legally a derivative work. > (Executables containing this object code plus portions of the Library will > still fall under Section 6.) Otherwise, if the work is a derivative of the > Library, you may distribute the object code for the work under the terms of > Section 6. Any executables containing that work also fall under Section 6, > whether or not they are linked directly with the Library itself. However, > linking a "work that uses the Library" with the Library creates an > executable that is a derivative of the Library (because it contains portions > of the Library), rather than a "work that uses the library". The executable > is therefore covered by this License. Section 6 states terms for > distribution of such executables. " > ----------- > > I'm honestrly not sure what this means. In my software, it is not possible > to link a compiled dll dynamicly, so I think I would have to include the > h-files of your library in my commecial, not open-sourced software in order > to use your library. Is that allowed? You might explain me the restrictions > in this paragraph? > > Sincerly, > Raphael > > > |