Free gadgets need free software

[Posted October 17, 2006 by corbet]

Your editor has occasionally taken time to write about Rockbox, a GPL-licensed firmware system for portable music players. One might think that such articles result from an attempt to disguise time spent playing with gadgets as real work - and not be entirely off the mark. But an incident this week shows why running free software on devices like music players is important.

Creative makes some nice players, including the "Zen Vision:M." It includes a large color screen, significant storage, and an FM radio. Like many such devices, it is able to connect the FM radio to that storage space and record radio programs. There are any number of reasons why this feature is useful; one may want to record a radio interview featuring a colleague, timeshift a program for later listening, or grab the DJ's talk to help identify an interesting song for later purchase. This capability certainly is not anything new; people have been hooking up their tape recorders to radios for decades.

As of firmware version 1.50.02, however, the Zen Vision:M player can no longer record from its FM radio. An "upgrade" for the Zen MicroPhoto removes the FM recorder feature from that device as well. In both cases, the hardware retains the FM recorder capability, but the new firmware takes it away. It is hard to imagine that legions of Creative customers have been clamoring for the removal of a useful feature from their expensive devices. Instead, this crippling of the hardware has been done to meet the demands of a different group of people: our friends in the entertainment industry.

Fortunately for current owners of this hardware, there does not appear to be any mechanism built into the player which forces a change to the newer version. It would not be entirely surprising to see forced-upgrade requirements built into future players, however, especially as the notion of "trusted content paths" gains ground. The gadget you thought you owned may turn into a different device tomorrow, and there is little that you can do about it.

Unless, of course, that gadget is running free software. Rockbox users do not have to deal with this sort of trouble; if somebody were to remove the FM recorder feature, somebody else would just patch it back in. Rockbox users enjoy a tangible level of freedom which has been taken away from people running proprietary firmware on their players.

This is an important point. Your editor is appalled by the number of AC adapters he must carry whenever he travels - we have a number of gadgets which, increasingly, we see as being entirely indispensable. The functions handled by those gadgets can only grow over time; we will become increasingly dependent upon them for our work, our communications, and our leisure. Whose interests will those gadgets serve? If others control the software on those gadgets, that software will be distorted to serve their interests; the Creative firmware "upgrade" is a strikingly clear example of just how that process can work. If we want to control our gadgets, it behooves us to only purchase those which can run free software.

[A postscript for those who are interested in what's up with Rockbox. The project abandoned its plans for a 3.0 release some months ago; the feature freeze was hurting development without bringing solutions to the final remaining problems. So development has been going full-steam ahead, with (usually stable) daily builds available for those who want the latest features. Support for iRiver H10, most iPods, and iAudio X5 players has been added; early-stage work is proceeding on iRiver IFP790 and Toshiba Gigabeat players. The port to the Sandisk Sansa e200 has recently overcome some significant hurdles and may start to make significant progress in the near future. Unfortunately, there appears to be no effort to port to the Creative players at this time.]

Why hardware and not software?

Posted Oct 19, 2006 3:36 UTC (Thu) by jamienk (guest, #1144) [Link] (36 responses)

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?

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 (guest, #31465) [Link] (32 responses)

My suggestion is three-fold:

1. Support unrestrained hardware; do not buy hardware with hardware DRM
locks that prohibit you from changing the software!

2. Support the GPLv3's anti-Tivoization principal, the lack of which
threatens to turn free software into proprietary.

3. Support Rockbox and other efforts of this nature! Even if the major
player manufacturers wall off their players with hardware DRM, they'll
currently have to do it with unfree software. But what happens if
manufacturers lock off their devices with unfree software and hardware
DRM? This leaves open a market opportunity for a smaller company to step
onto the market with a Rockbox-derived free player, which will cost them
less to build and deliver more features.

Building a free future in embedded devices

Posted Oct 19, 2006 6:07 UTC (Thu) by tetromino (guest, #33846) [Link] (31 responses)

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:

Creative (along with the vast majority of embedded manufacturers) uses a closed-source OS in its products; and
even if Creative's OS was under GPLv3, Creative could still distribute a "recommended upgrade" that would break FM recording, and most consumers would still blindly install it; and finally
the ability to cryptographically sign home-brewed firmware is utterly irrelevant in this case, since users could downgrade to the older official firmware version once they discovered the newer version's lack of features.

Building a free future in embedded devices

Posted Oct 19, 2006 6:26 UTC (Thu) by cventers (guest, #31465) [Link] (29 responses)

Did you read the third suggestion I made -- the one about supporting free
software 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
its status as free software but has further potential to encourage at
least _someone_ to build a free device.

Building a free future in embedded devices

Posted Oct 19, 2006 6:29 UTC (Thu) by cventers (guest, #31465) [Link]

Also, great apologies, I seem to have missed one of your points in
response :)

In your example, Creative could tivoize a GPLv2 Rockbox and not include
that functionality from day one. Then, the firmware was _never_ available,
and there is no firmware to downgrade to.

As for your point about 'recommended upgrade', I don't see that as an
important issue, because proprietary software is often recommended and
people still have friends that know about free software alternatives (say,
free web browser alternatives to IE).

Building a free future in embedded devices

Posted Oct 19, 2006 8:18 UTC (Thu) by mingo (guest, #31122) [Link] (16 responses)

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 (guest, #31465) [Link] (15 responses)

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] (10 responses)

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 (guest, #31465) [Link] (9 responses)

Did you not read what I said? I addressed the point about most of the
manufacturers 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] (8 responses)

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 (guest, #31465) [Link] (7 responses)

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). I already pointed this out by the way.

I'll expand on this a little bit, though... if Rockbox could suffer under
hardware DRM, then the manufacturers I spoke of that might be encouraged
by saving development costs could just save those development costs and
make a proprietary Rockbox fork anyway.

I want to request that anyone who is going to reply to me read what I have
to say. I don't expect you to agree to it, but please address my actual
post rather than acting as if you didn't see something. I believe it was
fairly comprehensive.

Building a free future in embedded devices

Posted Oct 19, 2006 19:34 UTC (Thu) by sepreece (guest, #19270) [Link] (6 responses)

"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 (guest, #31465) [Link] (2 responses)

Well, I suppose you're right about it not being a proprietary fork in the
sense 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,
but to the extent that it might possibly do better than GPLv2, I think it
is quite important.

Building a free future in embedded devices

Posted Oct 19, 2006 21:10 UTC (Thu) by bronson (subscriber, #4806) [Link] (1 responses)

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 (guest, #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 (guest, #755) [Link] (2 responses)

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] (1 responses)

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 (guest, #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 (guest, #33846) [Link] (2 responses)

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 (guest, #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 (guest, #18042) [Link] (10 responses)

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.

Building a free future in embedded devices

Posted Oct 19, 2006 21:11 UTC (Thu) by cventers (guest, #31465) [Link] (9 responses)

> "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] (1 responses)

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 (guest, #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 (guest, #18042) [Link] (6 responses)

>> "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 (guest, #31465) [Link] (5 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.

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 (guest, #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 (guest, #30178) [Link] (3 responses)

> 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 (guest, #31465) [Link] (2 responses)

Sure they would. Now, don't get me wrong - it's a scary proposition at
first. People were really nervous about relying on Linux for anything
important.

When you say that relying on independent third-party software that a
company has no control, influence, or power over to power their product is
mind-bogglingly retarded, I have two answers:

1. Free software gives you perfect control, influence and power over the
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.

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.

Relying on proprietary software leaves you in a mess any time one of these
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.

Building a free future in embedded devices

Posted Oct 21, 2006 20:39 UTC (Sat) by dirtyepic (guest, #30178) [Link] (1 responses)

> 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 (guest, #31465) [Link]

Well, it sounds like we're wasting our time with all this free software
stuff then, huh?!

Your argument could be generically applied to anyone accepting free
software as part of their product, and yes - that includes Tivo
themselves!

Personally I think the market is starting to grow up a little bit, as
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.

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
> irrelevant in this case, since users could downgrade to the older official
> firmware version once they discovered the newer version's lack of features.

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] (1 responses)

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 (guest, #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?)

Why not sue them?

Posted Oct 19, 2006 8:36 UTC (Thu) by NAR (subscriber, #1313) [Link] (5 responses)

Maybe I misunderstand something, but the story looks like this: a customer buys a gadget that can (among other things) record FM radio (I guess it's specified in the User's Manual too). Then the customer installs an "upgrade" from the vendor of the gadget and this feature (which the customer have already paid for) disappears. Isn't it illegal for the vendor to take away functionality that was already paid?

Bye,NAR

Why not sue them?

Posted Oct 19, 2006 9:12 UTC (Thu) by khim (subscriber, #9252) [Link] (4 responses)

Isn't it illegal for the vendor to take away functionality that was already paid?

Not at all! I'm pretty sure this thing includes typical "I don't have any right and you can sell my soul to devil when you feel like it" language in it's contract. Like iTunes does... When millions are happily sing contracts which can potentially force you to lose your house and/or work or do a lot of other nasty things and the companies you can be pretty sure such triviality as removal of the existing functionality will be "not a big deal"...

P.S. If you don't see any problems with iTunes contract then read it again: "Apple reserves the right, at any time and from time to time, to update, revise, supplement, and otherwise modify this Agreement and to impose new or additional rules, policies, terms, or conditions on your use of the Service. Such updates, revisions, supplements, modifications, and additional rules, policies, terms, and conditions (collectively referred to in this Agreement as "Additional Terms") will be effective immediately and incorporated into this Agreement". It does not really matter what the rest of the agreement says: Apple can introduce subscription fee $1'000'000 per second. No problem. Or it can say: "everything you've bought till xx.xx.xxxx is no longer yours". Just fine. Or any other thing. You've agreed in anvance. The exception being criminal laws - all other laws are irrelevant since you've already agreed to not use them... Of course it also contains words "your continued use of the iTunes Store following will be deemed to constitute your acceptance of any and all such Additional Terms" but since said rules can easily change between the time when you are reading latest revision of these terms and the time when you hit an "Ok" button - it does not change situation much: you've still agreeing to the something you've never had chance to read and understood. How anyone can agree to terms like this is beyond me but somehow iTunes store has buyers this means people are quite ready to sell soul for few nickels...

Why not sue them?

Posted Oct 19, 2006 18:28 UTC (Thu) by NRArnot (subscriber, #3033) [Link] (1 responses)

There may well be some juristictions where taking away functions which were there when the device was first purchased, and especially refusing to give them back, will be considered illegal (and perhaps even criminal). And there are quite a few places where contracts are subject to overriding legislation outlawing unfair terms (variously defined) so trying to deny all responsibility in the small print may not work. And of course, there's the longstanding issue about whether a shrink-wrap "contract" that you can't read until after you purchase is any sort of contract at all, or just packaging materials. If there's no valid contract, revising functionality downwards in an irreversible manner sounds a lot like criminal damage (just how does it differ from a garage returning your car with the windows deliberately smashed?)

A manufacturer who sells such a device world-wide will be walking on thin ice.

Why not sue them?

Posted Oct 19, 2006 19:38 UTC (Thu) by sepreece (guest, #19270) [Link]

I think this misses a key point - it is not the manufacturer who is installing the upgrade, it is the user, voluntarily choosing to give up some existing functionality in return for some new/improved functionality. The original device, with its original firmware, continues to meet its sales description. So, I doubt there's a legal issue with this.

Itunes "we own your soul" agreement

Posted Oct 20, 2006 0:39 UTC (Fri) by giraffedata (guest, #1954) [Link]

FYI, there are legal restrictions on how much force language like this has. The law does not give a person the power to commit to terms to be made up entirely by the other guy at a later date. The point of language like this in a contract is that the two parties have to agree to current terms on an ongoing basis. Your agreement with Apple concerning a song you download today doesn't mean Apple must give you the same terms on another song tomorrow. But if tomorrow's terms are different, Apple does have to tell you and if you don't actively agree to them, they aren't binding (and, of course, you stop using the service).

The active agreement to the new terms is the continuing use of the service you mention. But that doesn't count if you didn't know the terms changed, and there isn't some reason you should have known. Whether you should have known is one of those matters of opinion that we have juries and mountains of case law for, but it's all quite reasonable.

Why not sue them?

Posted Oct 20, 2006 10:04 UTC (Fri) by pointwood (guest, #2814) [Link]

I'm glad that you mention Apple and the terms and conditions for iTunes
because exactly Apple is currently in the hot seat here in Scandinavia for
exactly this. The thing is that we have some sensible laws here in Denmark
(and the other Scandinavian countries) that protects the consumer. Among
other things, they say that the seller can't change the terms and
conditions after the sale. The same thing will be true for this change I
would think. Which means that it should be possible to force Creative to
release an update that adds the feature again.

Free gadgets need free software

Posted Oct 19, 2006 13:18 UTC (Thu) by pbardet (guest, #22762) [Link] (1 responses)

I'm not quite sure how it applies to us, Linux users...
When I bought my "mp3" player, I made sure it would work under Linux, ie not using proprietary software to add/remove songs on the device. Therefore, I can't see how the manufacturer could force me to upgrade to the latest software since this device is never plugged into their "network".

On top of that, there is no way for me to upgrade the firmware on Linux since they (my manufacturer, others, I don't know, but AFAIK it applies to Creative) don't provide software to do it...

Free gadgets need free software

Posted Oct 21, 2006 6:36 UTC (Sat) by jneves (guest, #2859) [Link]

We live in networks. That scenario is real, until the day you are at a friend's home and he says "well, here's something you should listen to". And you here a bit, and you like, and (because your friend wouldn't mind installing the tools for your player on his proprietary system) load it into your player.

And suddenly there are things you can't do with your player because of a simple slip into the proprietary world... That will be fun.

Free gadgets need free software

Posted Oct 19, 2006 19:47 UTC (Thu) by utoddl (guest, #1232) [Link]

The functions handled by those gadgets can only grow over time

Evidently not. :^(