Posted
by
kdawsonon Tuesday August 11, 2009 @12:24AM
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?"

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.

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.

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.

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

As an example, you can't copyright the idea of a school for wizards and/or witches, although you can copyright a specific story built around that idea.

This isn't as clear as it sounds. If you write a story about a school called Hogwarts for wizards one of whom is named Harry Potter, you can expect to get sued for infringement under the theory that your story is a derivative work of J.K. Rowling's -- even though you've only copied ideas, not expressions.

I'm pretty sure that "Harry Potter," as a character, is an expression of the idea "student wizard".

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?

RMS and Linus disagree on a lot of things. That does not mean that they disagree on everything. Specifically, they both agree on what I said above.

You should do some actual research before spoiting your "I know something therefore I know everything." Linus often says that Linux drivers must be GPL. RMS (and the FSF FAQ) says that only GPL applications are allowed to link against GPL libraries.

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.

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

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.

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

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).

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.

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.

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.

The idea that linking implies derivation stems from the days when static linking was the norm. It is hard to argue that your application isn't a derivative work if it actually includes a copy of someone else's library in the binary. Dynamic linking, especially for programs that are designed to use more than one compatible library are a slightly murkier case, but only slightly so. That's why the GNU software that clones other software libraries (like glibc) tend to be under the LGPL. After all, in those

That's the beauty of the GPL, in that if the opposition (defendant, perhaps plaintiff in a declaratory judgment) doesn't accept the license, everything defaults back to standard copyright protections, which don't allow use/copying/distribution in the first place, thus being far stricter than the GPL. They are thus free not to accept the GPL, but should they do that, they better make very sure they are not infringing standard copyright, either, because that's the fallback.

That might be what you want (yay GPL), but if you're not thrilled about the GPL, you probably shouldn't be using any GPL software in your project, or you'll run into these issues. Take heed, original poster.

It's why I prefer the BSD license; I don't want my hobby to result in me talking to a lawyer.

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.

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.

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.)

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

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.

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

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.

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.

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.

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

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.

I can second this approach. I wrote a libary for some rather obscure functionality that took me about 120 hours to produce. I am a reasonably good software developer and it's not really possible for any organization to produce the same library for much less than 120 man-hours. A couple of companies found out about my library and decided that it was worthwhile to license my library from me rather than re-writing it themselves. They got a well-written, functional, well-tested library for much less than th

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.

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.

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.

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.

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

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.

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.

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....

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.

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.

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.

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

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.

I tend to find myself in agreement with the OP. More and more it seems like the GPL is not a license designed to promote free and open source software but instead comes across as a "I'll scratch your back but then you are legally obligated to scratch mine" contract. I realize this probably stems from an irrational fear of proprietary software -- fear that F/OSS code will get eaten u

The fact that it can't happen. If you BSD license project A, and company M takes it and makes closed source project B with it, project A is *still* available from your site for free and open. Your code has not been magically closed, the only thing that is closed is *their* code which they used to make their project different from yours.

If that's not very much, well, they've not got very much to sell then, have they.

Exactly. The reason for the GPL is not to "protect" code or keep code free. Code will be free forever under any open source license. Big Bad Corporation can't take your code and lock it up so nobody else can use it; it's still free! The only reason for the GPL is to "stick it" to corporations and anyone else to whom it isn't convenient to fully comply with all the strings (restrictions) attached to and imposed by the GPL. In my opinion, GPL code is counter-productive because of the complexity and ambig

It means when IBM incorporates JFS, or hires kernel-hackers, that those changes benefit every last linux user. That when Red Hat does the same, it might mean a competitor gets it too; but they're going to be forced to reveal their code, too.

BSD/LGPL only works in some cases. Linux is only popular because of the GPL.

That's a pretty stupid statement don't you think? I (and I'm sure I'm not the only one) use Linux because it WORKS and does what I want it to in the situations that I apply it to. I also use Windows 7, Windows Server, Apache, Python, Java, Opera and piles of other products under just about every license under the sun. And you know what? I don't give a rats ass about the license so long as it doesn't hinder me they can shove it under any license they want.

What he was saying is that Linux is working now because of the GPL during its development.

Of course most end users don't give a rat's ass about the GPL, but it is this GPL which allowed one modification made to Linux to be used anywhere. Without it, we would have an IBM Linux, a Red Hat Linux, etc. In this case, why not stick to Unix ?

What he was saying is that Linux is working now because of the GPL during its development.

Of course most end users don't give a rat's ass about the GPL, but it is this GPL which allowed one modification made to Linux to be used anywhere. Without it, we would have an IBM Linux, a Red Hat Linux, etc.

Actually, we do. And it doesn't matter, since it's just minor patches.

It is not at all clear whether the difference in forking behavior is due to the license or the external development velocity / source code organization. We don't have a large scale IBM BSD, a Red Hat BSD, etc - we have a few open source BSDs and Mac OS X, and IBM choose to contribute to an open source BSD (FreeBSD through Whistle) rather than create their own pure fork. Mac OS X also contribute changes back.

They were saying that Linux got to where it is today because of the GPL license. The argument is that Red Hat, IBM, Novell, and other companies wouldn't have contributed to Linux if they weren't forced to by the GPL. Instead, they would have kept the code only in their own software offerings instead of sharing it, and Linux wouldn't have gotten as far along as it is today.

The GPL basically forces collaboration and sharing. I agree that that isn't true freedom in the truest sense, definitely, but certa

The fact that it can't happen. If you BSD license project A, and company M takes it and makes closed source project B with it, project A is *still* available from your site for free and open. yada yada.

We've been through this a million times before. The company has now stolen the time of the guy who wrote the free code in the first place, or at least the guy may feel like that. It's also possible that they extended his file format or network protocol with proprietary parts, harming interoperability and the users of the free version by impeding the network effect.

Some developers care, some don't, some care or not depending on circumstance and goals of the software project. None of these positions is more irrational than the other.

We've been through this a million times before. The company has now stolen the time of the guy who wrote the free code in the first placeNo it hasn't. That guy was kind enough to give it away in an open way. This is the *point* of open source software, to be generous, and let everyone benefit from your work.

or at least the guy may feel like that.Then he (a) is not an open source developer (b) should use a closed license like the GPL, and stop claiming to be open.

No it hasn't. That guy was kind enough to give it away in an open way. This is the *point* of open source software, to be generous, and let everyone benefit from your work.

The guy might quite reasonably want to restrict use to other people who want to share code for free. Like if I run a "bring a bottle" party I am not too upset if everyone brings something, even if some drink more than they bring. I would not like it if someone went round collecting the bottles and selling them at the local market though.
If you don't want to come because "it's not really a free party then that's up to you - but don't complain about me making my own rules.

the attitude of "for-profit companies shouldn't get something for nothing" isn't very endearing

I don't really see what's wrong with that. Isn't the normal way economic transactions work in a market economy with copyright laws something like: if you want to use use a part of my copyrighted work in your own, you have to get a license from me, usually involving payment?

I see using the GPL as sticking with that as the default, but making a special exception that if you give blanket permission to the general public to use and distribute your own code, royalty-free, in both original and modified versions, then you may use my code royalty-free under the same terms. But if you want to stick to the normal copyright model, then I will also, and we can agree on terms in the usual manner.

Basically I don't see how someone who uses the normal approach to copyright licensing in their own products could possibly object to me asking them to negotiate a license in order to use my code as part of their product.

Who "meant" that? The reason I'd use the GPL isn't for some generic notion of openness, but more specifically as a way of allowing multiple copyright/reuse models to exist in a mutually agreed fashion. If you agree to license your code under the GPL, you can have mine under the GPL too. If you prefer a standard copyright/licensing model for your own software, then fine, let's do that for mine too. I'd consider adding more options of that sort t

It seems like anyone that really values and supports F/OSS would prefer LGPL or BSD style licenses. Allowing derivative works to remain closed source isn't a detriment to the open components and it really does look better to closed source companies. This should lead to more people adopting and using F/OSS, both open and otherwise. That's good, isn't it?

In theory, yes. In practice, however, it seems volunteers and companies contribute a lot more to GPL'ed projects than to BSD'ed ones, otherwise we'd be arguing for the "Year of FreeBSD on the Desktop" instead of Linux.

Personally, I like the idea of a BSD kernel with LGPL libraries and GPL applications, it seems to me as the best balance between freedom and widespread usage I can see. However, if devs believe otherwise and GPL everything I have no problem with it, the market will decide which option is bette

In theory, yes. In practice, however, it seems volunteers and companies contribute a lot more to GPL'ed projects than to BSD'ed ones, otherwise we'd be arguing for the "Year of FreeBSD on the Desktop" instead of Linux.Really? Every company I've ever worked at has used and contributed to BSD and LGPL projects, but not touched GPL with a barge pole.

Personally, I like the idea of a BSD kernel with LGPL libraries and GPL applications, it seems to me as the best balance between freedom and widespread usage I ca

Windows is only developed by Microsoft, and Darwin if it has somebody other than Apple contributing code, I've never heard of him. Regardless, both are irrelevant, my comment was clearly aimed at the Free OS market, otherwise we could argue that since most of humanity doesn't own a computer, neither should we and so we must throw them out of the window.

And in the Free OS market, Linux is far, *far* bigger than all the BSDs combined. Explain that however you want to, but it does lead one to think that your p

In theory, yes. In practice, however, it seems volunteers and companies contribute a lot more to GPL'ed projects than to BSD'ed ones, otherwise we'd be arguing for the "Year of FreeBSD on the Desktop" instead of Linux.

That's just because we've already seen the "Year of FreeBSD on the Desktop." It's called Mac OS X.

But seriously, you'll have to provide a citation with your assertion that companies contribute more to GPL'd projects than projects of other licenses. The only major GPL projects with corporate contributions that come to my mind immediately are Linux and MySQL. On the other hand, many, many non-GPL projects with corporate contributions immediately come to mind. All Apache projects, postgresql, ffmpeg, BSD, memcached, OpenOffice.org, QT, postfix, bind, all Mozilla software, webkit, need I go on?

The sad truth is, the actual value of the GPL is a lot less than everybody thinks. It doesn't protect code from suddently becoming non-free because 1) corporations can't do that anyway, and 2) companies that do use non-GPL code tend to give back their improvements anyway, even though they are not legally obligated to do so. They may do it to keep good karma amongst developers rather than a strong believe in Free software, but who cares? What then is the value of the GPL? I propose it has negative value, considering the incompatibilities it introduces (ZFS anyone?) and the needless complexity it brings, but of course that's just my opinion.

otherwise we'd be arguing for the "Year of FreeBSD on the Desktop" instead of Linux.

That's just because we've already seen the "Year of FreeBSD on the Desktop." It's called Mac OS X.

Except as Daengbo points out above us, OSX doesn't use the BSD license for the kernel part, it uses the APSL, which more resembles the GPL than the BSD, e.g. its a stronger "Copyleft" style of license thats more "restrictive" than the BSD. The rest of Mac OS X, the part that really counts!, of course, is proprietary, so the GP's point remains: "Year of *BSD on the Desktop" hasn't happened yet.

The only major GPL projects with corporate contributions that come to my mind immediately are Linux

In the context of the GP's "Year of XXX on the Desktop" reference, this is exactly the point: BSD-licensed OS kern

Say there is a nice GPLv2 library i know is distributed with every Linux distribution, something small. I write a closed source app that dynamically links to this GPLv2 library at runtime and calls a few functions from it. Who is violating the GPLv2 here? The developer? They haven't actually distributed the GPLv2 code, how can they be bound by its terms?

Is it the user? The GPLv2 explicitly says that the end user does not need to agree to the license at all just to run

The GPL does not guarantee that someone has to give you anything back. In fact, there is no reciprocation requirement at all.

I can, for example, take your GPL'd work, make some changes, then sell it to my customer. I am required, by the rules of the GPL, to give my customer the source, and they are allowed to do whatever they want, including give it to others, but if they paid $1,000,000 for it, chances are they're not going to do that. You have no right to demand the changes I made, or even a copy of the program from me.

This is a common myth around the GPL, that it enforces a reciprocation agreement. It doesn't. In fact, licenses that have such agreements are not compatible with the GPL.

It may not require direct reciprocation, but there is an element of preventing abuse involved. In the case where a company extends GPL software and then only sells the resulting binaries commercially, they are still required to provide any customers with the resulting source code under the GPL license, which further allows them to re-distribute it if they see fit. That means there's no effective way to hoard this code or lord it over others. If your derivative product sucks so bad or has such limited app

The community for a given derivative is its users. By definition the users will have a copy of the dervivative app and therefore the source. It was never intended that anyone and everyone should be required to have the changes.

In practice though, even private development will result in bug fixes and it will be in that private party's interest to pass those back to the original project so they are maintained by the community and don't have to be manually patched and merged in with each update.

Software is worth whatever someone will pay for it. There is no fraud involved in charging whatever someone will pay.

And the GPL puts no limit on what you may charge. The section you quote above is in regard to the fee for transfering a copy of the source code (upon written request). It is not a requirement for how much you can sell the binary for (with the source).

Many businesses pay in excess of $1,000,000 for custom software.

I'm not referring ot simply filing off the serial numbers. I'm talking about

There are so many examples for this I don't even know where to start. Lets say that I'm a manufacturing corporation and I have a database system and interface that monitors all of my manufacturing processes automatically and warns the appropriate people when a process starts to go out of a controlled state. I don't want my competitors to have this because it's just a huge boon to my output quality and reduces cost by millions every year.

He can continue to merge in any changes that the community makes, and certainly can take advantage of them.

Also if there is some bug or feature in mysql they need, they can make a stripped-down version of their application, such as an otherwise useless page of code that demonstrates the desired feature or bug, submit that, and hope the mysql guys fix it.

They could also fix mysql itself, contribute the fix back, and if it gets incorporated into the main source they are in exactly the same state but their cod

'Free' is not a magic word that means something absolutely, there is no $DEITY-given dictionary which provides a canonical meaning for the word.
Whether I call it 'free', 'open', 'shared', 'blue' or 'pretty' is completely irrelevant: what is relevant is what users and developers are allowed to do with the code and under what conditions.

This silly bickering about what kind 'free' is freer was boring already decades ago...