Slashdot Mirror
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.
Bruce
Bruce Perens.
# 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 Open Source Definition disallows this sort of license clause. Look at the part concerning "fields of endeavor". When I wrote that part in, I was thinking about people who might want to prohibit use of their software by abortion clinics, or by anti-abortion protesters. The Berkeley SPICE software actually prohibited use by the police of South Africa, and that provision remained in the license long after Apartheid had ended. So, I decided that this sort of license provision wasn't really a good idea.
Thanks
Bruce
Bruce Perens.
"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.
Thanks
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.
The more interesting question is how do you define "Kill people" for example if the US Army used a linux box as a mail server is it being used to kill people? I would say no.
I'm ignoring the moral issues of when is it moraly acceptable to kill someone and when is it not.
The cure of the ills of Democracy is more Democracy.
Erlang Developer and podcaster
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.
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
Thanks
Bruce
Bruce Perens.
Sorry but your point starts with a seriously erroneous assumption. You cannot compare software and physical objects. A piece of software is much more abstract and universal than any possible physical object. I can use one and the same algorithm in a sound app, a video app, on the processement of an image of a star or on the electronic eye of the robot fixing the door to your future new car. So here we get a serious problem. An algorithm, by itself, is a combination of math and logic, something very near to a formula. In its own nature it is useless. I cannot pick an algorithm and do something directly from it. Now if I apply it that's another question. i can use it to produce a combination of commands that come into a more concrete result. However here we also fall in one problem. Do you click mice? How do mice react on it? Click, click?
The problem is that software is, by itself, abstraction. And today, most of what it produces is also an abstraction, that only we are capable to understand. This whole evergrowing pyramid with a weight of air is the base for what software should be the most opened possible. Closing a critical door of development or claiming fees for a particular algorithm may stop the development of a critical sector per se. And we are still monkeys here. We just came out of the trees and started building the first wheel. If we are going to hamper the paths of development, we may stop in such a creative swamp that things will smell worser than a Middle Age street.
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.
Thanks
Bruce
Bruce Perens.
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
Fortunately the QPL is still applicable, too.
But the embedded version is not dual licensed under the QPL. This is a serious mistake on Trolltech's part. Konqueror was just ported to work with Qt/Embedded, and it's cool! But it is ILLEGAL to port Kicker or KWin over. Kicker and KWin are under the BSD license. They cannot link to a GPL library. I have written a Qt application that would be perfect on a palmtop, but it cannot use Qt/Embedded since it is under the BSD license.
A Government Is a Body of People, Usually Notably Ungoverned
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").
Supreme Lord High Commander of the Interstellar Task Force for the Eradication of Stupidity
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").
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").
No, there is a "direction" to compatibility. You can link a GPL application to a BSD library, but you cannot do the reverse. The argument that RMS makes is that someone could write a BSD wrapper for a GPL library, then link a proprietary application to the BSD library, thus circumventing the GPL.
A Government Is a Body of People, Usually Notably Ungoverned
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.
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...
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
In war it is generaly considered alright to shoot at other soldiers and military targets, but not civilians.
The cure of the ills of Democracy is more Democracy.
Erlang Developer and podcaster
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?
Yep, they could do that. There's no way to prevent this and be OSD-compliant (if you care about that), because the OSD requires the license to allow users to make any change to the code.
Since each Java class is essentially a shared library of its own, I find the LGPL's definition of a library a little vague. That's why I prefer the MPL, since both the MPL and Java are designed around the unit of an individual file.
A common misconception. Only the author of a work is allowed to change the copyright or licensing.
What you CAN do with a BSD program is to wrap it with a GPL license. But any recipient has full legal authority to remove the "wrapper" from all BSD parts. Because of this, wrapping a bare BSD application with the GPL is pointless. It does serve a purpose, however, when you wish to combine a BSD module with a GPLd module.
In reference to a Qt/Embedded version of Kicker, the licenses are in conflict. The BSD license gives the users many permissions that the GPL does not. You can indeed by sued by Trolltech for exercising the rights given you by the Kicker authors.
The BSD license is considered compatible with the GPL because you can include BSD code within GPL code, and distribute the whole under the GPL. But the reverse is not allowed. You cannot include GPL code within BSD code and distribute the whole under the BSD license. You would have to remove the GPL code first. And since Qt/Embedded is GPL, you could not distribute Kicker under the the author's own license without first "removing" Qt/Embedded.
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.
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
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).