|
|
Subscribe / Log in / New account

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

[Posted March 1, 2011 by jake]

On his blog, Mark Shuttleworth has responded to the recent Banshee controversy to explain Canonical's position. "We know that we need a healthy and vibrant ecosystem of application developers. We think services should work for them too, and we're committed to sharing revenue with them. We want to be entirely aligned in our interests: better code means a better result for both of us, better revenue means more resources to do what we love even better. Our interests, and upstream interests, should be perfectly aligned in this. So we have consistently had the view that revenue we can attribute to a particular upstream should create a revenue share for that upstream. We support Mozilla in this way, for example. The numbers are not vast, but nor are they insubstantial, and while we are not obliged to do so, we do so happily." The comment thread on the post is interesting as well, including a lengthy explanation from Shuttleworth on his views regarding the perception of divergent interests between Canonical and the Ubuntu community.
to post comments

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 18:09 UTC (Tue) by jspaleta (subscriber, #50639) [Link] (51 responses)

Mark continues to mischaracterize Red Hat's licensing agreements. He needs to learn to refrain from making such comments about competing products. I dare him to go to a public forum like a roundtable discussion at a video archived conference and sit next to a representative from Red Hat's exec team and make the same claims as to the proprietariness of Red Hat's licenses and defend his interpretation. I double dog dare him.

I also take issue with his statement that everything they put into Ubuntu is open. The UbuntuOne service is definitely not open. The client code..yes...the Ubuntu branded backend code...no. He's cutting that line very very thin with that statement.

He also seems to be reluctant to admit that Unity version 1 as released in Ubuntu 10.10 was a failure, and the same Canonical employees that were chearleading and hyping it hard for months prior to the 10.10 release.. stopped wanting to talk about it at all once it was released. If he wants to stand up the design and engineering process around Unity for discussion you can't do it without examining what went wrong with the Unity as delivered in 10.10. And you can't do it without talking about why Canonical felt the need to simultaneously create 2 versions of Unity in this development cycle side-by-side using two different toolkits. This is in direct conflict with Shuttleworth's previous statements that Canonical can only support one Desktop offering. Unity is now two distinctly different codebases, which fundamentally cannot be merged.

-jef

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 19:01 UTC (Tue) by whiprush (guest, #23428) [Link]

This is incorrect. 90% of the projects that go into making up "Unity" are shared between the frontends.

You are also making the assumption that the actual code is most of the work. They share the same design work, same user testing, same bug and feature tracking and interaction work. Contributors to projects like libdee, libbamf, or libunity contribute to both Unity 2D and Unity 3D at the same time, efforts are not split between the two. People submitting design ideas and mockups to the ayatana mailing list speak for both the 2D and 3D frontends.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 20:35 UTC (Tue) by dlang (guest, #313) [Link] (49 responses)

given the other discussion thread where it was pointed out that the redhat license forbids you from exercising your GPL rights, I think that calling it proprietary is fair

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 20:46 UTC (Tue) by jspaleta (subscriber, #50639) [Link] (48 responses)

Such an interpretation is unfounded and is at best speculative.

It was also pointed out that the license agreeement language associated with access to the content obtainable through the red hat site specifically states that the license of the content in question trumps the red hat agreement in question.

RHEL customers absolutely have the ability to use the code in question under the licensing terms provided by the GPL. Red Hat is under no obligation to continue to provide service or support.

It's not unlike a warrenty agreement that comes with an embedded linux device that I buy. If I flash my Nokia 810 with an alternative image with a custom kernel I've built from source myself, I voided the warranty. Same with my home router appliance. I voided the terms of a service contract because I've chosen to make use of rights inherent in the software licensing that Nokia cannot reasonably provide support for as a business entity. I've lost support I paid for as part of the price of the product because I've chosen to use my rights. Shouldn't we all be up in arms about that for the full spectrum of linux based gadgets on the market now? How dare the Nokias and the Ciscos and the Samsungs and the HPs of the world refuse to honor service contracts because I made use of my rights to modify the software distributed to me under the terms of the GPL. How dare they!

-jef


Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 20:56 UTC (Tue) by dlang (guest, #313) [Link] (39 responses)

see http://lwn.net/Articles/430161/

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 21:11 UTC (Tue) by jspaleta (subscriber, #50639) [Link] (38 responses)

Fair enough. I am mistaken as to the clause you originally referenced. Thank you for the clarifying link.

But my point still stands. They are under no obligation to provide support services if you make the choice to use all the rights given to you by the GPL..inclusive of the right to redistribute. If you are okay with watching an embedded linux vendor void your service agreement because you've made use of the GPL's "freedom to change the software to suit your needs" or "the freedom to use the software for any purpose" then you must self-consistenly be okay watching another vendor refuse you service if you use "the freedom to share the software with your friends and neighbors"

You cannot pick and choose which freedoms a business has to provide service for if you choose to make use of them. They are all equal. If you are going to give Red Hat a hard time for building a support service model which asks you to voluntarily refrain from making use of one freedom on the condition of receiving support services.. then you must necessarily be just as upset at an embedded vendor whose support service agreement requires you to voluntarily refrain from making use of other freedoms in exchange for support services. Which means you must be upset at basically _all_ embedded vendors.

What is unique here is that Red Hat is putting the stress on the distribution freedom in a way that other vendors are not. But make no mistake tieing service and support agreements to voluntary restraint on at least one of the GPL freedoms is common place among the ecosystem of sustainable businesses who are distributing linux and other GPL licensed code. If we want to have a conversation about that, lets do that across the board for all vendors and all GPL freedoms.

-jef

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 21:30 UTC (Tue) by dlang (guest, #313) [Link] (37 responses)

it is perfectly reasonable (although disappointing) to say that if you run any modified binaries you don't get support.

however saying that if you give someone a copy of the source you no longer get support seems to me to be directly violating the 'no additional restrictions' clause of the GPL, and the fact that people are saying that because it's RedHat doing this there is no problem sickens me (Imagine the outcry if Ubuntu did something like this)

add to this the fact that they also forbid you from running CentOS without paying them for support as well is also going way too far.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 21:33 UTC (Tue) by jspaleta (subscriber, #50639) [Link] (2 responses)

The comment about CentOS is also unfounded. Can you point to a customer that has been asked to pay for CentOS installs yet.

-jef

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 21:55 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

they are claiming the right to charge for CentOS installs, even if they have never exercised that option in the contract. see the rest of the thread following the link I posted

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 22:03 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

I commented on that assertion already.
http://lwn.net/Articles/430198/

There is no evidence that Red Hat interprets CentOS(or any source rebuilds) installs to count as Red Hat Software or a Red Hat product in the language of that clause.

-jef

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 21:45 UTC (Tue) by jspaleta (subscriber, #50639) [Link] (33 responses)

Okay what you have just done is make a moral judgement as to which of the freedoms the GPL guarantees is more important to you. That's perfectly fine.

But its is a _huge_ leap from that into trying to say that because Red Hat is putting conditions on its service contracts on the freedom you personally care about most, when other vendors put conditionals on their services related to other freedoms makes Red Hat somehow in breech of the requirements under the licensing in a fundamentally different way than those other vendors.

You, like myself, value the redistribution rights more than the benefit of the ongoing service agreement Red Hat is offering. You, like myself, are clearly are very unlikely customers for those services as a result. That's absolutely fine. Go ahead and argue its a bad value proposition compared to a competitor's service offering. Champion those other services as a paying customer of those competing services and increase their marketshare and put pressure on Red Hat to increase the value of their service offering. But to argue they are somehow in breech of the spirit of the GPL is a mischaracterization of what is going on.

-jef

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 21:54 UTC (Tue) by dlang (guest, #313) [Link] (31 responses)

no, I am saying that violating any of the terms of the GPL is bad.

I'm not saying that it's Ok to violate some of them and not Ok to violate others (that seems to be your position)

and for the record, I don't see any GPL issues with RedHat's 'obfuscated' patches. the preferred means for working on the code is in text files of C source code. the arrangement or storage of those files is not something that the GPL covers (if it did, then you could claim that by sun storing GPl files on the ZFS filesystem they had to provide the source code to ZFS as well)

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 0:27 UTC (Wed) by rahvin (guest, #16953) [Link] (30 responses)

Unless I'm missing something I don't see how they are violating the GPL. You still have all the same rights, Redhat's just have said they don't want to do business with you if you exercise some of those rights.

That doesn't take away those rights or even impinge on them. You might not like their refusal to do business and you might recommend alternative products as a result but you don't get to say they are violating the GPL by refusing to provide support. They aren't equivalent and it would be a serious issue to claim Rehat loses their right to do business with who they choose because their product is GPL.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 0:46 UTC (Wed) by DOT (subscriber, #58786) [Link] (29 responses)

As repeated ad nauseam, it's not a GPL violation. It is, however, a dick move that goes against the spirit of the GPL. Just because it is legally impractical for the GPL to cover this kind of abuse, doesn't mean that Red Hat is being a good open source citizen here.

I think it nicely parallels Canonical's move: we're OK, it's legal!

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 0:55 UTC (Wed) by jspaleta (subscriber, #50639) [Link] (12 responses)

There are similarities.

However the difference is... in this case... there isn't an established documented preference from the upstream project as to what vendors are meant to provide. In this case Red Hat is rolling back what has been previously thought of as a useful courtesy they have been extending.

In the other dick move situation that you reference, it runs directly counter to the wishes explictely documented and expressed by the upstream developers.

I wouldn't call that a direct parallel.

-jef

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 0:59 UTC (Wed) by DOT (subscriber, #58786) [Link]

I would, but hey, I'm an Ubuntu fan.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 1:10 UTC (Wed) by dlang (guest, #313) [Link] (10 responses)

I actually don't have a problem with Redhat not breaking out the patches. I see that they are making the source code used to compile the kernel available, and that's what the GPL requires.

what's fed to the compiler isn't a git tree, it's a set of source code files with the patches applied, and that's what's being provided to everyone.

Separate from this is the fact that they make the patches available in a way that seems to be in violation of the GPL by imposing additional restrictions to prohibit redistribution of the patches. They are under no obligation to provide the patches to anyone, but if they do make them available, they must do so under the provisions of the GPLv2, with no additional restrictions.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 2:25 UTC (Wed) by csd (subscriber, #66784) [Link] (9 responses)

The GPL states:"You may not impose any further restrictions on the recipients' exercise of the rights granted herein".
By saying they will cancel their service agreement they are not placing further restrictions on the recicipents' exercise of the rights granted in the GPL. The recipient continues to be free to redistribute it.
Or was it some other GPL clause that you think they violate?

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 3:31 UTC (Wed) by dlang (guest, #313) [Link] (8 responses)

Ok, so if they had a contract that siad that if they redistribute the code under the GPL they owed RedHat $20000 per instance of redistribution, that would be a valid contract that would not violate the GPL?

if you say that it would because it involves a payment, what if it was worded as a $20000/month discount from the standard price, the discount terminating if you use your GPL rights to redistribute the code?

_any_ penalty that kicks in if you choose to exercise your GPL rights is an additional restriction.

once you allow some restrictions on top of the GPL, where do you draw the line on other restrictions? and how can you justify doing so?

again, I have no problem with RedHat distributing patched source instead of pristine + patches. my problem is when they are releasing the broken out patches with additional restrictions

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 5:58 UTC (Wed) by csd (subscriber, #66784) [Link] (1 responses)

Ok, so if they had a contract that said they would take declare winter void and null if you distributed the code, would that violate the GPL ?
:-) Back to the real service agreement: it says they don't want to provide you service if you distribute the software. It doesn't say you're not allowed to do so - only that they won't service you if you do. Providing service is independent of the software license. I don't consider that placing further restrictions on your right to distribute, since you're still entitled to distribute freely.
How about this service agreement (real one, from an ISP): "We reserve the right to terminate any account at any time and for any reason we see necessary". If RH had this in their service agreement, would it violate the GPL ?

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 6:20 UTC (Wed) by dlang (guest, #313) [Link]

no, a clause in their service agreement saying that they could terminate the service at any time for no reason would not violate the GPL

however, if they have an internal policy that says that they will invoke this clause any time that someone exercised their GPL rights, they could find themselves in court facing a GPL violation lawsuit.

to use a similar example. In California employment is 'at will', which means that either party can terminate the employment at any time, with no reason given. A business owner doesn't have to give a reason for firing someone, they can just make the statement that they no longer wish to employ you.

If the owner sticks to that statement, there is very little that the employee can do to counter it (they can claim that there are other reasons, but at that point the burden of proof is on the employee to show something was wrong), but if the owner has an internal policy to fire people who use more than half of their sick days, or in any way shows a pattern to who they fire or don't fire, the employee can sue based on that pattern.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 6:16 UTC (Wed) by AndreE (guest, #60148) [Link] (1 responses)

Is the actual support terms of Red Hat as you've described (lazy of me I know, but I am falling asleep)? Or is it just a termination of support? And would you consider a termination of support to also be a penalty?

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 6:37 UTC (Wed) by dlang (guest, #313) [Link]

the actual terms being reported are that your support contract is terminated if you redistribute the broken out patches

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 3, 2011 7:53 UTC (Thu) by jzbiciak (guest, #5246) [Link] (3 responses)

Compare and contrast:

  1. The US Federal government enacts a nationwide drinking age of 21, versus
  2. The US Federal government enacts highway legislation denying federal highway funds to states that do not raise the drinking age to at least 21.

The first one isn't constitutional, whereas the second one is. The first one compels a particular behavior, whereas the second one offers a choice. It's called the power of the purse. Most states will choose to go along. Louisiana chose not to, so it has a lower drinking age. It makes more money off of Mardi Gras partiers than it would off of federal highway funds.

Same is true here. RedHat can't restrict you from redistributing the separated patches, and it doesn't. But, RedHat says up front that the support contract terminates if you do redistribute. That's not a restriction on redistribution, that's a limitation of the support contract. RedHat offers you a choice: keep the support contract or redistribute. It's your right to choose.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 3, 2011 18:02 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

Those of us not in the US consider #2 an appalling example of the corrupt nature of US lawmaking rather than a good thing that ought to be emulated. (In most of the EU that sort of nonsense, along with 'tying' unrelated riders onto bills, is nearly unheard of.)

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 3, 2011 19:43 UTC (Thu) by DOT (subscriber, #58786) [Link] (1 responses)

"In most of the EU that sort of nonsense, along with 'tying' unrelated riders onto bills, is nearly unheard of."

I seriously doubt that. If it's not illegal, why wouldn't a politician try to wield power that way? I vaguely remember an agriculture bill that was going to allow software patents.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 5, 2011 17:31 UTC (Sat) by BenHutchings (subscriber, #37955) [Link]

That particular bit of skulduggery around software patents went on in the agriculture committee of the European Commission (made up of representatives chosen by national governments). The directly elected European Parliament is currently less powerful than the Commission, which is convenient because commissioners are only very indirectly accountable to the public.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 1:06 UTC (Wed) by dlang (guest, #313) [Link] (15 responses)

if it isn't a GPL violation (from imposing extra requirements), then the GPL prohibition against imposing extra requirements is meaningless. anyone can distribute something and say "you only have permission to distribute my code along with this GPL code if you don't do X"

X could be anything, including a requirement to pay them for every copy you make.

If this is legal, then the GPL 3 anti-tivo clauses are a joke as the restrictions that the GPLv3 prohibits explicitly could be put into a contract.

I don't see it as being the same thing as what Cononical is doing. Canonical is doing something explicitly allowed by the license (changing the code) and is making the changes available to everyone. you may not like the changes that they are doing, but having the ability to change the code is one of the major purposes of the license (the other being the ability to redistribute the code)

Redhat is undermining the ability to redistribute the code with their support licence. Since people like to pick on Tivo as a great evil, what if Tivo were to sell you the DVR, but with a stipulation that you never give the code to anyone else, and if you do then they will disable your Tivo? Do you think that the Android handset makers wouldn't love to use Android but add in to their contract with the buyer that the buyer is not allowed to change anything on the phone?

please note for the record that I am not aware of any case where RedHat has invoked this clause, but prior to this week I was not aware of them trying to make life harder for people who receive source from them either.

most of the silly and onerous restrictions of EULAs are not invoked initially either, but the simple fact that they are there is a problem.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 1:18 UTC (Wed) by neilbrown (subscriber, #359) [Link] (2 responses)

> "you only have permission to distribute my code along with this GPL code if you don't do X"

No, I think it is more like
"If you exercise your right to distribute, we will terminate our business arrangement with you".

which is very different.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 1:22 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

If you can impose one restriction, why can't you impose another one?

why couldn't the fine print say "if you exercise your right to distribute, you owe us double our normal support fee"?

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 2:22 UTC (Wed) by neilbrown (subscriber, #359) [Link]

There is a difference between me telling you what you have to do, and me telling you what I am going to do.

One is "imposing an extra restriction". The other is exercising a basic freedom.

If I give you some code which I am allowed to give only because of the GPL, then I must give you the same right to copy and distribute. If you do, I cannot take any action against you. But nor do I need to perform any action for you. The reason I might perform an action for you would be because of a mutually beneficial contract. There are legal limits to what can be required in a contract, and I don't know what they are. However I suspect it is legal for a contract to have a termination clause based on certain behaviours of either party.

And I suspect that you are right - the fine print of the contract might include a penalty clause for certain behaviours. Certainly you should consult a lawyer before signing a contract....

I am reminded of a sign I have occasionally seen:
. Your right to smoke is respected
. Your decision not to is appreciated

there are other ways to influence behaviour than by removing right, and the GPL only confers a right.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 1:29 UTC (Wed) by jspaleta (subscriber, #50639) [Link] (11 responses)

In a world of "services" then a service provider can in fact impose a wide range of restrictions you must agree to when you use the service. This is already a widespread practise. Sometimes specific clauses such as arbitration requirement clauses which prevent you from suing your service provider have been taken to court and found to be invalid. But there are many other clauses.

Have you looked at the kindle terms of service in detail? Have you looked at the nook terms of service in detail? You may not like what you see but there are very significant restrictions on use associated with these services that are tied to shipping linux devices.

For example:
http://www.amazon.com/gp/help/customer/display.html?nodeI...

Want the kindle source code....here you go.

http://www.amazon.com/gp/help/customer/display.html?ie=UT...

It's taking a long time for it to download for me so I can't confirm if its a big tarball dump or a pristine source with patches yet. I'll get back to you.

Welcome to the world of tomorrow.. where other service providers are already doing exactly what you don't want to see. This behaviour is common...much more common than you seem to realize. If anything Red Hat is playing catch up with a growing common practise.

Are ready to fight back against the Amazon kindles of the world? Are your ready to proselytize your view of the world to kindle owners you know who have implicitly agreed to restrictions on use of GPL software on their devices in exchanged for access to the kindle services?

I would _love_ to see these sort of restrictions by service providers on use challenged in a court of law. But until then you have to accept that this is status quo throughout the _profitable_ linux vendor landscape.

-jef

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 2:15 UTC (Wed) by dlang (guest, #313) [Link] (10 responses)

you are mistaking what I am objecting to.

I am NOT objecting to RedHat providing their kernel source as a single tarball with patches applied instead of a pristine tree plus patches (or a public git repository like some other people are saying should be required). There is nothing legally wrong with this. I don't even object on moral grounds to their SRPM only containing the patched source (the argument about the patching time compared to compile time is compelling)

what I AM objecting to is them releasing the patches under "GPL plus additional restrictions".

they have the option to either

1. not release the broken out patches to anyone

2. distribute the broken out patches under the GPLv2 with NO additional restrictions.

either one of these is legitimate, and both are in common use by various distributions.

if they are in fact not releasing the broken out patches with the purpose of making other people's lives harder, that is worrying as it shows that they are headed in the wrong moral direction, even if what they are doing right now is still legal (i.e. the problem isn't what they are doing, it's why they are doing it), but while this is what a lot of people are up in arms about, it's not something I am fussing about (I will watch what they do and say, and adjust my actions accordingly)

by the way, the kindle download is base version + patches, not that it is something that I would object to either way.

What additional restrictions?

Posted Mar 2, 2011 4:48 UTC (Wed) by jjs (guest, #10315) [Link] (9 responses)

> what I AM objecting to is them releasing the patches under "GPL plus additional restrictions".

Where in the GPL does it mandate Red Hat MUST provide service? In fact, the GPL itself disclaims all warranty (although it doesn't prevent someone from providing it).

Red Hat is under NO obligation to provide service. They are simply saying "We will only provide service if you agree not to redistribute." Feel free to redistribute.

I'm not saying I like what they're doing, but there's no violation of the GPL.

BTW - suspect the reason they do this is the problem that crops up in the past - someone buys 1 Red Hat Service Pack, installs on 10 machines, then expects service for all 10. No, you get service for 1 machine. Want support for all 10, buy 10 support contracts.

What additional restrictions?

Posted Mar 2, 2011 5:04 UTC (Wed) by dlang (guest, #313) [Link] (8 responses)

nothing in the GPL says anything about providing service.

RedHat is perfectly correct to make you pay for service on every machine you ask for support on.

but forbidding redistribution of patches has nothing to do with this.

installing RedHat on 500 servers in your company involves _no_ redistribution, so forbidding it doesn't avoid any problems for RedHat in your scenario.

a company taking the RedHat patches and burning them on a million CDs and mailing them out to random people around the country also has no effect on the cost of supporting this company.

RedHat is required to follow the GPLv2 for the linux kernel and all work derived from it, if they don't, then RedHat looses it's permission to distribute the kernel. Part of following the GPLv2 is allowing people to redistribute the source code and make derived works from the source code.

RedHat is not required to provide the patches as such, all they are required to do is to provide the source code tree used to compile their kernel binaries that they ship.

but if they do provide any GPL derived source code (such as kernel patches to customers), they cannot add additional restrictions on what those customers can do with that source code.

if you are going to allow some additional restrictions (like the RedHat, "we'll only honor the support contract if you don't redistribute", where do you draw the line over what additional restrictions or contract terms you would allow?

when you buy many things (a car, a phone, or a DVR), you almost always sign a contract (at least in the US). Can that contract waive or eliminate your rights under the GPL? If not, why not? If so, what use is the GPL since any company can avoid complying with it by just getting all their customers to sign a contract waiving their rights?

This is not actually true

Posted Mar 2, 2011 8:15 UTC (Wed) by khim (subscriber, #9252) [Link] (7 responses)

When you buy many things (a car, a phone, or a DVR), you almost always sign a contract (at least in the US).

Firms like to pretend it's true, but in reality quite often these contracts are found to be unenforceable. If you actually signed the contract with ink and paper it'll be significantly more powerful.

Can that contract waive or eliminate your rights under the GPL? If not, why not?

No, but it can include waivers. The common cases which may lead to cancellation of support contract are various forms "tapering" (the papers "warranty void if removed" you encounter quite often). I don't see why abuse of service is not a valid reason to cancel your support contract. Remember: you've gotten sources with the binary. GPL is satisfied at this point. You can do whatever you want with these sources (modulo GPL requirements). Access to the history of changes is totally separate service. It does not even include software in any form! It just gives you access rights to some metainformation - and these rights can be easily revoked.

Note that Linux developers showed acceptance of such practice years ago when they adopted BitKeeper. Larry insisted on pretty draconian rules if you used his tool to see the Linux revision history - and indeed he "pulled the rug" when the rules were broken. If they accepted such M.O. back then then on what basis they may decide that today the same approach by RedHat is illegal?

If so, what use is the GPL since any company can avoid complying with it by just getting all their customers to sign a contract waiving their rights?

This will only work if customers value their contract more then their value their freedom under GPL. And the customers will still have all their GPL-granted rights anyway. If the contract will include some stiff penalties which will be triggered by the act of exercising these rights then it'll be ultimately up to the court to decide if it's reasonable demand or not. But I doubt any court will view simple cancellation of the contract as too high of a penalty.

This is not actually true

Posted Mar 2, 2011 16:31 UTC (Wed) by nye (subscriber, #51576) [Link]

>I don't see why abuse of service is not a valid reason to cancel your support contract.

But exercising the rights given to you by the license for a piece of software is not an abuse of service.

>Remember: you've gotten sources with the binary. GPL is satisfied at this point. You can do whatever you want with these sources (modulo GPL requirements).

And if you do choose to exercise the rights given to you by the GPL, the support contract you've paid for is terminated.

>Access to the history of changes is totally separate service. It does not even include software in any form! It just gives you access rights to some metainformation - and these rights can be easily revoked.

This is completely irrelevant to the topic. Why did you even bring it up? I think you're arguing about something that nobody's said.

This is not actually true

Posted Mar 2, 2011 18:57 UTC (Wed) by dlang (guest, #313) [Link] (5 responses)

frequently when you buy a car, phone or DVR, you do end up signing a paper contract.

I would have no legal problem if RedHat had a clause in their contract saying that if you ran any binary not supplied by RedHat that the contract would be void (I also wouldn't buy a support contract as that would be useless for the real world :-)

but what's going on here has nothing to do with changes to what the support contract covers.

you could be running only RHEL binaries and scripts on all your systems and still have your contract terminated if you give a copy of GPL source code to anyone. Your providing the source code to someone else in no way makes it harder for RedHat to support your systems.

as for your comments on bitkeeper, that is a separate issue, and one where I agree with you. there is no requirement for RedHat to provide access to the broken out patches.

however there is a critical difference between the bitkeeper issue and the current issue.

with bitkeeper, if you got a copy of a patch from bitkeeper, you were perfectly free to use it and distribute it under the terms of the GPL

with the current situation you are not.

Sorry, but this is bullshit...

Posted Mar 2, 2011 19:22 UTC (Wed) by khim (subscriber, #9252) [Link] (4 responses)

Your providing the source code to someone else in no way makes it harder for RedHat to support your systems.

Sorry, but no. Using the same logic you'll conclude that you can easily pass all sources and binaries along too: this is no way affect the original recepient. Yet copyright exist and even most radical people ask for reform, not abandonment of it.

If you "providing the source code to someone else" you may as well start acting as "support person" for them: solve easy and simple cases "in-house", then pass along complex cases to RedHat. This is in effect what Oracle does. It's hard to quantify the effect but it's foolish to claim that it does not exist.

with bitkeeper, if you got a copy of a patch from bitkeeper, you were perfectly free to use it and distribute it under the terms of the GPL

Only to persons who agreed not to write VCSes, remember? And when information was made available to persions "without contract"... well, "contract" was cancelled. Andrew only published metainformation in the free, he did nothing else at all - yet it was enough to "cancel the contract with the community". History does not repeat itself, but it does rhyme...

Sorry, but this is bullshit...

Posted Mar 2, 2011 19:45 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

The history with regard to bitkeeper and its restrictions I think is important to digest. I think it firmly illustrates that there is a line between legal and ethical behaviour. And I think it it illustrates the consequences that can result if the ethical burden isn't met. The ecosystem will attempt to route around you as broken behaviour if your behaviour can't be changed. Of course the bitkeeper history is more complicated than even that self-serving statement I just made. Like I said its important to digest.

I think its perfectly valid to look and discuss the Red Hat policy change as whether it continues to meet the expectations of a consensus opinion of ethical behaviour of the existing collaborating upstream kernel community. I look forward to seeing discussion along those lines.

-jef

Sorry, but this is bullshit...

Posted Mar 2, 2011 19:55 UTC (Wed) by dlang (guest, #313) [Link]

re: bitkeeper:

I said nothing about how you got access to the data, what I said is that nothing in the use of bitkeeper affected the ability to distribute the GPL files.

you may not have had a license to use bitkeeper (because you weren't willing to agree to the terms), but this is no different from not having a license to user Perforce our Visual Source Safe because you are not willing to pay for the license. None of these tools attempted to impose any limits on what you did with the files that were stored in them. If the files were GPL, then once _anyone_ extracted the file they were free to do anything within the permissions of the GPL with the files (including patches)

RedHat is imposing additional restrictions on what you can do with the GPL files.

Sorry, but this is bullshit...

Posted Mar 2, 2011 20:01 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

by the way, you _can_ pass along all sources and binaries of a RHEL distribution. This is the reason for the statement that it is impossible to pirate RHEL.

what you cannot do is to mislead people into thinking that you represent RedHat. This is why derivative distributions like CentOS make such a point to eliminate all trademark related branding. If you eliminate all trademark related branding then you are unequivocally _not_ claiming to be RedHat.

This doesn't mean that leaving it in means that you are doing something wrong, but it does mean that it is much easier for RedHat to claim that you are misleading people.

note that the above assumes that everything in RHEL is covered by an opensource license. If they include proprietary applications in RHEL, then those applications would obviously not be covered by the statements above.

Sorry, but this is bullshit...

Posted Mar 3, 2011 19:07 UTC (Thu) by vonbrand (subscriber, #4458) [Link]

It is a bit more complex than that. The Red Hat branding is propietary (AFAIU, it has to be if they want to use it as trademark), and you can't just redistribute that. Plus what they ship is a compilation (collection of works), and the compilation could very well be under a completely different license than the pieces. Red Hat has segregated the propietary stuff, and gives guidelines on how to remove it so you can rebuild the code as a new, propietary-free system. They aren't required to do that, BTW.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 1:30 UTC (Wed) by kevinm (guest, #69913) [Link]

It's not a moral judgement differentiating the two freedoms. It is a technical one.

There is a perfectly explicable technical reason why providing support to a product is made contingent on that product remaining unmodified. You may not agree that they couldn't support a modified version, but you should still be able to see why it is a reasonable position to take. There is a clear nexus between modifying the code and supporting that code.

This is *not* the case for further distributing the code. There is no nexus between distributing the code to third parties and supporting the code. Distribution does not make the code any harder or easier to support.

The same situation could occur with "freedom to modify", too - while it's reasonable to say "we won't support our hardware if it's running modified software", it wouldn't be reasonable to say "we'll never support any of our hardware for you ever again if you've ever modified any of this software".

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 21:19 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

RHEL customers absolutely have the ability to use the code in question under the licensing terms provided by the GPL. Red Hat is under no obligation to continue to provide service or support.
I think you'll find that paying them money normally gives them a corresponding obligation to provide you with services.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 21:29 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

I'll think you'll find that contract law generally allows for parties to set terms and conditions of a service contract in a far more nuanced way that what your statement would suggest and allows a party to set specific terms under which another party is in breach in such a way such that fees paid considered non-refundable.

For example there are many day to day situations where I can contract for services and if I don't cancel with enough notice I lose a portion or all of the money I paid even though I did not actually use the services I originally contracted for. Contract law has a lot of leeway for parties to define breach of contract which result in the non-refunding of fees paid.

But of course such a line of discourse has absolutely nothing to with GPL compliance and everything to do with risk management and the value proposition of the service in question.

-jef

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 21:27 UTC (Tue) by foom (subscriber, #14868) [Link]

> If I flash my Nokia 810 with an alternative image with a custom kernel I've built from source myself, I voided the warranty.

Actually, I believe [no reference handy] you'll find that courts have frequently found that a such a declaration of voided warranty has no real force. Your warranty is most likely still intact, unless they can demonstrate that your installing of a custom kernel caused the problem in question. (e.g. if you're wanting warranty service for a malfunctioning button, having a different kernel is exceedingly unlikely to have caused the problem.)

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 21:48 UTC (Tue) by pkern (subscriber, #32883) [Link] (4 responses)

Well, iff your interpretation of the Red Hat support terms is untrue, then the subscription holder might get his access terminated if an employee uses the GPL'ed patches to fix up another distribution. If he does this in a way that benefits all other users of the distributions, i.e. file a bug with the patch attached, which is the spirit of Free Software, his employer might face trouble.

That doesn't sound like the example of "hey, you're given a device and you're not allowed to re-flash it to remain in compliance to the warranty terms", it's more like "if you use our stuff to fix up your other devices that don't run our software, you better start planning to get your work done without us". I don't think that's particularly fair.

But then business isn't about fairness, I guess.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 21:55 UTC (Tue) by jspaleta (subscriber, #50639) [Link] (3 responses)

Please by all means have a discussion about whether the service terms are fair..are a good value for customers. That is a worthy discussion to have. Such a discussion is a statement as to the value of the service no different in arguing whether the price of the service is fair in relation to the value provided. But please don't couch such a discussion in the language that suggests its a breech of the licensing requirements or even the spirit.

-jef

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 1:46 UTC (Wed) by kevinm (guest, #69913) [Link]

The service terms are quite clearly designed such that:

- Red Hat can provide binary modified versions of GPL software to paying customers only;
- Those customers cannot further distribute those binaries to third parties without ceasing to be customers.

The net effect being that those binary modified versions of the GPL software is only available to those that pay Red Hat for the privilege. This seems to be quite clearly against the spirit of the GPL (I make no claims about the letter; I am sure that Red Hat has legal advice that says that it is not).

The saving grace is that Red Hat continues to provide the source to those modified versions to all comers, also apparently in the spirit of the GPL rather than its letter.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 2:30 UTC (Wed) by marrusl (guest, #67123) [Link] (1 responses)

> But please don't couch such a discussion in the language that suggests its a breech of the licensing requirements or even the spirit.

Whereas it's completely appropriate to couch the Banshee/Canonical discussion in language that compares changing affiliate codes to child labor and sweatshops as you have done on your blog. I see.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 2:40 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

I could have picked another example to make the point about speaking out against corporate behaviour is how you have corporate behaviour change. Nike was on my mind for other reasons.

If you feel that Red Hat has violated an ethical standard of behaviour.. by all means argue that point. But lets have the upstream kernel project establish what they feel what that standard of behaviour is first so we can make sure that _all_ the major vendors conform.

-jef

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 18:22 UTC (Tue) by ewan (guest, #5533) [Link] (11 responses)

The relevant bit of the Banshee source says:
If a distribution or other entity has a desire to modify the source code of the Banshee client to access a proxy (this one or an alternate implementation) hosted elsewhere, we request that the functionality and the Affiliate ID 'banshee-20' be retained. Again, all generated revenue is sent directly to the GNOME Foundation, which directly helps foster development and awareness of Free/Open Source Software and surrounding communities.
It may not be a licence condition, but it's a pretty clear request that distributors not redirect this money away from Gnome, and it's a request that Canonical have taken on themselves to completely ignore, in favour of sending the money into their own pockets instead.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 18:41 UTC (Tue) by epa (subscriber, #39769) [Link] (10 responses)

You are comparing two situations: Canonical shipping Banshee unmodified, versus shipping it with their changes. In that comparison, Canonical are 'taking money away' from the original recipients.

Mark Shuttleworth's point of view compares the two alternatives of Canonical not shipping Banshee, versus Canonical shipping Banshee with their changes. In that comparison, disregarding the small number of users who might install Banshee by hand rather than getting it as part of Ubuntu, Canonical are not taking money away from the original recipients but increasing the amount they get by increasing their user base.

Which of the two comparisons is correct? I don't know. There is something to be said for both.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 19:05 UTC (Tue) by AlexHudson (guest, #41828) [Link] (4 responses)

Ubuntu absolutely bring an awful lot to the table, and Mark absolutely has a point when he says that the free software community don't support commerce well. The problem arises when market norms butt up against social norms: respecting Banshee's request is a social norm, Canonical's changes are market-related. When you mix social and market you just end up with trouble; you can't successfully do both.

His vision of Canonical as a gatekeeper to Ubuntu just isn't going to fly, though. They don't have control of their platform in the same way Apple has control over the iPhone, and the more money they extract from people "partnering" with Canonical the more those people will look elsewhere. Eventually someone will do what what Canonical have done to others: force the price down to zero, and give it away.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 19:51 UTC (Tue) by jzb (editor, #7867) [Link] (2 responses)

"When you mix social and market you just end up with trouble; you can't successfully do both."

Wrong. It's *hard,* but not impossible. And this is not even a reasonable attempt. Look at Magnatune as one example of mixing, successfully, social and market.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 20:58 UTC (Tue) by AlexHudson (guest, #41828) [Link] (1 responses)

I didn't say it was impossible to do both at once, what I said was they are impossible to mix successfully.

Magnatune don't mix them: they do both at once (although they primarily operate within *market* norms). They state specifically what they will do, and if they started using DRM (as an example) that would be an obvious case of them breaking social convention. That would be mixing the two value systems, and it would fail.

The problem isn't doing something social and doing something commercial: plenty of organisations do that successfully. The problem is confusing people between the two. Just look at the crapstorm over Red Hat's handling of kernel source: that's a brilliant case in point of how responding to a commercial pressure by breaking a social convention (in this case, without any monetary impact on pretty much anyone) fails.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 21:33 UTC (Tue) by jzb (editor, #7867) [Link]

Hmm. I think I misunderstood what you were trying to say. I parsed it as you saying it was impossible to "mix" as in "do both."

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 19:56 UTC (Tue) by nlee (guest, #730) [Link]

Ubuntu is already basically free for users.

Ubuntu's other main selling point is a consistent product that is constantly being updated.

Notwithstanding any bumps when radical stuff is tried, in general the point releases are good and the LTS releases very good.

Driving the "price to zero" is pointless if it doesn't deliver the right experience.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 1, 2011 20:46 UTC (Tue) by ewan (guest, #5533) [Link] (4 responses)

You are comparing two situations: Canonical shipping Banshee unmodified, versus shipping it with their changes.

I'm not comparing any two situations; I'm simply pointing out that the people responsible to creating Ubuntu's music player made their wishes quite clear in advance and Canonical chose a course of action that involved doing exactly what they'd been asked nicely not to do.

I actually think that the model that Mark espouses ('offering services to the desktop') is a perfectly decent one. Rent-seeking on services that other people are offering, however, is not.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 1:09 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

Yet Banshee also is 'rent-seeking' in the sense that they are riding the popularity of Ubuntu.

It's not a clear cut case. Ubuntu would be less good for users without Banshee, but Banshee would get less users without Ubuntu.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 6:08 UTC (Wed) by gmaxwell (guest, #30048) [Link] (2 responses)

And both would be worse off without GTK, or GLIBC, or GCC, or the works of many great mathematicians and early computer scientists.

I everyone alone the "value chain" demanded their "fair cut", each slice would be infinitesimal. Why should Canonical or Banshee enjoy a unique and special privilege? Simply because they are later in the chain? ... that could be 'fixed' with some licensing revision, you know.

And thats what we should be afraid of: This sounds like a race to the bottom brewing with terrible results for everyone. Banshee did the right thing by sending 100% of money to a broadly acceptable largely disinterested third party (and, in fact, to the extent that they weren't a third party they were UP the chain), short of instead directing people to a not-for-profit resource not taking the money themselves is pretty much the closest thing you could get to a disarmament.

Not to mention the kind of bias this puts on the content of the distribution. Say, someday, Ubuntu users would be better off if something like LibreFM had first standing in the software but there is a bias against it because it can't be monetized like the amazon store. Ugly business.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 16:31 UTC (Wed) by renox (guest, #23785) [Link] (1 responses)

> Why should Canonical or Banshee enjoy a unique and special privilege?

They don't: in the same way that Canonical changed Banshee's configuration, distributions which repackage Ubuntu could also change this configuration.

> Simply because they are later in the chain? ... that could be 'fixed' with some licensing revision, you know.

Depends: if a software use GPL components, then it cannot add restrictions without replacing those GPL components, otherwise yes you're correct but note that this would add an incentive to *all* Linux distributions to remove this software as it wouldn't qualify as 'Free software' anymore.

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

Posted Mar 2, 2011 17:52 UTC (Wed) by gmaxwell (guest, #30048) [Link]

> They don't: in the same way that Canonical changed Banshee's configuration, distributions which repackage Ubuntu could also change this configuration.

Sure, but where is the cut for GCC on these systems that use it? The point being that only the downstream direction can control this is an accidental consequence of the licensing and realities of distribution— not a statement that the latter steps necessarily have greater moral authority to control the distribution of income.

> Depends: if a software use GPL components, then it cannot add restrictions without replacing those GPL components, otherwise yes you're correct but note that this would add an incentive to *all* Linux distributions to remove this software as it wouldn't qualify as 'Free software' anymore.

Indeed, but there are fairly few widely depended on GPL system libraries. As a result there is far less of a blockade there then there could be. It's really not a road we (the community of free software users and developers) really want to go down.

Maybe distributions would prohibit these packages, but that isn't clear. Distributions seem to be okay with preserving trademarked branding with (minor) software implications— a similar tolerance could emerge with respect to link promotion, especially when downstream changes to the links appear to be as parasitic as some people are perceiving Canonical's actions here.

Ugh. The whole thing is silly.

Posted Mar 2, 2011 9:06 UTC (Wed) by blujay (guest, #39961) [Link] (13 responses)

Hey, I have an idea: just remove the affiliate code and let Amazon keep all the money.

Hey, I have another idea: LET THE USER DECIDE. Let him put in his OWN affiliate code and get the money for himself to reduce his costs. Or let him put in his kid's affiliate code to build a college fund. Or let him put in the Red Cross's affiliate code to donate money to charity.

No one is under any obligation to do anything. If the user goes straight to amazon.com in his browser, NO ONE gets any affiliate money, whether he uses Banshee to play his music or not.

It's all hypothetical, non-existent "revenue" anyway. Amazon doesn't even have to have for the affiliate program. If they were to stop doing it, it'd be a moot point!

Bottom line: grow up. If you license your software under the GPL/etc, people can change it. If you don't want people to do that, don't make it Free Software.

And don't make a big brouhaha about MONEY THAT ISN'T YOURS in the first place: THE MONEY BELONGS TO THE USERS who may or may not buy anything. All it is is a silly little alphanumeric code that tells Amazon who, if anyone, to send a few cents to. Hey, I don't want to give it to either of you: I want to send it to my poor grandma who lives in a nursing home and makes extra money by knitting scarves because all she has is Social Security minus Medicare! (hypothetical, but the principle remains)

why this discussion exists

Posted Mar 2, 2011 19:32 UTC (Wed) by jku (subscriber, #42379) [Link] (12 responses)

Bottom line: grow up. If you license your software under the GPL/etc, people can change it. If you don't want people to do that, don't make it Free Software.

Thanks but I'm fairly sure most of us are grown-ups here.

Canonical, and many other companies that work on open source, don't just want to distribute software: they also want to be respected parts of the community. This isn't pure philanthropy, these companies just think that's good business.

Controversial moves (even if totally license compliant) are obviously going to affect how upstream developers, users, current and future employees and other stake holders deal with these companies. Whether the effect is small enough to be meaningless can of be debated but its existence should be fairly undisputed.

Did this help understand why this discussion exists?

why this discussion exists

Posted Mar 2, 2011 20:12 UTC (Wed) by dlang (guest, #313) [Link] (10 responses)

while the phrase "Bottome line: grow up." may be on the harsh side, there is a real problem here.

We have seen repeatedly that people release code under a particular license and then complain when people do things that are permitted under that license.

Think about all the complaints form BSD licensed authors who complain when their work is 'co-opted' by GPL authors.

If you say "this work is covered by license X, but please don't do Y with it even though it's allowed by license X", you are not really using license X, you are creating a new license.

In the case of the GPL, you can create such a license (GPL + additional restrictions), but if you do, you cannot mix that code with normal GPL licensed code.

Very few people read the text of the license for each piece of software. They read the GPLv2, GPLv3, BSD, and MIT licenses, and if a piece of software claims to be covered by one of these licenses they don't read the text of that license again, they assume that it's the standard license.

If this is not what you (as a software author) want, then you should not say that you are using one of these licenses, you should define your own license and say that your code is covered by that license (which can be defined as "GPLv2, but don't change the affiliate code" for example)

I have no sympathy for authors of BSD code who complain about their code being used in GPL projects, and I have no sympathy for authors of GPL code who complain that people modify their code. If you don't like what a license allows other people to do with your code, pick a license that you do like.

the only thing that you can do is to say that if people modify your code they can no longer use your trademarks, but be careful about doing this, you must defend your trademarks against _all_ infringement or you will loose the right to do so, and imposing trademark restrictions may annoy the community (see firefox vs iceweasel as an example)

legal and social pressure

Posted Mar 2, 2011 20:22 UTC (Wed) by jrn (subscriber, #64214) [Link] (4 responses)

> If this is not what you (as a software author) want, then you should not say that you are using one of these licenses, you should define your own license

Surely it is possible an author might think the best way to achieve their ends is to legally require some things and politely request others?

For example, that is the usual advice when someone asks, "how can I explain in the COPYING file how I expect to be cited when this program is used for scientific research?".

legal and social pressure

Posted Mar 2, 2011 21:59 UTC (Wed) by dlang (guest, #313) [Link] (3 responses)

in that case, don't get upset if people don't do what you are not requiring them to do, only 'politely requesting' that they do.

In many cases, people will not even see your 'polite request' as they will see your license (i.e. GPLv2 or BSD) and not go further to see if you have additional 'requests' that you want them to comply with.

legal and social pressure

Posted Mar 2, 2011 22:19 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (2 responses)

The license will often allow you to remove all user-visible trace of the original authors and project name and replace them with your own. Distributions that make a habit of doing that kind of thing tend to be frowned upon.

legal and social pressure

Posted Mar 2, 2011 22:43 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

unless the distros in question are CentOS and RHEL, in which case the distro stripping the branding is praised for their work.

legal and social pressure

Posted Mar 2, 2011 22:45 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

Because the upstream explicitly requests it in that case. Context matters.

why this discussion exists

Posted Mar 3, 2011 1:41 UTC (Thu) by gnufreex (guest, #70396) [Link] (4 responses)

>In the case of the GPL, you can create such a license (GPL + additional restrictions), but if you do, you cannot mix that code with normal GPL licensed code.

>Very few people read the text of the license for each piece of software. They read the GPLv2, GPLv3, BSD, and MIT licenses, and if a piece of software claims to be covered by one of these licenses they don't read the text of that license again, they assume that it's the standard license.

Um... I think you got things mixed up. If you do what you said, you can't call new license GPL.

What I think you meant is probably GPL exception. That is possible, but by definition exception can't be additional restriction. It is permission that removes some already existing restriction from GPL. For example, linking exception would allow linking to proprietary code, and that would be no-go with proper GPL.

Also, contrary to what you said, exceptions don't break compatibility with GPL proper (assuming that either version number is same or that "or later" clause is kept intact). If you want to merge GPL+lining exception code with GPL proper code, you just remove linking exception. GPL says that exceptions can be removed by distributors at will, which makes any exception GPL-compatible. I guess this ensures people only add exceptions that are reasonably required, and lame exception can make people fork project and remove exception.

Sorry for going off topic, just couldn't let this error slide.

why this discussion exists

Posted Mar 3, 2011 5:24 UTC (Thu) by dlang (guest, #313) [Link] (3 responses)

I'm talking about cases where people try to say something like 'this is released under the BSD license', but then try to say that they don't want it incorporated in GPL code

or in this case where something was licensed under the GPL, but then they say "don't change this particular string" (the affiliate code)

I agree that if these requests are to have any weight the software license is no longer BSD or GPL, it's something unique.

In the case of GPL + additonal restrictions, this means that you are no longer allowed to use other GPL code in your software, so by imposing the restriction (don't change the affiliate code) you may be violating the GPL yourself.

why this discussion exists

Posted Mar 3, 2011 6:39 UTC (Thu) by jrn (subscriber, #64214) [Link]

You realize that the law is not the end all and be all of decision making, right?

why this discussion exists

Posted Mar 3, 2011 9:08 UTC (Thu) by gnufreex (guest, #70396) [Link] (1 responses)

I agree about that, but you said that in case of GPL, adding restrictions to the license is possible. Well, it is not. GPL is not under GPL, it is copyrighted by FSF and this is copyright notice:

"Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed."

If someone wants to add additional restrictions to GPL, he needs to write new license from scratch since GPL text is copyrighted.

why this discussion exists

Posted Mar 3, 2011 18:08 UTC (Thu) by dlang (guest, #313) [Link]

you can incorporate it by reference by defining your new license text as something like

the terms of the GPL plus you must agree not to pursue patent claims against anyone using this software or it's derivatives

without violating the FSF copyright on the GPL

why this discussion exists

Posted Mar 3, 2011 0:37 UTC (Thu) by pboddie (guest, #50784) [Link]

Canonical, and many other companies that work on open source, don't just want to distribute software: they also want to be respected parts of the community. This isn't pure philanthropy, these companies just think that's good business.

I still think it's an own-goal for the company's reputation. Had they left the particular mechanism for fund-raising for the upstream project in place, they'd be able to have a (virtual) photo opportunity trumpeting how the Ubuntu user base has channelled much-needed money towards the developers and/or the GNOME Foundation (insert picture of large cheque) - even though it is likely not to be a very large amount of cash - and how Canonical helps open source projects to benefit from Ubuntu's popularity. Instead, Canonical just look cheap by skimming the top off what are effectively donations to a non-profit entity.

And on the issue of donating money effectively, of course a direct donation to a project is more effective if that is what one wants to achieve: it's an excuse that giving money to worthy causes is what an individual seeks to achieve when buying things (or playing the lottery in countries like the UK) where a percentage is donated to such causes.


Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds