Recent Features
| |||||||||||||
FSF should separate GPLv3 changes (Linux.com)FSF should separate GPLv3 changes (Linux.com)Posted Oct 18, 2006 4:09 UTC (Wed) by svkelley (guest, #37299)In reply to: FSF should separate GPLv3 changes (Linux.com) by man_ls Parent article: FSF should separate GPLv3 changes (Linux.com)
Complexity in software development and hardware interaction will increase, regardless of whether DRM is a part of a given product or not. The fact is FSF ambition with opening up commercial hardarware for hacking that use FSF software presumes that there are sufficient people that really care. Consumers don't. Companies have to make a living. They likewise have restrictions on liability. I am *not* going to give you loader access to my embedded flight management system, regardless of how altruistic your motivations may be.
Sean
(Log in to post comments)
safety-critical systems can use ROM Posted Oct 18, 2006 4:50 UTC (Wed) by stevenj (guest, #421) [Link] 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. 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 it—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.) 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.
safety-critical systems can use ROM Posted Oct 18, 2006 5:09 UTC (Wed) by bojan (subscriber, #14302) [Link] > 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.
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.
safety-critical systems can use ROM Posted Oct 18, 2006 11:51 UTC (Wed) by smitty_one_each (subscriber, #28989) [Link] >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.
For what values of 'always'? Among the long-term challenges here is the one where an idealogue fundamentally tweaks the 'spirit' of the GPL in questionable ways, and makes a big show of soliciting input, all the while shunting all input to /dev/null.
While sympathizing with where the FSF is trying to go, I'd argue that the market, as opposed to the license, is a preferred feedback loop.
free market is not the answer Posted Oct 18, 2006 12:42 UTC (Wed) by man_ls (subscriber, #15091) [Link] The free market has already spoken: use Windows, forget about Linux. Join AOL. iPod rules. Do you really want to leave your decisions to the market?
free market is not the answer Posted Oct 18, 2006 17:25 UTC (Wed) by smitty_one_each (subscriber, #28989) [Link] Your reply doesn't seem to take into account the increasing success of FOSS, and companies built upon it.AOL is TU. iPod rules what? I'm not arguing blind faith in the market; it is certainly subject to manipulation. However, over time, the court of public opinion, as expressed in the market, tends towards reasonableness.
free market is not the answer Posted Oct 18, 2006 22:14 UTC (Wed) by man_ls (subscriber, #15091) [Link] Yeah, the court of public opinion has chosen Windows, iPod (73% market share) and AOL (19% market share, #1 ISP with difference). Have you bought your copy of Oracle yet?Your reply doesn't seem to take into account the increasing success of FOSS, and companies built upon it.Yeah right. The most visible "FOSS" (what a horrible acronym), i.e. libre program is probably Firefox, and the most extended; it has been competing with Internet Explorer for ages, it is free (as in beer) as the competition, but also libre, there is a buoyant company behind it and it is the direct descendant of Netscape which in 1994 was the only reasonable choice. And IE has had the most horrible track record in performance, bugs and security that you can imagine; as to marketing Microsoft is now a convicted monopolist because of it. Yet last month our "FOSS" champion had 11 or 12% market share, depending on who you believe. Great success in the "court of public opinion". Reasonableness indeed. The free market is an economic mechanism, which must be nurtured and kept within bounds constantly through regulation. Its effect is to lower prices and improve efficiency. It doesn't choose technologies or morals; it just goes with the cheapest option. When two $0 options meet, convenience seems to win every time. Let's stop attributing human qualities to an economic phenomenon, please. We might try to make something other than money drive us for a change.
free market is not the answer Posted Oct 19, 2006 13:51 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link] >Let's stop attributing human qualities to an economic phenomenon, please. We might try to make something other than money drive us for a change.
Fair enough, but I have some difficulty with trying to view economic phenomena as pure abstraction: economics is a derivative of human behavior, subject to all of the usual chaotic influences. How does one _not_ anthropomorphize a fundamentally anthropomorphic thing?
I do agree, on a personal level, that "something other than money" would make a great driver. Externalizing my own non-monetary motives would probably bring in howls of derisive laughter, however. Money, OTOH, is the low-common-denominator metric that everyone at leasts understands, possibly without liking. Abstract motives attenuate rapidly; cold, hard cash drives far more people.
If you step back and look at the last couple of decades from a distance, FOSS has gone from nowhere to at least somewhere, and its adoption has a positive slope. Proprietary stuff, OTOH, is growing increasingly painful on all levels. I'll venture a guess that Vista proves to be the last OS excreted by Redmond.
Give it a couple of decades. Future so bright, we gotta wear cheap sunglasses.
safety-critical systems can use ROM Posted Oct 18, 2006 14:10 UTC (Wed) by cventers (subscriber, #31465) [Link] > For what values of 'always'? Among the long-term challenges here is the> one where an idealogue fundamentally tweaks the 'spirit' of the GPL in > questionable ways
I feel saddened that anyone sees things this way, especially given that
> ...and makes a big show of soliciting input, all the while shunting all
Pardon me, but do you have any evidence that this is what is happening?
In fact, the only parties I've ever heard complaining about this
(Ironically, the one kernel developer that /did/ participate was seen
Personally, based on the statements of some kernel developers, I'm sad to
safety-critical systems can use ROM Posted Oct 18, 2006 18:24 UTC (Wed) by nim-nim (subscriber, #34454) [Link] > While sympathizing with where the FSF is trying to go, I'd argue that the> market, as opposed to the license, is a preferred feedback loop.
ROTFL:
1. your licensing terms are part of your market offer
safety-critical systems can use ROM Posted Oct 19, 2006 9:54 UTC (Thu) by drag (subscriber, #31333) [Link] "While sympathizing with where the FSF is trying to go, I'd argue that the market, as opposed to the license, is a preferred feedback loop."
Well I don't know if you noticed, but FSF has invited many different people and many different corporations to join in on the discussion and I haven't seen a person or company actually involved in the proccess bitch about how the FSF is operating or complaining about the GPLv3 (although people say that there are still ways to improve it.) Many of them are major propriatory software makers and holders of large amounts of patents.
The only bitching I see is from people that refused to join in on it in the first place. I mean it would be different if they joined in and became disillutioned about it and dropping out and THEN complaining. Then it would have a meaningfull impact.
I mean seriously folks, come on. It's not like they are making it _difficult_.
After all the GPLv3 isn't even released yet? So how can you gauge the market based on a vocal group hating a beta version of the product (ie the license draft.)
Bitching over GPLv3? Posted Oct 19, 2006 20:46 UTC (Thu) by vonbrand (subscriber, #4458) [Link] The only bitching I see is from people that refused to join in on it in the first place. I mean it would be different if they joined in and became disillutioned about it and dropping out and THEN complaining. Then it would have a meaningfull impact. Said people have repeatedly stated that they objected to the whole "anti-DRM" idea well before the whole GPLv3 process started. They have had rows with RMS (and the FSF) for ages. Why should they now forget all that and just run with the crowd, expecting to be listened to this time around?
Bitching over GPLv3? Posted Oct 19, 2006 21:18 UTC (Thu) by khim (subscriber, #9252) [Link] Why should they now forget all that and just run with the crowd, expecting to be listened to this time around? They sure don't. And I respected Linux and kernel developers while they said "If you want politics, go over to the projects which do politics. We do code" and acted like it. But when they started doing politics I've lost most of the respect and then the question why arose. I mean: you "have had rows with RMS (and the FSF) for ages". Fine. You ignore the whole GPLv3 process since you don't believe your participation can change anything. No problem. But then you suddenly start "doing politics", you raise big stink, etc. Why ? If you can answer the question - I'm all ears. And I remember previous "row" very well indeed. When Linus started using BitKeeper RMS said right away that it's bad decision and it's so very sad that kernel developers are using non-free software for essential things. And RMS was right back then BTW. But have you seen RMS's loud and noisy campaign titled "Let's force kernel developers to drop BitKeeper" or anything like this ? I sure don't. It's one thing when you disagree with someone - and it's totally different thing when you slander and bad-mouth someone, sorry. Kernel developers crossed this line 2006.09.15...
Bitching over GPLv3? Posted Oct 19, 2006 21:57 UTC (Thu) by bronson (subscriber, #4806) [Link] Erm, where are the kernel devs bad-mouthing the FSF? Behind that link I see mostly glowing praise for the FSF, the GPL, and many of the GNU software products they have enabled. I think the kernel devs have expressed their opinion very professionally and clearly and they seem to have a good point.
Khim, if you consider this slander and bad-mouthing I do hope that you slander and bad-mouth me some time soon! :)
Bitching over GPLv3? Posted Oct 20, 2006 7:36 UTC (Fri) by khim (subscriber, #9252) [Link] Erm, where are the kernel devs bad-mouthing the FSF? On Groklaw (mostly Linus), comments on other sites (including LWN), interviews, etc. But there too. You don't need dirty words to slander and bad-mouth - it's possible to do it with great politeness. I think the kernel devs have expressed their opinion very professionally and clearly and they seem to have a good point. May be, but after that piece (and you are right - it's quite "politically correct") it become clear that they are not content with coding. They want to play politics - but they don't like open confrontation where FSF or RMS can respond. Do you know anyone who's using (or used) such tactics ? Right: it's our dear McBride. Do you like his approach ? Do you feel it's correct approach ? Why it's good for kernel developers then ? Because they are good guys ? Sorry but while all talks about GPLv2 is were internal discussion between kerel developers I was content and respected their right. It was open to the world - but that's just how linux development works. But when you start using "SCO tactic" (talk to the press first, to the offending party second) - all previous talks are changing colour: was they really only internals talk which become public since all talks about kernel development are public ? Or were they intended for the general public from the start ? And why they only talk to the general public - never to the FSF or RMS ? When they accuse FSF in "a fundamental violation of the trust" I'd like to see more the just "while we may argue forcefully for our political opinions, we may not suborn or coerce others to go along with them". GPL was always political: if "The licenses for most software are designed to take away your freedom to share and change it [but GPL is different]" (the very first sentence of the GPLv2) is not political then what is political ? And promise a user who needs changes in the system will always be free to make them himself, or hire any available programmer or company to make them for him was written years before GPLv2 (let alone GPLv3) so it's kind of hard to argue that "DRM-clause" constitute "violation of trust" - I already find it quite hard to fullfill this promise without such clause ("source code for all modules" plus "the scripts used to control compilation and installation of the executable" are not enough in today's world - or so it seems). P.S. The best summary of my thoughts: And that's about it: track record for RMS's OS kernel development is poor but track record for writing good licensed is good (not excellent due to GFDL, but if you'll compare GFDL with CCL...).
Bitching over GPLv3? Posted Oct 20, 2006 11:59 UTC (Fri) by smitty_one_each (subscriber, #28989) [Link] >When they accuse FSF in "a fundamental violation of the trust" I'd like to see more the just "while we may argue forcefully for our political opinions, we may not suborn or coerce others to go along with them". GPL was always political: if "The licenses for most software are designed to take away your freedom to share and change it [but GPL is different]" (the very first sentence of the GPLv2) is not political then what is political?
Are not licenses are about regulating issues of legality? If the GPL is political, are you contending that the FSF is, in fact, a political party? I have always, in my 5 or 6 years of membership, considered it a Foundation, and a *community*. I really don't buy off on RMS's philosophical/political views. Am I a bad person?
>Would I trust RMS to write a successful OS kernel?
>Would I trust kernel developers to choose (let alone write) successful license?
safety-critical systems can use ROM Posted Oct 19, 2006 20:13 UTC (Thu) by vonbrand (subscriber, #4458) [Link] 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. That is completely absurd. To place said software in ROM makes it next to impossible to update/fix, for absolutely no good (technical) reason. It will even go against the (probable) requirement to be able to update said software ASAP in all deployed systems in case some failure mode is discovered later on. Won't happen, period. If it means "don't use YaddaYadda-licensed software", they'll write their own, or get it elsewhere. In that kind of scenario, the cost of QA in general is probably much higher than developing stuff from scratch, so there is no particular incentive to go open source.
FSF should separate GPLv3 changes (Linux.com) Posted Oct 18, 2006 4:59 UTC (Wed) by beoba (guest, #16942) [Link] Then don't use GPLed code. Problem solved.
FSF should separate GPLv3 changes (Linux.com) Posted Oct 18, 2006 6:37 UTC (Wed) by bronson (subscriber, #4806) [Link] GPLv3, love it or leave it!!
FSF should separate GPLv3 changes (Linux.com) Posted Oct 18, 2006 11:04 UTC (Wed) by arcticwolf (guest, #8341) [Link] Same for the GPLv2, or, in fact, any software license on the market. If you don't like the license I put *my* code under, then don't use it. Read up on copyright law instead, and here's some cheese to go with your whine.Seriously, I have no idea where people get the idea that they're *entitled* to someone else's code. It's me who chooses to make it available - I'm making you an offer. Take it or leave it, but don't complain that I'm being unfair when I'm giving you my work for free.
FSF should separate GPLv3 changes (Linux.com) Posted Oct 18, 2006 7:00 UTC (Wed) by man_ls (subscriber, #15091) [Link] The fact is FSF ambition with opening up commercial hardarware for hacking that use FSF software presumes that there are sufficient people that really care. Consumers don't.True. Consumers are by definition bovine-like entities with a limited range of choices. The idea is to give the means to those consumers to become hackers. It has worked for some of us. The current breed of developers I know had 8-bit computers as children. They came at least with a BASIC interpreter, and that is how we learned to program; most people would just play games on them. Nowadays Windows and Mac OS X computers come with nothing similar. Even so you can download a whole development environment for free. GNU/Linux systems come with everything needed so that you can modify even the operating system. Some of those "consumers" do probably take advantage of it, even if it is not a huge commercial pressure -- as it was not with 8-bit computers and BASIC.
FSF should separate GPLv3 changes (Linux.com) Posted Oct 18, 2006 11:23 UTC (Wed) by MathFox (guest, #6104) [Link] The current breed of developers I know had 8-bit computers as children. They came at least with a BASIC interpreter, and that is how we learned to program; most people would just play games on them. Nowadays Windows and Mac OS X computers come with nothing similar.Open a terminal window under Mac OSX and type: $ echo $SHELL /bin/bash $ which python /usr/bin/pythonetc. etc. The possibilities are still there! In "8-bit times" not every child with a computer started programming, 90% was happy with just playing commercial games. Things aren't much different nowadays; only a small percentage of computer users will become hackers. (How much is 1% of 6 billion?)
FSF should separate GPLv3 changes (Linux.com) Posted Oct 18, 2006 7:25 UTC (Wed) by hofhansl (guest, #21652) [Link] Companies have to make a living. They likewise have restrictions on liability. I am *not* going to give you loader access to my embedded flight management systemLast time I looked nobody is being held at gunpoint and forced to use open source software. You use the work of others? Then respect the rules set by the authors. If you don't want to do that write it yourself. As I stated somewhere below, TIVO is circumventing the freedoms granted by the GPL. They are taking work from others and denying the freedoms granted by the license. If they can't live with people recompiling and running new versions of the software, why don't they write their own OS or pay up to another vendor?
FSF should separate GPLv3 changes (Linux.com) Posted Oct 18, 2006 12:33 UTC (Wed) by svkelley (guest, #37299) [Link] >>As I stated somewhere below, TIVO is circumventing the freedoms granted by the GPL. They are taking work from others and denying the freedoms granted by the license. If they can't live with people recompiling and running new versions of the software, why don't they write their own OS or pay up to another vendor?
Indeed, that is what will happen. Companies can and will choose WinCE and other commercial operating systems due to this restriction. Love it or leave it, understood.
We aren't making devices for hobbyist programmers. I am not an exception. In fact, just my interest in embedded Linux has been an uphill battle. GPLv3 essentially puts a knife in many interested developers like myself who want to see their company make greater use of embedded Linux. I am not making this liability and certification issue up. These are real commericial costs that have to be factored into the decision making for doing a device at all. I see an overall lack of understanding of consumer device development in this thread. Products come and go. They are changed quite frequently - sometimes they have a 3-6 month lifespan. We are not talking PCs with a standard platform for development.
Sean
FSF should separate GPLv3 changes (Linux.com) Posted Oct 18, 2006 13:27 UTC (Wed) by khim (subscriber, #9252) [Link] I see an overall lack of understanding of consumer device development in this thread. True. And that's good thing. I (and most of others) don't care about products "lifespan on market". I do care about usage. I f I do want to tinker with the box in the future - I'll buy Linux-based device. If I do not want to tinker with the box - I'll buy WinCE or VxWorks or whatever. My friends bought WTR54GL (and not WRT54G which is cheaper) exactly to have the ability to play with it later. When I buy the linux-based device and later (when this device is of course already fogotten by the manufacturer and is not supported) found out that there are no way to tinker with it - it feels like betrayal of trust... Now if there are no way to bring Linux-based tweakable device on the market - bring WinCE's or VxWork's based one. This is where I truly don't care what's inside of the box: if I don't have the ability to change it what difference it makes if it's MS-DOS, Linux or even OS/360 ?
FSF should separate GPLv3 changes (Linux.com) Posted Oct 18, 2006 14:19 UTC (Wed) by cventers (subscriber, #31465) [Link] I see it going one of three ways:
1. People get incredibly paranoid, over-react, and fork important
2. The kernel developers stand largely alone in sticking their nose up in
3. Enough GPLv3 software exists that some companies pay for WinCE or
By the way, you can replace 'hobbyist' with 'user' in these scenarios.
And I hear that you're not making devices for hobbyist programmers, but
FSF should separate GPLv3 changes (Linux.com) Posted Oct 18, 2006 21:30 UTC (Wed) by RareCactus (guest, #41198) [Link] I don't know which way each particular project will go, but I suspect that most of the important ones will stay GPLv2.In particular, it is certain that we will have at least a GPLv2-only kernel and libc.
None of this, of course, has anything to do with whether hobbyists will be able to modify things. That will be determined by what kind of DRM laws are passed, and what kind of hacked hardware consumers are able to get through the black or grey market.
FSF should separate GPLv3 changes (Linux.com) Posted Oct 18, 2006 21:39 UTC (Wed) by cventers (subscriber, #31465) [Link] > None of this, of course, has anything to do with whether hobbyists will> be able to modify things. That will be determined by what kind of DRM > laws are passed, and what kind of hacked hardware consumers are able to > get through the black or grey market.
You claim to be a kernel developer in another one of your posts, and I
The anti-Tivoization clause in GPLv3 is a clarification intended to
In fact, if the ability of hobbyists to modify things were something
FSF should separate GPLv3 changes (Linux.com) Posted Oct 18, 2006 13:41 UTC (Wed) by anandsr21 (guest, #28562) [Link] That is what the Linux Kernel team is afraid off. The World Domination doesn't look so promising to them. They don't care if Linux loses its freedom in the process. They care only about World Domination. I think it will be a hollow victory if all the devices end up being locked up.
I do like to think that they care more about the splitting of the community. But that is not visible in their comments. I wish there were more people like Alan Cox that could say exactly what was wrong with GPLv3. Most comments coming from the Kernel Camp are Trollish and FUDish.
FSF should separate GPLv3 changes (Linux.com) Posted Oct 18, 2006 14:25 UTC (Wed) by cventers (subscriber, #31465) [Link] > Most comments coming from the Kernel Camp are Trollish and FUDish.
Absolutely, and I think it is offending a lot of Linux users, developers
Disagreeing about a software license is one thing, but what I've stood
FSF should separate GPLv3 changes (Linux.com) Posted Oct 18, 2006 21:15 UTC (Wed) by RareCactus (guest, #41198) [Link] Linus chose the GPLv2 because he liked the license, not because he necessarily agreed with RMS in any other way.
I am a Linux developer, and I agree with Linus' choice, then and now. If you want politics, go over to the projects which do politics. We do code.
FSF should separate GPLv3 changes (Linux.com) Posted Oct 18, 2006 21:25 UTC (Wed) by cventers (subscriber, #31465) [Link] Color me a little confused with your response. I'm not calling the kernelguys out because they dislike GPLv3. I think they have as much right as anyone else to have an opinion on what license best suits their code. I think it is likely (given discussions on LKML, the views of the most active kernel developers, and practical matters) that Linux will remain GPLv2, and I'm perfectly okay with that. I'm not offended.
What I'm not okay with is the ad hominem attacks aimed at RMS and the
FSF should separate GPLv3 changes (Linux.com) Posted Oct 19, 2006 0:19 UTC (Thu) by walken (subscriber, #7089) [Link] > I am a Linux developer, and I agree with Linus' choice, then and now. If you want politics, go over to the projects which do politics. We do code.
What about the document titled 'The Dangers and Problems of the GPLv3' - was that code or politics ?
Please get off your high horse. You can't dismiss people arguments as 'doing politics' when they're only replying to your own inflamatory statements.
FSF should separate GPLv3 changes (Linux.com) Posted Oct 19, 2006 15:24 UTC (Thu) by GreyWizard (guest, #1026) [Link] Well said!
|
|||||||||||||