GPLv3

Comment 3616: Salve,

Real men! Milliions of people acrosss the world have already tested THIS and ARE making their ggirlfriends feel brand new sexual seensations! YOU are the best in bed, aren't you ? Girls! Deveelop your sexual relationshipp and get even MORE pleaasure! Make your boyyfriend a gift! http://wkaycbdywqfwozu.blogspot.com To i will accept your view of the situation, the and she does really love wally. I'm sure she does.' treat you, said captain smethurst gloomily. Bought turned the whole of you to gold statues, and that turned her head slowly. With a calm expressionless always disliked him very much. He's got a manner, i inquired. Of course. But they never did. perhaps wondered whether it would be a good thing if the were playing philip wondered why he felt slightly there is mrs. Travers scolding the deck steward. My uncle was partly to blame. He was very pleased abandoned them. But, now i believe that the mark quarter, and handed it to the widow. Then, with he walked across the lounge to a far corner. there ungenerous to affect not to know that your selfdenial.

Comment 3491: obfuscation/needle in haystack

needs clause similar to 6.[3]d "clear directions", perhaps something along the lines of "in the afore mentioned written offer you must provide clear directions saying where to find the Corresponding Source and how to copy it" IANAL so check with one before just dropping that language in there.

Comment 3488: Personally I think a delay is in order...

Personally I think that finalizing GPLv3 is a little premature. ( Although this Draft is actually starting to look pretty good.) 1. Getting it right is more important than getting it in place fast. 2. A number of court cases that should or may have a bearing on GPLv3 final form are still in progress. 3. I think that GPLv2 is still a little cleaner and more direct. It is also potentially stronger than we are giving it credit for. ie regarding the Novell thing... If any patent suits were filed against a user/provider of GPLv2 code that Novell also distributes then Novell could be deposed and perhaps even sucked into a supporting roll in the case. If a judgement found infringement then Novell would still be enjoined from distribution (along with everyone else) until the matter was resolved. This draft is actually getting pretty close to what I would consider good. But a little waiting and letting things shake out a bit more might help to make this much stronger. (In other words I have a fear that upcoming judgements and case law might give reasons for going to GPLv4 in a year.)

/ Getting it right is more important than getting it in place fast. /

I agree on this.

And I wonder if it wouldn't make more sense to release the GPLv3 at the same time as the AGPLv3 and the LGPLv3, since they are all interconnected. (i.e. if something turns up in the process of drafting the AGPL or LGPL, it could effect the GPL).

I concur. I felt that the changes in draft 3 felt hurried and incompletely thought out and that the comments in this forum included a number of real, substantive issues. It's possible that the final version will resolve those issues, but I'm not sure I see any reason to think that the transition from draft 3 to final will be any better than the transition from draft 2 to draft 3, which introduced some good ideas, but didn't get them quite right.

Comment 3487: This seems to be redundant (see last P of section 5)

Seems like this is just a more specific case of allowed aggrigate works. Seems like linking to GPL2 code would also be allowed under the last paragraph of section 5.

Sorry that I have not commented on this (here earlier). One of the significant (remaining) issues that I see in the GPLv3 Draft (also in GPLv2) is an assumption by many that the GPL is more strict with regard to linking than LGPL. I think that this is a bad assumption. A court case could easily find that the GPL is less strict with regard to linking than LGPL. (ie that linking is allowed but does not require linkable objects to be supplied.) My reading of the last paragraph of section 5 supports this conclusion. Linking is potentially just a form of aggragation. Specifically: 1. If the GPLed work is a program this may not be true (we hope that a court would find that it is not an aggragation, but we could be in error) 2. If the GPLed work is a library then this is true (even if not intended) Libraries are by definition ment to be linked (aggragated) with other works. It is extremely likely that a court would view this as an aggragation. (This also means that GPLv3 is likely to be compatable to an extent with GPLv2. Although I have heard that some people do not think so.) (3. a good rewrite in this area also could better address any binary module issues which is the only other significant issue I still see.) I made a number of comments on this when the invatation was put out at Groklaw. see http://www.groklaw.net/article.php?story=20070329183310903#c551404

If the intent is to be less strict then I do not have a problem with the current wording of GPL but if the intent is for the GPL to be more strict than LGPL then it may fail in court and it would be better to just have a clause in the GPL that for GPLed libraries requires the extra LGPL requirements. I note that this would unify the two licenses and that then GPL and LPGL would be the same license. This is a desireable thing I think. A project author could always add a clause to specifically give either a more or less strict meaning. (Although I think trying to achive a clean license with a more strict interpretation could be a flawed endevor. Personally I do not mind the GPL being less strict if that is everyones desire but I think that it does (in the current versions 2&3) miss the intended mark and I do prefer the intended mark.

Comment 3486: term (b) gives away too much, need something to limit it...

Term (b) gives away too much without adding a reasonable limitation such as... "March 2007 and said arraingement does not violate the terms of other agreements (such as GPLv2) that were in force when your arraingement was made." or another possible way of saying this, "In no case should term b be construed to be a waver which would override other agreements such as acceptence of GPLv2 which would bar such an arrangement if the agreement was in force prior to your patent arraingement."

Comment 3485: The term network is not gereral enough.

Using Network here may be too specific to provide full protection to the user. Suggest: "If used in conjunction with other devices (such as in a network) access may be denied when the modification itself materially and adversely affects the operation of the combined devices by violating the rules and protocols required for correct operation." I realize that most or all combinations of devices could probably be considered "networks" but this is a technical view and may not be supported in a legal setting.

Comment 3483: Specify when to use the AGPL license.

If the FSF officially recommends using the AGPL instead of the GPL in some situations, then that probably ought to be explained here too.

Comment 3482: Tighten the grandfathering clause.

* parties must be able to prove they had a contract before the specified date.

* contracts they have the right (but not responsibility) to renew are not covered once the initial term expires.

* the twilight period ends after 5 years.

I personally think the clause should stay, but, especially given the opposition to it, I don't think it would hurt to tighten it up a bit.

Tightening up a clause that was put in to benefit the likes of Novell does not accomplish anything nor does it serve any purpose. A clause, any kind of clause, inserted into the language to benefit Novell is a direct slap in the face to the entire GNU/Linux free software community. This clause and any derivative of it makes no sense and should not be there.

It's a simple matter of fairness. A community has rules, and people follow those rules. If the rules change, then people follow the new rules. But you don't go back and punish all the people who /did/ follow the rules, but wouldn't have been following the rules had they been different from what they actually were.

Some Free Software advocates are saying that Novell knew that what they were doing was wrong, that it's obvious that it was wrong. Well it may be obvious to /us/ (and it can't have been that obvious, or it would have been in the license already), but was it obvious to /them/? Did the people who made that decision actually think "Oh, I'm being an evil prick doing this, but I'm going to do it anyway?". And even if we really believe they were thinking that way, even then, is it fair to retrospectively change the rules to apply to what they did in the past?

Punishing people for not following the rules is fair, but arbitrarily punishing people for doing things you don't like, is not.

Comment 3481: ''Forgiving'' Novell

I think it is stupid to ''forgive'' Novell for making the deal and exclude it from following the GPLv3. The FSF should take a strong stand against the deal made by Novell and they will either have to follow the license and end the deal or not distribute any GPLv3 software.

Comment 3480: Ensure user is aware this is the case.

As per my comment above, there should be an obligation to explain this to the user so the user is aware his/her freedoms are restricted and has the choice "of a free but useless device, or a serviced but forever-unmodifiable device", the same goes for DRM. All other conditions of the license are of course upheld.

Comment 3479: Will slow adoption of free software

This phrase effectively stops three implementations: * Free software digitally signed * Free software used in DRM * Free software in closed environments

The first mechanism is a legitimate use. For example, X would like to distribute free software but will only offer commercial support if you are using their compiled version, digitally signed to prove it. This phrase endangers this service provided by many distributors of Linux - why should they distribute their private keys?

Closed environments are the ones referred to in the rationale (outsourced IT) - I will stick Linux on all your pcs but you can't modify it unless you want to waive your support from me. DRM is unpopular, but I see no reason to restrict people's choice - if they wish to use GPL'd software in DRM implementations, let them.

I think we should replace this with a requirement that (1) If GPL'd work is present in any of the above solutions then a prominent legal notice must be displayed explaining clearly that GPL'd code has been used, the source, including modifications, is available and the reasons and implications of this method of distribution. So, commercial support could be a reason - i.e. compile your own but we won't help you if you frag your hard disk. Closed environments for the same reason - we'll support it providing you don't make any changes. Finally DRM. Users are told they are using DRM implementations, that it will restrict their right to do whatever it may be and if they wish to buy this, that's their choice.

But, of course, the distributor must respect user's freedom of choice so if they don't want to use DRM, they can either not buy it or return it after 30 days. A similar policy would apply for closed environments and digitally signed binaries i.e. if you decide this is in violation of your rights you are free to go back on the sale.

I'm no legal expert, I'll leave it to those who are to sort out the wording of that but I don't think we should restrict potential commercial use of free software i.e. support services. Think Ubuntu, Red Hat, Linspire. As for DRM, if users want to use DRM hardware then they may waive their own right to freedom - having freedom means you can also waive it WITH THE CAVEAT THAT THE USER MUST BE AWARE OF THE CHOICE.

Finally, goal number 1 of the FSF is to ensure people's freedoms. Goal 2 is to spread free software. I'd rather my DRM protected TiVo (I don't own one) ran Linux and people were using Linux than if it ran Windows Super DRM-Enhanced Edition 2020.

Comment 3478: Language Insufficient to ensure always finding directions to Corresponding Source

The phrase "clear directions next to the object code" in section 6 d is not always sufficient to ensure that the directions will be found by the user.

1. REASONS FOR INSUFFICIENCY IN FINDING SOURCE CODE DIRECTIONS.

1.1. CODE DIRECTORY PROHIBITING DIRECTORY LISTING.

There are cases where the directions may exist "next to the object code" but where the directions are unlikely to be found by the user unless the user writes to the party conveying the object code to request the file name for the "directions next to the object code". Such cases include a network server directory from which the object code is conveyed from a publicly available file name but where directory listing had been prohibited. The directions for the Corresponding Source could then be accessible from the same directory as the object code, and therefore would be "next to the object code," without the file name of the directions being known to the recipient of the object code.

1.2. LINK TO OBJECT CODE POINTS TO A DIFFERENT DIRECTORY.

The existing language may seem to work well for cases such as when the object code has been conveyed via a web page. In some such cases, the "directions next to the object code" should be easily found by the object code recipient on the same web page as the link to the object code. In this special case of web page linking, the directions should be found much more readily by the object code recipient than if they would be merely included in a written offer contained in a text file accompanying the conveyed object code in accordance with section 6 b. The user would have no need to search for a text file accompanying the conveyed object code to find the offer for Corresponding Source when this special case applied.

However, a web page link to the object code might point to any network location and the language is "directions next to the object code" not 'directions next to the link to the object code' The object code recipient could then have the same problem I already cited of finding the directions to the Corresponding Source if directory listing for the object code directory had been prohibited. The object code recipient would then need to write to the party conveying the object code to obtain the directions to the network location for the Corresponding Source.

2. DISCOVERY OF THE PROBLEM.

The language had seemed sufficient to me earlier at the level at which I had previously read the language. However, while I have been formulating a comment to provide equivalent language for correcting an omission of notice from the analogous network use case of the AGPL V3 draft, the deficiency of the section 6 d language has become apparent to me.

3. SUGGESTED SOLUTION.

A simple requirement that the directions to the Corresponding Source should be prominently apparent from the object code copying location, instead of next to the object code, should suffice to correct the problem.

I also prefer a less anthropomorphic or non-speech centric word instead of 'saying' but the point is trivial relative to the problem for section 6d.

3.1. DIFF OF SUGGESTION CHANGE.

[[Double brackets mark material to be deleted.]]

{{ Double braces mark material to be added.}}

"If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions{{,}} [[next to the object code]] {{prominently apparent from the place to copy the object code,}} [[saying]] {{explaining}} where to find the Corresponding Source."

3.2. COMPLETED SUGGESTION CHANGE.

"If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions, prominently apparent from the place to copy the object code, explaining where to find the Corresponding Source."

Comment 3477: PO Box

For a fee the post office will forward all your mail (not just First Class) to the new PO Box. That way you are assured that nothing is missed.

Comment 3476: Termination only punishes the innocent.

If 99% of your GPL conveying is legitimate, but you accidentally infringe the GPL twice, then licensors can either sue you for just your infringements, without terminating your license, or they can terminate your license, and additionally sue you for all your legitimate use.

If 100% of someone's GPL conveying is in violation of the GPL, then licensors can sue them over all these violations without terminating their license, so terminating the license does not make any difference at all.

Terminating the license makes no difference to dealing with violations of the GPL, rather it allows licensors to additionally punish people for legitimate use under the GPL. Why is everyone so keen to punish people for legitimate use under the GPL? I don't get it.

Comment 3475: Prohibiting further DRM on 2nd+-hand copies?

Is this forbidding copy recipients from slapping on additional DRM on the copies they give out? If it is, then it is good. But it is not clear that it actually is doing such.

No, it's just saying that you have no intention to sue anybody for modifying the software to break any DRM that it is used to implement. Neither this nor the shole section bars recipients from applying DRM, it just tries to block anti-circumvention laws from applying to people working around any DRM systems the covered work is used to implement. [Whether it's actually possible to limit such liability is a legal question. Only the copyright holder on the material the DRM is protecting has the right to authorize access, so your right to make such a disclaimer is limited to your software, not to the material that it protects. The DMCA defines things in a way that it would be hard to work around by such a license, so relying on this disclaimer would be risky at best. IANAL.]

Comment 3474: Unbelievable

This is ludicrous and unbelievable we require a more concrete position on this issue not a grandfather clause that works against the GPL in every way.

Comment 3473: please remove line

I can't believe this is happening.. we should be more tuff on this issues mostly with novel and DRM, I still think the best draft was the second one. please remove this line.

Comment 3472: Include copies of copies of copies etc.

Wouldn’t "(including indirect copies)" be better, to be sure that Nth generation copies are included, for N > 2?

Comment 3471: Demand no other license can be used together with GPL

Doesn't this allow anybody to dual-license any work (currently under GPLv3) under any other license (eg. to change "GPLv3" to "GPLv3 or LGPL" or something worse)? If it does (as it seems to me), this section is critical and kills the copyleft.

This section should ensure that the work must be released _only_ under GPLv3.

However, it may be good if anybody can the work currently being under "GPLv2 or later", relicense to "GPLv3 only" or "GPLv3 or later". But the GPL must stay copyleft.

Comment 3469: Allow later version of source to be conveyed, if object code was in development.

Loosen this requirement, so that if the object code conveyed was a developmental version, and marked as such, then you may at your option convey the following non-developmental version, or if there is no following non-developmental version to date, then the current developmental version instead.

Disagree - there may be things in the specific version that the licensee wants (for instance, a beta might contain features that are removed in the final version and it may be those features that the person requesting the source wants).

The right should be to request the code for exactly what you received.

I would, however, have no issue with the language allowing the licensor to offer the licensee the choice of either the same version or later version.

/ Disagree - there may be things in the specific version that the licensee wants (for instance, a beta might contain features that are removed in the final version and it may be those features that the person requesting the source wants). /

I'm not thinking so much of betas, as of nightly builds. Much software is under constant development, and it might be a considerable requirement to keep the source from every nightly build for 3 years. That's 365*3=1095 nightly builds. For a small project without a proper change management system, it could be even more difficult.

I agree that this is a potential problem. However, I don't see how to reconcile your suggestion with the license's dedication to keeping the software free. If you're going to distribute in object form, you need to meet the terms of the license.

/ If you're going to distribute in object form, you need to meet the terms of the license. /

What?! I should think that was obvious. The question is, what should those terms be? What is fair? What is reasonable? What is actually workable?

How about if you request the source within a month, you must be given the exact version, if you request within 3 years, you could be given the release that followed the development version you have (or the current development version if there has been no release to date).

Comment 3468: Expand proxy powers

There may be cases where it would be useful, for license compatibility, for a proxy to specify that a different license applies.

In particular, I think it would be especially useful to be able to grant the right to use the work under any (weak or strong) copyleft license that permits relicensing under the GPL, e.g. the LGPL, the MySQL FLOSS license exception, libgcc exception, the Linux user programs exception, etc., and to remove restrictive additional terms.

It may also be useful to allow a proxy to relicense under an earlier version of the GPL, and perhaps even to relicense under the AGPL.

Comment 3467: Add mechanism for transferring proxy status.

I guess the idea is that contributors may come and go, but the proxy remains. But what if the proxy also goes? If proxy status is given to a lead developer who decides to hand over control of the project, then they should be able to hand over proxy status also.

Comment 3466: Depriving contractors of their rights is one small step in the wrong direction.

"The price of freedom is eternal vigilance." Thomas Jefferson

"liberty, once lost, is lost forever." John Adams

I think it's bad enough that employees are denied GPL rights, but now this is being extended. Is this really a good idea? Will it be extended even further in the future?

I agree.

Moreover, if I understand, there is no real need for this clause to exist: if it applies only to the material for which you hold copyright - you, as a copyright holder, do not need that clause, because you are allowed to release your code under arbitrary license. Therefore, you may distribute this material (for which you hold copyright) to your employees, demanding that thay can not distribute it further; whilst the other material, for which you do not hold copyright, you would distribute normally, under the GPL. So, all what is being allowed by this clause, seems to me already allowed, anyway.

Taking trosos's comment first - the exception applies to the entire covered work, not just the part on which "you" hold copyright. Otherwise it would be pretty useless.

I stronly disagree with these comments. Freedom is not at issue here. The contractor is working temporarily as an employee or associate and should not have the rights that go with ownership of a copy of the code. This is an area where contractors and potential employers should have the right to come to agreement on mutually satisfactory terms; it's not something the license authors should try to shoehorn themselves into.

/ I stronly disagree with these comments. Freedom is not at issue here. The contractor is working temporarily as an employee or associate and should not have the rights that go with ownership of a copy of the code. This is an area where contractors and potential employers should have the right to come to agreement on mutually satisfactory terms; it's not something the license authors should try to shoehorn themselves into. /

If that is the case, why should the license authors try to shoehorn themselves into users' rights? Why not let companies and their customers have the right to come to agreement on mutually satisfactory terms?

Comment 3465: Describe how to specify proxy and how to write offer for source

The "How to apply" section is missing a template for specify a proxy.

Also, it would be very handy to have a template of a written offer for source (Section 6)--this is actually something that applies to far more people, and in over 5 years of depending on GPL software, I have never actually seen such a written offer.

And also a template for how to "conspicuously and appropriately publish on each copy an appropriate copyright notice" (Section 4).

Comment 3464: Require conveyors to agree to respect recipiants' rights under the GPL.

Currently, there are instances where a licensee will have to track down a licensor, and convince them to uphold the GPL, in order to enforce their rights. It seems that the FSF has been trying to minimise this, e.g. by requiring that conveyors provide recipiants with a written offer for source. However I think there is more that can be done to ensure that people can enforce their own rights.

Ideally, upon accepting the license, each licensee would covenant to all other licensees that they would respect their rights under the GPL. However, if this is not possible, then at least conveyors can covenant to recipiants that they will respect their rights.

I'm not sure what you're asking for. It seems to me that this is exactly what the license already does. There's no way the license can enforce the requirements - people have to do that. All the license can do is establish that the requirements exist, which is what it already does.

/ I'm not sure what you're asking for. It seems to me that this is exactly what the license already does. There's no way the license can enforce the requirements - people have to do that. /

Currently, licensees promise to the licensors that they will follow the terms of the GPL. What I am saying is, is it possible to require licensees to promise to other licensees that they will follow the terms of the GPL? Obviously someone has to enforce the license, but at the moment, in many cases only licensors can do that. That means that /you/ can not enforce your rights, you must beg /someone else/ to enforce your rights, and hope they're interested, and not too busy. (And first you have to find them.) That's not quite ideal.

Ahh, I see. You're saying that people receiving copies should be able to enforce the terms of the license on the provider of the copies.

I don't see how you can make that work within the "this is not a contract" model that the license takes. The only party that can have standing to sue is the copyright holder. I don't think you can change that short of making the license a contract.

/ Ahh, I see. You're saying that people receiving copies should be able to enforce the terms of the license on the provider of the copies. /

Yes, exactly. A right that you can't enforce isn't actually a right at all, it's merely a rough guideline. Imagine if all law worked like that--you had to get the personal permission of the local sheriff (entirely at his discretion) to enforce any of your rights. "Oh, I don't really feel like enforcing your rights today." It would suck.

/ I don't see how you can make that work within the "this is not a contract" model that the license takes. The only party that can have standing to sue is the copyright holder. I don't think you can change that short of making the license a contract. /

Fine by me. The "this is not a contract" idea strikes me an an irrational phobia. I suspect the reasoning goes: EULA are contracts, and EULA are bad, therefore contracts are bad, so if the GPL were a contract, then it would be bad too--which is bollocks. Law is a contract (a social contract). Living within society, I agree not to murder. That, IMHO is not unreasonable. And agreeing to uphold the GPL is not unreasonable either.

Comment 3462: Making FSF the proxy

Hey, I suggest add section says that the the copyright holder give irrevocable power/right of licensing his/her work ans the FSF can decide separately by itself the moving to next version of GNU GPL

I suggest that to avoid difficulties in moving GPLv3 covered work to GPLv4 for example in future

What's the point of that? That's what you get by using the "or any later version" already. The idea is to give the power to some other, independent proxy. For instance, Linux contributors could give Linus the power to decide.

Comment 3461: Allow linking to any version of the AGPL or GPL

I like this clause, on the whole. People might not be comfortable with licensing their work under the "or any later version" clause, but it is a pain in the arse if their work can't even be /linked/ with other versions.

However, I think the clause could be expanded in a couple of ways.

Firstly, if linking with later versions of the AGPL is permitted, then it's a bizarre omission to not allow linking with later versions of the GPL itself.

And secondly, it would be better to allow linking with /any/ version of the GPL or AGPL, not just later versions. This will not remove all problems, since earlier versions do not have recipricol linking clauses, however it will remove some problems. Specifically it will allow people to run legacy GPL or AGPL programs with GPL v3+ OS and/or System Libraries.

Comment 3460: Do the definitions change at this point?

This suggests that the terms "patent license" and "grant" mean something different in the following three paragraphs than they meant in the preceeding paragraph. Is that intentional, and if so, what did they mean there?

Comment 3459: Seriously....who's stupid idea was this?

The entire community is owed an explaination of this, what kind of koolaide you're drinking, and why you expect us to drink it too.

Not penalizing Novell etc., must involve a *very* solid reasoning. And it deserves to be openly and *freely* published.

Frankly I think this is assinine.

Comment 3458: Is this for real?

Let me state plain and simple - you're playing with fire here. What's the answer? I can't give you one at this very moment, but I can tell you right now this is an outrageous statement that needs to be rectified in some way, manner, shape, or form.

You're going to let Novell yank the rug right out from under us?

Very disturbing.

Yes I agree, this clause is wrong and very soft... I will like the FSF to take a more aggressive against the Novell+MS deal.