Re: [opensource-dev] LGPL violation
On 10/28/10, Erik Anderson wrote: > There is a static component that is linked when linking to dynamic > libraries, however that is present mostly to inform the compiler on what the > ABI is, or how your compiled code is expected to interact with the DLL. It > is very possible to write a piece of code that explicitly loads the library > by name and manually builds calls to it. In fact, it's likely possible to > compile a program intended to run with a .dll without any related files > being on the machine at the time. Yeah, but that's not what we're talking about. libmedia_plugin_webkit.so is in fact linked statically with various Qt libraries - the entirety of the code for those Qt libraries is incorporated into libmedia_plugin_webkit.so by the linker at compile time, not just a stub. The same happens with libmedia_plugin_webkit.a and libmedia_plugin_webkit.dylib. I'm not sure exactly why Linden Lab decided to do this - it's not a common thing to do and getting it to work right requires a certain amount of mucking with the build system, since static libraries normally aren't compiled with options that allow them to be included in a shared library - but do it they did. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] LGPL violation
There is a static component that is linked when linking to dynamic
libraries, however that is present mostly to inform the compiler on what the
ABI is, or how your compiled code is expected to interact with the DLL. It
is very possible to write a piece of code that explicitly loads the library
by name and manually builds calls to it. In fact, it's likely possible to
compile a program intended to run with a .dll without any related files
being on the machine at the time.
On Thu, Oct 28, 2010 at 8:52 AM, Carlo Wood wrote:
> On Thu, Oct 28, 2010 at 08:27:52AM -0500, Dave Booth wrote:
> > On 10/28/2010 06:29, Carlo Wood wrote:
> > libmedia_plugin_webkit.{sp,dll,dylib}
> >
> > Make sure you quote examples of static linking when you're talking about
> > static linking :)
>
> Make sure you read carefully what I say and understand it before
> talking about wrong examples :)
>
> libmedia_plugin_webkit.{sp,dll,dylib} are linked STATICALLY with
> the Qt libs (as in, linked with .a).
>
> Thus:
>
> Qt*.a (LGPL) + LL*.o (LGPL+FLOSS) = libmedia_plugin_webkit.so
>
> ==> LL*.o must be made public (or their source code), or
> libmedia_plugin_webkit.so cannot be shipped.
>
> --
> Carlo Wood
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] LGPL violation
Actually the Qt wbekit source that LL uses is available as I had to
completely rebuild the set of libs on my system when I was working on
snowglobe using visual studio 2008 as the lib provided by LL caused an issue
when starting the viewer after being build due to an manifest
incompatibility issue.
From: opensource-dev-boun...@lists.secondlife.com
[mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Carlo Wood
Sent: Thursday, October 28, 2010 11:52 AM
To: Dave Booth
Cc: opensource-dev@lists.secondlife.com
Subject: Re: [opensource-dev] LGPL violation
On Thu, Oct 28, 2010 at 08:27:52AM -0500, Dave Booth wrote:
> On 10/28/2010 06:29, Carlo Wood wrote:
> libmedia_plugin_webkit.{sp,dll,dylib}
>
> Make sure you quote examples of static linking when you're talking about
> static linking :)
Make sure you read carefully what I say and understand it before
talking about wrong examples :)
libmedia_plugin_webkit.{sp,dll,dylib} are linked STATICALLY with
the Qt libs (as in, linked with .a).
Thus:
Qt*.a (LGPL) + LL*.o (LGPL+FLOSS) = libmedia_plugin_webkit.so
==> LL*.o must be made public (or their source code), or
libmedia_plugin_webkit.so cannot be shipped.
--
Carlo Wood
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting
privileges
_
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1153 / Virus Database: 424/3224 - Release Date: 10/28/10
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] LGPL violation
On Thu, Oct 28, 2010 at 08:27:52AM -0500, Dave Booth wrote:
> On 10/28/2010 06:29, Carlo Wood wrote:
> libmedia_plugin_webkit.{sp,dll,dylib}
>
> Make sure you quote examples of static linking when you're talking about
> static linking :)
Make sure you read carefully what I say and understand it before
talking about wrong examples :)
libmedia_plugin_webkit.{sp,dll,dylib} are linked STATICALLY with
the Qt libs (as in, linked with .a).
Thus:
Qt*.a (LGPL) + LL*.o (LGPL+FLOSS) = libmedia_plugin_webkit.so
==> LL*.o must be made public (or their source code), or
libmedia_plugin_webkit.so cannot be shipped.
--
Carlo Wood
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] LGPL violation
On 10/28/2010 06:29, Carlo Wood wrote:
libmedia_plugin_webkit.{sp,dll,dylib}
Make sure you quote examples of static linking when you're talking about
static linking :)
Dynamically loaded libraries (that is, after all, what "dll" is an
abbreviation for) are by definition not statically linked. if they were
statically linked you wouldnt need the .dll, the .so or the .dylib file
because the object code would have been incorporated into the binary at
link time. Statically linked progs dont require external library files,
dynamically linked ones do. Thats the reason that on Solaris systems
roots default shell is /sbin/sh rather than /bin/sh - its statically
linked so that even if the lib loader is hosed the sysadmin can still
get to a working shell to fix it. (historically, statically linked progs
went in /sbin not /bin - not always a convention honored these days
since so few progs are ever completely statically linked any more but in
this case it was)
Now get off my lawn ;)
Dave
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] LGPL violation
On Wed, Oct 27, 2010 at 10:17:01AM -0400, Oz Linden (Scott Lawrence) wrote:
> On 2010-10-23 7:27, Carlo Wood wrote:
> > I am not a lawyer :p, but I think that it is allowed to link an LGPL-ed
> > library statically against a proprietary executable provided you
> > provide the object code or source code of the work that uses the library.
>
> Not correct. LGPL code may be linked to other source without having the
> viral effect of requiring that other source also be published as open
> source. LGPL _does_ require that if any changes are made to the source
> under that license, then those changes (and the original sources) must
> be open and available either as LGPL or as GPL.
You state pretty firmly, while I believe you are in error.
You are NOT allowed to link statically with an LGPL-ed library unless you
provide the means for the user to relink the library, for example by
providing the .o (object) files that it is linked with.
>From many available links, let me quote an answer from
http://answers.google.com/answers/threadview/id/439136.html:
Q2a: What is the implication of static linking?
A2a: You need to comply with the license requirements. Eban Moglen in
http://www.spinics.net/lists/xf/msg02311.html
indicates that you are producing a "derivative work" of the code in
the library. In the United States the US Copyright Office states at
http://www.copyright.gov/circs/circ14.html
A "derivative work," that is, a work that is based on (or derived
from) one or more already existing works ... [copyright statements].
Both of those statements are pretty clear so section 6 of the LGPL
applies. Note that you can distribute (6a)
... [your work] as object code and/or source code, so that the user
can modify the Library and then relink to produce a modified
executable containing the modified Library
You can thus distribute object files (and protect your source code)
and still comply with the requirements of the LGPL.
However, others (in particular, Richard Stallman) does not necessarily
interpret the LGPL in this way. I strongly recommend you contact the
copyright holder prior to building a statically linked application for
distribution as a commercial product.
In this case, you'd have to contact Troll Tech and ask them if even
this is allowed, but at the very least you can NOT distribute
libmedia_plugin_webkit.{sp,dll,dylib}, which is statically linked
with Qt, without at least providing the object files that it exists
of (in addition to Qt), that you are the copyright holder of.
I think this is extremely logical: The user must at all times
be able to get the source code of the LGPL-ed library, change it,
and *RELINK* it with the application he or she is using.
The BSD guys have a different view though (just to make clear that
you completely orthogonal view really ought to be backed up by one
of your lawyers). Quoting
http://www.freebsd.org/doc/en/articles/bsdl-gpl/article.html#ORIGINS-LGPL
(where 'glibc' is used as an example of an LGPL-ed library):
If you statically link an application with glibc, such as is often
required in embedded systems, you cannot keep your application proprietary,
that is, the source must be released. Both the GPL and LGPL require
any modifications to the code directly under the license to be released.
--
Carlo Wood
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] LGPL violation
On Wed, 27 Oct 2010 23:38:55 +0200 Altair "Sythos" Memo wrote: > yu can put in a DLL all the code, LGPL allow you to do, bu you shoudl > release the LGPL part of code (not the piece yours or under other > license), you must release the LGPL code of DLL, not all please... turn on your typonese translator before read my last email XD ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] LGPL violation
On Wed, 27 Oct 2010 10:38:32 -0400 Malachi wrote: > does this mean that if i move all of my own code over to a dll file > that is loaded at runtime that i do not have to release the source > for it? uhm... both no and yes yu can put in a DLL all the code, LGPL allow you to do, bu you shoudl release the LGPL part of code (not the piece yours or under other license), you must release the LGPL code of DLL, not all ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] LGPL violation
does this mean that if i move all of my own code over to a dll file that is loaded at runtime that i do not have to release the source for it? On Wed, 27 Oct 2010 10:17:01 -0400, Oz Linden (Scott Lawrence) wrote: > On 2010-10-23 7:27, Carlo Wood wrote: >> I am not a lawyer :p, but I think that it is allowed to link an LGPL-ed >> library statically against a proprietary executable provided you >> provide the object code or source code of the work that uses the >> library. > > Not correct. LGPL code may be linked to other source without having the > viral effect of requiring that other source also be published as open > source. LGPL _does_ require that if any changes are made to the source > under that license, then those changes (and the original sources) must > be open and available either as LGPL or as GPL. > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] LGPL violation
On 2010-10-23 7:27, Carlo Wood wrote: > I am not a lawyer :p, but I think that it is allowed to link an LGPL-ed > library statically against a proprietary executable provided you > provide the object code or source code of the work that uses the library. Not correct. LGPL code may be linked to other source without having the viral effect of requiring that other source also be published as open source. LGPL _does_ require that if any changes are made to the source under that license, then those changes (and the original sources) must be open and available either as LGPL or as GPL. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] LGPL violation
I'm thinking that it may not require full source code if the ABI is published at least -- the only "static link" that seems involved here is whatever stub (.a?) is necessary to specify the ABI. That would permit someone to link to the library with alternate code (or replace the library with free source if necessary). It looks like they're going down a similar route with the mesh deconstruction code. On Sat, Oct 23, 2010 at 4:27 AM, Carlo Wood wrote: > I am not a lawyer :p, but I think that it is allowed to link an LGPL-ed > library statically against a proprietary executable provided you > provide the object code or source code of the work that uses the library. > > In other words, it must be possible to make changes to Qt and *relink*. > > Translating that idea to linking statically with a shared library, it > is clear that one still has to be able to make changes to Qt and relink, > or they are non-compliant. This means they must provide all the object > code that was used to create (link) libmedia_plugin_gstreamer.so, or > they must provide the source code so that people can generate this > object code themselves. > > Imho, the only practical solution is to make the source code availabe, > and most likely just all the source code of the whole viewer. > > On Fri, Oct 22, 2010 at 07:02:18PM -0700, Erik Anderson wrote: > > Not sure this is worth sending to the list, but could you clarify that > .so > > files are statically linked to the executable that they are loaded into? > This > > is a bit confusing to me. > > > > Or are they considered statically linked if you use the default dynamic > loading > > logic, rather than hand-coding GetProcAddr calls or equivalent? > > Nah - none of that. libmedia_plugin_gstreamer.so (the extension is > different > on OS other than linux I guess) is a shared library. However, it is > constructed > by linking statically with a modified version of Qt that was created by LL. > Obviously, the users need to know what those mods are and they should be > allowed to make changes of their own. > > For example, someone who already made changes to this version of Qt would > not be able to use the mesh viewer until LL releases the full source code, > so they are non-compliant if they release a 'beta' version of a viewer > without > providing the means to re-link libmedia_plugin_gstreamer.so with a > different Qt. > > -- > Carlo Wood > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] LGPL violation
I am not a lawyer :p, but I think that it is allowed to link an LGPL-ed library statically against a proprietary executable provided you provide the object code or source code of the work that uses the library. In other words, it must be possible to make changes to Qt and *relink*. Translating that idea to linking statically with a shared library, it is clear that one still has to be able to make changes to Qt and relink, or they are non-compliant. This means they must provide all the object code that was used to create (link) libmedia_plugin_gstreamer.so, or they must provide the source code so that people can generate this object code themselves. Imho, the only practical solution is to make the source code availabe, and most likely just all the source code of the whole viewer. On Fri, Oct 22, 2010 at 07:02:18PM -0700, Erik Anderson wrote: > Not sure this is worth sending to the list, but could you clarify that .so > files are statically linked to the executable that they are loaded into? This > is a bit confusing to me. > > Or are they considered statically linked if you use the default dynamic > loading > logic, rather than hand-coding GetProcAddr calls or equivalent? Nah - none of that. libmedia_plugin_gstreamer.so (the extension is different on OS other than linux I guess) is a shared library. However, it is constructed by linking statically with a modified version of Qt that was created by LL. Obviously, the users need to know what those mods are and they should be allowed to make changes of their own. For example, someone who already made changes to this version of Qt would not be able to use the mesh viewer until LL releases the full source code, so they are non-compliant if they release a 'beta' version of a viewer without providing the means to re-link libmedia_plugin_gstreamer.so with a different Qt. -- Carlo Wood ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
