In the traditional UK system, every single step of the process is open to the public and visible, except for the voter marking the paper.
That's actually really surprising. I can watch in my local polling stations as voters ask for ballot papers, are given them, hide in a booth to mark them, come out and put them in a box. I can watch the box all day. I can see the box carried to the counting room, and stand on the balcony as counters take the papers out of the boxes and sort them into piles. I don't have to trust anyone else to oversee the process, it's all there for me (or any other voter or candidate) to check.
Nothing that happens inside a box with electronics is visible to an outsider.
The manual system is vulnerable to small human errors and small opportunistic fraud. It is totally immune to large systematic fraud.
The only disadvantage is the expense, but the authorities are considering switching from it to new systems that are several times more expensive to run.
But there is no mechanism in the SMTP protocol to do that. You have to add something on to it. Now it isn't SMTP, it's anonymized SMTP on a virtual network, for which there is no RFC. Your solution is just as ad-hoc as any others.
SMTP says how two machines exchange email. It doesn't say which machines you should choose to exchange email with. For that matter, it doesn't say what should be in the messages (RFC822 / 2822 is not SMTP, and what I would propose would extend them.)
Anonymity is worth preserving, even if it means some people can't make as much money as they'd hoped. Let's not throw the baby out with the bath water
I agree with you. I did say that receiving spam is a price I am willing to pay for being able to receive email from anyone. But if
someone else insists that to send email to them I must either prove my identity to them, or that I must make myself traceable by the (trustable) ISP I am sending through, then that is their right, and it is up to me whether I choose to comply with their demands or choose not to send email to them.
So everyone in the world who uses email needs a GPG key, and needs to handshake with their email providers before they can send everything. (Yes Mum, you've generated your key pair, now you need to export the public key, and then supply the private key to your email program for every message. Remember to use a good password!)
And the only result is to prevent email forgery, not the majority of spam (in my experience) which is not forged to be any other user, but just sent on a throwaway account obtained for the purpose?
What if he signed up from an internet cafe? What if he signed up from a large company that needs months to go through its logs, or doesn't have secure access internally? What if he signed up from Bangladesh? (Nothing against Bangladesh, it's just somewhere fairly remote and difficult for my local police to deal with).
If he's planning a terrorist bombing, the police can have a go at tracking him down, but at least where I live it's hard enough to get police to spend resources investigating a burglary, never mind what they would see as electronic flyposting.
Cutting out forgery, or at least flagging possibly-forged from definitely-not-forged mail for customer-controlled filtering is worthwhile, and I described more details for that in another comment. Bear in mind that many people use a "From:" address that has no relation to the actual connection they send email from (I do myself), so even that would cause a lot of disruption, for a less than immense gain.
What would the new protocol give you that SMTP doesn't?
What allows spam isn't SMTP, it's the way SMTP is used: Any ISP will accept email for their customers from just about any ISP, many of whom in turn will allow just about anyone to sign up as a customer and send email, without proving identity or showing any bona fides beyond payment for the service.
How will your new protocol magically stop that happening?
A slight improvement could be brought about by:
Insisting all messages have a "sender:" which reflects the actual network origin
ISPs' outgoing servers accept mail only from their own connected customers (happens already), and that the "sender:" matches the customer sending the message.
ISPs' incoming servers accept mail only if the "sender:" matches the domain of the server that is sending the message
With this in place, you could whitelist reliably on the non-forgeable "sender:" field. It would cause some reconfiguration, and upset some people. It would require no changes to SMTP.
ISP's would then be able to add a new header field to outgoing mail, indicating "This is a bona-fide idenifiable, accountable customer", if it really was (and remove any such header field if the customer is not identifiable). The ISP at the receiving end could remove the header if it does not really trust the sending ISP to keep track of its users. Customers would then have the option of receiveing from only such "reliable" senders, plus a whitelist. Again, this is only extensions to current mailserver functionality, not changes to the protocol. All the software to run this scheme already exists.
(Corporations, universities etc. who do not send or receive mail through ISPs count as ISPs themselves under this scheme.)
Today, the demand for such steps is not there, but it may be within the next few years.
There are a few details to fill in: obviously ISPs would have to provide filtering options to their customers based on the new headers, to save customer bandwidth, but the gist of the system is all there.
First, in saying some recent bills may be counterproductive, he's only echoing what many anti-spam campaigners have been saying: the bills actually legalise a lot of spam.
Now, a good anti-spam law can contribute by driving spam further into the criminal underworld, but let's face it, it's most of the way there already, and you're not going to cut it down much more in that direction.
The key point is anonymity. If you can send email anonymously, you can send spam, legally or illegally. If you are willing not to receive anonymous email, you can receive zero spam (using whitelisting), or next to zero spam (counting on blacklisting of known spammers by name). Contrary to what some people say, the existing technical SMTP protocols are perfectly adequate for spam-free email: you just need a virtual email network using smtp, to which anonymous users are not admitted. I think it quite likely that MSN, AOL, etc. will be setting this up within the next 12-24 months. They might screw it up by trying to lock out competitors, but it can only be useful if it's reasonably inclusive.
Personally, I want to receive anonymous email, from people who've seen my web sites, or old friends who've looked up my address, or whatever. But to get these emails, I'm bound to get spam as well, legally or illegally, and I'm prepared to live with it.
It's not entrapment, it's "estoppel" and "unclean hands".
IANAL, but the guys who wrote IBM's Countersuit most definitely are. (fifth, sixth, and seventh defenses).
Also very interesting is "SIXTH COUNTERCLAIM", where IBM, as a copyright owner of parts of the Lnux kernel, is suing SCO for breach of the GNU General Public License in attempting to collect license fees for it.
You have to be kidding!
Anne Robinson is a clueless, dim-witted ex-hanger-on-of-Bob-Maxwell.
Her TV career path went from "Points of View" (reading letters of complaint about BBC programmes), through Watchdog (reading letters of complaint about bad companies or companies with excessively stupid customers -- I particularly liked the one where they attacked tool rental chains for hiring out chainsaws to idiots who then chopped their feet off), to that inane game show where she shows a complete inability to pronounce, let alone appear to understand, the questions and answers.
I say, get Paxman!
The only anti-competitive Microsoft action that is relevant to this is keeping secret the file and streaming formats used by Media Player
I don't believe the EU really wants those opened, as this would hurt DRM, which the EU is generally sympathetic to.
There is nothing wrong with including a media player in an operating system, any more than including a file browser, or a set of printer drivers. If they were operating a "Windows ain't done till RealPlayer won't run" policy that would be different, but I've not heard that alleged.
Microsoft's real offenses are, as ever, in the fields of dishonest marketing FUD and putting pressure on third parties to disfavour competitors. Most of which is quite likely to be technically legal, at least to the extent that can be proved.
I fear this move is motivated by a general US-bashing sentiment rather than any sincere grievance. While it is possible that Free Software could benefit as a side effect of a transatlantic trade war, the costs would probably outweigh the benefit.
This law is beyond insane. Being sent a few bytes of gibberish, called a "cookie", does absolutely no harm to anybody. The only reason it has any effect on anyone is because they are choosing to run a piece of software (called a "web browser"), which is designed to send that cookie back to the host who originated it with any other requests.
If you don't want that to happen, choose not to run a piece of software designed to do exactly that.
If some loony thinks that that is such a dangerous situation that citizens ought not to be exposed to it by the mere act of running the browser that came with their PC, then its still not the fault of the web site, it must surely be the fault of the browser manufacturer -- he is the one who has made the poor user vulnerable to this terror.
I thought the anti-deep-linking morons were bad, but this is about three times worse.
Times change. At that time, equality of women wasn't an issue and equality of races barely so. On the issues that they thought were current and important, they were essentially what is now called Libertarian.
"Aristocratic" is a red herring. Aristocrats have inherited legal privileges, which were very definitely ruled out. (I take it you don't live in an aristocracy -- I'll tell you about it sometime).
(I already posted this as AC, but I just remembered my slashdot username, which I haven't used in a while)
This is a confusion based on some odd history.
The word "liberal" in the world outside the USA has the meaning that "libertarian" has inside the USA.
For many years Americans had no word for "liberal" because they didn't need one. As an earlier poster said, the USA was founded on the principle of liberalism, and nobody involved in US politics wasn't a liberal. The US constitution is one of the best and clearest statements of liberal principles in history.
Some time later, some Americans started to dislike the liberal principles of the constitution. They therefore tried to say that it meant something other than what it said. This needed a lot of interpretation. Because they interpreted the constitution "liberally", and because the word Liberal wasn't in use in US politics at that point, they called themselves "liberals".
That is why "liberal" means the opposite in the USA of what it means in the rest of the (English and French speaking) world.
Of course, now that liberalism is a matter of political dispute in America, liberals need to call themselves something. They can't call themselves "liberals", as they would elsewhere, because the word has been stolen by their opponents. That is the origin of the term "libertarian".
It's all rather like why private schools in Britain are called "public schools".
Since I'm no longer anonymous, and to justify reposting this with the benefit of my immense karma, I'll put myself in context by saying I'm a generally pro-American Brit with political views which in Britain qualify me as lunatic-fringe liberal and in the US would count as moderate Libertarian.
I don't advocate complete deregulation for these industries. I would never want to see nationalisation, however, for industries which ought to be profitable, like telephone service. In these cases, I think the answer is a regulatory regime which aims to ensure competition, rather than one that attempts to control a monopoly like the one the Baby Bells were under.
If the industry is more a public good than a profitable service -- like sewage, for instance -- I think the state needs to run it.
The worst of all worlds is the "public-private partnership", whether in the form of government handing subsidies to operators (like the UK rail industry), or a regulator directing all aspects of how a company does business (like the Baby Bells). I don't want my politicians sitting round a table doing deals with companies; either make the rules and stay out, or do it yourself.
Public-private partnership in the UK is just code for the government doing an Enron to make its finances look better
I've written
an article about that -- it needs updating as it's a year or two old (prior to the Enron crash).
Basically, rather than preventing anti-competitive behaviour, the regulators were actually enforcing anti-competitive behaviour on the generating companies, while in most cases still applying price caps to the retail providers (driving them all insolvent).
The crisis was produced by a booming population combined with environmentally-driven bans on adding new generation capacity. The inability of the system to deal with the crisis was reinforced by the insane structure that was set up.
I have to agree it's "not a shining example", but I really think people are remembering British Rail through rose-coloured glasses.
My impression -- based on intimate knowledge of the current situation (I commute >20 miles into London every day) and dim childhood memories of BR, is that the current level of service is similar (bad), reliability is similar or slightly better (still bad), standard of information and "incidental" help for customers is infinitely better (moderate), and price is quite a bit higher, in real terms. Also remember that BR was not just bad but getting worse prior to being privatised.
I don't consider the claim that nationalisation is a bad idea is contradicted by the possibility that privatisation can be screwed up.
This is a normal failure of regulating monopolies. If your plan for an industry is to have a private monopoly and regulate it, then expect this sort of thing to happen every few decades.
If you choose nationalisation instead, it's much worse. Costs may be low, but service will be dreadful to non-existent. Want a new phone line installed? Sure: it will be ready in 6 months to a year (eg UK or Italy before privatisation).
Local community ownership has been raised here; that might work. One region of the UK -- Kingston upon Hull -- had a phone service run by the local council (city government). I think it was more or less OK, much like the nationalised service. The council sold it off for umpteen million at the top of the telecoms boom, then lost all the money in an investment swindle (or it might have been BCCI). In the UK at least, massive incompetence or corruption is always a danger with local government.
Deregulation is tricky too. Comms networks are a textbook natural monopoly: barriers to entry are huge. You will be lucky to end up with real competition.
I think light regulation is the best answer. Try to encourage competition rather than capping retail prices. The inefficiencies caused by having duplicated facilities provided by competing businesses are small compared to the institutional paralysis produced by public or private monopolies. In many countries people have abandoned monopoly-provided fixed lines in droves for competing cellular providers.
The moment you sit regulators round a table with the industry to make deals, you're heading for disaster. Politicians are tempted to do this to get "achievements" they can point to, but there's always a price and it's usually hidden from the electorate. It's better for the politicians to stand back, and only intervene when they see anti-competitive behaviour, and then stamp down without any discussion.
Re:It's more complicated than that.
on
Linus on DRM
·
· Score: 1
In the case you're talking about -- hardware sold with GPL software already installed -- you might win. There are possible loopholes in separating the signature from the executable: For instance, you could build the hardware to run any executable whose MD5SUM is 3500726268, which, lo and behold, is the value of the included linux version. There's no signing key at all in that case, just a ROM chip which, in some jurisdictions, you are prohibited from replacing. In fact, I believe this is the actual situation with some hardware sold today.
There are a whole bunch of other workarounds where the hardware is sold without the software, and the GPLd software is available separately, independently or as an option: unsigned versions might work on expensive "developer" hardware platforms, or work in a restricted way, and that should satisfy the requirements.
BTW, just so we're taking about the same thing:
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
This is slightly weaker than what you wrote above.
Re:It's more complicated than that.
on
Linus on DRM
·
· Score: 1
I should say that I used to take exactly your position, but I've since changed my mind. I see this as something intelligent people can disagree about.
A key issue is whether a modified version which will not run unsigned on the specific hardware is, none the less, still useful. It might run on different hardware.
There is a lot of relevant history here. It is a breach of the GPL to create a derived work of a GPLd work if that derived work depends on non-free libraries to run (with one irrelevant exception). That was in issue for KDE, for example, when Qt was non-free. However, if the derived work can run with free libraries, it does not matter that it can also run with non-free libraries. Another example: Code could be used in applications that linked against then non-free Motif, provided it would work if linked against free Lesstif instead.
I would think that a GPLd program that would run on a "chipped" console would be OK on that basis. It's not an obligation of the software publisher to provide you with the hardware you need to run his software.
Re:It's more complicated than that.
on
Linus on DRM
·
· Score: 3, Insightful
You've defined the issue very well, but I don't think either scenario can be prohibited.
Imagine this: Company A makes a set-top box as you describe. Company B develops and publishes a linux binary for it, with source, etc. Company A then signs the binary and distributes the detached signature. The box will now run the special signed version of Linux.
Who has broken the GPL? Company B hasn't done anything wrong at all. Company A has not used, distributed, or created a derived work of any GPL'd software. They are not a GPL licensee, unless you can claim that the MD5 sum of a program is a derived work, which is ludicrous.
No, it's difficult, but Linus is correct. The GPL protects the software only. The remedy to this problem lies elsewhere: people should choose not to buy crippled hardware, and governments should not make laws prohibiting people from modifying their own hardware.
Re:What this is about
on
Linus on DRM
·
· Score: 1
The provided binary would include a signature, produced with the manufacturer's private key, that applies only to that binary. The hardware verifies the signature with the manufacturer's public key. If one bit of the kernel binary has been changed, the signature will not verify, and only the manufacturer can produce one that will.
It could be argued that the source of a signed binary, which in the language of the GPL is "the preferred form for modification", must include the private key used to create the signature. However, as Linus points out, he and others have been signing GPL'd releases for years without anyone demanding copies of their private signing keys, so I don't really think that argument is valid.
The above scenario stinks, but the root evil is not what is done to Linux, but what is done to lock people in to the hardware. It ought to be legal to modify one's hardware, and if you can modify the hardware to accept binaries signed by you, for example, then the situation ceases to stink.
It is like people who write nearly-free software but restrict what kinds of task it can be used for. There are indeed many things wrong in the world, but only a few of them can be made better using software licensing conditions.
Re:What this is about
on
Linus on DRM
·
· Score: 1
True he didn't mention it, but it's essential. If the user has control of the kernel, he can have it fool any app that wants to check.
The hardware doesn't have to actually refuse to run an unsigned OS -- the design of Palladium is that an app can make a BIOS call that will reveal whether it is in a "trusted" environment. Hardware verification of OS signatures is part of the structure.
Slashdot Mirror
In the traditional UK system, every single step of the process is open to the public and visible, except for the voter marking the paper.
That's actually really surprising. I can watch in my local polling stations as voters ask for ballot papers, are given them, hide in a booth to mark them, come out and put them in a box. I can watch the box all day. I can see the box carried to the counting room, and stand on the balcony as counters take the papers out of the boxes and sort them into piles. I don't have to trust anyone else to oversee the process, it's all there for me (or any other voter or candidate) to check.
Nothing that happens inside a box with electronics is visible to an outsider.
The manual system is vulnerable to small human errors and small opportunistic fraud. It is totally immune to large systematic fraud.
The only disadvantage is the expense, but the authorities are considering switching from it to new systems that are several times more expensive to run.
So why create a new one?
But there is no mechanism in the SMTP protocol to do that. You have to add something on to it. Now it isn't SMTP, it's anonymized SMTP on a virtual network, for which there is no RFC. Your solution is just as ad-hoc as any others.
SMTP says how two machines exchange email. It doesn't say which machines you should choose to exchange email with. For that matter, it doesn't say what should be in the messages (RFC822 / 2822 is not SMTP, and what I would propose would extend them.)Anonymity is worth preserving, even if it means some people can't make as much money as they'd hoped. Let's not throw the baby out with the bath water
I agree with you. I did say that receiving spam is a price I am willing to pay for being able to receive email from anyone. But if someone else insists that to send email to them I must either prove my identity to them, or that I must make myself traceable by the (trustable) ISP I am sending through, then that is their right, and it is up to me whether I choose to comply with their demands or choose not to send email to them.
So everyone in the world who uses email needs a GPG key, and needs to handshake with their email providers before they can send everything. (Yes Mum, you've generated your key pair, now you need to export the public key, and then supply the private key to your email program for every message. Remember to use a good password!)
And the only result is to prevent email forgery, not the majority of spam (in my experience) which is not forged to be any other user, but just sent on a throwaway account obtained for the purpose?
What if he signed up from an internet cafe? What if he signed up from a large company that needs months to go through its logs, or doesn't have secure access internally? What if he signed up from Bangladesh? (Nothing against Bangladesh, it's just somewhere fairly remote and difficult for my local police to deal with).
If he's planning a terrorist bombing, the police can have a go at tracking him down, but at least where I live it's hard enough to get police to spend resources investigating a burglary, never mind what they would see as electronic flyposting.
Cutting out forgery, or at least flagging possibly-forged from definitely-not-forged mail for customer-controlled filtering is worthwhile, and I described more details for that in another comment. Bear in mind that many people use a "From:" address that has no relation to the actual connection they send email from (I do myself), so even that would cause a lot of disruption, for a less than immense gain.
What allows spam isn't SMTP, it's the way SMTP is used: Any ISP will accept email for their customers from just about any ISP, many of whom in turn will allow just about anyone to sign up as a customer and send email, without proving identity or showing any bona fides beyond payment for the service.
How will your new protocol magically stop that happening?
A slight improvement could be brought about by:
With this in place, you could whitelist reliably on the non-forgeable "sender:" field. It would cause some reconfiguration, and upset some people. It would require no changes to SMTP.
ISP's would then be able to add a new header field to outgoing mail, indicating "This is a bona-fide idenifiable, accountable customer", if it really was (and remove any such header field if the customer is not identifiable). The ISP at the receiving end could remove the header if it does not really trust the sending ISP to keep track of its users. Customers would then have the option of receiveing from only such "reliable" senders, plus a whitelist. Again, this is only extensions to current mailserver functionality, not changes to the protocol. All the software to run this scheme already exists.
(Corporations, universities etc. who do not send or receive mail through ISPs count as ISPs themselves under this scheme.)
Today, the demand for such steps is not there, but it may be within the next few years.
There are a few details to fill in: obviously ISPs would have to provide filtering options to their customers based on the new headers, to save customer bandwidth, but the gist of the system is all there.
Now, a good anti-spam law can contribute by driving spam further into the criminal underworld, but let's face it, it's most of the way there already, and you're not going to cut it down much more in that direction.
The key point is anonymity. If you can send email anonymously, you can send spam, legally or illegally. If you are willing not to receive anonymous email, you can receive zero spam (using whitelisting), or next to zero spam (counting on blacklisting of known spammers by name). Contrary to what some people say, the existing technical SMTP protocols are perfectly adequate for spam-free email: you just need a virtual email network using smtp, to which anonymous users are not admitted. I think it quite likely that MSN, AOL, etc. will be setting this up within the next 12-24 months. They might screw it up by trying to lock out competitors, but it can only be useful if it's reasonably inclusive.
Personally, I want to receive anonymous email, from people who've seen my web sites, or old friends who've looked up my address, or whatever. But to get these emails, I'm bound to get spam as well, legally or illegally, and I'm prepared to live with it.
IANAL, but the guys who wrote IBM's Countersuit most definitely are. (fifth, sixth, and seventh defenses).
Also very interesting is "SIXTH COUNTERCLAIM", where IBM, as a copyright owner of parts of the Lnux kernel, is suing SCO for breach of the GNU General Public License in attempting to collect license fees for it.
You have to be kidding! Anne Robinson is a clueless, dim-witted ex-hanger-on-of-Bob-Maxwell. Her TV career path went from "Points of View" (reading letters of complaint about BBC programmes), through Watchdog (reading letters of complaint about bad companies or companies with excessively stupid customers -- I particularly liked the one where they attacked tool rental chains for hiring out chainsaws to idiots who then chopped their feet off), to that inane game show where she shows a complete inability to pronounce, let alone appear to understand, the questions and answers. I say, get Paxman!
Previous discussion: http://yro.slashdot.org/article.pl?sid=03/04/23/12 29244&tid=123
The comments were more intelligent that time.
The only anti-competitive Microsoft action that is relevant to this is keeping secret the file and streaming formats used by Media Player
I don't believe the EU really wants those opened, as this would hurt DRM, which the EU is generally sympathetic to.
There is nothing wrong with including a media player in an operating system, any more than including a file browser, or a set of printer drivers. If they were operating a "Windows ain't done till RealPlayer won't run" policy that would be different, but I've not heard that alleged.
Microsoft's real offenses are, as ever, in the fields of dishonest marketing FUD and putting pressure on third parties to disfavour competitors. Most of which is quite likely to be technically legal, at least to the extent that can be proved.
I fear this move is motivated by a general US-bashing sentiment rather than any sincere grievance. While it is possible that Free Software could benefit as a side effect of a transatlantic trade war, the costs would probably outweigh the benefit.
If you don't want that to happen, choose not to run a piece of software designed to do exactly that.
If some loony thinks that that is such a dangerous situation that citizens ought not to be exposed to it by the mere act of running the browser that came with their PC, then its still not the fault of the web site, it must surely be the fault of the browser manufacturer -- he is the one who has made the poor user vulnerable to this terror.
I thought the anti-deep-linking morons were bad, but this is about three times worse.
(in every sense!)
"Aristocratic" is a red herring. Aristocrats have inherited legal privileges, which were very definitely ruled out. (I take it you don't live in an aristocracy -- I'll tell you about it sometime).
This is a confusion based on some odd history. The word "liberal" in the world outside the USA has the meaning that "libertarian" has inside the USA.
For many years Americans had no word for "liberal" because they didn't need one. As an earlier poster said, the USA was founded on the principle of liberalism, and nobody involved in US politics wasn't a liberal. The US constitution is one of the best and clearest statements of liberal principles in history.
Some time later, some Americans started to dislike the liberal principles of the constitution. They therefore tried to say that it meant something other than what it said. This needed a lot of interpretation. Because they interpreted the constitution "liberally", and because the word Liberal wasn't in use in US politics at that point, they called themselves "liberals".
That is why "liberal" means the opposite in the USA of what it means in the rest of the (English and French speaking) world.
Of course, now that liberalism is a matter of political dispute in America, liberals need to call themselves something. They can't call themselves "liberals", as they would elsewhere, because the word has been stolen by their opponents. That is the origin of the term "libertarian".
It's all rather like why private schools in Britain are called "public schools".
Since I'm no longer anonymous, and to justify reposting this with the benefit of my immense karma, I'll put myself in context by saying I'm a generally pro-American Brit with political views which in Britain qualify me as lunatic-fringe liberal and in the US would count as moderate Libertarian.
I don't advocate complete deregulation for these industries. I would never want to see nationalisation, however, for industries which ought to be profitable, like telephone service. In these cases, I think the answer is a regulatory regime which aims to ensure competition, rather than one that attempts to control a monopoly like the one the Baby Bells were under.
If the industry is more a public good than a profitable service -- like sewage, for instance -- I think the state needs to run it.
The worst of all worlds is the "public-private partnership", whether in the form of government handing subsidies to operators (like the UK rail industry), or a regulator directing all aspects of how a company does business (like the Baby Bells). I don't want my politicians sitting round a table doing deals with companies; either make the rules and stay out, or do it yourself.
Public-private partnership in the UK is just code for the government doing an Enron to make its finances look better
I've written an article about that -- it needs updating as it's a year or two old (prior to the Enron crash).
Basically, rather than preventing anti-competitive behaviour, the regulators were actually enforcing anti-competitive behaviour on the generating companies, while in most cases still applying price caps to the retail providers (driving them all insolvent).
The crisis was produced by a booming population combined with environmentally-driven bans on adding new generation capacity. The inability of the system to deal with the crisis was reinforced by the insane structure that was set up.
I have to agree it's "not a shining example", but I really think people are remembering British Rail through rose-coloured glasses.
My impression -- based on intimate knowledge of the current situation (I commute >20 miles into London every day) and dim childhood memories of BR, is that the current level of service is similar (bad), reliability is similar or slightly better (still bad), standard of information and "incidental" help for customers is infinitely better (moderate), and price is quite a bit higher, in real terms. Also remember that BR was not just bad but getting worse prior to being privatised.
I don't consider the claim that nationalisation is a bad idea is contradicted by the possibility that privatisation can be screwed up.
This is a normal failure of regulating monopolies. If your plan for an industry is to have a private monopoly and regulate it, then expect this sort of thing to happen every few decades.
If you choose nationalisation instead, it's much worse. Costs may be low, but service will be dreadful to non-existent. Want a new phone line installed? Sure: it will be ready in 6 months to a year (eg UK or Italy before privatisation).
Local community ownership has been raised here; that might work. One region of the UK -- Kingston upon Hull -- had a phone service run by the local council (city government). I think it was more or less OK, much like the nationalised service. The council sold it off for umpteen million at the top of the telecoms boom, then lost all the money in an investment swindle (or it might have been BCCI). In the UK at least, massive incompetence or corruption is always a danger with local government.
Deregulation is tricky too. Comms networks are a textbook natural monopoly: barriers to entry are huge. You will be lucky to end up with real competition.
I think light regulation is the best answer. Try to encourage competition rather than capping retail prices. The inefficiencies caused by having duplicated facilities provided by competing businesses are small compared to the institutional paralysis produced by public or private monopolies. In many countries people have abandoned monopoly-provided fixed lines in droves for competing cellular providers.
The moment you sit regulators round a table with the industry to make deals, you're heading for disaster. Politicians are tempted to do this to get "achievements" they can point to, but there's always a price and it's usually hidden from the electorate. It's better for the politicians to stand back, and only intervene when they see anti-competitive behaviour, and then stamp down without any discussion.
In the case you're talking about -- hardware sold with GPL software already installed -- you might win. There are possible loopholes in separating the signature from the executable: For instance, you could build the hardware to run any executable whose MD5SUM is 3500726268, which, lo and behold, is the value of the included linux version. There's no signing key at all in that case, just a ROM chip which, in some jurisdictions, you are prohibited from replacing. In fact, I believe this is the actual situation with some hardware sold today.
There are a whole bunch of other workarounds where the hardware is sold without the software, and the GPLd software is available separately, independently or as an option: unsigned versions might work on expensive "developer" hardware platforms, or work in a restricted way, and that should satisfy the requirements.
BTW, just so we're taking about the same thing:
This is slightly weaker than what you wrote above.
I should say that I used to take exactly your position, but I've since changed my mind. I see this as something intelligent people can disagree about.
A key issue is whether a modified version which will not run unsigned on the specific hardware is, none the less, still useful. It might run on different hardware.
There is a lot of relevant history here. It is a breach of the GPL to create a derived work of a GPLd work if that derived work depends on non-free libraries to run (with one irrelevant exception). That was in issue for KDE, for example, when Qt was non-free. However, if the derived work can run with free libraries, it does not matter that it can also run with non-free libraries. Another example: Code could be used in applications that linked against then non-free Motif, provided it would work if linked against free Lesstif instead.
I would think that a GPLd program that would run on a "chipped" console would be OK on that basis. It's not an obligation of the software publisher to provide you with the hardware you need to run his software.
You've defined the issue very well, but I don't think either scenario can be prohibited.
Imagine this: Company A makes a set-top box as you describe. Company B develops and publishes a linux binary for it, with source, etc. Company A then signs the binary and distributes the detached signature. The box will now run the special signed version of Linux.
Who has broken the GPL? Company B hasn't done anything wrong at all. Company A has not used, distributed, or created a derived work of any GPL'd software. They are not a GPL licensee, unless you can claim that the MD5 sum of a program is a derived work, which is ludicrous.
No, it's difficult, but Linus is correct. The GPL protects the software only. The remedy to this problem lies elsewhere: people should choose not to buy crippled hardware, and governments should not make laws prohibiting people from modifying their own hardware.
The provided binary would include a signature, produced with the manufacturer's private key, that applies only to that binary. The hardware verifies the signature with the manufacturer's public key. If one bit of the kernel binary has been changed, the signature will not verify, and only the manufacturer can produce one that will.
For background, see the Palladium FAQ
It could be argued that the source of a signed binary, which in the language of the GPL is "the preferred form for modification", must include the private key used to create the signature. However, as Linus points out, he and others have been signing GPL'd releases for years without anyone demanding copies of their private signing keys, so I don't really think that argument is valid.
Reluctantly, I think Linus is right.
The above scenario stinks, but the root evil is not what is done to Linux, but what is done to lock people in to the hardware. It ought to be legal to modify one's hardware, and if you can modify the hardware to accept binaries signed by you, for example, then the situation ceases to stink.
It is like people who write nearly-free software but restrict what kinds of task it can be used for. There are indeed many things wrong in the world, but only a few of them can be made better using software licensing conditions.
True he didn't mention it, but it's essential. If the user has control of the kernel, he can have it fool any app that wants to check.
The hardware doesn't have to actually refuse to run an unsigned OS -- the design of Palladium is that an app can make a BIOS call that will reveal whether it is in a "trusted" environment. Hardware verification of OS signatures is part of the structure.