|
|
|
| Authored by: Anonymous on Wednesday, May 02 2012 @ 11:14 AM EDT |
AFAIK, the derivative work is not being created by linking
against
an API, it is being created by linking against an
implementation of that API.
The GPL clauses only come into
play when the only implementation of the API is
under GPL or
when that is the implementation required for some
other
reason.
So the existence of a non-GPL alternate
implementation changes the picture? Does the alternate need to be functional vs
simple stubs? What if dynamically linking against the alternate results in
execution without runtime errors, but that doesn't actually accomplish
anything?
Somehow there are people (like the poster before me)
who
don't see this as reasonable exit clause, but to me it seems
like a rather
simple way to make sure the development stays
public: if you don't or can't
accept the licensing rules set
by the copyright owner of the library, you are
free to
contact them for a separate arrangement or to roll your
own
implementation and use that instead.
The difference between
RMS's motivations and Ellison's matter little under the law. The main question
of law is the extent to which copyright law gives the copyright owner the right
to make/enforce rules. Clearly there has to be a limit, the question is where
it is.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Wednesday, May 02 2012 @ 11:16 AM EDT |
in dynamic linking the library is a shared object
it is not included in your program
It may be loaded into memory by something else
In a dynamically linked application there is only use of an API.
In a statically linked application, the library is included in the final binary
compilation
In the latter, your work and the GPL work become part of the same thing, you
have to distribute the library with your work, they are inseparable, that is
understandable.
With dynamic linking it is possible to ship an application without including the
library, so long as the recipient has a copy of the library, it will work.
As someone pointed out the FSF views dynamic linking as making a derivative
work.
This makes about as much sense as Oracle do at the moment.
This is also the excuse that Microsoft needed to accuse the GPL of being 'viral'[ Reply to This | Parent | # ]
|
| |
| Authored by: kuroshima on Thursday, May 03 2012 @ 03:59 AM EDT |
Here's something I never really understood about dynamic linking and the GPL
(Static linking is clear). Assume that I create a program that links against a
standard API via dynamic linking. That API is implemented by multiple vendors,
under a pletora of software licenses, including severeal comercial, closed
source ones, a BSD one, an MPL v1 one, an LGPL one, and a GPL one. They all
function as drop in replacements for one another, and I, as the creator of the
program, have no control over what the program will link to. I'm not forced to
release it for all possible compatible licenses right? specially given that
there are multiply incompatible ones involved. In fact, it can be even more
confusing if there is a single library, that is distributed under multiple
licenses, such as, for example, the license set for LibreOffice. You can not
discern what license the user accepted when it installed the library.
Second issue, assume that you release the code for a program under an
Apache/BSD/other GPL compatible permisive license, but build the program for
personal use by linking to a GPL library, because it performs better than the
drop-in replacement under a permisive license. The binary as a whole is thus
under the GPL. The trick here is that if I don't distribute the binary, but I
only distribute the code, I'm not bound by the GPL right? even if I include
instructions and/or build scripts for both the permisive license library and the
GPL library?[ Reply to This | Parent | # ]
|
|
|
|
|
