It was inevitable that this would happen. For Maemo to propagate and compete with Android and Apple, which both have DRM built in, than it would eventually have to adopt DRM too. It won't get support from content providers without it, and cell providers are insistent on having control of the devices on their network. At least Nokia is being pragmatic about it and offering an unsigned mode for the phone operate in. And I hate the term "trusted computing", it's like calling the IRS my personal financial advisor.

Also DRM is usually based in software, so it's adoption shouldn't prevent moving the n900 to Maemo6.

Just looked at the slides pointed at to from the original post it appears the DRM aspect is indeed "optional".

Generally should not be an issue if you buy the device directly from Nokia.

The question is if you decide to use an open source version of the kernel you will not be able to use any software that signs itself to the security framework.

Worst case scenario would be something like the phone/modem is proprietary and is "security-enabled". Would this mean you may not be able to access it via an open source kernel?

I don't expect Nokia would lock-out something essential like this but it does raise a few questions.

I suppose all we can do is wait and see what Maemo 6 brings.

If the security framework is open sourced and available to non-Nokia signed kernels, Mer would probably have it too. Heck, I wouldn't mind it on my PC.

From the wiki page again..

Q: Cellular is marked as a protected ressource in the slide. Can one still use it (phone, data, sms etc.) while running in open mode? While runnin a rebuilt kernel?

A: If you use your own kernel, you are the one to set the security policy for the device, meaning that your SW in this case can make calls, send sms and so on (for example). Please note that the list of protected resources on the slide is given just as example (to show the possible granularity level), so it doesn't mean that we would have exactly these resources.

Or better, contact Elena again. Communication, u know?

The Mawemo 6 security framework has been discussed at length at http://talk.maemo.org/showthread.php?t=32672 - please continue there that discussion.

We'll merge all the "Maemo 6 in the N900" threads to this one since currently there is a lot of duplicated discussions.

I have no problem with the DRM. Well, actually I do, I would never buy DRMed content, but I understand the need for it - it's hard to convince content publishers that DRM is from a practical point of view pure BS - the ones that care not to pay (pirates and pirated content consumers) will still get that content one way or the other, while the legit paying customers will be treated as criminals upfront and will have a big inconvenience in consuming their rightfully owned/licensed content (it actually makes legit customers to turn to pirates from time to time when they cannot get the content they paid in a way they want). So, since most (luckily not all) content providers go haywire when they hear `the platform is fully open and supports no DRM of any kind`, one has to cater to their needs if they are to come to their platform. Yes, it's stupid, all the things I said still stand, but do you really think that some manager that decides about those things from some major content provider even knows the problems with DRM or how it works? No, he has instilled mantra `no glove (DRM), no love`, and in today's market if you want to draw people to your platform you need to have plenty of content available on it. That's just the way it is.

What I have a problem with is the way it is to be implemented, judging from that wiki page - you need to use a different kernel for `opened` and for `closed` mode. That's even more of an inconvenience than the DRM itself. There are plenty of ways to implement DRM (at the expense of CPU/memory, tho) without killing the openness. After all, typical DRM implementations work on widely opened and documented types of encryption - it's the keys that are kept as secret. What I'd propose is to move the DRM support from the kernel into additional software layer (or at least a kernel module that can be loaded/unloaded run-time), just the way it is on today's computers. There are plenty of ways to do that, from encrypted partitions/folders, to real-time checking with DRM servers (after all, it's meant to be `always connected`), to hardware implementations. All of which wouldn't require you to boot into a different kind of system whenever you want to consume DRM content, and would allow you to enjoy the openness and the DRM content at the same time.

I hope that the people that decide about that have thought long and hard about the implications and inconveniences that could come from dual-kernel system as a DRM implementation. I'm not sure that they could even do that given the GPLv2 on the linux kernel.

edit: Sorry, qgil, just saw your post. If I have something more to say about the security implementation I'll take it there.

we want maemo6 on nokia n900,
we want maemo6 on nokia n900,
we want maemo6 on nokia n900,we want maemo6 on nokia n900
we want maemo6 on nokia n900, we want maemo6 on nokia n900

i want maemo 6 os better to have a compete maemo os than incomplete one

After further consideration, I would say that maemo 6 not being on the n900 would be a bad thing only if:

1. maemo 6 apps can not be run on maemo 5. Since both will be using QT this seems unlikely. Also, the term 'Backports' comes to mind.

2. Nokia decides to focus on developing maemo 6 rather than giving us our portrait mode, better virtual keyboard. etc. Given Nokia's treatment of Symbian, Hanlon's razor may apply here.

Am I the only one who doesn't care about portrait mode at all?

In fact, am I the only one who is annoyed that the phone app switches the phone to portrait mode if the keyboard isn't out?

I guess I don't understand, because frankly I think everything should be in landscape mode. Maybe I have big hands but I have no trouble operating it with one hand...