Talk:GNU General Public License/Archive 4

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Archive 6

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

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 [1]. 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)

"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

GPLv2 vs GPLv3 debate

I didn't add these links[2][3] 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)

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)

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)

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

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

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)

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)

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)

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.

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)

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