|
|
Subscribe / Log in / New account

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

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

Posted Mar 2, 2011 1:06 UTC (Wed) by dlang (guest, #313)
In reply to: Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld by DOT
Parent article: Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

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.


to post comments

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.


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