| |||||||||||||
safety-critical systems can use ROMsafety-critical systems can use ROMPosted Oct 18, 2006 5:09 UTC (Wed) by bojan (subscriber, #14302)In reply to: safety-critical systems can use ROM by stevenj Parent article: FSF should separate GPLv3 changes (Linux.com)
> As Moglen and Stallman have repeatedly pointed out, in conditions where non-modifiability is critical for safety, or because of legal constraints, you can always use a ROM.
This is naive. Every piece of software has bugs. Once you make it a ROM, you can't easily fix it. On the other hand, a DRM enabled piece of hardware can always receive a bug-fixed non-modifiable binary quite easily.
> As for the assertion that most consumers don't care about modifiability, pause to consider that this has also been a standard argument against GPLv2 and against free software in general.
I think the problem with some consumer devices may be related to legal constraints here. For instance, mobile phones and other devices that emit variuos frequencies at various power levels may need to be non-modifiable by the user. Otherwise, these devices wouldn't get use approval at all.
PS. I'm just pointing out the facts here. Not taking sides.
(Log in to post comments)
safety-critical systems can use ROM Posted Oct 18, 2006 5:52 UTC (Wed) by jstAusr (guest, #27224) [Link] I find it interesting that you didn't quote the second paragraph:
stevenj wrote:
Which seems to answer your complaint about the first paragraph.
bojan wrote:
Wouldn't the frequencies be a good candidate for ROM?
safety-critical systems can use ROM Posted Oct 18, 2006 6:35 UTC (Wed) by bronson (subscriber, #4806) [Link] Wouldn't the frequencies be a good candidate for ROM?Absolutely not! Frequency tables tend to be very different in different countries and in fact are continually changing. How many wireless chips nowadays hard-code the frequency tables? None! There's a reason for that. Um, isn't the point of the FSF to advocate free software? I fail to see how software permanently burned onto a ROM is more free. Does it help the user? Or the developer? Or anybody at all? ROMing something is almost always a step in the wrong direction[1]. Why on earth are you advocating this? [1]: except in extremely price-sensitive scenarios of course, where burning a few million ROMs becomes noticeably cheaper than serial EEPPROMs or flash. But on-die flash in modern microcontrollers is making even this moot.
about "put it in ROM" Posted Oct 18, 2006 11:27 UTC (Wed) by coriordan (guest, #7544) [Link] Why does "put it in ROM" increase freedom? Currently, there are three options:
If hardware distributors have all three options, they might often go for option #2 because it allows them to lock out the user without limiting their ability to control the user's computer. If option #2 is taken away, then locking out the user will come with the cost of also locking themselves out. Option #1 would be far preferable, and sometimes option #3 would be offensive, but presenting options #1 and #3 will yield more #1s than presenting options #1, #2, and #3 - which could yield a lot of #2s. For genuine cases, such as setting the radio strength on a wifi card, manufacturers might put that bit of the driver in ROM. If there is no cost to them, then manufacturers will DRM the entire driver (instead of just the radio strength bit), and will tell the free software community "Sorry, we're complying with regulations".
about "put it in ROM" Posted Oct 18, 2006 12:14 UTC (Wed) by svkelley (guest, #37299) [Link] >>For genuine cases, such as setting the radio strength on a wifi card, manufacturers might put that bit of the driver in ROM. If there is no cost to them, then manufacturers will DRM the entire driver (instead of just the radio strength bit), and will tell the free software community "Sorry, we're complying with regulations".
No one in the aviation business is foolish enough to put their avionics software into a ROM. FAA and other regulators require the ability to update the firmware to fix critical issues. You would never be able to ship a product as you would fail certification.
You may not realize this but ROM costs far more than FLASH based memory for large sizes. I can't think of a single device that I make or have worked on in the past three years that uses ROM for any storage.
Sean
about "put it in ROM" Posted Oct 18, 2006 13:20 UTC (Wed) by coriordan (guest, #7544) [Link] They can also put the software-containing-whatever in a locked box. That's another thing GPLv3 can't prevent and doesn't try to prevent. Or they can send out a worker to take out the dodgy ROM and put in a working one. But these are corner cases. If GPLv3 is perfect for every application except for the critical parts of some avionics software, that's not a big problem. Being suitable for 99.999% of applications would be just grand. The avionics industry might just have to write some of their software themselves (but I suspect they do this already). (I put my previous commented into my blog: Preventing modification: put it in ROM?)
about "put it in ROM" Posted Oct 18, 2006 21:31 UTC (Wed) by bronson (subscriber, #4806) [Link] Reply to your blog (commenting here because I don't want to sign up for yet another site):
That's some tortured logic. How are you going to cut out option 2? The GPLv2 will still allow it and clearly there are a large number of people who are still interested in its existence. Besides, option 2 is a freedom that I personally value highly. All this talk of restricting what you can and cannot do with the compiled software... If the FSF shares your view on freedom, maybe it's time for them to change their name to the "Free Sourcecode Foundation"?
about "put it in ROM" Posted Oct 19, 2006 11:28 UTC (Thu) by coriordan (guest, #7544) [Link] GPLv3 cuts out option #2. GPLv2 will still have option #2, as will many other free software licences. Developers can choose what licence to use.
The way that GPLv3 cuts out option #2 does not interfere with "what you can and cannot do with the compiled software". GPLv3 only says that if you distribution a software+hardware system, and if you rigg the hardware to malfunction if the software does not have an approved fingerprint, then you have to also distribute whatever digital magic dust is needed to authorise a fingerprint.
So this only places a requirement on people who are distributing products which combine software+hardware, and which are specially rigged to prevent running software modification. It is very unlikely that this includes you. It doesn't include any of the Linux hackers, AFAICT, and it doesn't include Red Hat, or Debian, or SuSE, or Ubuntu. It is only an additional requirement on the company behind the Tivo, and some router manufacturers.
safety-critical systems can use ROM Posted Oct 18, 2006 7:00 UTC (Wed) by bojan (subscriber, #14302) [Link] > Which seems to answer your complaint about the first paragraph.
So, who gets the keys for a mobile phone? I would think according to GPLv3, that would be the end user (i.e. a person buying a mobile phone). Now if that's the case, can't they do whatever they like, including changing the output of the device, the frequencies it operates on etc.?
I don't think regulators would like that.
safety-critical systems can use ROM Posted Oct 18, 2006 7:31 UTC (Wed) by man_ls (subscriber, #15091) [Link] I don't think regulators would like that.Regulators don't like it either when people stick a knife into each other; you are still allowed to buy pointy cutlery. A silly but perhaps significant example. My wireless router (a 3COM WDR100) asks at initialization the country it will be used in (and warns that "it might be illegal to choose incorrectly). If I say US or Japan instead of Spain it might use an illegal part of the spectrum here. With the hacked WRT54GL I also have, it will probably give me that choice too (haven't checked really). Would it be illegal? Probably. Do regulators like it? Who cares, I'm a responsible person and promise solemnly not to do it.
safety-critical systems can use ROM Posted Oct 18, 2006 8:54 UTC (Wed) by edomaur (subscriber, #14520) [Link] >> Who cares, I'm a responsible person and promise solemnly not to do it.
IRL, this is not the case for every person who lives on this Earth.
safety-critical systems can use ROM Posted Oct 18, 2006 9:14 UTC (Wed) by man_ls (subscriber, #15091) [Link] You can only regulate so much -- I would say it is reasonable to do so against careless modification, but not to prevent knowledgeable people from doing so. Just requiring to update the firmware is a reasonable barrier of entry IMHO, at least for things such as wireless spectrum use. We are not talking about spectrum scanners or police radio receivers (and they would be hard to prevent anyway).
safety-critical systems can use ROM Posted Oct 18, 2006 10:25 UTC (Wed) by nix (subscriber, #2304) [Link] ... and if they maliciously pick a wrong value, then that's for the justice system to deal with. (Note that the justice system can distinguish between malicious and non-malicious intent, which code cannot. Hell, code can't even determine that you have specific permission to use some frequency, and bans you anyway: viz Alan Cox's complaints that frequency governors in some wireless systems forbid him from using frequencies which he *is* in fact allowed to use due to an amateur radio license...)
If everything followed your criteria, it would be impossible to invite a guest into your house (they're not the owner! they're probably a burglar!)
safety-critical systems can use ROM Posted Oct 18, 2006 10:19 UTC (Wed) by bojan (subscriber, #14302) [Link] > Regulators don't like it either when people stick a knife into each other; you are still allowed to buy pointy cutlery.
In some countries, it is illegal for manufacturers to ship devices that aren't "locked" to particular settings. And that's made illegal because the regulators think that users shouldn't be able to fiddle with devices in such manner. Whether this is "right" or not, is another matter.
So, if there was a device on such a market with GPLv3 software on it, the manufacturer would be forced to discontinue it (maybe even recall it), as it would not be compliant with regulations.
safety-critical systems can use ROM Posted Oct 18, 2006 14:36 UTC (Wed) by coriordan (guest, #7544) [Link] Nah, just stick the small amount of regulation-fettered logic into ROM, or some other modifiable technology, or don't give the users access to that part of the software storage - and put the rest of the code somewhere that the user can modify it.
Using telephones as an example, the software for setting the frequency etc. might have to go into ROM, but the rest could be left in user-modifiable storage.
safety-critical systems can use ROM Posted Oct 18, 2006 19:57 UTC (Wed) by RareCactus (guest, #41198) [Link] But what if the user lives in a country where he needs frequency X, but he only has a phone that is locked to frequency Y?Then the company that made the phone software is in violation of the end user clause of the GPLv3.
This is just one example of why the GPLv3 is a terrible idea, and is going to hurt commercial adoption of open source software. Companies avoid legal grey areas like this like the plague, because they don't want to waste time and money on legal hassles.
Of course, RMS doesn't care about stuff like this. He's happy to sit in his ivory tower and tinker with HURD, which they rewrite every few months or so (heavily borrowing from the Linux sources of course.) RMS does not believe in choice-- he believes that all software should be open source, and that closed source software is immoral. I am NOT kidding about this, read his web page if you doubt me.
But Linus, who is a running a real project that is making a real difference in the world, recognizes that this license is a poison pill for open source projects, and is happy to avoid it. Good for him, and for us who use and contribute to Linux.
safety-critical systems can use ROM Posted Oct 18, 2006 20:40 UTC (Wed) by RareCactus (guest, #41198) [Link] Ok, I have been searching the text of the GPLv3 to see just how it proposes to enforce end-user modification rights. This paragraph at the end of section 2 seems relevant:The Corresponding Source also includes any encryption or authorization keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances. (For instance, if the work is a DVD player and can play certain DVDs, it must be possible for modified versions to play those DVDs. If the work communicates with an online service, it must be possible for modified versions to communicate with the same online service in the same way such that the service cannot distinguish.) A key need not be included in cases where use of the work normally implies the user already has the key and can read and copy it, as in privacy applications where users generate their own keys. However, the fact that a key is generated based on the object code of the work or is present in hardware that limits its use does not alter the requirement to include it in the Corresponding Source. And section 3:
3. No Denying Users' Rights through Technical Measures. No covered work constitutes part of an effective technological "protection" measure under section 1201 of Title 17 of the United States Code. When you convey a covered work, you waive any legal power to forbid circumvention of technical measures that include use of the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing the legal rights of third parties against the work's users. So maybe I was incorrect in saying that using ROM to provide constraints on the program would be contrary to the license. I'm not sure-- I'm not a lawyer. :( In any case, there are still enough odious and ambiguous clauses in this license that I believe any sane company wouldn't touch it with a ten-foot pole.
safety-critical systems can use ROM Posted Oct 18, 2006 20:42 UTC (Wed) by coriordan (guest, #7544) [Link] I can't make sense of your scenario.
For one, I don't think any country sells telephones that don't work in other countries.
More to the point, the fact that it might be illegal for a company in whatever country to sell phones that broadcast outside of whatever range is not something that can be fixed by GPLv3.
If the company is required to lock down the frequency, they have to either put it in ROM, use DRM, or place a physical barrier (plastic casing or whatever) between the software container and the outside world. This is dictated by law, not by our licences.
GPLv3 says that DRM isn't an option, so the phone maker will have to go with ROM or a lump of plastic. The effects on phone buyers is the same.
safety-critical systems can use ROM Posted Oct 18, 2006 21:41 UTC (Wed) by bronson (subscriber, #4806) [Link] GPLv3 says that DRM isn't an option, so the phone maker will have to go with ROM or a lump of plastic. The effects on phone buyers is the same....Until the phone buyer needs to upgrade the firmware on his handset. Maybe he wants a fix for a manufacturer defect, or for his phone to follow the new bluetooth standards, or just add a feature. Happens all the time. Yet, if the software is in ROM, the user is SOL. How can anybody possibly think that my freedom is increased by putting the software that I use into ROM instead of Flash? This just boggles the mind.
safety-critical systems can use ROM Posted Oct 18, 2006 22:53 UTC (Wed) by man_ls (subscriber, #15091) [Link] Putting a small portion of software in ROM and letting the rest be user-serviceable helps freedom. Having a device which can be upgraded by the manufacturer but not by you does not help freedom; the software might as well be burnt in ROM and we would not have the illusion of freedom. Sometimes small locks and visible bars help freedom.
No one uses ROM anymore, get over it already Posted Oct 19, 2006 1:59 UTC (Thu) by svkelley (guest, #37299) [Link] What people don't seem to understand is that no one uses ROM any more in embedded devices. It is all programmable flash. What is clear is that the people working on the GPLv3 draft really lack any knowledge of modern embedded systems and the components that make them up.
Sean
Not all flash is updateable Posted Oct 19, 2006 7:23 UTC (Thu) by man_ls (subscriber, #15091) [Link] I would imagine that not all flash memory inside a device must be made user-serviceable. Even that it takes some effort to make it updateable from software. So, set the flash contents in the factory and just avoid upgrades on the field, and effectively you have a ROM, right?
Not all flash is updateable Posted Nov 2, 2006 17:27 UTC (Thu) by wookey (subscriber, #5501) [Link] Not really. Both nor and nand flash are intrinsically read/write. You could wire up a flash chip with the write line tied down so it couldn't be used bu then there is a problem about how to get the code into the device in the first place. Myabe you could do it with JTAG, but normally you have use JTAG on the CPU which then used the write line to get data into the chip.
In theory you could put some content in the chip before soldering it down, but the whole production process is now set up assuming that you don't have to do this sort of thing any more (and we all save money because of it).
So the 'just put it in ROM' is not a trivial thing. It requires significant design and production changes, if it is possible at all.
safety-critical systems can use ROM Posted Oct 18, 2006 23:12 UTC (Wed) by bojan (subscriber, #14302) [Link] > GPLv3 says that DRM isn't an option, so the phone maker will have to go with ROM or a lump of plastic. The effects on phone buyers is the same.
I don't think it's the same. Manufacturers prefer options that are cheap, because consumers prefer to buy cheaper products. In a mass production scenario (and all "consumer" devices are such), the emphasis is low cost. Putting yet another protection mechanism in place increases the cost and complexity for the manufacturer, not to mention reduces flexibility with the ROM option. Instead, they can use this money to purchase proprietary software that doesn't have the "restrictions" that this hypothetical GPLv3 software has. And they get where they want to go with less hassle.
The other player here, of course, is the mobile phone (or other service type) company providing the service. They may be inclined to like manufacturers of "flexible" but "locked" phones better than the ones that need physical intervention in case something goes wrong. After all, the user has a contract that defines conditions of entry to the network. The "locked" software here provides a convenient way for the service provider to have an easy upgrade path (in case of errors in software, changed regulation, changed contract conditions etc.), while having reasonably difficult to "hack" technical measures in place against potential disruptions on the network by users modifying devices in order to go around contract conditions.
We need to understand that it's not going to be engineers making those decisions. It's going to be accountants. The end effect would most likely be that such software would not be used in such devices. Whether this is good or bad for FOSS remains to be seen.
safety-critical systems can use ROM Posted Oct 20, 2006 8:59 UTC (Fri) by coriordan (guest, #7544) [Link] I don't think the numbers will square up. The cost of using a ROM chip, or of adding some tamper-proof seal, is probably few cents in a 100 euro phone. Whatever the cost is, I'm sure it's less than the point at which hardware manufacturers round out the figures. I don't know the marketing terms, but what I means is that if the phone plus a standard profit margin yields a price of 98 euro or 101 euro, the manufacturer will round those numbers up or down to 100 euro. I think the cost of using a ROM chip in mass production will be certainly less than 1 euro. Or whatever the cost is, it will be significantly less than having two computing systems in one - something that Motorolla find cost effective just to have a strong separation between modifiable and non-modifiable bits.
safety-critical systems can use ROM Posted Oct 18, 2006 22:42 UTC (Wed) by man_ls (subscriber, #15091) [Link] RMS does not believe in choice-- he believes that all software should be open source, and that closed source software is immoral.Stallman is known for his strong opinions on this matter, yes. Surprise surprise: believing that something is immoral is not the same as believing that something is evil, shoud be banned or the perpetrators should be executed on the spot. We people do immoral things all the time and we live on. By the way, if you said that to Stallman's face you would be treated to one of his "free software is different from open source" speeches. You would probably want to avoid that, that (and not morality) might be the real reason why people who have met Stallman or just seen him in action avoid the phrase "open source". Of course, RMS doesn't care about stuff like this. He's happy to sit in his ivory tower [...] But Linus, who is a running a real project that is making a real difference in the world, recognizes that this license is a poison pill for open source projects, and is happy to avoid it.You might be surprised to learn that GNU software (built by Stallman and accolytes) is used even more broadly than the Linux kernel (built by Torvals and company): it is also used in the *BSD family and on multiple proprietary Unices, and also on Windows and Mac OS X. It is hard to find a computer anywhere that cannot run any GNU software, and most do run it. By the way, from his ivory tower he created a license that governs now about 350 million lines of code (conservative estimate by Ingo Molnar, should be closer to a billion). To put this in perspective, it is about 70 to 200 times the size of the Linux kernel. To each his own; you may not like Stallman, but I would say he is acutely aware of actual computer programming issues. That is why he is designing the GPLv3. It is on purpose. Yes, really.
FSF software used widely? Posted Oct 19, 2006 20:33 UTC (Thu) by vonbrand (subscriber, #4458) [Link] Come on, what is used widely is BSD (and similar)-licensed stuff, i.e., sendmail, (La)TeX, X, apache, and a long list of other stuff. What the FSF really has built is a tiny fraction of open source software, and that (together with most software available freely in source code) was propelled to center stage by Linux. Before around '97, the whole GPL code was stuff that was played around with at universities and at best a curiosity outside, the only notable exception being the GCC stuff (courtesy of Cygnus, building on rather primitive FSF beginnings), and perhaps emacs (mostly in the form of xemacs).
FSF software used quite widely Posted Oct 19, 2006 23:09 UTC (Thu) by man_ls (subscriber, #15091) [Link] Come on, what is used widely is BSD (and similar)-licensed stuff, i.e., sendmail, (La)TeX, X, apache, and a long list of other stuff.Just so you broaden the spectrum of software you use every day, let me point you to some useful links: try bash as your command shell. Once you have your BSD-licensed X server running, be sure to try out GNU Object Model Environment, better known as GNOME, as your desktop: it runs on some tens of Linux distributions apart from commercial Unices and BSD variants. Also try GIMP (GNU's image manipulation program) to manipulate your images. Now that I think about it, just browse the or visit your favorite mirror, for such gems as glibc, ghostscript, gawk, wget, patch or GNU tar. They are quite useful if you ever want to put together a Linux distribution, or even a *BSD variant. You might have enough with Linux and BusyBox though, if you don't want a graphical environment; if you do, be sure to get acquainted to GTK. It is quite popular; used in Dia, Gnumeric, GnuCash and a thousand other programs.
Yes, you will probably need BSD-licensed software. Lots of it. I'm glad it is there too, and I'm thankful for the people who wrote it. There is no point in diminishing their good work. I found some references saying that a Linux distro is 3% Linux, 28% GNU software. They are from 1999 though; I haven't found anything more recent. I would venture that Linux is still playing catch up in 2006, but you seem really knowledgeable and will surely be able to supply better figures. :P What the FSF really has built is a tiny fraction of open source softwareThe FSF (and in particular Stallman) wrote the GPL. The estimate of 350+ million lines of code under the GPL comes from Ingo Molnar, kernel developer who is not so fond of the FSF; still he would probably bet for a billion rather. I wouldn't say that this is "a tiny fraction of open source software" unless I was trying to discredit the FSF. Of course not all of it was built by the FSF, but the authors liked the license enough that they generously put their work at your disposal under its conditions. Not that I want to confuse both things (code written by the FSF and code under the GPL), but since you speak about "the whole GPL code" later on, I take it that you noticed that it is an important contribution of the FSF. Even if I was trying to discredit the FSF, I would choose a different field, really. Even in a discussion about the GPLv3: I would try to dispute other facts, not the influence of the FSF in libre software.
safety-critical systems can use ROM Posted Oct 18, 2006 12:09 UTC (Wed) by svkelley (guest, #37299) [Link] stevenj wrote:>> And in any case, your flight-management example seems like something of a red herring. GPLv3 wouldn't require you to give me the keys to update itt—only the airline (the owner of the plane) needs to have the keys, and they presumably have both a legal and financial interest in not crashing their planes. (If the aircraft owner does want to crash their plane, your DRM is, sadly, not going to stop them.)
>Which seems to answer your complaint about the first paragraph.
However, this fails when you consider that the avionics devices can be sold to private individuals not just to airlines. Again, you run the risk of serious liability *and* FAA regulation.
Sean
safety-critical systems can use ROM Posted Oct 18, 2006 16:05 UTC (Wed) by stevenj (guest, #421) [Link] If a private individual owns a plane and wants to crash it, witholding keys to their DRM isn't going to stop them. So what exactly does your DRM accomplish? Your scare scenario just doesn't make sense to me. Regarding legal restrictions, do you have a concrete example of a current FAA regulation that requires DRMed flight-management systems?
safety-critical systems can use ROM Posted Oct 18, 2006 6:13 UTC (Wed) by bignose (subscriber, #40) [Link] > Every piece of software has bugs.
Yes. And what the vendor considers a "bug" isn't always what the user considers a "bug". A user in legal possession of a device should be the one that decides whether a bug fix goes into the device or not.
> Once you make it a ROM, you can't easily fix it. On the other hand, a
No. It can only receive bug fixes from *one* place -- the holder of the secrets that allow the modified software to run. The GPL is designed *explicitly* to allow the user to have this power, so that if the software is modifiable at all, they can choose bug fixes and improvements from any available source.
Consider: in a great deal of embedded systems, many things the vendor wants to "fix" as bugs are actually features that the user wants to remain in the software. The GPL is designed so that the vendor can't be the only one to have that freedom.
And, of course, if they don't want their users to have that freedom, vendors are not forced to choose software under GPL at all. The goal here is to increase the amount of software with guaranteed user freedoms, so that it becomes less and less economically viable to avoid giving those freedoms to user. But if a vendor really want to write software without using GPLed sources to restrict user freedoms, they can pay that ongoing cost.
safety-critical systems can use ROM Posted Oct 18, 2006 6:32 UTC (Wed) by timschmidt (guest, #38269) [Link] > No. It can only receive bug fixes from *one* place -- the holder of the> secrets that allow the modified software to run. The GPL is designed > *explicitly* to allow the user to have this power, so that if the software > is modifiable at all, they can choose bug fixes and improvements from any > available source.
And it's not like shipping out a $1 hobbled flash chip or actual ROM is too costly a thing to do - even a hundred times - for a multi-hundred-million dollar plane.
--tim
safety-critical systems can use ROM Posted Oct 18, 2006 7:02 UTC (Wed) by bojan (subscriber, #14302) [Link] > And it's not like shipping out a $1 hobbled flash chip or actual ROM is too costly a thing to do - even a hundred times - for a multi-hundred-million dollar plane.
I don't think letting regular users change ROM chips inside mobile phones and Tivo's would be something that those manufacturers would like doing.
safety-critical systems can use ROM Posted Oct 18, 2006 10:17 UTC (Wed) by bignose (subscriber, #40) [Link] > I don't think letting regular users change ROM chips inside mobile phones> and Tivo's would be something that those manufacturers would like doing.
Exactly. That's why it's important to ensure that free software can't be warped by such manufacturers. If they want the freedoms associated with the software, they must let their users have those same freedoms; so those users can get their device's software improved by anyone, not just those approved by the manufacturer.
safety-critical systems can use ROM Posted Oct 18, 2006 11:07 UTC (Wed) by bojan (subscriber, #14302) [Link] > That's why it's important to ensure that free software can't be warped by such manufacturers.
Sadly, if manufacturers (PCs included) get pushed into DRM-or-nothing direction by big content providers, free software as defined by GPLv3 would simply not be an option as no manufacturer would give you their hardware keys. And given their contracts with content providers and the desire to ship hardware that can present whatever content providers make (i.e. what the masses like to see), they would pick revenue over freedom any day (most manufacturers are big business, which is all about making money). End result, such free software just wouldn't run on any hardware, which would make it irrelevant.
Now, whether that's worse than GPLv2 free software that can be locked down through hardware DRM, I don't know.
safety-critical systems can use ROM Posted Oct 18, 2006 11:26 UTC (Wed) by bignose (subscriber, #40) [Link] > Sadly, if [the DRM cartel gets their way] End result, such free software> just wouldn't run on any hardware, which would make it irrelevant.
That sounds like the DRM cartel's ideal outcome, yes.
Nothing makes it more certain that us assuming it's already inevitable.
safety-critical systems can use ROM Posted Oct 18, 2006 18:37 UTC (Wed) by Arker (guest, #14205) [Link] It's far worse, actually.
A basic ethical principle is to avoid doing harm. If you write software and release it under a license that allows it to be Tivoised, you're aiding and abetting the harm they perpetrate. You'd be better off, ethically speaking, to do nothing. If you license it so they can't do that, and they go ahead and write their own software to do the same thing instead, at least you have not aided them. Additionally, if they have to write their own software, that takes time and resources from them, weakening them. It may be a very small effect, but markets sometimes turn on very small effects.
safety-critical systems can use ROM Posted Oct 19, 2006 12:21 UTC (Thu) by nim-nim (subscriber, #34454) [Link] > Sadly, if manufacturers (PCs included) get pushed into DRM-or-nothing> direction by big content providers, free software as defined by GPLv3 would > simply not be an option as no manufacturer would give you their hardware > keys
The power balance is not so simple. As other stated, manufacturers worry most about per-device cost.
Let them freely DRM-ize their existing and planed FLOSS-using products and they'll bow to content providers easily. Make the DRM-ization costly (requiring flash replacement by ROM, existing software replacement by other code, cutting future access to FLOSS code) and you bet manufacturers will fight tooth and nail against mandatory DRMs.
safety-critical systems can use ROM Posted Oct 18, 2006 23:33 UTC (Wed) by bojan (subscriber, #14302) [Link] > No. It can only receive bug fixes from *one* place -- the holder of the secrets that allow the modified software to run.
Yes, that's what I meant. The manufacturer of the device and/or service provider can do that easily. And that's exactly what they want.
> The GPL is designed *explicitly* to allow the user to have this power, so that if the software is modifiable at all, they can choose bug fixes and improvements from any available source.
Hmm... I don't think a lot of service providers would appreciate such freedom in their devices. After all, users usually enter into contracts with service providers about "permitted behaviour" on the network. Having a device on a network that can be easily modified can cause network disruptions that affects other users (i.e. customers). Not good for business...
I know, they can use proprietary software. I reckon that's exactly what they would do if the only other option was GPLv3 licensed software. Maybe that's good for FOSS - I don't know.
safety-critical systems can use ROM Posted Oct 19, 2006 0:01 UTC (Thu) by bignose (subscriber, #40) [Link] > I don't think a lot of service providers would appreciate such freedom in> their devices.
*Whose* devices? The legal owner of the device, not the service provider, gets to say what software changes occur on it.
In the case where the service provider *is* the legal owner of the device, they get to change it however they like. Not otherwise.
> After all, users usually enter into contracts with service
Right. And if the user causes their device to breach that "permitted behaviour", they lose their service. If those are the terms of the service, so be it.
This is quite orthogonal to the issue of preventing a legal owner of a device from getting their software improvements from anywhere they like and installing them.
safety-critical systems can use ROM Posted Oct 19, 2006 0:18 UTC (Thu) by bojan (subscriber, #14302) [Link] > *Whose* devices? The legal owner of the device, not the service provider, gets to say what software changes occur on it.
Not necessarily. It all depends on the contract the owner of the device has with the provider.
I think you also interpreted my sentence too literally. Sure, once the device is sold it belongs to the user. But when it's displayed in the shop, it is "their device" (i.e. the service provider's). Regardless, it's the contract that determines who gets to update the software.
I know, there are examples with cars and how you can do whatever you like with them once they have been sold to you. But those analogies don't apply here, as there is (generally) no contract of service provision between the car manufacturers and car users.
safety-critical systems can use ROM Posted Oct 19, 2006 0:59 UTC (Thu) by bignose (subscriber, #40) [Link] > > *Whose* devices? The legal owner of the device, not the service> > provider, gets to say what software changes occur on it.
> Not necessarily. It all depends on the contract the owner of the device
The legal owner of the device gets to decide what changes are made to the device. The service provider gets to say when and how to provide whatever service they're providing.
> Sure, once the device is sold it belongs to the user. But when it's
This discussion is in the context of the device being in legal possession of the user, and who gets to say what software changes can be made from that point. Before that time, this discussion doesn't apply, and the device maker can make any software changes they like.
> Regardless, it's the contract that determines who gets to update the
No. It's the contract with the service provider that determines *whether and how the service is provided*. If the device owner decides they still want to have changes made to the device, that's their choice.
To put it another way: The service contract gets to say things only within the bounds of the service. The device can be used for a much wider range of things not included in that contract, and the service provider has nothing to say about that.
The legal owner of the device should be allowed to do anything they want with the device, *including* breach their contract, and wear the consequences. It's not for the device vendor to second-guess the legal system and deliberately make it technically impossible to do things the vendor doesn't like. Not with free software, anyway.
safety-critical systems can use ROM Posted Oct 19, 2006 1:46 UTC (Thu) by bojan (subscriber, #14302) [Link] > No. It's the contract with the service provider that determines *whether and how the service is provided*. If the device owner decides they still want to have changes made to the device, that's their choice.
Again, not necessarily. Contracts can contain all kinds of promises asked from the user. They can even ask that the user not be allowed to modify the device *at all*, but they would probably ask that user cannot modify the device and then connect it to the same network. The effect (for the provider) would be the same.
Attempts to cirumvent technical protection measures may be legal in some countries and illegal in others. In any case, an attempt to connect such a device to provider's network would be a violation of the contract, if that was one of the conditions. An attempt to connect any other device to such a network would probably be some sort of trespassing.
> To put it another way: The service contract gets to say things only within the bounds of the service. The device can be used for a much wider range of things not included in that contract, and the service provider has nothing to say about that.
That also may not be true. A contract can contain the language that prevents the user from using the device for any other purpose.
Contracts are private agreements between parties. They can contain all kinds of "surrender of freedom", as they are entered into voluntarily.
> The legal owner of the device should be allowed to do anything they want with the device, *including* breach their contract, and wear the consequences. It's not for the device vendor to second-guess the legal system and deliberately make it technically impossible to do things the vendor doesn't like.
They would not be second-guessing the legal system at all. They could do it through contracts. In some countries they may even have out-of-contract protection through DMCA and such.
> Not with free software, anyway.
Well, that's the issue here, really. I don't have a definitive answer to that. I'm just trying to present variuos points of view that parties involved may have.
|
|||||||||||||