Building a free future in embedded devices
Building a free future in embedded devices
Posted Oct 19, 2006 20:36 UTC (Thu) by jdivine (guest, #18042)In reply to: Building a free future in embedded devices by cventers
Parent article: Free gadgets need free software
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.
- Even if a Manufacturer B "tivoizes" Rockbox -- even if their "tivoized" Rockbox contains Manufacturer A's code -- the code still has to be released. Manufacturer A can still use that code. That's all that Manufacturer A cares about.
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.
Posted Oct 19, 2006 21:11 UTC (Thu)
by cventers (guest, #31465)
[Link] (9 responses)
Posted Oct 19, 2006 21:47 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (1 responses)
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. ;-)
Posted Oct 19, 2006 22:06 UTC (Thu)
by cventers (guest, #31465)
[Link]
Posted Oct 19, 2006 22:04 UTC (Thu)
by jdivine (guest, #18042)
[Link] (6 responses)
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.
Posted Oct 19, 2006 22:42 UTC (Thu)
by cventers (guest, #31465)
[Link] (5 responses)
Posted Oct 20, 2006 0:32 UTC (Fri)
by jdivine (guest, #18042)
[Link]
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.
Posted Oct 21, 2006 15:55 UTC (Sat)
by dirtyepic (guest, #30178)
[Link] (3 responses)
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.
Posted Oct 21, 2006 19:35 UTC (Sat)
by cventers (guest, #31465)
[Link] (2 responses)
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
Posted Oct 21, 2006 20:39 UTC (Sat)
by dirtyepic (guest, #30178)
[Link] (1 responses)
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.
Posted Oct 21, 2006 22:10 UTC (Sat)
by cventers (guest, #31465)
[Link]
Your argument could be generically applied to anyone accepting free
Personally I think the market is starting to grow up a little bit, as
> "Tivoisation" does not equal "proprietary fork." Not even close. Building a free future in embedded devices
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.
for an end-user, absolutely.
Building a free future in embedded devices
> Huh? With Tivoization, the end user still has access to all the source Building a free future in embedded devices
> 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?
:)
>> "Tivoisation" does not equal "proprietary fork." Not even close.Building a free future in embedded devices
>
>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 Building a free future in embedded devices
> 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?
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!Building a free future in embedded devices
> Because GPLv3's relevance to Rockbox is not in the promotion of RockboxBuilding a free future in embedded devices
> to hardware manufacturers. Rockbox's property as _free software_ makes it
> attractive to hardware manufacturers.
Sure they would. Now, don't get me wrong - it's a scary proposition at Building a free future in embedded devices
first. People were really nervous about relying on Linux for anything
important.
company has no control, influence, or power over to power their product is
mind-bogglingly retarded, I have two answers:
independent third-party software
2. Lots of product and service providers _do_ make that mind-bogglingly
stupid move already - just look at Symbian and Windows CE.
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.
scenarios comes true. Home-brew software, and free software, do not.
Home-brew software costs more to make and maintain than free software, so
free software is indeed an interesting option.
> All the doomsday scenarios you mention:Building a free future in embedded devices
>
> 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.
Well, it sounds like we're wasting our time with all this free software Building a free future in embedded devices
stuff then, huh?!
software as part of their product, and yes - that includes Tivo
themselves!
businesses realize that free software is the best means of software
production. But perhaps I'm wrong, and the billions of dollars in
investment is actually nothing more than a blind gamble.