[Mono-devel-list] ByteFX development

Michael L Torrie torriem at chem.byu.edu
Wed Sep 22 10:07:32 EDT 2004

On Wed, 2004-09-22 at 07:24 -0400, Jonathan Pryor wrote:
> Which is why the GPL needs some *serious* clarification in the context
> of dynamic linking.

Well, copyright law needs clarification in the context of dynamic
linking.  This issue affects more than just the GPL.

Even the idea of loading the dynamic code into your program's address
space being the definition of a "derivative" work breaks down as we head
into the future of distributed, NUMA computing.  At that point, linking
to a DLL is reduced merely to a messaging protocol, which then asks the
loaded question, does speaking a protocol bind you to a license?

Despite this, the spirit of the GPL is clear.  Unfortunately,
uscrupulous people abound, so we'll need a clear legal precidence sooner
or later.  Maybe IBM vs SCO will get us that.

> > What I'm getting at is this: There has to be a reason, based in law, for 
> > why the GPL license would be binding on me as a developer.  Normally, 
> > people can't tell me how I have to license my work.  Why can the GPL 
> > force me to do something?
> "Normally," the GPL can force you to do something because you're
> creating a derivative work (based on copyright law), and/or because
> you're copying/distributing the GPL'd code.  The GPL states that it only
> covers copying, distribution, and modification.
> Consequently, the GPL can force you to do something if: (1) you modify
> the GPL'd work (in which you're *definitely* creating a derivative work
> as far as copyright is concerned), and (2) you copy/distribute the GPL'd
> work along with your own.  Static linking is the conventional example. 
> This has some interesting consequences if you *don't* copy/distribute
> the GPL'd work, which I touch upon below.

The GPL can never *force* you do do anything.  It doesn't magically
convert your closed code to GPL either.  In other words, just because
you link against a GPL'd library doesn't mean that random people can
legally claim your code.  They can sue you for copyright infringement,
though. And as a developer you can't be held responsible for how your
users will use or abuse your binary code after the fact.  (IE the kernel
and the binary-only tainted modules.)

If you are creating a derivative work using a GPL'd component and you
have not released your code as GPL, then you are committing copyright
infringement and you have 3 options:
1. GPL your code
2. Remove your dependency on (and derivation of) GPL code
3. Negotiotiate a license to use code under non-GPL terms.


> > It's *not* because I agreed to the GPL when I downloaded GPL software, 
> > or when I used a GPL program.  The GPL isn't an EULA or click-through 
> > "license" -- the GPL is not a contract.  (I read a good explanation 
> > about this somewhere, but it was long ago so I don't have a reference 
> > off hand.)
> You probably read it at groklaw.net. :-)
> > There are circumstances, however, when I'm legally not allowed to make 
> > copies of my own work (oversimplification alert).  If my code is a 
> > derivative of or contains someone else's code, copyright law says I 
> > cannot distribute my code without the permission of the owner of the 
> > other code.
> Correct.
> > Now the GPL comes into the picture.  When code is released under the 
> > GPL, it's a blanket statement giving anyone permission to distribute 
> > derivatives or combinations of the GPLed code.  Except, it only gives 
> > permission to you if you agree to a few things, one of which is that you 
> > have to GPL your code too.
> > 
> > So the moral of the story is that you're only bound by the GPL if you 
> > are attempting to make copies of something that 1) you don't hold the 
> > copyright on, 2) you don't have specific permission from the copyright 
> > holder to make copies of, and 3) the code has been released under the GPL.
> > 
> > "Relying on" and "making copies of" are two different things, and only 
> > the latter is illegal without a license.  When copyright law is not 
> > involved, neither is the GPL.
> The implication of this is as follows: You can create a proprietary
> program, link against a GPL'd library (readline, for example), and be in
> the clear *if* you never actually copy/distribute the library.  You
> could instead require that the user download/install readline
> separately.
> This is the joy of dynamic linking, and by that thought process would
> completely destroy the intent of the GPL -- a proprietary app could link
> against a GPL'd library without any problems (aside from slightly more
> complicated installation instructions for the user).
> The logic to this is as follows: the GPL clause 0 defines a "work based
> on the program" as "either the Program or any derivative work under
> copyright law...a work containing the program or a portion of it, either
> verbatim or with modifications..."  With dynamic linking, and especially
> with packaging solutions like RPM and PKG, the proprietary app would
> never contain a GPL'd work or a portion of it (aside, perhaps, from
> function names used by the dynamic linker, and function names should be
> "fair use" since I could re-implement readline, using the same function
> names for compatibility).
> Obviously this interpretation would be frowned upon by rms and company. 
> Alas, this thought process isn't covered on the GPL faq, so I have no
> idea what reason rms would have for preventing dynamic linking, but I'm
> sure there is one.  I hope.
> Things get more confusing with GPL section 3.  Readline is included with
> most Linux distributions, so is it part of the OS?  If it is, then
> proprietary apps can link against it at will and not follow the GPL.
> Yuck.
> <snip/>
> > So who decides whether referencing a GPLed assembly ends up with a 
> > derivative work?  Not the GPL, and not the owner of the GPL code.  Only 
> > courts can decide, because only courts can decide whether something is 
> > copyright infringement.  Since a court hasn't taken up this topic yet 
> > (unless there's somehow applicable precedent), it's entirely undefined.
> Let's hear it for the courts, and a system of laws so complex we need a
> lawyer around to even *contemplate* doing anything complicated!
> Hip hip, hooray!
> Of course, simple laws would be more easily broken, so I'm not sure what
> the solution to this problem is either, but it's easier to complain than
> to fix the system... :-(
>  - Jon
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list

More information about the Mono-devel-list mailing list