On Tuesday, December 14, 2010 9:46:09 AM UTC+11, Anthony wrote: > > On Monday, December 13, 2010 3:30:17 PM UTC-5, Branko Vukelic wrote: > > Start verbatim copy --------------------------------- > > > On Mon, Dec 13, 2010 at 1:09 PM, --- <lic...@fsf.org> wrote: > > > Importing code and sharing namespaces would most probably be creating a > > > derivative work and would need to be licensed under GPLv2 as well. > > > Ok, so let me clarify a bit. By importing code, we mean (since this is > > a Python library) that the application framework will execute parts of > > the application, and that the application in turn may execute parts of > > the framework. It is a fact that the application may not execute > > properly without the presence of the framework, but the framework > > authors do not consider applications derivative work because of this. > > Could you please advise on this position? > > The answer would be the same. These activities would create a derivative > work. > > > Would releasing the framework under the terms of LGPL allow > > proprietary software vendors to > > If the goal is to allow proprietary software vendors to do certain > things you should just say so. There are ways of doing this without > harming the free software community. The LGPL isn't recommended in this > case (see: > [http://www.gnu.org/licenses/why-not-lgpl.html]<http://www.gnu.org/licenses/why-not-lgpl.html%5D>). > > > > One way is to dual-license the code. Release the code under a strong > copyleft license such as the GPL and if a company wishes to distribute > it under proprietary terms sell them a copy of the software under a > suitable license. Done right this is a great way of funding the > development of free software. This was everyone always has access to a > copy of the code under a free software license and proprietary software > companies fund your development efforts. > > Another way is to Release the code under a strong copyleft license such > as the GPL and to add narrowly defined exceptions which would allow > proprietary software to interact with your software in particular > ways. See: > [http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs] > > End verbatim copy --------------------------------- > > Judge for yourself if I understood correctly what the guy says. > > Thanks for investigating that. Reading their FAQ, it seems that GNU doesn't > generally want anyone to use LGPL at all, purely based on principle. So > their response may be more of a preference than a legal opinion (i.e., even > if we could use LGPL, they would prefer we don't). If a web2py application > doesn't count as an "Application" or "Combined Work" under LGPL, then I > don't know what does. In any case, this discussion has convinced me that if > we really want to get this right, we would probably have to consult an > intellectual property attorney with open source experience. Maybe it's not > worth the bother/cost right now, though. >
The manner in which the LGPL works when applied to a library actually depends to a degree on more than just the function APIs the library may expose. Take C++ for example. You might think that the LGPL on a reusable class library would be fine, but technically this may not be the case. The problem with C++ is template classes. For these the code implementation is effectively in the header files which get included into your application code when compiled and the expansion of those templates against types within your application ends up as part of your application binary, as opposed to it being a part of the library. Thus technically the template code may be construed as ending up as part of your application. As such, the library API in C++ may not draw a distinct enough line whereby that library could then be replaced with a distinct implementation of that library and provide the same functionality without reliance on any of the prior LGPL code. This being because the LGPL code is a part of your program binary still. Even with the C programming language you might have issues if you were using preprocessor macros to do a poor mans version of C++ template. So, it can depend not only on the specific language being used, but how that language is used and how the language is implemented. The LGPL and how it applies therefore isn't always clear cut and that is possibly part of why they have a preference for it not being used. This is why you always need to have lawyers who have some understanding of how programming systems are implemented, or have had sufficient expert advice on it, to make judgements and advise you. It is dangerous to simply assume that something sounds okay. Graham
