[Mono-devel-list] ByteFX development

Chris Turchin chris at turchin.net
Wed Sep 22 03:37:33 EDT 2004


I have been lurking in the background and was wondering what the
situation is when I have provider factory like:


which, let's say, uses System.Data as a default provider but could also
use a GPL'ed DataProvider if the user were so inclined and modified the
app.config accordingly. 

Am I then as a developer of this application in the position that I need
to conform to all licenses which might apply to the possible data
providers, just because I am using a DB provider factory that could in
theory support them? This seems ridiculous to me, as I am just providing
someone with the opportunity to use another DB provider if they want, I
am not distributing it with my application. If this is the case,
however, then suddenly flexible nature of the IDb* interfaces falls into
a whole other light for me...

I am interested in hearing what all the 'non-lawyers' out there there


On Tue, 2004-09-21 at 22:00 -0400, Joshua Tauberer wrote:
> Jonathan Pryor wrote:
> > Yes, and no.  The metadata is sufficiently small (assembly name,
> > version, public key, referenced classes, etc.) that it could probably be
> > declared "fair use".
> ...
> > So, to simplify (is that safe?), your program must be GPL'd if it
> > directly or indirectly relies upon GPL'd facilities, *unless* it's "just
> > data" for those facilities.
> This can't be the end of the story, though.  If you start the sentence 
> "Your program must be GPLed if...", the end of the sentence has to have 
> something to do with making copies of someone else's copyrighted work.
> 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?
> 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.)
> 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.
> 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 next question is: Can you rely on software without making a 
> derivative/copy of some aspect of it?  So, you might be right that if 
> you rely on GPL software you are bound by the GPL, but only if relying 
> on the software necessarily involves integrating GPLed stuff, or a 
> derivative of it, into your own stuff.
> 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.
> I liked that disclaimer, Jon.  I'm going to reference it here in an 
> attempt at irony.
Chris Turchin <chris at turchin.net>

More information about the Mono-devel-list mailing list