Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
|
| |||||||||||
Why hardware and not software?Why hardware and not software?Posted Oct 19, 2006 3:36 UTC (Thu) by jamienk (subscriber, #1144)Parent article: Free gadgets need free software
If these companies currently give us software for their hardware that doesn't do the obvious things that we want it to, and if these companies will soon force us to upgrade to software that does even less, then what makes us think that they will allow us to run other software in the future?
We can "only purchase" those that support alternative software, but doesn't that really just amount to us "only purchasing" those that support the features we want in their software?
(Log in to post comments)
Why hardware and not software? Posted Oct 19, 2006 4:06 UTC (Thu) by bojan (subscriber, #14302) [Link] > then what makes us think that they will allow us to run other software in the future?
Especially after they "discover" hardware DRM...
Building a free future in embedded devices Posted Oct 19, 2006 4:41 UTC (Thu) by cventers (subscriber, #31465) [Link] My suggestion is three-fold:
1. Support unrestrained hardware; do not buy hardware with hardware DRM
2. Support the GPLv3's anti-Tivoization principal, the lack of which
3. Support Rockbox and other efforts of this nature! Even if the major
Building a free future in embedded devices Posted Oct 19, 2006 6:07 UTC (Thu) by tetromino (subscriber, #33846) [Link] Support the GPLv3's anti-Tivoization principal, the lack of which threatens to turn free software into proprietary. Please explain how GPLv3 is relevant here, considering that:
Building a free future in embedded devices Posted Oct 19, 2006 6:26 UTC (Thu) by cventers (subscriber, #31465) [Link] Did you read the third suggestion I made -- the one about supporting freesoftware alternatives to encourage the production of free devices? If updating Rockbox could be prohibited with hardware DRM, manufacturers would be able to make Rockbox effectively proprietary, and would have basically no incentive not to do so.
Giving Rockbox the GPLv3 anti-tivoization clarification not only defends
Building a free future in embedded devices Posted Oct 19, 2006 6:29 UTC (Thu) by cventers (subscriber, #31465) [Link] Also, great apologies, I seem to have missed one of your points inresponse :)
In your example, Creative could tivoize a GPLv2 Rockbox and not include
As for your point about 'recommended upgrade', I don't see that as an
Building a free future in embedded devices Posted Oct 19, 2006 8:18 UTC (Thu) by mingo (subscriber, #31122) [Link] I think you have not answered the fundamental question that was asked: Please explain how GPLv3 is relevant here, considering that: [...]
Building a free future in embedded devices Posted Oct 19, 2006 13:26 UTC (Thu) by cventers (subscriber, #31465) [Link] Was I not clear about something? I believe I addressed that question in my original post as well as my response to the inquiry. I also addressed that in a past post on this subject pretty clearly. But since I have obviously not been clear enough, I will recap here once more. Rockbox is only useful on embedded devices. If all embedded devices come with hardware DRM, Rockbox development will cease to be possible, because there will be no platform on which users and developers can build, try, and enjoy modified versions. At that point, the developers might as well have gone for the BSD license, because due to their nature of being software specifically for embedded devices, GPLv2 sadly cannot defend them in the ways truly necessary to prevent proprietary forks. Now, you might point out that manufacturers have a choice of whether to use free software or proprietary software, and if the free software comes with difficult terms they'll just use proprietary software instead and everyone will lose. If you want to do that, go ahead, but I'm going to point out that you're using precisely the same argument that GPL dissenters / BSD license advocates have been using for years, and reality has been anything but. The _actual_ advantage of the GPL to the corporate user is that they can contribute without having their contribution eaten by a proprietary fork, and I believe that the Linux kernel has enjoyed years of impressive contributions from large companies as a result. Now I'll come full circle to what I was saying before about the player market. Sure, you might see the majority of hardware manufacturers choosing to reject free software and use hardware DRM. If they do that with un-free software, it's going to cost them more to build a player that will be less good. This leaves room for an enterprising competitor to enter the market with cheaper hardware (lacking the DRM), cheaper software (software gratis and libre), and on the whole, a device with more features. So even if most everyone else goes crazy, there is a sensible business reason for someone to invest in a free device, by virtue of the fact that Rockbox exists. Now you might claim that it doesn't matter, that's a weak argument because Rockbox isn't much of a reason to convince the production of a free device. If you go that way, I'll say that I hope you are wrong but the reason I will call you out for it is because you'll be effectively saying "Rockbox shouldn't have the opportunity to try." The anti-anti-Tivoization argument often floated by the kernel community is something along the lines of "So what if they lock /their/ hardware up, you can just download the source and run it elsewhere!" Rockbox users don't have that choice. That's exactly the point - they can't. And it's damn foolish to look only at the current very prosporous nature of Linux and assume that such a thing would have always been possible under any hostile conditions. Linux might be safe without the anti-Tivoization clause (I'm not even sure that is true, but hey...), but what about all the other free software projects that collectively dwarf Linux? Are they not important? Proprietary forks have a history of killing free software. GPLv2 totally prevented proprietary forks in covered software for many years until Tivo came along, and now GPLv3 aims to close the loop-hole letting embedded devices get away with proprietary forking now too. Of course, I may be wrong about what I'm saying, but you ask me whether GPLv3 is even relevant in this discussion, and I'd be curious to hear why you think it is not. I'm not a Rockbox developer -- I don't speak for those guys, but I think it's clear that GPLv3 is by default better than GPLv2, most especially in their case. It may not be capable of doing enough to keep the project alive, but it does more than GPLv2.
Building a free future in embedded devices Posted Oct 19, 2006 14:03 UTC (Thu) by vonbrand (subscriber, #4458) [Link] Again, how does a GPLv3(draft) licensed third party product (capable of) running on <whatever embedded device> change anything if the manufacturer doesn't allow it (by whatever means, DRM or just keeping all specificacions to themselves and running only propietary stuff)?
Building a free future in embedded devices Posted Oct 19, 2006 18:28 UTC (Thu) by cventers (subscriber, #31465) [Link] Did you not read what I said? I addressed the point about most of themanufacturers going off into hardware DRM land. Rockbox's very existence holds the possibility of convincing another manufacturer to make a free device, because if they do, they can take advantage of Rockbox and save on engineering and product development costs in order to give them a competitive edge. I've raised this point multiple times now -- I'm rather amazed you missed it.
Building a free future in embedded devices Posted Oct 19, 2006 19:06 UTC (Thu) by bronson (subscriber, #4806) [Link] Encouraging manufacturers to go open because it saves on development cost, eh? That's true of just about every open source license ever drafted. As Ingo asked, how does this have anything to do with the GPLv3 specifically?
(other than the GPLv3 containing poorly-understood language that will likely encourage companies to NOT adopt it, of course!)
Building a free future in embedded devices Posted Oct 19, 2006 19:15 UTC (Thu) by cventers (subscriber, #31465) [Link] It's relevant because of why GPL is a better license for coproratecontribution than BSD - it prevents proprietary forks and creates a level playing field. GPLv2 has a loop-hole that seems to allow tivoization (proprietary forks). I already pointed this out by the way.
I'll expand on this a little bit, though... if Rockbox could suffer under
I want to request that anyone who is going to reply to me read what I have
Building a free future in embedded devices Posted Oct 19, 2006 19:34 UTC (Thu) by sepreece (subscriber, #19270) [Link] "a loop-hole that seems to allow tivoization (proprietary forks)"
I don't think a tivoized device is a "proprietary fork" in any real sense. Normally, a proprietary fork would mean that the code, and future changes to it, disappeared into a proprietary version that was no longer open to the community. From the corporate point of view, the "proprietary fork" issue would be about visibility of competitors' (or others') changes to their code. Tivoization, however, doesn't change the GPL requirements that the source code be made available, so that concern does not apply - the enhanced code is still visible/available.
Building a free future in embedded devices Posted Oct 19, 2006 20:04 UTC (Thu) by cventers (subscriber, #31465) [Link] Well, I suppose you're right about it not being a proprietary fork in thesense that would offend commercial contribution -- perhaps I step too far there. But I still think GPLv3 is important and relevant here because in a licensing structure that permits Tivoization, no counter-incentive exists for manufacturers wishing to make use of free software.
And again - I stress that GPLv3 can't crack this DRM issue all by itself,
Building a free future in embedded devices Posted Oct 19, 2006 21:10 UTC (Thu) by bronson (subscriber, #4806) [Link] in a licensing structure that permits Tivoization, no counter-incentive exists for manufacturers wishing to make use of free software.What?! The most effective counter-incentive is the free market. Always has been, always will be. If a device doesn't make its customers happy, customers won't buy it. Anyone who thinks that the GPLv3 is the customer's last defense against the evil DRM manufacturers is simply deluding himself. Think about DRM-fettered devices... TiVO has become mostly irrelevant in the PVR market. It's being eaten on the high end by Myth and Sage boxes and on the low-end by Comcast's junk. Customers have voted with their feet. If TiVO had been more open with their hardware, I think they would still be selling a ton of boxes. But, no, they were greedy and are now getting what they deserve. Let's say Apple wants to produce an iPod that only plays iTunes music. Even with all the DRM in the world, could they? Not successfully. Would the GPLv3 affect Apple's decision? Not in the slightest. Adding controversial, divisive, and poorly-understood wording to a widely-used license to try to protect against a problem that may or may not even exist... That sounds like a clear-cut case of overengineering to me.
Building a free future in embedded devices Posted Oct 19, 2006 21:32 UTC (Thu) by cventers (subscriber, #31465) [Link] I think you are making the mistake of confusing hardware DRM with, say,content DRM. Apple couldn't get away with making an iPod that only played iTunes music, but they could certainly get away with making an iPod that only ran Apple-signed firmware. That's the important distinction. I am like you in this way - I believe the free market is _vastly_ powerful and will disrupt content DRM completely. I'm eagerly awaiting the mass purchase of Zune players, for instance, because I know lots of iTunes customers that are about to lose their lunch when they realize that their paid-for "MP3s" won't play on their new "MP3 player" because what they were sold is actually proprietary DRM-laden crap.
Let's be clear, here... Posted Oct 23, 2006 2:05 UTC (Mon) by Baylink (subscriber, #755) [Link] The *issue* with GPL'd code, the *reason* why we don't want people to sequester the code, and why GPL prevents it, is so that purchasers have control over the things they buy.If the manufacturer is permitted to do things to the hardware which make it impossible for the purchaser to exercise those GPL rights, then they might as well not have them -- and the manufacturer shouldn't be entitled to take advantage of the GPLd code. I didn't know which side of this argument I was on until I had to compose this reply, but I do now.
Let's be clear, here... Posted Oct 23, 2006 14:46 UTC (Mon) by vonbrand (subscriber, #4458) [Link] Strange... GPL doesn't say anywhing about "consumer's control over the device they buy", it talks about the programmer's freedom to tinker with and reuse the source code if they somehow get a copy of the program to run. You see, this is exactly the problem: GPLv3 advocates are trying to change the fundamental orientation of the license. Sure, this might be 100% in line with the FSF's (current) intentions, but it is not what GPLv2 says, and so is a breach of the solemn promise of "new versions similar in spirit" given with the license. Some people did select GPL because of what it says, not what the post of the week on some random website implies. What is the most hilarious part of all this is that (as a post above says) the whole TiVo matter is getting resolved by TiVo going under... replaced by closed source alternatives.
Let's be clear, here... Posted Oct 23, 2006 16:07 UTC (Mon) by cventers (subscriber, #31465) [Link] I understand that your objection is one of the primary gripes about the anti-Tivoization clause. It is one that many people share. It is also one that I find patently absurd. Quoting the GNU manifesto: Complete system sources will be available to everyone. As a result, 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. Users will no longer be at the mercy of one programmer or company which owns the sources and is in sole position to make changes. (emphasis mine) (Keep in mind it is the GNU General Public License we are talking about here) And here, quoting from the foreward to a GCC book, written by RMS in February 2004: Good software must also be ethically good: it has to respect the users' freedom. [snip] By the early 90s, the nearly-finished GNU operating system was completed by the addition of a kernel, Linux, that became free software in 1992. The combined GNU/Linux operating system has achieved the goal of making it possible to use a computer in freedom. But freedom is never automatically secure, and we need to work to defend it. The Free Software Movement needs your support. And here, quoting from the Free Software Definition: The freedom to run the program means the freedom for any kind of person or organization to use it on any kind of computer system, for any kind of overall job and purpose, without being required to communicate about it with the developer or any other specific entity. In this freedom, it is the user's purpose that matters, not the developer's purpose; you as a user are free to run a program for your purposes, and if you distribute it to someone else, she is then free to run it for her purposes, but you are not entitled to impose your purposes on her. At least for GNU, RMS, FSF and "free software", the goal has always been to be able to use a computer in freedom. When a manufacturer uses GPL-licensed free software and bolts on a crypto chip that prevents the end-user from running any kind of modified code the manufacturer themselves did not approve of, that does not maintain the right to use the computer in freedom, and in fact, that's not even upholding freedom 1 (the right to adapt the software to your needs). It's at times like this that I really do sympathize with Stallman and his dislike of the term 'open source'. There has been for a long while people who don't align well with Stallman or his message and 'open source' was a deliberate effort to distance from that. In the process, I think a lot of people started forgetting / stopped caring about the goals of GNU or the FSF, or the 'freedom' in 'free software'. That sucks. But what really sucks is the fact that there are people who now feel like using the computer in freedom or having the freedom to adapt was apparently never part of the equation in the first place. If you're not happy with that idea, let's talk about that, but this 'freedom' stuff isn't 'what the post of the week on some random website implies' - it's the fundamental philosophy. And perhaps you never cared to listen to or consider that free software philosophy. That's fine. I read up on it extensively, which was why I'm totally unsurprised and unoffended by the GPLv3's anti-Tivoization clause. It makes perfect logical sense, and it's precisely in the spirit of GNU, FSF, RMS and GPL. But if you never realized this was about using a computer in freedom, and instead adopted the 'open source' idea entirely with no consideration for 'free software', perhaps you should have chosen another license than the GNU General Public License, written by Richard Stallman of the Free Software Foundation? I agree with Linus. GPLv2 is a great license. But I don't see how GPLv3's anti-Tivoization clause counts for anything more than a clarification of legal terminology to stop something many people (even many kernel developers!) consider abusive.
Building a free future in embedded devices Posted Oct 19, 2006 14:16 UTC (Thu) by tetromino (subscriber, #33846) [Link] Your point is moot: no manufacturer in the world. no commercial entity, actually ships Rockbox on its audio players. IMHO, they are not going to start using Rockbox in the near future either (software patents are the most obvious reason). In other words, it doesn't matter whether Rockbox is GPLv2 or GPLv3: the hardware manufacturers don't care either way, because they don't care about Rockbox in the first place.
So by telling Rockbox to adopt GPLv3, you are telling Rockbox users and devs to sacrifice some of their freedom in order to solve a problem that does not exist.
Building a free future in embedded devices Posted Oct 19, 2006 18:30 UTC (Thu) by cventers (subscriber, #31465) [Link] You must not have read everything I said.It's possible my point is entirely moot, because Rockbox might never succeed. But there were people who said Linux would never go anywhere either. Do tell me - how am I telling Rockbox users and developers to sacrifice freedom by going with GPLv3? What freedom do the users or developers of Rockbox lose?
Building a free future in embedded devices Posted Oct 26, 2006 13:31 UTC (Thu) by jond (subscriber, #37669) [Link] I read on LWN that SanDisk were at least entertaining this notion: http://lwn.net/Articles/186091/
Building a free future in embedded devices Posted Oct 19, 2006 22:56 UTC (Thu) by bojan (subscriber, #14302) [Link] > This leaves room for an enterprising competitor to enter the market with cheaper hardware (lacking the DRM), cheaper software (software gratis and libre), and on the whole, a device with more features. So even if most everyone else goes crazy, there is a sensible business reason for someone to invest in a free device, by virtue of the fact that Rockbox exists.
Well, sort of. A device without content won't be successful no matter what. The market for such things just doesn't exist (or is really, really small).
And now we get back to exactly where Tivo is - it's not the manufacturers that want hardware DRM - it is the content providers. So, if they start demanding en masse "have hardware DRM or we won't give you our content", Rockbox under GPLv3 isn't going to play (sorry, bad pun). Some reports related to this Creative story suggest that they removed recording because RIAA insisted on that.
So, when the manufacturers "discover" hardware DRM through their content providing friends, the game in this embedded market will shift to the next level. Now, whether having GPLv2 software available for such devices is a good thing (i.e. because it enables you and me to start a business making such things based on free software for less money) or not - I don't know.
PS. I wouldn't be betting on DRM enabled hardware (i.e. chips) being more expensive forever. If the demand for it goes up, it's going to become "standard feature" and the price will drop to the level of other hardware, or below, depending on volume.
Building a free future in embedded devices Posted Oct 19, 2006 20:36 UTC (Thu) by jdivine (subscriber, #18042) [Link] I do not agree that applying the GPLv3 "anti-tivoization" clause to Rockbox would encourage manufacturers to use Rockbox. Nor would it encourage them to contribute code to Rockbox.
- The only thing that "tivoization" prevents is running unapproved code on certain hardware devices. Manufacturer A does not care about running modified code on Manufacturer B's device.
From a manufacturer's perspective, the GPLv2 protects their contributions just as well as the GPLv3 does.
"Tivoisation" does not equal "proprietary fork." Not even close.
Building a free future in embedded devices Posted Oct 19, 2006 21:11 UTC (Thu) by cventers (subscriber, #31465) [Link] > "Tivoisation" does not equal "proprietary fork." Not even close.For a manufacturer, perhaps not; for an end-user, absolutely. But I do conceed that in terms of what a manufacturer (someone capable of making their own device) might see, they wouldn't personally have reason to worry. However, I'm not claiming that the anti-tivoization clause would encourage manufacturers to use or contribute to Rockbox either. Rockbox being free software would encourage that; GPLv3 anti-tivoization would ensure that Rockbox _survives_ as free software once a manufacturer makes that choice.
Building a free future in embedded devices Posted Oct 19, 2006 21:47 UTC (Thu) by bronson (subscriber, #4806) [Link] for an end-user, absolutely.Huh? With Tivoization, the end user still has access to all the source code. With the proprietary fork the original source code is gone for good. How can you possibly view these two scenarios as equally bad? Also, why are you so worried about Rockbox's survival? Rockbox is healthier now than it ever has been. It will be around for a very long time, whether the FSF decides to release the GPLv3 with the controversial DRM clauses or not. Unless the GPLv3 irrevocably divides the rockbox community of course. ;-)
Building a free future in embedded devices Posted Oct 19, 2006 22:06 UTC (Thu) by cventers (subscriber, #31465) [Link] > Huh? With Tivoization, the end user still has access to all the source> code. With the proprietary fork the original source code is gone for > good. How can you possibly view these two scenarios as equally bad? Whether or not I consider both situations as "proprietary forks" has no relevance to how individually bad I think either one is. So when you say how could I possibly view these two scenarios as equally bad, your answer is -- I don't. > Also, why are you so worried about Rockbox's survival? Rockbox is > healthier now than it ever has been. Yes, I'm glad to see that. But I worry about issues like tivoization. And I think I'm not alone in that worry either - a number of kernel developers I spoke to on LKML feel the same way; their disagreement that remains with me is what to do about it. > It will be around for a very long time, whether the FSF decides to > release the GPLv3 with the controversial DRM clauses or not. I hope you're right. That said, no one has told me yet why the GPLv3's DRM clauses would in any way harm Rockbox. If that's true, and no one can answer me, then the changes at minimum would do nothing and at best might improve the landscape, in which case I don't see any sensible reason in not at least trying to improve the landscape. The argument that seems to be brought up about the Linux kernel as it relates to the DRM clauses is a paranoia that the DRM clauses would cause hardware manufacturers to say "Nope, not going to use Linux, because this DRM clause is in my way." In other words, manufacturers that would be put off by the anti-DRM clause would only be put off by it precisely because they wanted to Tivoize the code. Otherwise it wouldn't be an issue. Tivoizing Linux may not be seen as a huge problem by everyone, because hey - there's still tons of computers to run the modified source code Tivo releases. Tivoizing Rockbox could mean death, because there is a scarcity of devices on which it might run in the first place. (Addressing a larger audience:) And this is what I think is _really_ important here. People need to stop with this "FSF trying to take our freedoms away" crap, because the only people that will be affected by the anti-Tivoization primitives are people that want to Tivoize the code. So if we're going to debate those provisions, can we stick to talking about whether or not manufacturers should be allowed by the license to Tivoize? > Unless the GPLv3 irrevocably divides the rockbox community of > course. ;-) I see differences of opinions but no such divided communities. Why must we always agree about everything in order to survive? :)
Building a free future in embedded devices Posted Oct 19, 2006 22:04 UTC (Thu) by jdivine (subscriber, #18042) [Link] >> "Tivoisation" does not equal "proprietary fork." Not even close.> >For a manufacturer, perhaps not; for an end-user, absolutely.
How can you make this claim? The software is free. The end user is free to download the software and install it to whatever device will run it. The end user is not forced to purchase a crippled hardware device that won't allow unapproved software upgrades. The fact that some hardware is crippled does not affect the freedom of the software.
>However, I'm not claiming that the anti-tivoization clause would encourage manufacturers to use or contribute to Rockbox either.
Yes, you did! In response to a question about how the GPLv3's "anti-tivoization" clause is relevant to this thread, you responded in part:
>Rockbox's very existence holds the possibility of convincing another manufacturer to make a free device, because if they do, they can take advantage of Rockbox and save on engineering and product development costs in order to give them a competitive edge.
Another poster again questioned how the GPLv3 is relevant, and your response began:
>It's relevant because of why GPL is a better license for coprorate contribution than BSD - it prevents proprietary forks and creates a level playing field. GPLv2 has a loop-hole that seems to allow tivoization (proprietary forks).
Taken together, how are these statements _not_ to be interpreted as suggesting that the GPLv3 will encourage manufacturers' use of projects that adopt it? You certainly seem to be saying that manufacturers would be more inclined to use free software in their products if only they could be assured their hard work wouldn't be "taken proprietary." And you've made the mistaken assertion that the GPLv2 allows proprietary forks while the GPLv3 prevents them.
If this is not your position, please clarify it -- succinctly, if at all possible.
Building a free future in embedded devices Posted Oct 19, 2006 22:42 UTC (Thu) by cventers (subscriber, #31465) [Link] > How can you make this claim? The software is free. The end user is free> to download the software and install it to whatever device will run it. > The end user is not forced to purchase a crippled hardware device that > won't allow unapproved software upgrades. The fact that some hardware is > crippled does not affect the freedom of the software. If the receiving user of a piece of software cannot adapt said software under Freedom #1, then by definition it is not free software, at least if you adopt FSF's original terminology. And as Stallman says, "If the software is missing in a significant way one of these freedoms, then the software is proprietary software." > Taken together, how are these statements _not_ to be interpreted as > suggesting that the GPLv3 will encourage manufacturers' use of projects > that adopt it? Because GPLv3's relevance to Rockbox is not in the promotion of Rockbox to hardware manufacturers. Rockbox's property as _free software_ makes it attractive to hardware manufacturers. So far GPLv3 isn't relevant, right? GPLv3 is relevant to Rockbox because it clarifies the terminology used to uphold Freedoms 0-3 such that Tivoization is not possible. And I have brought up a number of times now that Tivoization could effectively kill Rockbox. Note that when I bring up the 'level playing field' it is _wrong_ to think of the playing field as only consisting of companies. Rockbox developers don't have the tools or money necessary to make the hardware on which Rockbox runs. Thusly, if all their potential hardware uses Rockbox but allows no one but the hardware manufacturer to update it, the Rockbox developers have just been excluded from participating in their own project. That's not a level playing field, and that's _exactly_ why GPLv3 is relevant to Rockbox. Would you like to address that point, instead of combining aspects of multiple discreet arguments I am making into a phony straw-man that you can attack?
Building a free future in embedded devices Posted Oct 20, 2006 0:32 UTC (Fri) by jdivine (subscriber, #18042) [Link] Please do not accuse me of making up a straw man argument. I attempted to distill what exactly you were arguing (from two responses to the same question, I might add, not "multiple discreet arguments") and I posed the question to you if my distillation was in fact correct! I even asked you to clarify your argument if my interpretation was wrong!
Many have already argued why tivoisation does not affect the freedom of free software; I won't rehash the same thing, except to say that the user _can_ use, modify, run, and redistribute the software. Only the device is constrained, not the software. It's unfortunate that manufacturers would sell crippled hardware, but it doesn't affect the freedom of the software.
"Tivoisation" can not kill Rockbox. Rockbox can only die if people stop developing it. Even if all manufacturers suddenly stop producing uncrippled hardware, all existing devices will continue to run Rockbox quite happily. This scenario would be unfortunate (we all want to see Rockbox ported to more shiny new devices) but is quite unlikely -- because a sizable market exists for uncrippled hardware. This market will continue to exist unless uncrippled hardware is made illegal, in which case any anti-tivoisation clauses become quite irrelevant. In short, the scenario in which Rockbox developers would be locked out of their own project is implausible.
I do not know if Rockbox will move to GPLv3 -- I don't know whether they can or if they use "GPLv2 only" code, or whether they even wish to switch. If they do, I don't have any problem with that -- it's entirely the choice of the Rockbox developers. I'm not opposed to the GPLv3 at all (although I hope they might consider naming it the "GGPL" or something else, to avoid the whole mess with "GPLv2 or later" licensed code.) I oppose DRM on principle and I think that Tivo played a dirty trick, and I'm glad a license will exist that developers can choose if they don't want their software used on crippled hardware. I'm just unconvinced that the "anti-tivoisation clause" advances free software or software freedom.
Building a free future in embedded devices Posted Oct 21, 2006 15:55 UTC (Sat) by dirtyepic (subscriber, #30178) [Link] > Because GPLv3's relevance to Rockbox is not in the promotion of Rockbox> to hardware manufacturers. Rockbox's property as _free software_ makes it > attractive to hardware manufacturers.
I see what you're saying, that the GPLv3 would insure that any device created and distributed with Rockbox firmware be open and free of any DRM mechanisms that limit the end user's freedoms. But do you honestly believe for a second that any given hardware manufacturer in the world is going to rely on independent third-party software that it has absolutely no control, influence, or power over to run their devices? That would be a mind-bogglingly retarded business move. Just consider the QA nightmare that would be. What happens if (when) the third-party decides to move in a direction that directly conflicts with your business plan? What happens if (when) the RIAA comes knocking on your door demanding you remove FM recording capability? What happens if interest wanes out and the project is abandoned?
Basically, to have any semblance of control over the software, the company has to maintain their own fork. With GPLv[2,3] licensed software, they're required to distribute the source along with their modifications back to the user and therefore the community. With GPLv3, they must also provide keys to any DRM mechanisms in their devices which prevent the user from running modified code.
Or, they can just write their own software and not have to deal with any of this bullshit.
Guess which one they usually go with.
Building a free future in embedded devices Posted Oct 21, 2006 19:35 UTC (Sat) by cventers (subscriber, #31465) [Link] Sure they would. Now, don't get me wrong - it's a scary proposition atfirst. People were really nervous about relying on Linux for anything important.
When you say that relying on independent third-party software that a
1. Free software gives you perfect control, influence and power over the
All the doomsday scenarios you mention:
1. No control? Not true. They can make whatever changes they want to the
Relying on proprietary software leaves you in a mess any time one of these
Building a free future in embedded devices Posted Oct 21, 2006 20:39 UTC (Sat) by dirtyepic (subscriber, #30178) [Link] > All the doomsday scenarios you mention:> > 1. No control? Not true. They can make whatever changes they want to the > software, and if upstream doesn't like them, that doesn't stop them from > using those changes in their own version. > 2. No influence? Not true. They can hire / employ one or more Rockbox > developers, just as some companies hire Linux developers today. > 3. Mainline goes in a different direction? No problem, you can still keep > using _your_ Rockbox. > 4. Mainline devs lose interest and the project goes away? No problem, you > can still keep using _your_ Rockbox.
All of which amount to developing and maintaining their own fork of the software, with the additional requirement they must share all of their work with anyone they distribute the device to. By developing and maintaining their own proprietary firmware in-house they also avoid the above scenarios, with the added bonus of keeping all their little sekrits safe from prying eyes. They lose out on startup costs, not to mention peer review, community contribution, and all the other goodies that are obvious to us on our side of the fence, of course, but somehow i don't think they really care that much.
Building a free future in embedded devices Posted Oct 21, 2006 22:10 UTC (Sat) by cventers (subscriber, #31465) [Link] Well, it sounds like we're wasting our time with all this free softwarestuff then, huh?!
Your argument could be generically applied to anyone accepting free
Personally I think the market is starting to grow up a little bit, as
Building a free future in embedded devices Posted Oct 19, 2006 11:37 UTC (Thu) by nim-nim (subscriber, #34454) [Link] > 1. Creative (along with the vast majority of embedded manufacturers) uses a> closed-source OS in its products; and
But some manufacturers DO use FLOSS OSes. They're the ones we don't want to listen to DRM sirens just because media industry likes it and they can freely drm-ize their FLOSS product.
> 3. the ability to cryptographically sign home-brewed firmware is utterly
Don't be naïve, of course the media industry would require signing by a new key and revocation of the old one when the new firmware is applied in this case.
Why hardware and not software? Posted Oct 19, 2006 8:39 UTC (Thu) by nix (subscriber, #2304) [Link] Because if you allow running alternative firmware (and especially if you publish specs: not hard as much of these devices are off-the-shelf parts) then people might *choose your device over competitors' because of that support*.
(In fact we already see this among the blind: a huge percentage of Rockbox's users are blind because no other player firmware has even halfway decent accessibility. I guess that blind users are too small a market segment to bother with, or something.)
Why hardware and not software? Posted Oct 20, 2006 0:20 UTC (Fri) by giraffedata (subscriber, #1954) [Link] Because if you allow running alternative firmware (and especially if you publish specs: not hard as much of these devices are off-the-shelf parts) then people might *choose your device over competitors' because of that support*. But I think the point is this: It is even more obvious that if you allow recording off the air through your standard firmware, people might choose your device over a competitor's. And yet, Creative actively chooses not to. So won't whatever drives Creative to withhold recording function also drive Creative to withhold alternative firmware capability? This looks a lot like the wireless telephone issue (will the government allow a manufacturer to sell a telephone on which the user can replace the control program, if the user could put on a version that violates broadcast laws?)
|
|||||||||||