Preview of GPL V3, Part 2
Meltr writes "NewsForge.com
has published Part 2 of their GPL V3 preview.
It clarifies
Part 1,
mentions the possibility of GPL V2.1, and discusses the system library exception
and the issue of patents." We had covered their initial "sneak preview" a month ago.
I agree that there are several issues like patents, and the ASP loophole that need fixing, but should we be considering changing the rules to the GPL just as more business, and users are getting to understand it? Hopefully RMS can avoid making any controvercial changes that whould devide the community ( I remember a few months back reading a article on advgato that advocated barring use of any GPL'd software by anyone suing any free software author over patent infringement, that I found to be a verry bad idea).
The GNU General Public License explicitly states that you can take the terms from any previous or future version of the license and use it in the place of the current version, as a user of the code and resulting software. Doesn't this clause make it impossible to plug holes in the GPL?
Here is the clause:
Given the recent arguemtns by RMS on the debian-policy list, it's about time that they made it so that binary packages don't need to be shipped with a copy of the GPL, but instead only a URL for where they can find it.
.deb should have a full copy of the GPL even though every Debian user already has the GPL in /usr/share/common-licenses/GPL, there's a chance that someone who doesn't use Debian downloads a package and plays with it, and since they won't necessarily have the GPL on their system, if the package doesn't contain it, they're violating the GPL.
For those who don't read that list, RMS was making a big fuss about how every single
Thanks
Bruce
Bruce Perens.
I heard you had a rather large lawyers bill to pay though, and no cash. Still, i'm glad you put your new patent to good use.
Syllable : It's an Operating System
This Slashdot article reveals that the Army plans to use Linux in embedded devices. Your code may be used to kill people. IMO the GNU license ought to be modified with an ethics clause. Sure this won't stop Saddam Hussein from using Linux to kill if he can, but it would have stopped the US Army, who respects licensing and copyrights and US law.
Bruce
Bruce Perens.
There is a common open-source myth that really has to be cleared up.
Many say that there is a big difference between software and physical objects when it comes to selling, that things should be sold for it's direct cost. In the case of software, just the cost for the CD, manuals and distribution costs (like labour).
Lets take automobiles as an example. To make a car costs about 1/10 of what it is sold to the end customer for. This means, if you add labour at the factory, material costs, robots etc you just come up with about 1/10 of the customer price tag. If you buy a car for $30.000 the cost for making it at the factory was about $3.000.
Sounds like making cars is a real moneymaker doesn't it. Despite this most car manufacturers aren't going to great these days. The reason for this is that most of the costs are in intellectual property of different kinds. There are huge costs in developing new cars, engineering, testing etc. These are the big costs, not the product itself.
The same goes for, say oracle or Microsoft. Sure Gates and Ellison are rich but most of the money you buy office for is put back into the production of new versions. The costs are huge, salaries for thousands of people.
So indirect costs (and most of all different kind of IP) are often the biggest part of any business so you cannot just calculate with just the material cost.
# more GPLv3.ianal
GPLv3.ianal: A file or directory in the path name does not exist.
# ls
GPLv3.txt
# more GPLv3.txt
Can not output: non-printable characters
#
"The criterion has to be somewhat more general than just allowing libc. But we definitely do not want to permit linking with third-party non-free libraries."
;-) So you start reading the copyright information in the books and find references that work. While you find references that work, you find that they aren't all exactly what you need.
I'm sorry to ask it, but who are "we"? Certainly not I. The GPL is a bit too restrictive for my tastes. Upon a second reading of the LGPL, it may be a violation of the LGPL to release non-libraries under that license.
Sure, mod me down as a troll. I really don't care. I have a differing opinion and should be silenced.
Imagine, if you will, working on a paper for a class. You decide to release this paper under the mythical Free Paper License, so that content providers can use it and so that other students can benefit from your work. So you go to the library and start collecting sources. You start referencing sources. You start quoting sources in your article.
But wait! You're in violation of your license! Wha...? You heard me. The mythical Free Paper License requires all referenced content to be available under the conditions of either the FPL or the LFPL.
What to do then? You start writing a supplementary paper that will be available under the Lesser Free Paper License. Unfortunately, at this point your professor balks, stating that your paper should be dependent only on outside sources, and that he/she won't accept a paper that has extra dependencies. So you try to bribe someone else into writing the LFPL paper for you. No luck. So much for making your paper "Free."
The point of all this? The GPL is too restrictive IMHO. While RMS may see real danger to allowing linking to "non-Free" libraries, I fail to see it. It's no more restrictive than quoting a source in an academic paper that falls under a restrictive licensing/copyright notice.
Stating on Slashdot that I like cheese since 1997.
Bruce
Bruce Perens.
I see the version clause as a necessary evil. If you write a good piece of software, you maximize its utility by specifying "version $foo or later," where $foo is as low as possible. If Linux is GPL 2 and Mozilla is GPL 2.1 or greater, you have an artificial obstacle to sharing.
Compare this to LGPL clause that permits relicensing under the GPL. You may not want someone to make a GPL fork of your LGPL library, but that's a risk you have to take to realize the goal of the LGPL--linking with GPL code.
This is one of the clauses I really like about the Debian Free Software Guidelines. (I prefer to refer to the DFSG, as the Open-Patch^H^H^H^H^HSource Definition is weakened by the OSI's role in interpreting it. Yes, I know you wrote them both.) A good free software license should restrict its domain to the software.
I hate that university research continues to produce software for "non-commercial" use. The GNU GPL has nothing to say about using software, although the waters have been muddied by recent discussions about dynamic linking, plugins, and CORBA-like components. (What, after all, is the difference between dlopen() and system()?) The GNU GPL should stay that way. I'd rather leave the "ASP loophole" in place than muddy the waters even further.
Likewise, free software licenses should say as little as possible about patents. Every once in a while, Slashdot posts an outrageous patent story and someone says, "Hey, let's amend the GPL to punish patent aggressors." Bad idea. Copyleft to subvert copyright. Patent pools (e.g., mutual defense) to subvert patents.
It's always the perfect time for hypocrisy! What better way to promote freedom than to introduce yet even more restrictions?! Hopefully this will be the final straw that forced people to see through the facade that is the GPL. The BSD license has never looked better, especially with that bullshit ASP exception proposed for the GPL.
Right now you get a lot of rights when you receive a GPLed program. You can create derivative works for your own use which means that you can link them to anything you damn well please.
If the user is doing the linking of a non-Free module to other Free Software, I don't see
People make a great deal of the "derivative works" concept in the GPL. But remember that the GPL gets all of it's strength from Copyright law. It is not an EULA -- it is a true License in the legal sense. One of the things that is not copyrightable is a "method of operation". The canonical example of this is the manual transmission shifter pattern. The person who first designed the H which is now universal could not have copyrighted that design decision becuase it was a method of operation.
I argue that an API *is* a method of operation and is not copyrightable. As such, anyone can utilize that API without creating an infringing derivative work. The GPL, as a license, can't restrict that becaue it can only restrict derivative works.
An this is a *good* result. What if Microsoft attempted to claim a copyright over their API? Wine could not exist. MS could also demand royalties from anyone who used one their libraries in Free Software. This limitation of Copyright Law is a *good* thing and it protects us.
Now I'm all for encouraging Free and Open Software. But I'm not willing to give up my rights to do so. Turning the GPL into an overreaching EULA is not the way to go.
I have discovered a truly marvelous sig, unfortunately the sig limit is too small to contain i
Bruce
Bruce Perens.
Let's say you want to make blocks of plastic that fit together. *cough Lego cough*
The first piece you make, costs you $15,000. The rest of the peices off the same mold cost $0.001. It was the initial cost, along with R&D time, that makes the item expensive to produce. Making the Nth copy is just pennies.
i.e.
You spend 2 YEARS writing a game, on a 2 million dollar budget. The first [gold] CD produced has the high cost. The 2nd, 3rd, etc, cost almost nothing to reproduce, just the physical media.
In both cases, people expect to sell Y copies at Z price to offset the total cost of production.
I have been writing a Java library that we originally were going to license as GPL. Someone pointed out that the whole project would be mearly an acedemic exercise because users would no doubt be using non-GPL code for just about everything else that might call our library in which case they would be in violation. So we switched to LGPL for genderal industry compatibilty. Would you suggest this is the wisest license for Java software?
Similarly, with LGPL could someone simply change access to constructors and methods to "public" to circomvent package protection and allow them manipulate/extend the library from their own proprietary packages? This would not be suitable reciprocation IMO. If not, LGPL works perfectly for Java because I can excercise the license through package protection :~)
Bruce
Bruce Perens.
I hope that a new GPL version, in its attempt to close loopholes, doesn't become even more difficult to parse, and thus more likely to result in a bad decision.
I am so glad that RMS is still in the comments gathering stage. Some of the proposals I've seen for GPL are very unfree (in both the FSF and the dictionary sense). These proposals seem to be more about protecting the author's sensibilities rather than eliminating the traditional restrictions normally tied to software.
1) Further restrictions upon linkage. Dynamic and runtime linkage is *using* the software in the manner it was meant to be used. And the freedom to use the software in any way is the FIRST freedom listed by the FSF. It's sensible at times to restrict what libaries an application can link to, because that could co-opt the application and make it unfree. But the reverse is impossible. There is no way to make a libary unfree by using it for an unfree application. No derivative work is being made under copyright law. Nothing is being modified or distributed with additional restrictions. The only thing being hurt is the author's sensibilities.
In RMS' zeal to prevent proprietary authors from using his libraries, he ends up hurting Free Software authors who use non-GPL licenses. The GPLv3 should be looking at ways to include non-GPL but Free Software authors in the community, instead of seeking further ways to exclude them. As it now stands, software in the public domain or under a BSD, MIT or other "copycenter" license cannot use GPLd libraries, such as readline or Qt/Embedded. Some proposals for the GPLv3 would further alienate these freedom loving folk.
Looking at the various dynamic (not static) libraries in existance, the only ones that I know of that dictate the terms of the application's licensing are are small subset of "Free" Software libraries. (there may be some proprietary licenses that do this, I am just not aware of any) Microsoft doesn't care how I license my MFC application. RogueWave doesn't care how I license my Tools++ application. Only the FSF demands I use a specific license for my own original and non-derivative works.
2) New restrictions upon use. That RMS is even contemplating this scares me. By *use* I mean the ASP "loophole". Again, this is another case where the only harm is harm to the author's sensibilities. RMS and the GPLv2 allows me to modify GIMP (as an example) for my own private use. They do not restrict my friends from coming over to my residence and using the modified GIMP on my computer. But the GPLv3 will regulate how my friends can use my modified copy of GIMP if they do so over the internet instead of physically walking to my residence. Where is the logic in this?
There are parts in the GPL v 2 that need cleaning up and clarifying. Please do so. But don't add new unprecedented restrictions. If the only thing being hurt is your sensibilities then leave it out.
A Government Is a Body of People, Usually Notably Ungoverned
In the future I'll have to distribute the game I'm working on for Windows, Linux and possible other platforms.
The program depends on a JRE (being written in Java) and several libraries published under the LGPL and zlib/libpng license.
Now, from the GPL I understand that I can not distribute the JRE along with my program. What I think I am allowed to do is let my program's installer (which is custom license, almost a free one. I understand that I can use that) download the JRE and then install it.
For the libraries I understand that I can distribute them along as long as I clearly seperate them from the other code. I plan to do this by packaging the libraries as JAR files.
So my question... am I correct in my assumptions concerning the JRE, Windows installer, LGPL- and zlib/libpng-licenses?
Monkey sense
Okay, I'll admit that I apparently don't understand the GPL at all.
Are the following situations illegal under the GPL?
1) I write a GPL'ed application that links to a closed-source, proprietary library, such as Motif, and distribute just my application's source.
2) In updating the code of a commercial, closed-source package at work, I take advantage of a GPL'ed library. I make no changes to the library, and I include the source of the library in the distribution, but due to not wanting to have my company not sue my ass off, I don't include the source to the entire project. The library is not statically linked into the program -- it is installed seperately.
3a) For this same piece of software, I include several shell scripts to do parts of the functionality with customized versions of a few GPL'ed utilities. I include the source for the GPL'ed utilities, but I do not include to source for the larger package that includes and actually invokes these shell scripts to do certain tasks. The shell scripts are not GPL'ed.
3b) The shell scripts are GPL'ed, but the app that calls them still isn't.
4a) I build the closed application with a hacked up version of bison. I include that bison and it's source code, but not the application's.
4b) I do not include that version of bison or its source.
5) My closed-source package talks to a CORBA object that defines a well-known interface. That object is replaced with a GPL'ed version on some user's machine.
If any of these are illegal, then isn't this extremely unfriendly to every known license other than the GPL, including the BSD licenses and public domain licenses?
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
To split a few hairs, I would ask, "acceptable to whom?" Killing another human is never acceptable to my ethical code. It may be to yours. We'll never resolve our differences on this.
A more useful consideration may be how people actually respond to killing under necessity. Guilt and severe emotional distress are quite common among soldiers, police officers, and others who kill under necessity (self defense, to save innocent lives, etc.). Not everyone has this response, but many do. We should trust this fundamental human reaction and say that while we would not call these people "bad" for what they did, their sense of guilt is real and should be respected.
The best sense I can make of it is that you can find yourself in a situation in which there is no morally acceptable choice. My philosophy of conscientious objection to military service is that once you are in a war, you may well find yourself facing a situation in which you cannot behave ethically. You must choose between killing someone else and having that other person continue to kill people. Neither killing the other, nor allowing him to continue killing is an acceptable choice. Either leaves you with dirty hands. The ethical thing to do is to plan ahead and avoid the situtation if possible.
Perhaps you can't avoid the situation. Too bad---no one promised that you would be given the opportunity to get through life with a clean conscience. Many major ethical thinkers, including Aristotle and Calvin, understood that chance and luck play an important part in the ethical life and that you may be damned through no fault of your own, but by circumstances beyond your control.
Oh, hey, that's a great idea. My code can't be used to help my nation, even if I want it to because I'm forced by some other code to GPL it, but it can be used to help out my nation's enemies because they don't respect me.
Yeah, let me discourage my military from using technology that peopl around the world work to make the best so that they'll be forced to use something like Windows. We've all seen how well that worked out for the Navy.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
You may think we're 6 hours behind, but in actuality, we are 18 hours ahead. Don't even bother spouting off some nonsense about the calendar date, because that whole system was created by Papists.
"Watch these suckers jump when I get root." - l33t j03
Somewhat related to 5: 6a) I build a closed-source application that makes use of a library that provides a set of services for which there is a GPL'ed implementation. I don't build against the GPL'ed version, but it is binary compatible. I don't distribute a copy of the library -- maybe the commercial versions are expensive. What if I suggest that the GPL'ed version may be a solution for users but don't include it in my distribution, so that users choose to dynamically link with that GPL'ed library with my approval. 6b) What if I don't endorse it, and a user does it anyway?
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
I agree with you mostly, but I think voluntary euthanasia is acceptable.
cpeterso
Bruce
Bruce Perens.
In automobiles it is worth an entire engineer's yearly salary to figure out how to replace a 10-cent widget with a 5-cent one. This saving of 5 cents on a 15,000 dollar item is important because the margin is very small.
Yes there are huge armies of engineers designing the cars, but their cost is still pretty small compared to the materials, labor, shipping, sales commisions, advertising, etc. You have to take into account the enormous numbers of cars sold.
GPL could do a lot more than it does now to protect open-source authors from patent abuses. While there are some patent-only companies, most of the worst software patents are held by software companies, and these companies often also use open-source software.
One thing GPL could do is make companies that use open-source software implicitly license other users to use that software as well. This might seem unenforcable or extreme, but IBM does something like this in its open-source license. The IBM Public License is at http://www10.software.ibm.com/developerworks/opens ource/license10.html. Here is a relevant
snippet:
Similarly, the GPL could be amended to add something like the following:This is a purely defensive approach, which works for IBM because it is a big company. Open-source authors are not huge companies, which means that it would be a good idea for the language to create a counter-claim in their favor, in addition to protecting them against liability. Defensive language does little to deter intimidation lawsuits, but if the open-source author can also counter-claim for significant damages, then potential plaintiffs will think twice. An example:
The problem is that the exact words of the LGPL seem to require dynamic linking of my library, so that it can be "replaced by the user". This imho is unacceptable, since my library is not popular and thus must be provided with the appliacation. This requires the application to be "installed", which greatly reduces it's ease of use. Perhaps more important: it means a programmer cannot modify my library (releasing the code modifications) and use it in their closed program, since the shared library would conflict with other users of my library, this completely defeats one of the main advantages of Open Source, which is that you can change it!
I have taken to adding a disclaimer that says "static linking of my library is allowed, no matter what the LGPL says, and is in fact even encouraged". But I would like to know if there is any better way, or if the LGPL allows this.
I would prefer not to make my own license just because of this, since we have way too many licenses as is, but this worries me no end...
2) Read Section 2 paragraph b "You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License." If you did not distribute or publish the derived package you would be off the hook, but since you say "commercial" presumably it is to be distributed in return for money. Trouble.
3a,3b,4a) If you have read this far in the post you should have read section 3. "For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable." All modules means ALL modules. Trouble.
4b) Same as the answer to Question 1, if bison is something normally distributed with the major components of the OS you are ok, otherwise trouble.
5) Dynamic linking is hard.. let's go shopping! My best understanding of this case is that you are not in trouble. (You could be in trouble if the original non-GPL object had not existed, but since it does exist I think the fact that a plug-compatible GPL equivalent object exists is irrelevant. I figure I have a 50% chance of being wrong, so someone better correct me.)
I know it's hard to understand licenses and official fine print like that, but it is still important to read them. :-)
"The Crystal Wind is the Storm, and the Storm is Data, and the Data is Life"
I also would like to know in which ways it's harmful to link to closed libraries. Consider these cases:
1) A call to a URL gives you the exact time based on an atomic clock in Boulder. You call that URL in your code and use the results in some calculation. Does the source to the URL you call have to be under the GPL in order to use the GPL 3.0 for your code, or for someone to make use of your code with the URL in some manner.
2) Now that URL is a corba/RMI service, but again not GPL'ed. Can I still call it and use the GPL?
3) Simple case, that I think draws out the real issue - you have a PCI card that does encryption for you with a closed source API (or possibly comes with a closed orb to call as a CORBA service). Can I not use that in a GPL'ed program?
I think the real issue is twofold - what he really wants is partly to not encourage the use of non-free libraries, but even more importantly he does not want Free (GPL) programs to ever have ties to non-Free programs so that the Free code users can be harmed by alterations/vanishings of the non-Free library. Say the encryption card vendor went out of business and lots of Free programs had been written based on them.
I guess a side aspect of that is that they are trying to stop the case where the card maker would ship some Free tool bundled with the card and a non-Free part to access the card. Still, by examining the Free portion it seems you could figure out how to work with the card.
I still don't really see the point of it though. The Free programs could always be patched to use some other library if troubles ensued. Also, it seems like it would NEVER be bad to have a Free program that had "drivers" to use some non-Free code.
I'm not trying to start a flame war, I like the rest of the GPL but this part seems odd to me, and I'd like to understand the philosophy behind it.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
% hello_world
Alice develops a GPL library.
Bill Gates wants to link his code to it.
segmentation violation - core dumped
"The Crystal Wind is the Storm, and the Storm is Data, and the Data is Life"
They already did, fuckwit. It's called the Echelon.
I'm too sexy for you.
The LGPL does permit static linking. In fact it makes no references to dynamic linking at all.
If a statically linked application is distributed without source, and is linked with an LGPL library then the distributor must more or less do this (consult section 6 for precision):
(a) Provide source code for the LGPL portion
(b) Provide object files (just one will do) for the rest of the application such that the user can modify the LGPL part and recreate the application.
The easiest way to do (b) is dynamic linkage, but it is possible to do so statically as well. (b) is an important freedom that perhaps you had forgotten. The LGPL does not just protect your right to receive source code for some library that an application happens to use. It protects your right to change the LGPL'd part of the application.
If you wish to make it clear that static linking is allowed, I suggest you say "contrary to popular belief, static linking of my library with closed source code is allowed; please consult section 6 of the LGPL for details".
I may be way over my head here (forgive me if I am), but wouldn't having it dynamically linked make it easier for a user to modify? I guess the scenario I have in mind is 1) Big Commercial Company releases Neat Product with fltk (statically) linked to it. 2) You, someone else, or even the user himself modifies fltk to fix a bug, or whatever. Now if fltk were dynamically linked, the user could plug in the latest version, and there you go. But if it's statically linked, then the user is pretty much stuck with it until Big Commercial Company decides to release an "upgrade". It seems the static use is what defeats the advantage that you can change it.
Visit me on #weirdness on the Galaxynet.
As others have noted, section 6a of the LGPL says that distributing header files and object files is sufficient.
I just wanted to thank you for your work on fltk. I'm working on a GLUT binding library for Inventor. If it goes well, I may look at writing a fltk binding library.
If any of these are illegal, then isn't this extremely unfriendly to every known license other than the GPL, including the BSD licenses and public domain licenses?
You could cut the irony with a knife. On one hand, the FSF does not want people to own software. On the other hand, they explicitly discourage the use of public domain. That they could sue you for refusing to own your work that linked to libreadline seems par for the course. It's okay if you give your stuff to the FSF, but give it to the public and you'd better get a lawyer.
A Government Is a Body of People, Usually Notably Ungoverned
On the other hand, they explicitly discourage the use of public domain.
My understanding was that they discouraged the use of public domain because it doesn't afford the same protection against non-free derivative works that the GPL does. People are only required to own software (with the GPL) so far as to enforce (in the context of the current copyright system) the distribution and derivative rules. If stuff could be placed into the public domain such that all improvements to it were also public domain, then that would be great, but unfortunately the GPL is needed to enforce such a system.
Quidquid latine dictum sit, altum viditur.
1) I write a GPL'ed application that links to a closed-source, proprietary library, such as Motif, and distribute just my application's source.
...
1) Read Section 3 of the GPLv2.
Incorrect. Section 3 of the GPL only deals with situations when binaries are distributed:
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided
Since the original poster said he'd only be distributing the source to his application, he is fine. However, if anyone down the track attempted to distribute binaries, then there'd be trouble. This means that you can link to any non-free library you like, but your application can only ever be distributed as source.
The copyright holder may add a specific exception to the license, allowing distribution of binaries linked to that specific library (or one providing equivalent functionality). This is like an extension of the system libraries clause. I'm not 100% sure, but I don't think this would make the program any less free. I'm interested in what others may think of this.
There is also the additional problem that the license does not apply to the copyright holder. The only person who can be infringed against (and therefore subject to damages) by breaking the license is the copyright holder. Since it's unlikely that the copyright holder would seek damages against themselves, this means that they don't need to to abide by the conditions of the GPL. They can therefore distribute binaries linked to non-free libraries (even statically, if the non-free library allows it, though most non-free libraries forbid this method of redistribution, instead requiring the non-free library to be obtained directly from the author). However, anyone who receives these binaries may not redistribute them, because the GPL applies to them. This means that a copyright holder alone may distribute binaries linked to non-free libraries. The way around this is for the copyright holder to grant a specific exception in the license, as above, which allows anyone to redistribute binaries linked to the particular non-free library. Of course, if an application developer uses someone else's GPL'd code in their program which links to a non-free library, they may not grant an exception for that code, so they cannot distribute binaries at all, and the viral nature of the GPL is preserved. The other person may grant an exception if you ask them, but they have no obligation to.
(This last part always makes me feel uneasy; if I've got it wrong, please let me know.)
Quidquid latine dictum sit, altum viditur.
And that, in a nutshell, is the irony. You shouldn't own software. It's derivitives shouldn't be owned either. They only way to prevent owned derivitives is to own the original.
I think the FSF just started off on the wrong premises. None of their conclusions would have been affected if they had admitted it's okay to own software. In some ways their arguments could even have been strengthened by admitting that it's okay. After all, how can you share what you don't own?
A Government Is a Body of People, Usually Notably Ungoverned
They only way to prevent owned derivitives is to own the original.
Under the current copyright system. It is plausible that a system could exist in which derivatives could be protected without requiring ownership.
Thus the ownership imposed in the GPL is more of a legal hoop that the FSF has to jump through in order to achieve its slated goals of free software. There's nothing wrong or hypocritical with opposing software ownership, and then using it as a means to the end of free software. The GPL only exists as this means as a result of the current copyright system system. It only endorses ownership in as much as it is forced to in order to have legal grounding in the current copyright system. If a solution could be found which did away with software ownership and still preserved the freeness of free software, I'm sure the FSF would jump all over it.
Personally, though, I've never been sure about how I feel about software ownership.
Quidquid latine dictum sit, altum viditur.
Not to mention all the other drawbacks to statically linked binaries such as increased size. Dynamically linking to libraries contributes to code-reuse and modularity in the system. As you mentioned, if something is broken in the library, you just fix it in the library and don't have to recompile the applications that use it.
----
Celebrate the finer things in life
Perhaps version 3 will specify that redistribution can only be under 3.0 or later. I could modify your code and opt to distribute it under the new, strict GPL 3.0, which would not allow you to redistribute it under the old, lax GPL 2.0. I don't expect restrictive abuses, but they are possible.
Ask me if I've been required to disclose any crypto keys.
If a solution could be found which did away with software ownership and still preserved the freeness of free software, I'm sure the FSF would jump all over it.
The only way to guarantee certain attributes of Free Software is to own the software. If you wish that all distributions of your authored software retain access to the source code, you have to have sufficient ownership rights in it order to assert that control. You cannot control something if you do not own it (unless you employ coercion).
There's nothing wrong or hypocritical with opposing software ownership, and then using it as a means to the end of free software.
If the FSF viewed software ownership like "fire", then fought fire with fire, that's okay. But reading throught the FSF pages, I get the distinct impression that they believe software ownership to be evil and immoral. If so, then owning software with a GPL label on it is still evil and immoral. It would be like fighting murder with murder. As my Mother always told me, two wrongs do not make a right.
As an aside, if the FSF ever got its wish and copyright law suddenly disappeared, nothing much would change. The vast majority of proprietary licenses are not predicated on copyright law, but on contract law. Lack of copyright law would not affect the Microsoft EULA in any way. What would happen is that those people who wished to protect their software ownership rights (whether the be Free or proprietary) would find other ways to do so besides relying on government recognition. Take a look at this Free Nation article for an anarcho-capitalist look at copyright law. The Free Nation site also has other articles on intellectual property from a libertarian perspective, including the one mentioned at GNU.
A Government Is a Body of People, Usually Notably Ungoverned
QA and BT? Aren't those things mutually exclusive?
"Watch these suckers jump when I get root." - l33t j03
In my experience dynamic linking makes the programs much larger. Dynamic linking cannot win unless more than one program is using the library, and I think for many useful LGPL libraries this is not true. Don't forget that each incompatable version can be considered a different library. Also you can easily tell that a dynamically linked executable takes much more disk space than a stripped static linked executable for a library like mine, where the functions are numerous and fairly small, because the symbols are actually larger than the linked objects! (it is true that these symbols do not take memory when loaded in).
I have also found dynamic linking to be a real pain to support. More than half the makefile is to get around problems with making shared libraries. On Windoze we are forced to add horrible kludges and macros to get around stupidity in VC++ design. Conversely, on Unix we have no ability to share symbols between source files without also bloating the library with another public symbol, and I am forced to arrange the code in weird ways to make as many variables static as possible.
Both systems have the annoying fact that if my library calls another shared library, you need to link that other library, even if you don't link to any functions that use it, this forced us to split the library into a part that uses OpenGL and a part that does not, and also forces me to design it to not call libimage or any other possibly useful library. (I would prefer a shared library system where a call to a missing library produces a crash with "Symbol XYZABC not found")
I can assure you that retaining binary compatability is a huge pain and seriously damages our ability to improve this product. Every change that would break binary compatability is being pushed to version 2.0, even though some of them are trivial (replacing some shorts with ints for widget positions) and have been wanted for more than a year.
And dynamic linking does make it a pain to "install" a program. A lot of useful utilites should be able to be downloaded as a single executable, double-clicked by a user with no permission, and they should work! This means all shared libraries must be installed on the machine, and I'm sorry to say my library is not popular enough that anybody can assumme that!
I actually think dynamic libraries are a mistake, almost all the time. Everybody here laughs at Windoze "DLL hell" but seem to refuse to believe that we are creating the same mess, or worse, on Linux. Dynamic libraries should be reserved for common system interfaces (ie libc). A lot of stuff that is dynamic like OpenGL should be written as a "service" with header files full of macros that shove the correct bytes to the service, and static-linked code to open a socket to the service (and don't complain that sockets are slow, FIX THEM! Also try to design interfaces where return values are not needed all the time, like OpenGL, so that synchronization is not needed and batch transfers can be done).
I'm surprised that 3a) & 3b) are considered illegal - surely Be Inc can ship GNU Emacs (with source) with BeOS. Sun are going to ship Eazel with Solaris, and that's GPL, isn't it?