On 25/07/2006, at 10:47 PM, Lynn Fredricks wrote:
Andy Dent wrote
No RB source code can ever be anything other than GPL as the
inclusion mechanism will make LGPL turn into GPL.
LGPL is only safe if you have dynamic libraries which can be
replaced by an end user.
Hi Andy,
Can you explain exactly how you came to this conclusion?
WELL
that first sentence didn't read anything like my version in my head :-)
Let me try again:
"Any attempt to release RB source code under LGPL fails - no such
source code can ever be anything other than GPL as the inclusion
mechanism will make LGPL turn into GPL."
Of COURSE you can release RB source code under any other license you
like! I frequently give away code.
There are some people out there with contrary views as to the ability
to release code under LGPL safely - I'm just pointing out that if you
really want people to be able to reuse (and contribute to) your code,
LGPL will prevent those with cautious lawyers/management. The
following opinions are a summary of the research and resulting
official company policies adopted towards LGPL at two different
shrink-wrap software companies where I've worked.
The basis for this opinion with some discussion from other sources is
included below...
LGPL defaults to the same behaviour as GPL *unless* the component
under LGPL is a separate dynamic library that can be replaced by the
user.
(AD RB-specific note, this would allow a dynamic library invoked via
declares but no form of RB compiled code.)
Otherwise people are bound by the GPL constraints of having to GPL
their own source.
The reason is the simple intent that a user be able to replace the
LGPL portion with a later version.
I've been responsible for researching this issue at two different
organisations seeking to use LGPL software in commercial packages, so
I'm pretty confident of this advice, backed in one case by an
intellectual property lawyer.
Good discussion of straight GPL issues [1].
Discussions
RC: I am with the understanding that if you write an interface to a
GPL'ed component and then write your software to that interface, all
you need to GPL is the interface, not everything else. I have seen
businesses do this, again this is backed up by a IP lawyer. (This is
second hand experience so the details might be hidden from me).
AD:
I'm not sure how this can work. Maybe *interface* is a bit vague for me.
For LGPL, there's a scenario where it works.
1. LGPL component is published by well-meaning person in form which
is not dynamically linkable (happens all the time)
2. write your own dynamic linkable wrapper for component
3. release your wrapper under LGPL ( must do this according to LGPL)
4. your main app can now call your wrapper, as can anyone else
5. for extra credit, release a crude, maybe much slower version of
the entire functionality conforming to the DLL interface of 2. under
a different license, just to prove that the swappable nature is
really there (think of this as unit-testing the license)
however
For a GPL piece of source, it doesn't matter how you call it unless
you have a separation amounting to a separate application invoked by
a separate process. eg: shelling out to the command line or using
some network comms to call a service.
The bottom line, as I understand it, is you can never incorporate a
piece of GPL code into your app via any form of lexical inclusion or
dynamic linking.
Further to the above discussion, this is quite clearly debunked by a
quote[2] that showed up recently on a mailing list.
If, at execution time, your work is linked with a GPL work,
it is a derived work.
Note that it does not matter whether the linking is static or
dynamic, so making use of a
GPL-licensed shared library creates a work derived from the
library.
[1] http://www.findinglisp.com/blog/2005/01/some-thoughts-on-free-
software-and-gnu.html
[2] http://www.linuxdevices.com/articles/AT9161119242.html
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
