On Jul 7, 2010, at 10:36 AM, Paul Emsley wrote:
>> The LGPL does not "know" of any difference between static linking and
>> dynamic linking. In either method, the code "mixes" on the binary level.
>
> Agreed.
That is incorrect. As Konstantin pointed out, LGPL requires that if
the binary is distributed as a single executable (that is, using a
static library) then the non-LGPL components must at least be available
in object form so that people can relink it to modified versions of
the library.
In LGPLv2.1 in the preamble it states:
If you link other code with the library, you must provide complete
object files to the recipients, so that they can relink them with
the library after making changes to the library and recompiling it.
and the relevant section is 6a (since 6b is for shared libraries)
Accompany the work with the complete corresponding machine-readable
source code for the Library including whatever changes were used in
the work (which must be distributed under Sections 1 and 2 above);
and, if the work is an executable linked with the Library, with the
complete machine-readable "work that uses the Library", as object
code and/or source code,
And in LGPLv3, section 4d which states that you must:
d) Do one of the following:
0) Convey the Minimal Corresponding Source under the terms of this
License, and the Corresponding Application Code in a form suitable for,
and under terms that permit, the user to recombine or relink the
Application with a modified version of the Linked Version to produce
a modified Combined Work, in the manner specified by section 6 of the
GNU GPL for conveying Corresponding Source.
1) Use a suitable shared library mechanism for linking with the
Library. A suitable mechanism is one that (a) uses at run time a copy
of the Library already present on the user's computer system, and (b)
will operate properly with a modified version of the Library that
is interface-compatible with the Linked Version.
PMR:
> COMP's argument is that although the LGPL does
> allow for inclusion into commercial closed source projects you either have to
> distribute the LGPL'd portion as a dynamically linked library
> which the end user could replace if desired or a API-based rebuild system.
I think it's quite clear from the license that the proprietary company
is correct. (I'm not sure what "API-based rebuild system" means, but it
sounds close enough.)
I can only conjecture as to the business impact this might have on
said company. First, I know that some companies ship their software
statically linked because then they don't have to worry about shared
library paths and other things which lead to "DLL hell."
For example, Warren Delano experimented with shipping all of PyMol
as a single executable, in order to simplify installation. Dave
Weininger at Daylight was doing some web application development
where the server and all the web site documents were packed into
a single executable. All someone had to do was start the program.
It needed no configuration. (I think the HTML pages were compiled
in as static sections, not through extensions in the ELF format.)
Were that the case then it increases the difficulty in shipping
binaries for each platform; there's twice as many packages (the
binary version and the linkable version), and there's the additional
build system for the linkable version. After all, most companies
have build systems which only work in their environment, and making
which was is useable in general is more work.
Second, if the code they ship is an actual executable then it's
harder to make internal API calls, in case some of those are
proprietary. Consider the old Qt license where if you used the
API then it's one fee but if you expose the API to others then
it's another fee. If you have to ship linkable .o files then
it's hard to hide access to other parts of the code.
(Or in chemistry, I know that if you use the OpenEye toolkits
and sell a program which uses some of the API functionality
and want to sell to people who are not OpenEye customers then
you can do that, and for a lower fee than distributing the full
toolkit to them. But in that case, they want to make sure your
customers can't get access to the full toolkit. Static linking
is one solution here.)
Third, if the software uses a license manager then there's going
to be some module like "license_manager.o" which does the check.
If you can see the .o file and replace it then it might be easy
to bypass the license checks. It is possible to hide the checks,
but again that's more work on the proprietary vendor side.
PMR:
> I am not so sure I should change my licence because it is a
> better business model for a downstream commercial exploiter.
The right term here is "proprietary" not "commercial." The FSF
points out that you can (and should!) sell free software.
The GNU answer is along the lines of:
http://www.gnu.org/licenses/gpl-faq.html#SwitchToLGPL
"It is supposed to put pressure on you to release your
program in a way that makes it part of our community."
Also, if this is the only sticky point then you can switch
to LGPLv3. That's uses an interesting design, where LGPLv3
*is* GPLv3 plus an additional set of permissions. You can
add your own permissions on top of that, and say that it's
distributed under LGPLv3 plus the additional permission that
section d) 0) is not required.
Best regards,
Andrew
[email protected]
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Blueobelisk-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
