[Mono-dev] Off topic: Reflection and Licensing question

Thu Apr 30 10:22:18 EDT 2009

Just trying to make it a bit more clear (Michael and Miguel, from the
outside seems like you both weren't discussing exactly the same subject):

Michael, you can make your reflection-based plugin that accepts any library,
GPL or not, as long as you publish the needed interfaces as non-GPL, or
reuse some standard one (ADO.NET).
You can't just wrap the GPL library to conform to your particular interface,
the library should natively implement your non-GPL interface or the standard
one, or if you do really build a wrapper it has to be made separately
available as a GPL open-source project, even if it is reflection-based, as
it IS LINKING to the GPLed API or it wouldn't be needed.
What you can't do is distribute the GPL library with your non-GPL app.
You should instruct your end-user how to download and install and configure
the GPL library (and your GPL wrapper if you needed to develop one), if he
would like to use it with your app.
The end-user is king in such matters.

Personally, I find MySQL not worth all that effort for turn-key
(all-in-a-box) solutions,  for those situations I use PostgresSQL or SQLite
according to the need to scale.

Regards,

On Thu, Apr 30, 2009 at 1:03 AM, Michael B. Trausch <mbt at zest.trausch.us>wrote:

> On Wed, 29 Apr 2009 19:12:41 -0400
> Miguel de Icaza <miguel at novell.com> wrote:
>
> > Loading GPL code into a proprietary application is not allowed by the
> > GPL.    You can do that in the privacy of your home, but you can not
> > redistribute this configuration without infringing the license.
>
> I am not sure what you mean by that.  Linking GPL code into a
> proprietary application is certainly not permitted.  If I author a
> proprietary application and I link against a library that is GPL, then
> I must either retain the application in-house and never distribute it,
> or I must distribute it under the GPL when I _do_ distribute it.  Since
> the GPL's effects only kick in upon distribution, and not usage, this
> makes sense.
>
> Here's a couple of examples to illustrate.
>
> Example 1:
>  Let's say that I have a proprietary application, and we'll call it
>  TheApplication.  (No, I am not creative; oh, well.)  TheApplication
>  depends on MySQL, but the driver libraries for MySQL are GPL'd.
>  Having written the application, I don't feel like keeping it in
>  development for several more days/weeks/months/whatever just to write
>  an adapter to the database to replace the GPL'd library.  So,
>  instead, I write a "shim" and GPL this shim.  The shim exposes the
>  MySQL client library's API via a named pipe and I just connect to the
>  named pipe and call the client library's functions by asking the shim
>  to do so for me.
>
> Example 2:
>  Let's say that I have the same proprietary application,
>  TheApplication.  However, I say, "I will not write the database
>  functionality.  I will leave this up to you to provide.  Here is the
>  interface that I expect to be able to use, you give me the file, I
>  will load it, and I will use its interfaces."  So, John Doe decides
>  that he needs to use this application with MySQL, and creates a GPL'd
>  module for this application program which enables the proprietary
>  software to work with MySQL.  He then distributes his work under the
>  GPL, because he likes freedom.  He doesn't have the time to write
>  a clone of TheApplication, so this is the best he can do.
>
> In example 1, I as the application developer have intentionally and
> deviously attempted to get out of my responsibility to release my code
> under the GPL by creating a wrapper, to separate the MySQL client
> library from my program by intentionally placing the library in a
> different address space.  This is wrong.  It goes exactly against what
> the GPL tries to do with regards to liberating software.  Basically, I
> have said, "Nah-nah-nah-boo-boo, stick your head in doo-doo," and taken
> free software and used it improperly.  This isn't cool.
>
> In example 2, however, I decide instead that it's not a good idea for
> me to try to support eleventy-one databases directly; I cannot
> anticipate my end-user's needs.  So instead, I say, "Here is the
> application software.  If your needs are simple, you can use SQLite,
> which I have written a module for, and is in the public domain.  If you
> need to support another database in your environment, that's up to
> you.  Here are the interfaces that I will use in a module."  John Doe
> does just that.  It doesn't _matter_ what license someone writes a
> module for, that module isn't a derived work, and it's not linked into
> my program.  It's distributed by someone else as a completely separate
> work.  John Doe did just that, and he should be commended for choosing
> the GPL for the module that he wrote.  This is just fine.  It's less
> than ideal (at least in my opinion, as I believe that all software
> should be free software in the manner in which the FSF has defined it),
> but TheApplication doesn't try to do anything nasty or uncool, and John
> Doe has provided a very useful and free software module that people are
> free to improve upon and redistribute (separately, of course, from the
> application, for obvious reasons).
>
> The line between the two examples is indeed a fine one.  However,
> interface usage does not constitute linking.  Dependencies do.
>
> As has already been mentioned elsewhere in this thread, if mechanisms
> like LoadLibrary() or dlopen() or Java or CLR Reflection were
> considered linking, the ramifications would be very troublesome and
> dangerous for those who did write proprietary software.  So much so
> that they would choose either to not write it at all, or make it free
> software in the first place.
>
> Let's not forget that the GPL does not apply to usage.  It _only_
> applies to distribution.  If I write a free software module for a
> proprietary program and distribute it, I have in no way violated GPL.
> What the GPL covers is not determined by whether or not code lives in a
> single address space.  It is determined at build time for the program
> in question.  If you statically link against a GPL'd component, then
> you must also be GPL by definition.  If you dynamically link against a
> GPL'd component, there is no difference from static linking other than
> a technical one.  Dynamic linking was designed to reduce memory and
> storage requirements since many programs use the same libraries.
> However, dlopen() and LoadLibrary()'s usage isn't linking.  It's
> declaring a dependency on an interface, not a library.  Reflection is
> functionally equivalent to using dlopen() and/or LoadLibrary(), but
> significantly more powerful due to the technical nature of the CLR.
> And even so, if there were an agreed-upon convention that made it
> possible to preserve metadata in native executables, then we'd have
> reflection at a native level, which still wouldn't be linking.
>
>        --- Mike
>
> --
> Unix is user friendly - it's just picky about it's friends.
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>

-- 
Rafael "Monoman" Teixeira
---------------------------------------
"To be creative means to be in love with life. You can be creative only if
you love life enough that you want to enhance its beauty, you want to bring
a little more music to it, a little more poetry to it, a little more dance
to it."
Osho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090430/d91484c7/attachment-0001.html 