Weekly Edition
Return to the Press pageSponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
FSF should separate GPLv3 changes (Linux.com)
Bruce Byfield thinks that
GPLv3 changes should be looked at separately, not as one huge change.
"The trouble with GPLv3 is that it contains the accumulation of 15
years' worth of changes. Some of these changes, such as improvements in the
clarity of the language or attempts to make the license more acceptable in
a variety of international jurisdictions or to cover BitTorrent downloads,
might be accepted with hardly a dissenting comment, if they could be agreed
upon separately. Even those who prefer the GPLv2 would probably admit that
such changes are necessary improvements that make the license easier to
understand and use."
(Log in to post comments)
FSF should separate GPLv3 changes (Linux.com) Posted Oct 17, 2006 18:15 UTC (Tue) by cventers (subscriber, #31465) [Link] I have an alternate suggestion - things should proceed exactly as theyhave been proceeding, and anyone with concerns about the license should take them to the FSF's open drafting process. When the FSF releases the new GPL in mid-January, those who like the license should switch, and those that do not should stay.
Everyone wins!
bad idea Posted Oct 17, 2006 18:20 UTC (Tue) by coriordan (guest, #7544) [Link] To the extent that exceptions are necessary, they can be written using section 7a. An LGPL-style exception will be necessary, and one it is in the public drafting process: http://gplv3.fsf.org/comments/lgpl-draft-1.html. A DRM exception might be useful, if some people don't want to stop tivoisation but do want the other changes in the licence. Time will tell. Otherwise, it sounds like he's suggesting that it would be good to have 10 incompatible GPLs, for mostly trivial reasons. I read the article, but I don't see an explanation for why that would be good.
Not Enough Posted Oct 17, 2006 21:54 UTC (Tue) by GreyWizard (subscriber, #1026) [Link] That won't satisfy Torvalds or fellow travelers because they don't like that additional permissions can be stripped away. Torvalds even refused to use the existing LGPL for one project because it can be converted to the GPL. Obviously that feature is important for license compatibility but they are sufficiently hostile to the Free Software Foundation to presume bad faith.
Not Enough Posted Oct 18, 2006 4:43 UTC (Wed) by beoba (guest, #16942) [Link] The only response I could think of:
D R A M A
Not Enough Posted Oct 18, 2006 6:23 UTC (Wed) by bronson (subscriber, #4806) [Link] "Torvalds even refused to use the existing LGPL for one project because it can be converted to the GPL."
What project? Linus likes the GPLv2: http://lkml.org/lkml/2006/9/24/246
sparse Posted Oct 18, 2006 7:20 UTC (Wed) by xoddam (subscriber, #2322) [Link] What project?The sparse C parser & checker. The FAQ begins: There isn't a web page for this software and no-one packages it AFAICT, which is pretty unusual. It's developed more-or-less in sync with the kernel and the 'sparse annotations' of the kernel source. You have to fetch the git repository before you can read the FAQ... rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/sparse.git/ (or a tarball from here)
sparse Posted Oct 18, 2006 10:21 UTC (Wed) by nix (subscriber, #2304) [Link] 'Religious', hmm. As in 'if we'd not had this attitude we'd have many fewer front-ends and back-ends than we do now'. That seems more, I don't know, *pragmatic* to me.
"Religious" Posted Oct 18, 2006 19:50 UTC (Wed) by GreyWizard (subscriber, #1026) [Link] When Torvalds says "religious" he appears to mean "having a strong opinion which I don't share." Requiring that users be allowed to modify and reinstall software? Religious. Lengthy paeons in praise of tit-for-tat? Pragmatic! Don't spoil the fun with inconvenient logic.
sparse Posted Oct 20, 2006 6:24 UTC (Fri) by viro (subscriber, #7872) [Link] That's an interesting argument, seeing that gcc-based thing in thatarea (stronger typechecking, etc.) is simply proprietary. I'm not saying that Stanford Checker is a bad thing. But it's closed by any definition. I've worked on sparse. A lot. Rewrite of preprocessor more or less from scratch, lots and lots in type inferrence stuff (starting with FP handling, non-lvalue composites, bitwise extensions, etc.), many parts in phase 2 and phase 3, etc. There had been early architecture decisions I'm unhappy with, but compared to gcc it's a pleasure to hack on. In a very large part because nobody has been playing games along the lines of "what if this change makes it easier to abuse the thing into a separate frontend for their backend?"
Unlike gcc, implementing new class of checks is not a monumental
Pragmatic/Religious Posted Oct 23, 2006 18:46 UTC (Mon) by GreyWizard (subscriber, #1026) [Link] I don't doubt the technical merits of sparse and you make a good case for separating licensing goals from technical decisions, but this seems to miss the point. GPL restrictions on derivative works are imposed for pragmatic reasons and have had positive consequences. Refusing to make it easy to separate the front and back ends of GCC may be a mistake but "religion" has nothing to do with it. Brandishing pejorative terms as Torvalds does is not productive.
Pragmatic/Religious Posted Oct 24, 2006 0:03 UTC (Tue) by viro (subscriber, #7872) [Link] Both license choice and technical decisions were driven by the samepre-set political decision. And I wouldn't call it pragmatic - even if you agree that blocking creation of (independent) proprietary backends had been worth the trouble, you still have 100% genuine proprietary derivatives of gcc that might very well not be such if they would not be artificially made work-intensive. Well done, RMS... The same thing had served as additional barrier to alternative free compilers and _that_ contributed to gcc stagnation in late 90s (basically, until egcs fork). That same thing had actually _reduced_ the number of viable frontends; granted, m3 folks had their own kind of fucked-in-headness that added problems, but... Basically, we have all usual results of PHB with a vision forcing political, er, considerations on a project and not bothering to think of consequences. BTW, "religion" is not the word I would use, but then I'm not as polite as Linus. My preference for description would be "SNAFU by a high-level suit with agenda".
Pragmatic/Religious Posted Oct 25, 2006 23:01 UTC (Wed) by nix (subscriber, #2304) [Link] Again, the decision had positive consequences: but maybe you don't careabout the existence of the Objective C and (IIRC) C++ frontends. Some of us do.
Pragmatic/Religious Posted Oct 25, 2006 23:36 UTC (Wed) by viro (subscriber, #7872) [Link] ObjC is definitely in the same realm as m3 (if even that - cvsup isseriously used and non-trivial, whatever.app tends to be... Applish, for the lack of printable description). As for the C++... I would be very surprised if that one hadn't used enough code from C frontend at any point in its evolution to be a clear derivative, but ICBW.
Note that "your library is a derivative of my library, you get to
If anything, I would expect any losses to be in weird backends for
sparse Posted Oct 25, 2006 23:00 UTC (Wed) by nix (subscriber, #2304) [Link] The Stanford Checker is, as I understand it, no longer based on GCC.
And, yes, it *is* easier to hack on a project that contains a frontend for
But there aren't any `games' being played in the GCC source to make it
(The largest remaining barrier is all the implicit assumptions inside
(Joe, feel free to correct me if I'm talking rubbish: I'm merely an
sparse Posted Oct 26, 2006 0:08 UTC (Thu) by viro (subscriber, #7872) [Link]
OK, now you've got me curious; I was refering to aforementioned
As for sparse... There is a kinda-sorta-not-really attempt at
Of course the lack of ancient cruft helps; no arguments here.
FSF should separate GPLv3 changes (Linux.com) Posted Oct 17, 2006 18:25 UTC (Tue) by Alan_Hicks (subscriber, #20469) [Link] That reminds me a lot of Henry Clay and the Compromise of 1850, wherein a single bill was proposed that would do five different things all at once in order to ease tension between the North and South States prior to the War Between the States. Though the bill failed, each measure was then passed in seperate bills, accomplishing the exact same thing, and (many feel) postponing the war for a decade during which the North was able to outpace the South in industrialization.
I wonder what the outcome will be for the tensions between the FSF and Open Source community. Will "passing" each provision seperately abate tensions for awhile? If it does, will one side gain a large advantage over the other in the philosophical debate? Can the GPLv3 be adopted with these large changes, or will each of these changes need to be "stepped" in individually?
FSF should separate GPLv3 changes (Linux.com) Posted Oct 18, 2006 2:37 UTC (Wed) by smitty_one_each (subscriber, #28989) [Link] >large advantage over the other in the philosophical debateI submit that a healthy dose of tolerance would help. Got to disagree agreeably.
FSF should separate GPLv3 changes (Linux.com) Posted Oct 18, 2006 4:58 UTC (Wed) by drag (subscriber, #31333) [Link] So you saying that they should use the method of introducing the GPLv3 parts at a time so that the FSF can increase it's code capacity during the conflict postpontment and use it's added strength to crush all opposition?
FSF should separate GPLv3 changes (Linux.com) Posted Oct 17, 2006 21:46 UTC (Tue) by man_ls (subscriber, #15091) [Link] I would say it is not worth it. The most vocal opponents against the anti-tivoization clause are the kernel developers. As Ciaran has suggested above it can be added as an exception. They are not candidates for using the new license anyway, since the kernel is "GPLv2 only".Besides, their arguments seem to be more of a, let's say, tactical nature than otherwise. It is only natural that they would want the Linux kernel to be used as widely as possible. Short term this is good for the community and good for them personally: there will be a healthy demand for their skills for many years to come. Long term we may imagine a less promising picture: a situation where most devices are locked down, and people cannot lawfully replace the software anywhere. Even if there are some general purpose computers still open, people would see no difference between, say, Windows 2015 and any Linux-based system. Even worse, they would see no value at all in learning how to program those growingly complex systems, not more than in designing your own microwave ovens. Not for fun anyway. The message of "share and share alike" is completely lost on these future people. The free software community was so slow and painfully put together, and it has done something with no equivalence in History -- a collaborative effort spanning many thousands of people from all continents who do barely know each other and communicate almost solely using the written word. Something as close to Plato's "government of the wise" in its governance as the world has seen; and it has produced a complete and free multipurpose operating system available to all; it also underlies the most powerful means of communication that we have so far invented, the internet. It all falls apart quietly and slowly as people fail to see the point in cooperating with your neighbor, since only professionals would be allowed to play with such things as "source code" on real-world equipment. "See but not touch" code would be the norm. Here is where the interests of kernel developers and of the general community diverge. Their skills would still be in high demand in this scenario, but we all lose in the process.
FSF should separate GPLv3 changes (Linux.com) Posted Oct 17, 2006 22:31 UTC (Tue) by emkey (guest, #144) [Link] The problem with this argument is it assumes that a GPL v3 OS could have an appreciable impact on the trends you mention. I'm a long ways from convinced on that point. I think it would be a very bad idea for people to put all their eggs in the gpl v3 basket.
Far more effective would be an approach that somehow blunts the lobbying efforts of the entertainment industry. I don't find it credible that the gpl v3 will have any appreciable impact in that area.
Some of the activities of the music and movie lobbying groups are starting to sound mighty close to racketering. I wonder if anyone has tried to persue some sort of legal action along those lines?
GPLv3 impact Posted Oct 17, 2006 23:36 UTC (Tue) by man_ls (subscriber, #15091) [Link] You are probably right. It might be argued that every little bit helps, though. Who would have thought 15 years ago that the GPLv2 would be such a big influence in the industry as it is today?
GPLv2 impact Posted Oct 19, 2006 20:04 UTC (Thu) by vonbrand (subscriber, #4458) [Link] The GPLv2 has a huge impact on industry? That's news to me... Industry has had a huge impact on Linux' assorted distributions (and viceversa, in many cases), but that is a completely different kettle of fish. Besides, anti-DRM efforts have had their impact on PCs: Remember the CPU-ID stuff, and the whole blabbering about "trusted PCs" (trusted by the RIAA and MSFT, not the user!)? It all came to nothing, because Joe Sixpack users weren't happy, and that is the right way to go about this problem. A license that prohibits use of the code in some embedded settings (where it isn't all that popular to begin with) won't change anything. Linux is pervasive in higher end uses, and there you see (slow) openings: Intel is contributing drivers for WiFi and graphics, Oracle and other large vendors do support their stuff on Linux, etc.
FSF should separate GPLv3 changes (Linux.com) Posted Oct 18, 2006 0:04 UTC (Wed) by jstAusr (guest, #27224) [Link] You may not have noticed, but everytime the "US Government" also known as US Corporations run afoul of the law, they change the law.
FSF should separate GPLv3 changes (Linux.com) Posted Oct 18, 2006 9:22 UTC (Wed) by khim (subscriber, #9252) [Link] The problem with this argument is it assumes that a GPL v3 OS could have an appreciable impact on the trends you mention. Read this then. The fact is simple: while everyone is using rhetoric "DRM or die" today (Linux kernel developers, FSF, etc) it's just not so simple: it's entirely possible to create the system where you can have strong DRM and you can run GPLv3 code. Or even have the whole GPLv3 OS... Actually it's already done today (you have read the article, right ?)... If there are will be sizable amount of code not available for DRM lock-in the vendors will supply "dual-purpose" systems. In fact it will strengthen DRM position not weaken it - once it'll become clear you'll see that "entertainment industry" will push for this type of change! Think about it: if you are trying to "protect" (in TiVo style) huge codebase with GPL components - you precious DRM is at risk! One buffer overflow - and DRM protection is moot. Now if you clearly separate "protected path" and put in separate part of the system and make it talk with the rest of the system via simple (and thus checkable) interface - then your DRM have a chance. And (coincidently) you now have no reason whatsoever to fight the GPLv3! Okaaay... Then why all this hoopla about "DRM and GPLv3" ? Oh, it's easy: if you want to develop properly layered DRM-support you must work hard. It's expensive. It's much easier to just lock everything down and be done with it. That's why verdors don't like the proposed GPLv3 (and since a lot of kernel hackers are either work for vendors or work with vendors they are not happy too). But the fact is: GPLv3 is good for both used and "entertainment industry" (even if it was not the initial goal). Far more effective would be an approach that somehow blunts the lobbying efforts of the entertainment industry. I don't find it credible that the gpl v3 will have any appreciable impact in that area. Sadly the GPLv3 will have the opposite effect - if you are talking about the ability to want your video collection in a form you like it. But that's not the problem here: GPLv3 is not designed to fight the DRM battle. It's designed to fight TiVo battle - and that's totally different kettle of fish. It does not concern "entertainment industry" at all - but it does concern free software very much... Oh - and it does concern hardware vendors (they'll be forced to work somewhat harder to satisfy both GPLv3 requirements and "entertainment industry" requirements) - but in few years when infrastructure will be ready it'll not be a big deal...
FSF should separate GPLv3 changes (Linux.com) Posted Oct 17, 2006 23:45 UTC (Tue) by error27 (subscriber, #8346) [Link] >> they would see no value at all in learning how to program those growingly complex systems
>> Their skills would still be in high demand in this scenario, but we all lose in the process.
I hate to be pedantic, but in your scenario how did they come by these skills that they don't value? I think you should explain that part with greater verbosity. :P
Kernel skills Posted Oct 18, 2006 6:49 UTC (Wed) by man_ls (subscriber, #15091) [Link] Existing kernel developers would benefit. Would-be kernel deveopers would be restrained by non-modifiable software. It is like in Rice's vampire novels where one of the regular occupations of old, strong vampires is killing young ones so that they do not prosper. :PWell, it is a bit exaggerated; high salaries make wonders to attract bright professionals. But the point is that only professionals would get to play with real hardware; there would be no place for hobbyists writing code in their spare time. In this scenario there is no way that a student anywhere might start a project as "just a hobby, won't be big and professional like gnu".
FSF should separate GPLv3 changes (Linux.com) Posted Oct 18, 2006 4:09 UTC (Wed) by svkelley (guest, #37299) [Link] 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
safety-critical systems can use ROM Posted Oct 18, 2006 4:50 UTC (Wed) by stevenj (subscriber, #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 (subscriber, #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 (subscriber, #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 shoul | |||||||||||