Talk:GNU General Public License

From Wikipedia, the free encyclopedia

This is the talk page for discussing improvements to the GNU General Public License article.
Article policies
Archives: 1, 2, 3
Free software Portal
This article is part of WikiProject Free Software, an effort to create, expand, organize, and improve free software-related articles.
B rated as B-Class on the assessment scale
Top rated as top-importance on the assessment scale
To-do list for GNU General Public License: edit · history · watch · refresh
Archive
Archives
  1. /Archive 1: Feb 2003 - Apr 2004
  2. /Archive 2: Jul 2004 - Jul 2005
  3. /Archive 3: Jul 2005 - Jun 2006


Contents

[edit] “Can Technical Tricks Circumvent the GPL” link

The old link to a news post by Stallman was really to an archived mailing list posting of somebody quoting him. I changed the link to point to the original posting itself in the Dejanews Google Groups archive. User:Gronky changed it back, calling the old link “canonical”. I disagree; the original article appears to have been a usenet post, and as such the most canonical link is to a archive of usenet, such as Google Groups. --193.11.177.2 04:45, 4 July 2006 (UTC)

You're right, sorry about that, I missed that detail. Gronky 09:48, 4 July 2006 (UTC)

[edit] Reversion of Red Hat comment

I have removed the following text from the article:

The ability of a publisher to limit redistribution was called into question by the license for Red Hat Enterprise Linux (RHEL). This RHEL license requires a user to pay for every system on which they install any part of RHEL, even though many components of RHEL are distributed under the terms of the GPL [2]. This has led to questions whether the RHEL license violates the GPL.

Firstly, it is completely uncited. Secondly, it is misleading; Google can indeed find some people asking the question, but I can't find any examples that aren't immediately followed by someone else explaining that no, the Red Hat license does not violate the GPL.

Note that the "pay for every installation" clause is part of the support subscription contract. There is nothing in the GPL that says you cannot charge people to support your software. In fact, the FSF is quite explicit that they completely approve of this business model and see it as one of the valid ways for a software company to make money. The software license, meanwhile, contains the following text:

With the exception of certain image files identified in Section 2 below, the license terms for the components permit Client to copy, modify, and redistribute the component, in both source code and binary code forms. This agreement does not limit Client's rights under, or grant Client rights that supersede, the license terms of any particular component.

Hmm, I'm not sure exactly how this license is supposed to restrict your rights under the GPL when it contains a clause that explictly affirms those rights.

Of course, I'm not a lawyer (or a Red Hat employee), so take my opinions with the usual pinch of salt, but I see no compelling reason to keep this comment in the article, as it misleadingly suggests that there is a controversy where there is, in fact, none. — Haeleth Talk 11:11, 8 July 2006 (UTC)

Haeleth is correct. I added the text from my memory of the discussion, and then hoped I or someone else could find the citation. I remember there being a much more drawn out discussion on some newsgroups and mailing lists, but I haven't been able to find a citeable source.
As for the validitity of the original controversy, it centered around Section 5 the RHEL service agreement, titled "Reporting and Inspection". This section states that:
  • Users must report all Installed Systems (Section 3 defines Installed Systems as systems running RHEL Software or any part of it).
  • Red Hat had the right to inspect the user's location to verify the number of Installed Systems.
  • If Red Hat found Installed Systems that were not coverered by a RHEL license agreement, Red Hat could bill the user for those additional systems.
That seems to be saying that if I take RHEL and install it on another one of my systems, I have to pay Red Hat for an additionl RHEL license. That seemed a violation of the GPL, and to contradict the later clause reaffirming the user's rights under the GPL.
However, after rereading the license, I see that it says that a user who installs RHEL on additional systems only has to pay Red Hat for any Services provided for that systems, such as technical support and access to the Red Hat Network software subscritption services. So, if I install RHEL Software on another system, but do not use the RHEL Services, it appears I don't owe Red Hat anything. That is consistent with your analysis, and I agree that it seems compliant with the GPL.
I expect much of the controversy also faded because those who wanted a free version of RHEL soon had other options, in the form of Fedora Linux from Red Hat or various RHEL clones, such as CentOS. These provided nearly the same software as RHEL and clearly did not require any payment to Red Hat.
-- Seitz 18:06, 8 July 2006 (UTC)
As an aside, re-reading my comment, I realise it may have come across as dismissive of your edit. Please let me assure you that I did not intend that.
After doing a little more reading myself, there seems to be more controversy than I initially thought; there isn't a controversy now, in that there is a consensus that everything's OK, but there do seem to be a lot of individuals who run into the Red Hat license and have a WTF moment. So it might, in fact, be useful to work something in to the article; at the very least, if we can find some of those extensive discussions you mention (and the archives must be out there somewhere!), then there should be some good sources to cite on the subject of the support-contract business model. (I'm thinking along the lines of replacing the "myths" bit with a section on GPL-related business models: refactoring the stuff about Trolltech and MySQL, and adding a paragraph on Red Hat-style support-driven businesses. This would all be very relevant to that.) — Haeleth Talk 21:03, 8 July 2006 (UTC)

[edit] "Opponent"

This article fail to make the distinction from criticism ( critics ) and Opponent , very few GPL user and developper regard the use and usage of there license as a problem , the Opponent of the GPL and free software on the other end always try to make it look bad or associate it with some qualification that is normally use to convey a sense of bad behavior or unwanted quality.

Microsoft is not a critique of the GPL , it dont use it and dont contribute to it and oppose it directly and often

lie about its quality.

reference :

Bill Gates : http://www.theregister.co.uk/2002/04/22/gates_gpl_will_eat_your/ http://news.com.com/2100-1001-268667.html

Craig Mundie, Microsoft Senior Vice President :

http://www.microsoft.com/presspass/exec/craig/05-03sharedsource.mspx

Microsoft CEO Steve Ballmer :

http://www.theregister.co.uk/2001/06/02/ballmer_linux_is_a_cancer/ http://www.wgz.org/chromatic/essays/BallmerLying.html http://www.adti.net/samizdat/msft.on.linux.html

The Open Source Advocate , who are constantly arguing that Open Source is better then Free software :

Eric Steven Raymond , aka ESR , The former president of the Open Source Initiative

http://www.onlamp.com/pub/a/onlamp/2005/06/30/esr_interview.html

BSD's

The BSD After 36 years of failure due to there own hubris and unrealistic views are today attacking and attaching themself to the GPL and GNU/Linux.

They oppose the GPL because it protect the freedom it give , unlike them who got taken over by the Traitors who closed everything.

This is why I suggest that the critics of Opponent be placed under the category Opponent and that critics be left to those who support and use it. —Preceding unsigned comment added by Moulinneuf (talk • contribs) 23:55, 30 August 2006

[edit] GPLv2 vs GPLv3 debate

I didn't add these links[3][4] to the page to avoid the page growing into a link farm, but there's a lot of debate about GPLv2 vs GPLv3 and I think these describe many current concerns nicely. Should the matters be explained in the article? Or would that emphasize the current situation too much? -- Coffee2theorems | Talk 18:58, 26 September 2006 (UTC)

Linus et al have been complaining for the entire year, but none of it has been that notable to mention in the article. I'd like to see if it actually has any weight or substance to the situation. --69.165.73.238 19:37, 26 September 2006 (UTC)

[edit] Done the following

modified false viral criticism with addition of : Making a derivative work of a software program IS NOT SOMETHING THAT CAN HAPPEN BY ACCIDENT. You, the hypothetical developer of the derived work, receive the program accompanied by its unambiguous terms of use, and IT IS YOUR RESPONSIBILITY TO READ AND FULLY UNDERSTAND THOSE TERMS. If you do not, then that is your fault, and ignorance of the law does not excuse its transgression. linking to this text : http://www.metastatic.org/text/the-gpl-is-not-viral.html Thanks. —Preceding unsigned comment added by 66.130.66.19 (talk • contribs) 14:11, 10 October 2006

That language might be at home in a discussion forum, but here it is inappropriate and POV. Reverted. However, I changed word "complaint" to "label" to better convey the sense of denigration that the users of the term usually mean to imply. --193.11.177.69 19:56, 10 October 2006 (UTC)
Yeah, that little polemic of mine really doesn't belong here. I think the point is correct, but it's a strong opinion, and isn't worded well for Wikipedia. Cheers. Casey Marshall 06:36, 2 August 2007 (UTC)

[edit] Redistributing modfied code under the same name

I read in the preamble: "If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations."

Is this a part of the license or not, since its the preamble? Is someone, modifying and passing on without changing the name or clearly indicating that there is a modification, violating the GPL? tokyoahead 05:26, 18 October 2006 (UTC)

The preamble is not legally binding, since it is not part of the list of terms and conditions. However, this is covered within the terms and conditions themselves in section 2(a):

You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

Therefore, if someone modifies the source code and distributes it without prominent notices stating that fact, they are in violation of the GPL. In practice, this usually means adding a comment at the start of the file that simply says something like "// Modified by Joe Bloggs, 1st April 2002, to fix compilation on Solaris" or whatever.
How this applies to binary distributions isn't immediately obvious to me. It would probably be sensible to include a notice in the documentation - it may or may not be required, but it has obvious pragmatic advantages (e.g. people will know who to go to for the source code).
What there certainly isn't is any requirement to change the program's name. Some licenses do have this requirement - the LaTeX license does - but the GNU GPL doesn't. Again, there are advantages to it if you have changed the way the program behaves significantly, but if all you've done is ported it to a different platform, there's unlikely to be any reason to change the name.
Note that I'm not a lawyer and this is not legal advice. If you're in any serious doubt, you have three options: consult a lawyer, contact the FSF and ask them what the license is intended to require, or contact the author of the GPL'd software in question and ask them what form of notice they would consider adequate. — Haeleth Talk 10:28, 18 October 2006 (UTC)
Yeah, that sounds about right. So far as I know, any issues with naming would fall under trademark laws which the GPL doesn't address at all (AFAIK). --Gwern (contribs) 18:03, 18 October 2006 (UTC)

[edit] GPL criticism

From the article:

Critics of the GPL often describe it as being "viral", based on the GPL terms that all derived works must in turn be licensed under the GPL. Since the definition of "derived work" is commonly interpreted to include software containing GPLed code or dynamically linking to GPLed libraries (see above), the "virus" label comes from the view that the GPL forces its terms onto all other software whose authors choose to add GPLed code to their own. [citation needed] This is part of a philosophical difference between the GPL and permissive free software licenses such as the BSD-style licenses, which put fewer restrictions on derived works. While proponents of the GPL believe that free software should ensure that its freedoms are preserved in derivative works, others believe that free software should give its users the maximum freedom to redistribute it as they wish.

Where is the basis for this paragraph? Where is there a reference that "critics" of the GPL "often" describe it as being viral, and that they do so "based on the GPL terms that all derived works must in turn be licensed under the GPL"? Where is the reference as to the origin of the virus label? This paragraph is crap, and it's unreferenced, so I removed it. -anon —Preceding unsigned comment added by 75.202.233.125 (talk • contribs) 08:02, 20 October 2006

It's sourced and amended to reflect that source. All praise research. :) Hiding Talk 12:11, 20 October 2006 (UTC)
Much better. Do you mind if I remove the second sentence now? Or do you think we should work that into something which can reasonably be sourced? -anon —Preceding unsigned comment added by 75.202.233.125 (talk • contribs) 08:20, 20 October 2006
I see that as backed up by the source, to be honest Anthony. Hiding Talk 12:24, 20 October 2006 (UTC)

[edit] a deletion in criticism

Just got rid of this: "This can include licenses which disallow reproduction of source or the binaries but allow free modification for personal or corporate use. One such example of a license of that variety is the Open Public License"

Whose inaccuracy was pointed out in the Very Next Sentence. Moreover it seems to be useless spam. —Preceding unsigned comment added by 68.215.209.95 (talk • contribs) 16:39, 25 October 2006

[edit] GPL criticism paragraph removed

This new paragraph which I added to the article was removed considered "vandalism". Why is it considered vandalism when it includes valid cites to valid GPL criticisms? Maybe the heading "The GPL as a restrictive license" was not appropriate? Can the paragraph be improved to not be considered "unconstructive"? Thanks. 83.37.6.160

Some editors confuse "original research" with "vandalism" ... I'd say it was because you did not have "credible" sources. To quote WP:VERIFY:

Anyone can create a website or pay to have a book published, then claim to be an expert in a certain field. For that reason, self-published books, personal websites, and blogs are largely not acceptable as sources.

Or they may have felt that the sources did nor represent a neutral POV ... can't say I really disagree with their decision, but I'd have used a different reason. --72.75.107.168 05:58, 21 November 2006 (UTC)
Just for the record, sources have to be credible and reliable, but they don't need to have a neutral POV. Their use in the article, of course, has to be neutral. RossPatterson 15:03, 21 November 2006 (UTC)

[edit] GPL vs. BSD, I disagree

While proponents of the GPL believe that free software should ensure that its freedoms are preserved in derivative works". I agree with that. It continues: "others believe that free software should give its users the maximum freedom to redistribute it as they wish.

The seccond part is actually also an argument for GPL (read it again). GPL gives the users the maximum freedom to redistribute the software as they wish (or not to distribute the software if they don't want to). This part should be rephrased to reflect that others [not proponents of GPL] believe that free software should allow distributors and developers to distribute the software and/or derived work of the free software as non free software (i.e without the source and/or with a proprietary EULA) as they wish (i.e that they [developers, companies and distributors] should be free to restrict their end users, should they want to). Anyhow, the second part of the sentence is not correct because it also fit GPL. Kricke 20:27, 5 January 2007 (UTC)

The 2nd part of that sentence is true as it stands, and here’s the reasoning behind it. If you take GPL software and make modifications to it, you are legally bound by a license that restricts what you, the developer of this modified version, can do as far as redistribution is concerned. In effect, by accepting the GPL license in order to redistribute modifications, you are giving up some of your rights. Specifically, you are giving up the right to redistribute the source code (or compiled binary) in any way you see fit. The 2nd part of the sentence is saying some believe that free software should not include such restrictions. Not including the restrictions means more freedom for the author of the changes and less freedom for those receiving the redistributed works (the users in most cases.) --Pekster 02:19, 8 January 2007 (UTC)
What I basically don't agree with is that the person (or entity) that redistribute free software with additional restrictions to it (e.g. with a new EULA) classify as a user. If a user redistribute software, it is to his/her "neighbor", which is not possible if someone has made the free software unfree before it reached the user. Therefor, some "unrestrictive" free licenses does not "give its users the maximum freedom to redistribute it as they wish" (the user of the previously free software that someone made unfree and therefor unable to give a copy of it to her neighbor). Kricke 13:51, 12 January 2007 (UTC)
Addendum: "others believe that free software should give its users the maximum freedom to redistribute it as they wish." should be rephrased to something like "others believe that free software should give its redistributors the maximum freedom to redistribute it as they wish (e.g release derivative works as propriety, non free, software if they want to)". Kricke 13:57, 12 January 2007 (UTC)

[edit] Erroneous statements in "Criticism"

In contrast with proprietary software and their end-user licenses (EULA), the GPL makes offering the source code a necessary obligation.

As clarified elsewhere in the article, redistribution is the only scenerio that necessitates offering source code. EULAs (which are a shaky comparison to begin with, as GPL is a copyright license and EULAs are contracts), as a general rule, do not allow redistribution in any form. The language here implies that GPL makes requirements that the EULAs do not, but a close analysis does not bear this out. It is hard for me to see how allowing redisribution under certain conditions (one of which is the presence of source) is more restrictive than not allowing it at all. If you were to use GPL code only in ways that are allowed by your typical EULA, you would never run into the requirement to distribute source, as you would never do any distribution.

The license weakens the ability to grant end-users the right to copy or use the software for a limited number of computers.

This statement is false on its face. Every "end-user" (or any user whatever) who recieves code under GPL can use that code for any purpose he chooses. As GPL is a copyright license and not a contract, it does not even have the ability to restrict the manner of use of the code (in the language of copyright, distribution is something markedly distinct from use). One use that is allowed under GPL (as are all other uses) is copying the software for "a limited number of computers" (in fact, however many computers might be under your possession). Consider Google. Google internally modifies GPL software in order to suit their specific needs. Under GPL, it is perfectly within their right to install that software on however many computers might be under their possession, and this does not trigger any specific obligation under the GPL. Installing software on multiple computers belonging to the same entity is not distribution (as copyright understands the term), and as such the terms of the GPL do not even come into play.

There are also no protections in the GPL from activities normally permitted by copyright laws, such as reverse engineering. Such agreements can be made between parties, but a party can avoid such agreements by receiving the GPL work elsewhere.

Not only does GPL not "protect" one from reverse engineering, it is incompatible with any restrictions on such activity. No agreement can be made between a party distributing GPL code and a party receiving it that restricts the uses to which the recipient can put the software (including the use of reverse engineering). Any distribution that includes such terms is facially incompatible with the GPL, so saying that such agreements can be made in such a flippant way has a real potential of misleading anyone who reads this as to his obligations under GPL.

Pursuant to the above reasons, I will remove the cited claims from the article. They could conceivably be added back if it were explained (as I have done above) that those claims materially misrepresent the content of the GPL. It is my opinion that adding this discussion to the article proper would clutter it unneccesarily. As these are not valid criticisms, if they were to be added back to the article, it would have to be in the context of clarifying why these things are not the case and not proffering them as legitimate criticism. 209.30.170.226 22:54, 8 January 2007 (UTC)

[edit] Rethinking "common misconceptions"

Hei, where is the section? Can't find it anymore! It seems like Jimmi Hugh deleted that part. I think his deletion is not well reasoned, as it contains additional information, if one does not want read the GPL. 136.159.65.84 (talk) 23:44, 21 February 2008 (UTC)sstein

The common misconceptions section would be clearer if it was written assertively rather than in double-negatives. So instead of saying "Common misconception: The world is flat, actually it is round", it would be better if we said "Little known fact: The world is round; some people incorrectly think it is flat". Can anyone offer a better title than "Little known fact"? Other comments? Gronky 14:44, 1 February 2007 (UTC)

The formatting could better distinguish between the erroneous belief and its correction - quotes or italicizing seem like a good idea. --Gwern (contribs) 15:03 1 February 2007 (GMT)
Little known fact" won't work - it implies the falsehood is *generally* believed which is not true. Common misconception is better. If we can improve on that great, but I can't think of how at the moment. Arker 21:08, 1 February 2007 (UTC)
OK, Practical examples doesn't capture it either. I actually think Common misconceptions really sums it up nicely, because that's exactly what these are. They're errors of fact, widely believed but not dominantly, frequently repeated by those who either don't understand the GPL or are campaigning against it. Unfortunately, calling it that would require listing the falsehood, not the truth, and I can see why you wouldn't want to describe each entry that way. RossPatterson 23:40, 6 February 2007 (UTC)
Other words I thought of were "clarifcations", "specifics", "What's allowed and what's prohibited" (too long, but it's a good idea for a broader scoped section). I'm not so happy with "practical examples" either, but I wanted to start working on it to see what ideas would come up. Gronky 12:48, 7 February 2007 (UTC)
I think we should be very careful to stay away from words like "clarifications" and "corrections." We are not be attempting to clarify the license or correct people's misconceptions, merely to point out that misconceptions exist, say what they are, and explain why the FSF or whoever think they are misconceptions—all appropriately cited, of course. At the moment there aren't any cites showing that these are in fact misconceptions that people hold—with all the commentary out there on the GPL this shouldn't be hard to find—or even that the are common. NicM 14:50, 7 July 2007 (UTC).
I find the current wording very misleading. Under a section heading "Common Misconceptions", there are three bold statements. The natural reading of this is that those statements are misconceptions, when in fact they are the opposite. As a first-time reader, I read the first paragraph several times trying to figure out how it was refuting the statement that "The GPL only requires you to distribute source code if you are distributing binary versions," before determining that it wasn't. I think it is important that either the section be renamed or the typical "misconception:... / fact:..." format be used. Darrellk 11:18, 7 July 2007 (UTC)
I think DarrellK is right. It's confusing and inaccurate to call this "common misconceptions" and then list a bunch of correctly conceived. I think that the section should ideally be rewritten and probably reformatted. I don't think the current list format is either particularly encyclopedic or effective. —mako๛ 13:41, 7 July 2007 (UTC)
Yeah, I agree with DarrellK too. It seems to me that the pre-"rethinking" version was better than what we have now, even given the "double-negatives" that Gronky originally set out to improve. RossPatterson 17:51, 7 July 2007 (UTC)
I came here to say the same thing - I read the "misconceptions" section and thought that the bolded lines were falsehoods, which really confused me. Instead of saying
  • The GPL only requires you to distribute source code if you are distributing binary versions
  • Anyone can charge for copies of software licensed under the GPL
  • Non-free software can be developed with tools licensed under the GPL
it should say something like
  • "If you use code licensed under the GPL, you have to release your program's source code no matter what."
  • "Software licensed under the GPL must be given away for free, it cannot be sold."
  • "Any software created with GPL tools must be released under the GPL."
This makes them true "misconceptions" and putting them in quotes makes it clearer that these are common (and false) statements, and not a list of facts.
The section is unclear, since selling GPL code could be a de-facto business "failure". I can sell my software for $1000, but no restrictions are made on the owner, so it could be redistributed for free: this is allowed by the GPL, leaving my for-charge software unsold, since there is a free-of-charge alternative.
Can this issue be clarified in the article? Sensei 12:07, 7 August 2007 (UTC)
From GNU.org:
If I distribute GPL'd software for a fee, am I required to also make it available to the public without a charge?
No. However, if someone pays your fee and gets a copy, the GPL gives them the freedom to release it to the public, with or without a fee. For example, someone could pay your fee, and then put her copy on a web site for the general public.

[edit] x264 MPEG-LA/GPL incompatibility

In the opening paragraph of the x264 page, it comments how there might be an incompatibility between the MPEG-LA license and GPL in jurisdictions that recognize software patents. Does anyone know what this incompatibility is? What does it have to do with? What sections of the licenses are incompatible? How are they incompatible? What needs to change before they are compatible? Does it matter that they are incompatible? Was the writer just making things up? What do these licenses have to do with one another? Should that statement even be on that page?

Those are just some of the questions I'd love to have answered about that statement. --MyOwnLittlWorld 02:23, 18 March 2007 (UTC)

I don't think the article needs to specifically answer the MPEG-LA patent question, but it does need to explain how the GPL responds to software patents, generally. --75.69.87.211 13:26, 19 March 2007 (UTC)
Agreed. —mako (talk•contribs) 21:06, 19 March 2007 (UTC)

[edit] "See Also" - can we split into sections?

I wanted to add a link to Affero General Public License as it (and its successor version 2) has the potential to close the "ASP loophole" in the GPL (through v3) that many developers gripe about. It struck me to split the see also section into GPL approved/compatible licenses, and "others", like the BSD. Informedbanker 15:45, 23 April 2007 (UTC) informedbanker 11:45 April 23, 2007 (EST)

There must be a better way to organise this information. If we're linking to free software license already, and providing sufficient context, then there shouldn't be any need to maintain a large list of see also links. Chris Cunningham 17:39, 23 April 2007 (UTC)

[edit] Copyright on derivatives

  1. Who owns the copyright to a derivative work?
  2. If Work B is derived from Work A, and Work C is derived from Work B, and Work C violates the GPL, does the copyright owner of Work A, as well as the copyright owner of Work B, have the right to sue the creator of Work C?

VanishingUser 03:57, 25 April 2007 (UTC)

For any code you write under GPL you own the copyright to that. (Similarly anything you write on Wikipedia you also own the copyright to, see WP:C.) GPL'd code can have many copyright holders. If you work for a company, you normally sign a waver to assign copyright to the company: this allows them to enforce their copyright more effectively.
On the second point, they can both sue. Realistically though they will ask C to fix the problems so that C releases their code under GPL. They can use the FSF's "GPL Compliance Lab" to do this for them. Legal action is possible, but won't normally happen unless discussion fails. --h2g2bob 04:13, 25 April 2007 (UTC)

[edit] Flawed Criticism Section

I think that the major problem why many BSD camp is against GPL is actually the fact that merely linking (not even modifying the library) would force the entire application license to be GPL. This is particularly the case in the Java world. Thus one cannot distribute GPL libraries along with the commercial or open/free programs that uses a non-GPL license. There is simply no way around the problem. People have no problem with LGPL in this case, in contrast.

This distinction between LGPL and GPL has been quite important. MySQL for instance, changed the license of MySQL JDBC driver license from LGPL to GPL for v3 driver, intentionally. This change basically bars open source applications not using GPL license from using the driver. For open source applications that have to stick to a particular open source license, there is simply no way around the problem. There is no loss to MySQL anyways since they don't get paid in this case. Of course, this approach also forces commercial applications to purchase the commercial license of the driver. In fact, this strategy has been quite popular. It is ironic, that GPL has been used as a way to force people to pay up, or not to use the software as the result, as opposed to be free. 71.105.96.173 18:32, 22 May 2007 (UTC)

The difference of opinion about licenses between the pro-BSD and pro-GPL camps is largely philosophical, just as are the differences between the Open Source and Free Software communities, and between the Free Software Foundation and commercial software vendors. In the BSD v. GPL case, it goes to the core of one's personal definition of "freedom". BSD advocates often describe the GPL's "freedoms" as "restrictions", because in the BSD community code is allowed to be used in just about any way one can think of. GPL advocates often describe the BSD license as "unfree" because it doesn't ensure that the rights granted are passed intact or extended to cover code changes. The two groups generally have different primary goals, and that's expressed in their choice of licenses.
To make a long story short, I guess I disagree with your suggestion that the Criticism section is flawed in some undefined manner. It seems to sum up the actual divide pretty well. RossPatterson 22:32, 22 May 2007 (UTC)
I think that you missed the point. The criticism said "GPL terms require that all modified versions of the software must in turn be licensed under the GPL." That is not the main criticism of GPL. I am saying that for LGPL, the modification only needs to be reveal for the part that is relevant to the library, which people has little objection. Second, merely linking GPL (say a GPL MySQL java JDBC driver) would force the entire software (say a generic front end to various databases) to be GPL, but for LGPL one can still use other license.
The result of GPL's restriction is that it forces softwares (even free ones that not using GPL) to come up solutions that ultimately makes it difficult for the end user. In the above example, the generic front end to various databases would not be able to distribute with the GPL driver. The users would have to follow an instruction to download and install by themselves. This creates a burden for the end user. 71.105.110.181 12:52, 29 May 2007 (UTC)
Well, everyone's entitled to their opinion, you as well as I. But neither of us are entitled to voice our opinions in Wikipedia articles. If you can find published examples that support your opinion that the "main criticism of [the] GPL" is as you say (to be honest, I can't figure out what you say the main criticism is), go ahead and add it to the article. I lack the time at the moment to find citations that support my claim above, so I won't be adding it, at least not right now. RossPatterson 01:55, 30 May 2007 (UTC)
  • "In the above example, the generic front end to various databases would not be able to distribute with the GPL driver". "not able to distribute"!? Sorry, it would be impossible to distribute without making it GPL, which is not the same. The distributor is free to either make all her software GPL, or not include GPL code at all. Where's the problem? If all free software were licensed under the LGPL, FS could never beat commercial software, except by price (because any company could "steal" FS and include it in a proprietary bundle). Licensing under the GPL means that in the long run proprietary software will fall behind the FS technically, because they will not be able to "steal" the efforts of the FS community (and it's more obvious day by day that they can not keep up reproducing the work of the FS community). Guess which license ensures a more free future for software? To know more about it, read GPL vs LGPL at gnu.org. — isilanes (talk|contribs) 17:00, 29 May 2007 (UTC)
This page and the BSD license page seems to be written by GPL people. I feels that it is appropriate, particularly given the fact the criticism section is totally lacking in substance, to add FreeBSD's criticism on GPL. I felt funny since quoting the CEO from the company many OSS programmers despise only seem to give GPL more sympathy. That's a stealthy way of getting around true criticisms. Coconut99 99 23:13, 5 June 2007 (UTC)
That FreeBSD page should probably be mentioned alright, but it's pretty nonsensicle and those statements are neither backed up by reason or evidence. Gronky 10:21, 6 June 2007 (UTC)

[edit] Logo Author

I skipped through this the article and some other GNU related but I could not find a word on the artist that has designed the GNU Logo. Did I got blind or there are no info on it? On the Image page I found as Author "Aurelio A. Heckert" but I guest he is the author of the file and not the designer of the logo. Should we not have some info on him? --192.33.238.6 15:10, 4 June 2007 (UTC)

You're right, Wikipedia should have this info, but it should be on the GNU or GNU project page(s), not this one. Gronky 13:41, 5 June 2007 (UTC)

[edit] Stuff I removed from the criticisms section

The criticisms section contained a load of nonsense, which was, of course, not supported by any references. I removed three or so paragraphs, here's the last version before I did so: [5]. Gronky 10:04, 6 June 2007 (UTC)

[edit] I've deadheaded the external links section

The external links section had turned into a sprawl, so I've deleted most of them. Many of the links that I deleted were interesting though, and would make good references for parts of this article, so do take a look at the last version of the page that had all those links: [6]. Gronky 10:29, 6 June 2007 (UTC)

[edit] some rewriting

Reading this article earlier today, I saw two problems: (1) The lead was pov-ish, and dominated by boring "rah-rah" statistics about how popular the GPL is. (2) The History section (as noted in the template at the top) was a timeline of versions of the GPL, rather than a discussion of the history of the license in the sense of its importance to a social movement. The result of all this was that you could read several screenfuls of the article without ever finding out anything that would be of interest to the typical person. To try to fix this, I've rewritten the lead to be more npov, and to say more about the social significance of the license. I've also renamed the History section to Versions, and inserted a new History section above it, with a discussion about the social history, as opposed to the version history.--76.81.164.27 18:40, 11 June 2007 (UTC)

The last sentence on version 3, "in the aftermath of the Novell-Microsoft agreement, Linux kernel developer Linus Torvalds expressed interest in reconsidering GPLv3" is not or is no longer accurate. It would be more accurate to say that Linus has expressed that he is satisfied with the GPL 2 because it is a superior license to the GPL 3. See here, here, here here, and here. I don't want to get into a pissing match with the many free-bies here, but with a FSF board member trolling the LKML, I think Linus has dropped the diplomacy. Wasn't his strong suit, anyway. But the point is, Linus has made it very clear that he is not open to GPL 3. 216.175.85.40 07:22, 26 August 2007 (UTC)

[edit] owner?

If the resulting software is kept only for use by the modifier, 
no disclosure of source code is required.
The GPL is automatically revoked upon any violation of its terms,
but copyright owners of works licensed with the GPL are free to 
negotiate alternate terms with authors of derived works

But who's the owner?. Because some GNU projects are the works of a community, or then "first to create the projects" can negotiate the works of others?.—Preceding unsigned comment added by 200.73.30.108 (talk • contribs) 15:45, 5 July 2007

The "owner" is a matter of law, not of license (or logic, for that matter). Under copyright law, nothing is "the work[] of a community", but rather the individual works of the members of the communities. This question is exactly the reason that official projects of the Free Software Foundation (e.g., GCC, Emacs) require that contributors sign an agreement assigning their copyright interests to the FSF. That way there is no question under law of who the owner is, or of who has the right to compel licensees to comply with the GPL terms. The undisputed owner in such projects is the FSF. As a counter example, Linus Torvalds has never required copyright assignment for code contributed to the Linux kernel, and the "ownership" of code within the kernel is an oft-discussed question. Indeed, when GPL3 was first proposed, several prominent Linux community members noted that it was probably impossible to change the kernel license simply because it would be so difficult to identify the various contributors who own the copyrights. RossPatterson 23:34, 5 July 2007 (UTC)

[edit] GPL in closed source projects.

I would like to use #ziplib licensed under GPL for my closed source project. It says some legal terms which led me to think I'm not allowed to use it, and then the bottom line said otherwise:

Bottom line - In plain English this means you can use this library in commercial closed-source applications.

I went here to verify if this was the case, and I'm still not sure. Can I use GPL software in non-GPL, closed source projects or can't I?

Ripper234 12:41, 14 July 2007 (UTC)

No, you can't use GPL software in closed source applications. But SharpZipLib is a special case — its authors offer you an exception to that rule, similar in concept and in text to the exception for the GNU Classpath implementation of the standard Java library. If you don't trust their "Bottom line" statement, then you really need to had the entire license off to your lawyer for a reliable opinion on the use of SharpZipLib. But regardless of how that turns out, the exception doesn't apply to software that is licensed solely under the GPL. RossPatterson 15:19, 14 July 2007 (UTC)

[edit] GPLv3 clarification needed

The article claims that the GPLv3 offers better compatibility to other licenses but GPLv3 text looks rather more restrictive than the GPLv2. If no lawyer explains why there should be better compatibility, this claim should be removed from wikipedia

I don't know if it is a relevant source, since it's not third-party (i.e., it's published by the authors of GPLv3), but the rationale documents from the GPLv3 legislative history talk at great length about how the additional compatibility works, and those rationale documents were written primarily by SFLC attorney, Richard Fontana. Frankly, I don't think there are any attorneys who are particularly qualified to make the assessment anyway, even if SFLC is a biased party since they are FSF's attorneys. -- bkuhn 21:54, 16 August 2007 (UTC)

[edit] On dynamic linking

Without really discussing the legal implications, as someone well-versed in the possible technicalities but not the legalities, I would like to just note here that it is possible for software to dynamically link to libraries that weren't even written at the moment the software was released, even if the original developers didn't intend for this to happen. What libraries a program dynamically links to is beyond the control of the developer. Shinobu (talk) 04:14, 6 December 2007 (UTC)

Absolutely agree. Also, an application can be written to use a Java interface without being aware of any particular implementation of that interface. It's possible that the user who causes that application to run with a GPL'd implementation of that interface is creating a "derived work" (a term which GPLv3 doesn't actually use, by the way), but since what they have created is transient and unlikely to be distributed, it hardly matters.

The GPL FAQ makes a distinction between dynamic linking and fork/exec - they say that one creates a derivative work and the other doesn't. Can anyone tell me what words in the actual license could possibly lead one to this conclusion? Mhkay (talk) 18:20, 14 January 2008 (UTC)

[edit] "In court" section needs a reorg

At the moment it's a not-terribly-useful timeline covering people both using and attacking the GPL in a variety of jurisdictions. Is there some sensible and useful way to sort this out? I've also added a note on BusyBox, the refs for which are in that article - David Gerard (talk) 23:34, 22 December 2007 (UTC)

[edit] Does the license encourage supplying a visible notice to the original authors?

For example, if you install a CMS that uses this license, does the license encourage you to put a footer link to the makers of the CMS? -79.182.0.62 (talk) 11:40, 10 January 2008 (UTC)

No. See SugarCRM for an example of an outcry caused by a license which did do this. Chris Cunningham (talk) 11:57, 10 January 2008 (UTC)
This article indeed mentions there was an outcry but doesn't attribute it to having to put a link in sites' footers. -79.182.0.62 (talk) 18:25, 12 January 2008 (UTC)

[edit] The license in CMS

How does the license limit clients if they install a CMS that use it? We've already established above that they won't have to put a link in the footer for the original authors. So modifications would have to be GPL too, but is there anything else they can't they do, that they could if the CMS was completely public domain? -79.182.0.62 (talk) 18:25, 12 January 2008 (UTC)

It doesn't limit them at all, beyond a prominent copyright / license notice, so long as they don't actually allow clients to download the server-side code they're using. They can modify at as they wish. Chris Cunningham (talk) 18:43, 12 January 2008 (UTC)
But we've established above they don't have to put a copyright in the site itself. -79.182.0.62 (talk) 20:31, 12 January 2008 (UTC)
No, we haven't. There's no requirement to stick the URLs of the original authors in some "footer" of a web app; there is a requirement to post a prominent copyright notice, but this need not be some banner ad.
I'd seriously encourage you to just Google any further questions regarding the licence's terms. Talk pages are not general discussion forums for the subject. Chris Cunningham (talk) 00:39, 13 January 2008 (UTC)
Well, just last question - what is "prominent" if not a link? -79.182.0.62 (talk) 12:00, 13 January 2008 (UTC)
There's no given definition. I don't believe anyone has yet been legally challenged on the issue. Chris Cunningham (talk) 12:38, 13 January 2008 (UTC)
And they won't ever be, because they are not distributing the software. The license requires a copyright notice whenever someone distributes the software, not when they use it. —Preceding unsigned comment added by 66.102.196.44 (talk) 06:21, 8 March 2008 (UTC)

[edit] Software as a service and GPL

Should this be mentioned or explained? (http://en.wikipedia.org/wiki/Software_as_a_Service)

[edit] GPL can be more "business friendly" than BSD

The case of Quake3 (that may improve the article if incorporated in some form or another): Quake3 is now GPL'ed. However, it can also be bought (as source) to be closed for commercial purposes. At the same time, there is no BSD (or similar) version. One has to either use GPL or pay to have a new game. i.e. BSD in that case would be less "business friendly". In general at least in that case one can clearly say Quake3 is more profitable for ID software being released in GPL (+closed dual licenced) rather than in BSD (or even alongside BSD). --Leladax (talk) 22:34, 25 February 2008 (UTC)

[edit] aggregation vs combination

It's not really made clear enough in the article, but the GPL allows for linkage with closed-source applications under certain circumstances. To put it briefly, GPL allows aggregation but not combination. As an example, Say I have a closed-source application that as part of its duties needs to read in data of different file-types. To accomodate this, I have provided a generic plugin interface to allow any file-type that has a plugin available to be used. As a separate component, I supply a plugin that makes use of GNU readline for some reason or another. readline is GPL'd, which means that the plugin needs to be released with a GPL-compatible license. The program itself can remain closed source, however. This is because the plugin architecture makes no assumptions about what the plugin has to do internally. In fact, since plugins can be supplied by anyone, as the author of the original program I am unable to make any guarantees that no one will do this. This execution model is essentially the same as if I call an external executable from a shell script; Utilizing gpl'd programs inside of a shell-script doesn't mean you have to gpl your shell-script. —Preceding unsigned comment added by 66.102.196.44 (talk) 06:11, 8 March 2008 (UTC)