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

Posted Mar 1, 2011 21:30 UTC (Tue) by dlang (guest, #313)
In reply to: Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld by jspaleta
Parent article: Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

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:

The US Federal government enacts a nationwide drinking age of 21, versus
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".