Forgot your password?
typodupeerror
GNU is Not Unix Linux Business

GPLv2 Libraries — Is There a Point? 585

Posted by kdawson
from the spirit-of-the-license dept.
PiSkyHi writes "I understand that if I build an application that links with a library that is licensed under GPLv2, I must also make my application GPL2. I can see that value in this for an application. But for a library, what's to stop me separating my program into a GPLv2-compliant client app that talks to the rest of my (choose my own license) application?"
This discussion has been archived. No new comments can be posted.

GPLv2 Libraries — Is There a Point?

Comments Filter:
  • Step 1: see GPL (Score:5, Insightful)

    by seanadams.com (463190) * on Tuesday August 11, 2009 @12:28AM (#29019535) Homepage
    The GPL is not explicit on this, it's just that linking is the established rule of thumb. Last I checked, the specifics of multiple processes vs linking are only mentioned in the FSF's FAQ [gnu.org], so it's only a guideline for interpretation.

    I think a reasonable test would be to ask: is my program still mostly useful even if the GPLd helper/plugin is removed (modulo the specific removed function)?. If so, then I think it could be argued that your program is NOT a derivative work and that the GPL helper is governed the same as, say, a GPLd user application bundled with a commercial Unix/OSX distro. Personally I don't think it should matter how exactly it communicates with your code - what makes launching a process any different from a function call here?

    Conversely: artificially doing contortions with your software to move essential libraries out to a separate app is not only in bad faith, but it doesn't work around the license at all. And if you ever had to argue otherwise, anyone turning up your slashdot story would not probably work in your favor.

    IMHO the GPL, even v3, needs some work to clarify this question and also to close the hole for the software-as-a-service industry to modify GPL code without reciprocating.

    • Re: (Score:3, Interesting)

      by PhrostyMcByte (589271)

      IMHO the GPL, even v3, needs some work to clarify this question and also to close the hole for the software-as-a-service industry to modify GPL code without reciprocating.

      I would like to see the GPL get clarified, too. Some companies play pretty loose with the GPL's definition -- like MySQL saying their protocol documentation is under GPL, and interpreting that to mean any code you write using that documentation must be under the GPL too.

      FSF has done part of what you mention, though -- see the AGPL. It ex

    • by mini me (132455)

      I don't think it should matter how exactly it communicates with your code

      What if I write an application that makes calls to standard Unix commands and the user is using the GNU operating system? Should that make my application subject to the GPL?

      What if I make my application available to a variety of different Unix flavours? Will it automatically inherit the code sharing license restrictions of the Unix utilities on every platform it runs on?

      • by SL Baur (19540)

        What if I write an application that makes calls to standard Unix commands and the user is using the GNU operating system? Should that make my application subject to the GPL?

        There is no "GNU operating system" but I'll assume you mean a system with GNU fileutils, etc. installed on it. No. Standard Unix commands have had a stable interface since before many of you were born.

        This may become important in the future. It depends on the API. As far as I know, no one is patenting APIs.

        Can you copyright an API such that a black box implementation can not be made without violating the copyright? I don't know.

        • Re: (Score:3, Insightful)

          by Abcd1234 (188840)

          No. Standard Unix commands have had a stable interface since before many of you were born.

          Uh, so what? libc has been standardized for at least as long, and yet if glibc, the GNU implementation of the libc specification, were under the straight GPL, then anything linked against it would fall under the GPL.

          In short: API has absolutely nothing to do with it. The question is, what is the definition of "combined work", and that goes right to the heart of the GPL (and has been a point of controversy every sinc

      • Re: (Score:3, Informative)

        by Tony Hoyle (11698)

        FSF say that linking - even dynamic linking - creates a combined work (in memory) that is subject to the GPL.

        Of course that theory has holes (eg. I'm not distributing that combined work.. it stays in memory, so the license it's under is irrelevant), but it's stuck for now.

        A separate app is in no way a combined work as it doesn't share any memory space.. and it'd be hard to make a license that applied a restriction like that.

    • Not only is the GPL not specific on this issue, but it is unclear whether a clear license restriction on linking would even apply. Imagine if RMS and Linus had their way, and the author of an application could not only restrict distribution, but linking as well. Microsoft could legally prevent people from writing apps and drivers for their OS. Homebrew for restricted systems would actually be illegal. Would it be legal to write compatible libraries?

      The great thing about shared libraries is, you don't have t

    • Re: (Score:3, Informative)

      by mattbee (17533)

      Not sure about now, but a few years back, MySQL made this pretty explicit - they considered any kind of bundling of MySQL to be "linking". i.e. if your application could only work with MySQL, and you shipped it with your app, that was linking, even though they might have only communicated through a socket. The whole concept of program linking has come on quite a bit since 1990, so I agree with the parent, if there aren't alternative components that can be swapped out with a GPL'd one, that's linking.

    • Do NOT see the GPL (Score:3, Informative)

      by Cajun Hell (725246)

      IMHO the GPL, even v3, needs some work to clarify this question and also to close the hole for the software-as-a-service industry to modify GPL code without reciprocating.

      I've seen this kind of thing before, and it surprises me that so many people have such a deep misunderstanding of copyright law.

      The GPL ***CAN'T*** define what a derived work is; it lacks the power to do that. Congress (not FSF and not Microsoft), through copyright law, does that.

      Reading pages at FSF may clarify the issue, simply bec

    • Re: (Score:3, Insightful)

      by sjames (1099)

      In general, the test would be "can I simply delete the GPL portions from the project and still have everything work (possibly by substituting in already existing commercial alternatives). If the answer is no, then you are at the very least violating the spirit of the license and are on shaky legal ground.

      Another way to look at it would be if the proprietary portion of the project is deleted entirely, is the GPL portion useful standing alone (that is, is the proprietary portion merely a value add?). If so, r

  • Umm... (Score:5, Informative)

    by Phroggy (441) <slashdot3 AT phroggy DOT com> on Tuesday August 11, 2009 @12:32AM (#29019559) Homepage

    what's to stop me separating my program into a GPLv2-compliant client app that talks to the rest of my (choose my own license) application?

    Umm... nothing?

    If you're writing your application from scratch without using anybody else's libraries, you're free to release it under whatever license you like, even if it happens to talk to a GPL'd client plugin thingie, and even if you wrote that GPL'd client plugin thingie around somebody else's GPL'd library.

    Why do you imagine that somehow there's a problem here?

    • Re: (Score:3, Informative)

      by seanadams.com (463190) *

      If you're writing your application from scratch without using anybody else's libraries, you're free to release it under whatever license you like, even if it happens to talk to a GPL'd client plugin thingie, and even if you wrote that GPL'd client plugin thingie around somebody else's GPL'd library.

      Which GPL are you reading that says this is OK? If the license doesn't permit it then it's a question for copyright law of whether you're making a derivative work. I would say that in this case you ARE, unless it

      • Re:Umm... (Score:4, Interesting)

        by piojo (995934) on Tuesday August 11, 2009 @12:50AM (#29019673)

        If you write the Foo app on your own without any connection to a GPL licensed library, then Foo obviously cannot be said to be a derivative work of anything. What if you then add some capability for Foo to interact with a GPL'd library?--for instance, adding Readline capability to an app that previously used the BSD Editline library.

        Would this make your program a "derivative work"? That's a question for our legal system--it's not the FSF's right to define what constitutes a derivative work (nor is it the right of the any copyright holder--this is a question of legal definition).

        And... err... I'm obviously not a lawyer.

        • by SL Baur (19540)

          What if you then add some capability for Foo to interact with a GPL'd library?--for instance, adding Readline capability to an app that previously used the BSD Editline library.

          I don't think that matters.

          (Example from my own experience). Under my watch, Wnn support got integrated into XEmacs. There were two flavors at that time - Wnn4[1] (which was free software) and Wnn6 (which was only available for sale in Japan). Now let's say you built an XEmacs 2x binary with Wnn6 support (the Wnn6 library could only be statically linked) and Canna. Does that require the recipient to own an Wnn6 license if he is using Canna? No.

          Wnn6 is certainly not usable with its associated server. I

          • by piojo (995934)

            I don't think that matters.

            For what it's worth, I agree with you. I have no idea what a derivative work actually is, but I'm pretty sure it's not what the FSF says it is. I just read a lot of heated opinions on sites like this that essentially say, "Because you link, your program must be GPL'd!" I think a lot of people don't understand the issues and just take the text of the license to be utter truth.

            • Re:Umm... (Score:5, Informative)

              by swillden (191260) <shawn-ds@willden.org> on Tuesday August 11, 2009 @02:49AM (#29020275) Homepage Journal

              For what it's worth, I agree with you.

              FWIW, the IP attorneys I've discussed this with don't agree with you. They take the GPL at the FSF's word with regard to the meaning of "derivative work". I asked a couple about this and the response was that because the clearly-stated intent of the license was to preclude linking except to code distributed under compatible terms, that a court would most likely agree with the copyright holder. Basically, the "linking implies derivation" notion is reasonable and well-understood by all parties, so the court would accept it.

              Of course, these were corporate attorneys looking to protect the corporations assets, and lawyers in such situations generally err on the side of an overabundance of caution.

    • by Ruie (30480)

      what's to stop me separating my program into a GPLv2-compliant client app that talks to the rest of my (choose my own license) application?

      If you were ready to write your own code, you could just as well rewrite the library. In fact, it is usually simpler as your application likely uses only a small subset of functions said library provides.

      • by quadrox (1174915)

        Generalizing from what you said, noboday ever needs libraries because 1) programmers can just write the code themselves instead of using the libraries 2) non-programmers obviously have no use for libraries.

        Your statement makes no sense at all.

    • by piojo (995934)

      you're free to release it under whatever license you like, even if it happens to talk to a GPL'd client plugin thingie, and even if you wrote that GPL'd client plugin thingie around somebody else's GPL'd library.

      There are two scenarios where I imagine this might not work. The first is if the GPL'd client plugin thingie is integral for useful operation of your program, a judge might rule that your plugin and your program are actually just one work.

      The second way is if you get sued and can't afford a sufficiently convincing lawyer and/or expert witness to explain the issues properly (or you get a judge that doesn't care). (But I'm no lawyer.)

    • by spyowl (838397)

      Exactly. I don't understand the issue. It will look like this:

      [ (GPL library) - > (GPL program) ] (protocol) (non-GPL program that doesn't use the GPL library)

      What protocol is doesn't matter. It can be a standard I/O, local socket, or a network protocol like FTP/HTTP/etc. Can a GPL web browser like Arora communicate with a proprietary web server like IIS? Of course it can!

      If you asked RMS, he would have you offer everything under GPL, but that's the choice you can make on your own. It has pretty much n

    • Re:Umm... (Score:5, Interesting)

      by SL Baur (19540) <steve@xemacs.org> on Tuesday August 11, 2009 @01:07AM (#29019767) Homepage Journal

      I would tend to agree. It's fairly well established that license does not extend across process boundaries - Clearcase interface code in emacs does not make emacs proprietary.

      There's a lot of FUD at the library level. I think you're probably safe with dynamic linking/loading. Stallman hated me for introducing .so elisp modules in XEmacs, but it was on ideological grounds not legal grounds - it made it possible to distribute executable code in emacs sans source code.

      I *would* recommend paying attention to discussion on lkml on the nuances between EXPORT_SYMBOL and EXPORT_SYMBOL_GPL. If your work is a derived work from a GPLed interface, then yes your work falls under the GPL.

      One of the most significant events of 2009 in IT has been Microsoft releasing code under GPL. The intent of the GPL is that if I give you something under GPL and you modify it to do something interesting and distribute that, you have to share it back to the community. The tricky part is defining "modify". In US copyright law, that means creating a derived work. Is linking against a library a derived work? Sorry, that's above my pay grade.

      I find it interesting that it is Microsoft that may validate the whole thing. They are certainly learning. Stallman's copyright assignment requirement for all GNU code, it gives the FSF total control over the work. That's more than Bill Gates managed to achieve. And dang it, I never received any of the $1 consideration payments I was supposed to receive when I signed FSF copyright assignment papers.

      TL;DR Yes, I just likened FSF to Microsoft.

      Disclaimer: I'm an ex-XEmacs maintainer, not a lawyer. Your mileage may vary. Offer void where prohibited. Contact your local dealership for more details.

    • Why do you imagine that somehow there's a problem here?

      Well, the problem is that the FSF takes a rather narrow view on what constitutes linking and "derivative work". Not everyone agrees with the FSF interpretation of what constitutes linking and the language in the GPL is not always deterministic on this matter. The GPL does not (and perhaps cannot) offer a precise, exhaustive and unambiguous definition of "linking" because of the tremendous variety of hardware and software currently in use. The FSF interprets the license strictly while others have interpreted

    • Re:Umm... (Score:4, Informative)

      by Anonymous Coward on Tuesday August 11, 2009 @01:54AM (#29020011)

      A history lesson: GCC includes an objective C front-end. This front-end was originally implemented at NeXT for their new ground-breaking computer in the 1980's, and published as a proprietary component of the NeXT system software. They did not link directly to the GCC backend, but implemented an intermediate file format that was written by the proprietary frontend and read by a patched GCC, and they only published the source to the latter. FSF argued that NeXT was in violation of the GPL, and after months of legal wrangling NeXT gave up, published the front-end source under GPL and the case did not go to court.

      AFAIK the FSF still holds that the only way to use a GPL component in proprietary software is through an API that is supported by multiple implementations, not all of which are GPL, regardless of how the connection between the proprietary software and the GPL software is technically implemented.

  • by poliopteragriseoapte (973295) on Tuesday August 11, 2009 @12:36AM (#29019581)
    The point is that enhancements to the library stay LGPL. I did this myself. I needed to modify LGPL libraries for the purposes of my application. I modified the libraries, and I am redistributing them under the LGPL. My main application is distributed under BSD license, and uses the LGPL libraries. The libraries make perfect sense separately (and in fact, I have people using them for reasons unrelated to the application I built). I think that, out of courtesy, and probably out of need, you need to make sure that the libraries are available separately.
    • by X0563511 (793323)

      Or, the author is ignorant of the LGPL or the difference between it and the 'regular' GPL.

      Step 1: ask the author
      Step 2: worry about working around it

      Why bother if it's possible you don't need to bother?

    • Surprisingly, you are not correct. Unlike the GPL, the LGPL applies differently to a project depending on whether you make changes to the LGPL code or not. I'll summarize:

      If you use LGPL code without modifying it, you can write code which links against it (either dynamically or statically--this is something not generally understood about the LGPL, although if you choose to statically link, you must provide the source or object files so somebody can recompile or at least relink--this doesn't apply if yo
      • BUT if you modify the LGPL code and want to link against it either dynamically or statically, your work is considered "work based on the library" under the LGPL, and Section 6 applies, meaning you are required to also release your code under the LGPL license.

        And I'll clarify just in case I wasn't clear. All your code that you link against a modified LGPL library must be released under the LGPL according to the conditions in Section 6, not just the changes that you make or add to the library source files. Again: There is no such requirement if you don't modify the library in question.

        • Re: (Score:2, Informative)

          by Anonymous Coward

          You're completely full of shit. Here's section 6 of the LGPL:

          6. Revised Versions of the GNU Lesser General Public License.

          The Free Software Foundation may publish revised and/or new versions of the GNU Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

          Each version is given a distinguishing version number. If the Library as you received it specifies that a certain numbered version of the GNU Lesser General Public License âoeor any later versionâ applies to it, you have the option of following the terms and conditions either of that published version or of any later version published by the Free Software Foundation. If the Library as you received it does not specify a version number of the GNU Lesser General Public License, you may choose any version of the GNU Lesser General Public License ever published by the Free Software Foundation.

          If the Library as you received it specifies that a proxy can decide whether future versions of the GNU Lesser General Public License shall apply, that proxy's public statement of acceptance of any version is permanent authorization for you to choose that version for the Library.

          There's nothing in there about releasing applications that link to modified LGPL libraries under LGPL. Furthermore, the situation you describe is completely bizarre, because there's absolutely no way of determining what "upstream" is. The grandparent's post indicates that he forked the LGPL library. Which is a perfectly valid thing to do. And he's licensing the derivative work of the LGPL library under the LGPL. There should

  • Author's wish (Score:5, Informative)

    by ianare (1132971) on Tuesday August 11, 2009 @12:37AM (#29019587)

    This is exactly why the LGPL [wikipedia.org] was created. Or sometimes you will have a GPL lib with the linking or classpath exception [wikipedia.org]. You will find most libs are licensed under these, or even more permissive terms.

    Therefore, if the lib in question is explicitly licensed under normal GPL, it's the author's wish that any apps that use it must be GPL compatible. I think it's only fair to follow the author's wish.

  • terms vs license (Score:5, Interesting)

    by NiteMair (309303) on Tuesday August 11, 2009 @12:38AM (#29019601)

    Doesn't the license basically stipulate that you must release your code under the terms of the license? That doesn't necessarily mean you have license your code as GPL.

    This is actually a common FUD discussion that occurs between developers who use MIT/BSD license for their code, and are afraid to link to GPL libraries because it might force them to release their code as GPL. I'm pretty certain that as long as their code is available under the same terms as GPL code, they can license their code however they wish otherwise. It just means if a GPL nut comes a knockin', they'll have to provide the code as if it was GPL'd.

    Correct me if I'm wrong (and I often am).

    • Indeed. GPL doesn't stop you from releasing your code under another license. It just requires that any code linked to GPL and redistributed must be additionally available under the GPL.

    • So I write a program licensed under the GPL, then someone else comes along and forks it, and makes it MIT/GPL. It is still mostly my work. Then Big Corporation comes along and takes the MIT licensed library, and creates a closed sourced, proprietary application from it.

      I don't know if you are wrong or not, but I hope you are. That would be a serious loophole if it were true.

      • by NiteMair (309303)

        No, nobody can fork *your* work and relicense it. As copyright holder of the code you have written, you have exclusive rights to license it however you wish.

        Thus, nobody can simply relicense your code without your permission.

    • Re: (Score:3, Insightful)

      by Hatta (162192) *

      Doesn't the license basically stipulate that you must release your code under the terms of the license? That doesn't necessarily mean you have license your code as GPL.

      What's the difference? If the original license is GPL, and you must release derivative works under the same terms as the original license, then you are releasing under the terms of the GPL i.e. you are licensing it under the GPL.

  • With commingling, it will be hard for GPL zealots to discover that you are indeed violating the GPL but once they do (I do not know how they do it), just release everything and beg for forgiveness. By that time, you'll already have made your profit.

    But remember: You'll not be able to put a price on the publicity all the "fracas" will generate.

  • by kripkenstein (913150) on Tuesday August 11, 2009 @12:45AM (#29019643) Homepage

    I understand that if I build an application that links with a library that is licensed under GPLv2, I must also make my application GPL2

    That is NOT correct.

    The criteria is 'derivative work', not 'link to'. Linking is sometimes a rule of thumb in this area, but it isn't decisive.

    Note that 'derivative work' is a legal term, not a technical one. So before you try to circumvent the GPL in this way, consult a lawyer.

  • http://clisp.cvs.sourceforge.net/*checkout*/clisp/clisp/doc/Why-CLISP-is-under-GPL [sourceforge.net]

    It's not a direct link, but nonetheless you should strive for independence of that functionality. Otherwise you are trying to comply with the letter of the law, but it may not be enough.

  • by minsk (805035) on Tuesday August 11, 2009 @12:56AM (#29019707)

    Quite aside from the legal meaning of the GPL, you could always ask the authors what they intended. If they want to prevent proprietary applications from using the library, as promoted by , that should influence your decision.

    IMO, if the internals of your application are dictated by a GPL'd library -- *regardless* of how that library is linked, integrated, called, or plugged in -- your application is a derivative work. To separate them, put the library aside. Do a proper design. Gather scenarios you need the plugin to support. Document them. Write a new API. Document it. Collect some alternative libraries. Verify that you were not unduly influenced by the GPL'd one.

    Or, you know, GPL the application.

  • The GPL Problem (Score:2, Informative)

    by cdrguru (88047)

    The problem is that there are plenty of zealots that will tell you that incorporating any GPL-licensed component in any way immediately forces the entire body of work to be released under GPL.

    This can be interpreted at various times to include static linking, dynamic linking, linkage via any sort of invocation such as exec, RPC, and any other sort of connection between two pieces of code. What is the "right" answer? It isn't all that clear. It can be a matter of intent or of benefit. If the developer is

    • Re:The GPL Problem (Score:5, Insightful)

      by minsk (805035) on Tuesday August 11, 2009 @01:27AM (#29019861)

      I've always found that position funny...

      Some people share something freely, with the requirement that anyone building atop it does likewise. They're zealots.

      Other people require you to agree to a contract before looking at their program. Disallow reverse engineering. Disallow redistribution. Disallow extension, enhancement, improvement, porting, circumvention. They're normal.

      Dude, what?

  • by ChaseTec (447725) <chase@osdev.org> on Tuesday August 11, 2009 @01:11AM (#29019787) Homepage
    You can't make a linked wrapper library since the GPL wrapper would be GPL too. See: http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLWrapper [gnu.org] However it sounds like you are talking about a service based wrapper. Then I'd say it depends on how integrated your service wrapper is with your main program. If you use separate processes but lots of IPC and shared memory then I'd think you app is to tightly integrated making it a derived work. If you make a network based service then I'd say you are legally clear even if you'll probably piss off the library author. See: http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#NFUseGPLPlugins [gnu.org] You could also make your app GPL but put a lot of the functionality in non-free plugs, see: http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#FSWithNFLibs [gnu.org] Of course you could also just release you app as GPL and not worry about it. What is stopping you from using the GPL?
  • The whole idea of "linking" is too specific to a technology or architecture. It assumes that some code is "compiled" into some form of library and the functions become available through a "linking" process during the build.

    What if I call functions in my library over SOAP? The application is still "linked" to a service ("library"), but using that logic a web browser would have to be GPLed if you access any GPLed web server.
  • What's to stop you? (Score:3, Interesting)

    by mysidia (191772) on Tuesday August 11, 2009 @01:34AM (#29019919)

    RMS and others, (The community) possibly are there to stop you.

    Probably some people have some creative interpretations of what it means to link against a GPL library, also. To call such things at least a gray area if not outright violations.

    If/when they find out, they might point to your software as an example of bad practice, or put you in the "GPL Violations hall of shame", or some such.

    This is especially interesting with respect to scripting languages... If I write a PHP script that utilizes mysql_* function calls of PHP, which can only be invoked when PHP has been linked against the Mysql Client library....

    Is my PHP script essentially linked against the GPL'ed mysqlclient library, and therefore, (if I distribute my PHP script commercially without source) a GPL violation?

  • I looked into this (Score:4, Informative)

    by dowlingw (557752) on Tuesday August 11, 2009 @01:56AM (#29020021) Homepage
    I was recently looking into this using the concept of dual-licensed GPL/LPGL 'glue' connectors. This is the response I got back from the Free Software Foundation:

    You are correct. The answer is no. If the LGPLed library dynamically calls the GPLed library, then it is the FSF's position that the LGPLed library is a derivative of the GPLed library, and thus the work as a whole may only be distributed under the GPL. Please see this section of the FAQ:http://www.gnu.org/licenses/gpl-faq.html#GPLWrapper.

    For your specific requirements, I'd advise touching base with them - they have an advice service for these types of questions.

  • by countach (534280)

    Actually, you wouldn't have to make your program GPL2, you would only have to make it compatible with GPL2. Which usually means GPL2 or something even more liberal like BSD. And only then of course, if you distribute.

  • Mysql, anyone? (Score:5, Interesting)

    by sanermind (512885) on Tuesday August 11, 2009 @02:13AM (#29020099)
    This reminds me of our experience with mysql.. they changed the license of their drivers (the jdbc driver, in this instance) to GPL from LGPL a while ago, and also affirmed a legal position (at least in their marketing materials) that using the now GPL library would require any application dynamically linking/loading it to also be GPL, with the exception of being able to buy licenses to a separate non-GPL'd commercial instantiation of the library. (They also conveniently hired the guy who had been maintaining the previously freely useable LGPL version).

    In theory, of course, someone else could re-invent the wheel and create another fully LGPL JDBC driver for mysql.. (I was ever-so-mildly tempted to do start work on that myself, out of spite and irritation, but didn't have the time).

    Needless to say, after talking to the lawyer we had to switch our entire infrastructure over to postgresql. On the bright side, I found that I rather preferred postgres as a more comprehensive and functional sql anyway. (No more having to do manual tricks for multi-merges, etc). Still, it seemed like very bad faith to switch the license like that right out from under people who had already been using it, all in the hopes of further monetizing mysql. (Yes, the earlier license applied to the old versions of the driver... which happened not to work properly with newer versions of mysql).

    I once talked to someone else else who makes a a bit of money on the side selling some piece of booking software. Unfortunately for him, almost half his clients were deploying his software in mysql shops. His software was a drop-in .war archive that was trivial to install (just copy it into tomcat/webapps or whatever (well, and run the database creation script to set up the tables for it) and it was good to go. After the license change he was unable to distribute a fully packaged pre-working .war file with the necessary drivers for client databases. (Oracle was propriatary, but free to distribute).. he had to write a specialized install script that the customer could use to unpack the .war, install the mysql jdbc driver, and repackage it, where the script required the client to affirm that they were using a legally licensed non-GPL version of the jdbc driver from mysql to be able to install/link it. This took the liability off of him ...The liability for having the temerity to want to talk with a basic software infrastructure service (such as a sql server), without GPL'ing his little niche app.

    I'm all for the GPL. I love it! I've used it myself in a few things I've developed. I love all the good it's brought, etc, the idea of openness, a publishing and peer-reviewed manner of developing code, all that.

    But I still find it very obnoxious to make a piece of library glue GPL. That's exactly what the LGPL is there for. Logically, it's not a derivative work of mysql if you use it for processing sql transactions (making no modifications or redistributions of it of any kind) any more than a file you create in the gimp is a derivative work of the gimp.
    • Re: (Score:3, Interesting)

      by jeremyp (130771)

      When you added up the man-time required to move everything to Postgres, did it come to more or less than the cost of buying a commercial licence for the MySQL JDBC drivers?

      • Re: (Score:3, Insightful)

        by julesh (229690)

        When you added up the man-time required to move everything to Postgres, did it come to more or less than the cost of buying a commercial licence for the MySQL JDBC drivers?

        MySQL don't appear to publish the prices of their commercial licenses, telling you instead to "contact sales". My experience has generally been that when this happens, the answer is "more expensive than you can afford."

        In a well engineered system, the cost of changing the database should be less than a man week of work (likely cost, arou

  • by itsdapead (734413) on Tuesday August 11, 2009 @06:44AM (#29021307)

    Are you actually asking "can I circumvent the GPL on someone else's library using a wrapper"? or was the question "Why should I bother licensing my own library under the GPL, when others could circumvent it using a wrapper"?

    The first of these has been pretty much answered elsewhere.

    The answer to the second is to relax. If Big Evil Software Corp abuses your work this way then they're heading for a lot of bad publicity, even if you don't have (or can't afford) a legal case.

    If someone gets away with this, shame on them, but what have you actually lost? Would Big Evil Software Corp have paid you (or even have heard of you) if you'd kept the code closed?

    Licenses will have loopholes, and the more loopholes you try to close the more you introduce, and the more work you make for lawyers. How do you legally define the difference between a wrapper and a server so that a jury in Utah can tell the difference?

    The free softwar community shouldn't fall into the trap of thinking like the RIAA and confusing "intellectual property" with real property. Violating the GPL isn't big, isn't clever but is no more "theft" than copying a movie, and the damages caused are intangible and hypothetical.

  • by real gumby (11516) on Tuesday August 11, 2009 @03:29PM (#29028059)

    I wrote the LGPL v1 and badgered RMS into allowing it (John Gilmore thought up the great dynamic linking clause). RMS's biggest objection back then was exactly the case you give.

    I still think in the balance the library license is a net positive for the FSF's cause. But this hinges on the definition of a "derivative work"

God made machine language; all the rest is the work of man.

Working...