GPL and Plug-INs and XML\Ada

GPL and Plug-INs and XML\Ada

[David Botton]

If a person wrote an executable that had a plug-in architecture, would it be
possible then to include GPL'd plug-ins with out the application becoming
GPL'd?

For example, If I wrote an application that had a closed lic. and it allowed
features to be plugged-in. One such group of features was for file "import".
So, I throw together a GPL'd plug-in that included XML\Ada and dropped that
dll in the dir and it is picked up at run time by the closed lic.
application.

This would be different than:

I write an XML COM object that uses XML\Ada and now my XML COM object is of
course GPL'd, but closed lic. programs (say in VB or Ada) could now use my
XML COM object to access XML.

I could see where this case would be problematic (although I question that
also), but the previous cases seems to be no problem. Would including a
GPL'd COM / Corba object virus to my app and make it GPL'd?

Thoughts?

David Botton

Re: GPL and Plug-INs and XML\Ada

[tmoran]

>be possible then to include GPL'd plug-ins with out the application
>becoming GPL'd?
  Seems to me the app is effectively an OS running a program (the
plug-in) which happens to be GPL'd.  Clearly creating a plug-in with
one license cannot change the terms of the original app's license,
and I presume the GPL is not intended to prevent the creation/distribution
of GPL'd plug-ins.

Re: GPL and Plug-INs and XML\Ada

[Frank Ranner]

David Botton wrote:
> 
> If a person wrote an executable that had a plug-in architecture, would it be
> possible then to include GPL'd plug-ins with out the application becoming
> GPL'd?
>
The best bet would be to make the plug-ins LGPL, which explicitly allows
dynamic
linking from a non-Free application.

Otherwise, if you are the author of both the non-Free app and the GPL
plug-in you
can do whatever you want. Now, if XML/Ada is GPLd and not written by
you, you cannot
link it the way you suggest, ie as a dll/so. You can link it the way
Gimp does it's
plugins, ie as a sub-executable that is forked and piped to. This is
obviously allowed,
otherwise you couldn't even pipe the output from a proprietary program
into any gnu
utility.
 
> For example, If I wrote an application that had a closed lic. and it allowed
> features to be plugged-in. One such group of features was for file "import".
> So, I throw together a GPL'd plug-in that included XML\Ada and dropped that
> dll in the dir and it is picked up at run time by the closed lic.
> application.
> 
> This would be different than:
> 
> I write an XML COM object that uses XML\Ada and now my XML COM object is of
> course GPL'd, but closed lic. programs (say in VB or Ada) could now use my
> XML COM object to access XML.
> 
> I could see where this case would be problematic (although I question that
> also), but the previous cases seems to be no problem. Would including a
> GPL'd COM / Corba object virus to my app and make it GPL'd?
> 
The whole situation of linking has become much more complicated since
the early
days where you had pipe, static link, or dynamic link. Now there is RPC,
DCE, Corba, 
Java Beans, SOAP, Sockets and who knows what other means of
communication between modules.
For those modules to start comparing licences would appear absurd.

Nevertheless, Richard Stallman is at work on GPL version 3 which will
attempt to address
the issue of Free/non-Free links.

Disclaimer, I am not a lawyer; my opinion is based only on reading many
discussions on
the same subject by many other non-lawyers.

Regards,
Frank Ranner

Re: GPL and Plug-INs and XML\Ada

[Tarjei T. Jensen]

David Botton
>For example, If I wrote an application that had a closed lic. and it
allowed
>features to be plugged-in. One such group of features was for file
"import".
>So, I throw together a GPL'd plug-in that included XML\Ada and dropped that
>dll in the dir and it is picked up at run time by the closed lic.
>application.

As long as  you do not link with the GPL library you should be safe.  To be
on the safe side you could add a non-XML dll in order to demonstrate that it
is not a way to rip off the library.


Greetings,

Re: GPL and Plug-INs and XML\Ada

[Ted Dennison]

In article <mailman.988742163.24922.comp.lang.ada@ada.eu.org>, David Botton
says...
>
>If a person wrote an executable that had a plug-in architecture, would it be
>possible then to include GPL'd plug-ins with out the application becoming
>GPL'd?

It might help to better define what you mean by "plug-in". Precisely how are the
GPL'd code and the non-GPL'ed code tied together? How is code in the GPL'ed code
invoked from the non-GPL'ed code?

Probably this isn't the best place to ask though. For a really thorny issue, I'd
try to ask in a GNU group, or ask RMS directly.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: GPL and Plug-INs and XML\Ada

[Stephen Leake]

"David Botton" <David@Botton.com> writes:

> If a person wrote an executable that had a plug-in architecture, would it be
> possible then to include GPL'd plug-ins with out the application becoming
> GPL'd?
> 
> For example, If I wrote an application that had a closed lic. and it allowed
> features to be plugged-in. One such group of features was for file "import".
> So, I throw together a GPL'd plug-in that included XML\Ada and dropped that
> dll in the dir and it is picked up at run time by the closed lic.
> application.

The key is the linking mechanism. I asked essentially the same
question on a Windows CVS mailing list; apparently the Free Software
Foundation position is that a "dll" (which stands for Dynamic Link
Library) is _linked_, which is the term used in the GPL. So GPL dlls
do "infect" the full app.

> This would be different than:
> 
> I write an XML COM object that uses XML\Ada and now my XML COM object is of
> course GPL'd, but closed lic. programs (say in VB or Ada) could now use my
> XML COM object to access XML.

Here, since the connection between the application program and the COM
object is by message passing over a network (hmm, I'm just assuming
that), there is no "linking" in the GPL sense. So I would say no, the
application is not infected by the COM object's GPL.

> I could see where this case would be problematic (although I
> question that also), but the previous cases seems to be no problem.
> Would including a GPL'd COM / Corba object virus to my app and make
> it GPL'd?
> 
> Thoughts?

Obviously we came to different conclusions from the same data.
Clearly, if you are seriously considering marketing either of these
mechanisms, get the advice of a competent lawyer!

-- 
-- Stephe

Re: GPL and Plug-INs and XML\Ada

[Marin David Condic]

This would seem to be impossible to enforce. If its impossible to enforce,
its a good bet that it won't stand up in front of a judge.

If you had some sort of dynamic binding to something else that is not part
of your .EXE - no matter what the specific mechanism is - it would seem that
the license on the thing you bind to can't really impose something on your
code. (If it could, don't you think Bill Gates would have claimed ownership
of everything ever run on a Micro$oft OS?) If you make reference to someone
else's book while writing your own book, does this violate the other guy's
copyright?

That is to say, if you don't have a translation of the library included in
your .EXE and if you don't distribute (copy) the other guy's DLL onto your
disk, you have not violated his copyright. So claims based on copyright
don't seem to hold up - you don't really copy anything, right? (There may be
other problems - is the API to his DLL some sort of trade secret? etc? Or
could someone else "reverse engineer" it without violating any
restrictions?) If the copyright owner extends the right to you to copy and
distribute his DLL separately, then putting it on a separate disk - or on
the same disk - seems to be nothing but a splitting of hairs that makes no
difference. They remain separate products that function independently & can
be distributed separately.

Obviously, this gets significantly more complicated if you're talking about
something that *isn't* dynamically linked, such as compiler libraries &
runtime kernels - but that wasn't the original question. If I were the
judge, I'd look at such a situation on the basis that the compiler is pretty
well useless to a developer unless the developer can retain full ownership
of the product of his labor. Compiler writers used to put all kinds of
restrictions on their runtime code, but you don't see that anymore. Either
a) it wouldn't hold up in court (the "That dog don't hunt!" principle of
arbitrary judgement) or b) the American Free Enterprise System saw to it
that such compiler vendors got spanked for doing it.

It seems logical that calling a DLL couldn't impose an open source rule on
my code. Otherwise, any software that ran on Linux would have to be open
sourced because at the end of the day, Linux is really equivalent to a big,
giant DLL. If making Posix calls on a Linux development platform could force
open source on me, I bet there'd be a lot of developers in trouble right
now. :-)

Has there ever been a court challenge based on GPL'ed DLL's?

MDC

--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:uy9sfvdaf.fsf@gsfc.nasa.gov...
> The key is the linking mechanism. I asked essentially the same
> question on a Windows CVS mailing list; apparently the Free Software
> Foundation position is that a "dll" (which stands for Dynamic Link
> Library) is _linked_, which is the term used in the GPL. So GPL dlls
> do "infect" the full app.

Re: GPL and Plug-INs and XML\Ada

[tmoran]

>question on a Windows CVS mailing list; apparently the Free Software
>Foundation position is that a "dll" (which stands for Dynamic Link
>Library) is _linked_, which is the term used in the GPL. So GPL dlls

  A linker is a utility that merges multiple object files together
into a single executable file.  That exe file could be distributed.
A loader takes a file containing a chunk of code and brings it into
memory, possibly relocating addresses and such, so the code can be
executed.  (A "linking loader" does both.) So a DLL, regardless of
the name Microsoft gave it, is a module which can be loaded and
executed.  It is not "linked" to become part of distributable object,
but is loaded to be executed.  A DLL is basically the same as a
subroutine on a library tape, to be loaded dynamically by a program
that needs to use it.  So, unless the word "linked" is specifically
defined within the GPL to have a non-standard meaning, it must be
understood in the way it's normally been used in software for the
last 40 years.  A DLL is loaded, not linked.

Re: GPL and Plug-INs and XML\Ada

[Marin David Condic]

Fair enough, but I have a question: At some point in the process of linking
my app such that it will work with your DLL, somewhere there has to be
something that scans over the interface to your DLL & makes sure my app is
compliant with that interface. Correct? There *may* be some kind of
copyright issues involved here - but certainly some rather convoluted ones.
Id est, I have to read over your specification and "copy" from that
procedure names, parameters, etc. IMHO, that would be a *real* stretch of
the concepts of copyright, but then, I'm not a lawyer.

I still don't think it would hold up in court and I'm wondering if anyone
has actually ever brought a case. Until there is some case law on the
subject, its hard to say exactly what is correct. Until you have at least
one judge making a ruling on it, it could go in any direction.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/



<tmoran@acm.org> wrote in message
news:t33I6.36036$Jh5.32810476@news1.rdc1.sfba.home.com...
>   A linker is a utility that merges multiple object files together
> into a single executable file.  That exe file could be distributed.
> A loader takes a file containing a chunk of code and brings it into
> memory, possibly relocating addresses and such, so the code can be
> executed.  (A "linking loader" does both.) So a DLL, regardless of
> the name Microsoft gave it, is a module which can be loaded and
> executed.  It is not "linked" to become part of distributable object,
> but is loaded to be executed.  A DLL is basically the same as a
> subroutine on a library tape, to be loaded dynamically by a program
> that needs to use it.  So, unless the word "linked" is specifically
> defined within the GPL to have a non-standard meaning, it must be
> understood in the way it's normally been used in software for the
> last 40 years.  A DLL is loaded, not linked.