Ari Jaaksi of Nokia Wants to Educate the Linux Community

Wed Jun 11 14:44:00 -0700 2008
manage

Ari Jaaksi of Nokia wants to educate the Linux developers:

There are certain business rules [developers] need to obey, such as DRM, IPR [intellectual property rights], SIM locks and subsidised business models."

...Jaaksi said in This ZDNet Story.

But perhaps the community has some education for Jaaksi and Nokia. Jaaksi hosted me at a Nokia dinner in 2000, he's a nice guy and has been interested in Linux for a long time. But Nokia's barking up the wrong tree this time, because Nokia can do everything it wants with DRM, IPR, and SIM locks without bothering the Linux developers about it - and both Nokia and the Linux developers will like it better that way. It's surprising that Nokia doesn't understand that at this late date.

Of course Jaaksi's concerned that developers are unsympathetic to technologies that attempt to shackle the customer. He acknowledges that such technologies "aren't the Open Source way". And those developers have put their preference in writing, with the GPL and especially GPL3, which requires that there be means to change the software in embedded devices without disabling any of the functionality.

This is important to the Open Source / Free Software developers because without hardware, software isn't of much use. A future of locked-down embedded devices wouldn't leave much room for Free Software to run, especially software other than applications, like the Linux kernel. Thus, the provisions in GPL3 that require a path to change the software in hardware are important. But how does one do DRM, SIM locking, and protect critical copyrighted property in that context?

The key is knowing how to draw bright lines between different parts of the system. That's a legal term, and in this case it means a line between the Free Software and the rest of the system, that is "bright" in that the two pieces are very well separated, and there is no dispute that one could be a derivative work of the other, or infringes on the other in any way. All of the Free Software goes on one side of that line, and all of the lock-down stuff on the other side.

And so we can have what I call a bright-line system. That's a system that is designed, from the start, to separate those two pieces. In a properly engineered bright-line system, you can replace every byte of the Free Software, and yet the DRM keeps working as it should, the SIM locking continues to lock, and the GSM stack, which is the precious  "intellectual property" of most cellular companies, is still hidden away where nobody can see it. Many of my consulting customers are building these systems into their products today.

To build a bright-line system, you need an effective partnership between your legal team and engineering. I spend a lot of time building that bridge for various companies. It requires that engineers learn enough about the law to know when to ask the right questions, and to know not to answer them by themselves. That's important: my expert-witness practice has been fed by lawsuits in which engineers did what lawyers should have. And goofed.

The law team in a bright-line engineering partnership has to operate differently than they're used to. They have to be conscious that engineers are scored on meeting a timeline, and can't stop development while they're waiting for an answer from legal. Thus, legal has to be able to take on-impulse calls from engineering, and answer them in a timely fashion.

That's too expensive!, say the lawyers and managers. But it's part of the cost of doing business today. When I learned electronics, engineers built products by soldering together resistors and transistors. But today, the job of engineers is to build derivative works by combining units of intellectual property owned by third parties. That's not what they're trained for, and it's a mine-field of potential litigation for every company that puts software in its products - whether or not that software includes Open Source. Without an effective partnership between legal and engineering, your company walks that mine-field every day.

Once they've built an effective partnership between legal and engineering, it's time to design the system. There are three ways to keep Free Software separated from proprietary software effectively, and a fourth that has been tried but is too legally dangerous for me to recommend. They are:

Separate CPU:

Most cell phone designs include two CPUs, often on the same ASIC: an ARM9, an embedded CPU capable of running a full-featured operating system like Linux, and an ARM7, a smaller CPU that usually runs a real-time operating system. Generally the GSM stack lives in the ARM7. The ARM9 runs a full-featured OS like Linux, does high-level functions, and stays asleep when the phone isn't being used.

This is an ideal structure for a bright-line system, because all of the software that needs to be locked down can live in the ARM7, and all of the Free Software can live in the ARM9. The way the two CPUs communicate should be publicly documented or should be a full Open Standard to meet the requirements of GPL3.

Most phones use, believe it or not, the Hayes Modem control protocol to communicate between the two CPUs today. But obviously a better communication path is needed to send streaming media to DRM. If there is to be no potential to tap the unencrypted media stream from the Free Software, there must be a path to the display and audio output hardware from the ARM7.

Kernel under a Kernel

You may have noticed this statement that Linus Torvalds placed as a prelude to the GPL that comes with the Linux kernel:

NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it.

Linus' statement is unnecessary, as the terms of the GPL say that anyway. But the point here is that an application that just calls normal system services of the kernel is not a derivative work of the kernel. Similarly, a real-time kernel under the Linux kernel, exporting a publicly-documented set of system services to Linux, would not be a derivative work of Linux. DRM, SIM-locking, the GSM stack, and other such software could live in such a real-time kernel and could be protected from the Linux kernel and other Free Software.

User Mode

You can put anything you like in a user-mode program that runs on top of the kernel, as long as that program only links to programs that don't have strong reciprocal (or share-and-share-alike) terms like the GPL. Most Linux libraries are under the LGPL and similar licenses to make this easy for you. It's possible to implement DRM, SIM locking, and other lock-down features in a user-mode program, but it's not as proof against attacks on the security of those systems as the two methods above. If all you want to do is separate two pieces of copyrighted property, this is a good way to do it.

How Not To Do It

One method used by various companies is to place the proprietary property in a run-time dynamicaly-linked kernel module. I don't recommend this because it's legally ambiguous. The law doesn't define what constitutes a derivative work in software because copyright law was written before there was software. And various lawyers that I ask have opined on either side of the debate. But fortunately, you don't have to win this argument. Your goal shouldn't be to win lawsuits, but to not be sued at all. That means that your design must be so unambiguous in its separation of the Free Software from the proprietary software that there is no issue to be litigated. So, don't use dynamic linking as a means of keeping proprietary and Free Software separate.

- Bruce Perens

Bruce Perens provides consulting services to several national governments and major corporations on Open Source issues. He can be reached via email to bruce at perens dot com, or via phone at +1 510-984-1055.

In other news...

Wed Jun 11 17:24:57 -0700 2008
manage

The OpenMoko FreeRunner starts mass production this week.

The telecom industry loves Linux, and it isn't just because of the cost.  I'm just now finishing up a project on Sprint-Nextel's push-to-talk network and I can say it is almost all Linux servers (RHEL) with just a very small handful of Sun boxes and one or two HP systems.

In other news...
Wed Jun 11 19:46:36 -0700 2008
manage

Months ago they indicated that the first release of the GTA02 would be targeted at developers so that bugs could be worked out, and like the GTA01 release it would not be able to  be used as a reliable phone. But I didn't see any mention of this on openmoko.org

In other news...
Thu Jun 12 01:32:21 -0700 2008
manage

Once you discover the little spots where the device still needs work (6 hour battery life without sleep mode, sometimes 8-9 reboots to get associated to the gsm network, etc), the GTA01 has been functioning as my cellphone for two months now.

its not reliable (went to dallas, and it was a brick, due to channel differences?), but compared to my old cellphone, it was passable.

i think the term "reliable" needs some definition here. :)

In other news...
Thu Jun 12 02:04:11 -0700 2008
manage

Have they not been releasing updates?

In other news...
Thu Jun 12 16:31:07 -0700 2008
manage

To be blunt, "kindof".

Their development method is cathedral-only, no bazarr to speak of.

Its comon to find people in the irc channel cursing "taiwan", because they d ump software on the community, instead of participating with it.

I update my unit weekly. very few applications are updated, and they're adding bugs faster than they're removing them. instead, they decided to completely swap out the UI, instead of making their current UI fully functional.


I'm very disapointed. but then again, its open source, if i had time to do something *other* than work on my 25,000 line kernel patches (no, not kidding), i could fix it. that makes it at least partially my fault.

 

I'm just glad to carry one less proprietary OS on my person, on a day-to-day basis. now, i need to switch digital cameras... (aparently, samsung built some linux cameras..)

Ari Jaaksi of Nokia Wants to Educate the Linux Community
Wed Jun 11 17:33:38 -0700 2008
manage

In your opinion, is there anything special about these two cases:

System calls in kernel X that are non-standard and that, by their nature, are particular to the kernel? If not, how does this differ from the case of the readline library?

GPL'ed dynamically loadable modules that externalize non-standard interfaces to user-space, where those non-standard interfaces are highly specific to a non-free program?

(These refer to real-world cases I've seen and I'm not interested in arguing about them -- only in hearing how you advise about such things. I (a ways back) wasn't asked to advise in the serious way you do but was asked for an opinion about them and tried to indicate that basically I didn't know but it sounded a bit sketchy.)

-t

Ari Jaaksi of Nokia Wants to Educate the Linux Community
Wed Jun 11 18:17:50 -0700 2008
manage

I tell my customers to stay away from both, they are legally ambiguous and I don't want my customers to be the test case.

I advise them that if it has to mess with the kernel, to put the BSD or GPL license on it, and keep it publicly available, and try to get the kernel team to accept it.

Sometimes there is friction. Some causes are:

  • Vendor-owned software or trade-secret hardware interface in an embedded product. You must design especially carefully to protect this third party's rights, and your liability to both the third party and the Free Software folks.
  • Lazy over-estimate of the differentiating value of your kernel driver and the information it reveals.
  • Poor engineering resulting in too much proprietary information at the driver level.
  • Legal isn't funded sufficiently to meet engineering's needs, or isn't cooperative.
  • Engineering didn't get "Intellectual Property 101" training. Call me and get it for them.
Ari Jaaksi of Nokia Wants to Educate the Linux Community
Sun Jun 15 08:24:22 -0700 2008
manage

I work on 'simi-open' linux drivers which have been chosen because they are non-GPL.  Specifically, a set of well known network drivers under a BSD license.  As a company we choose these drivers as a starting point because of the BSD-ness.  We do release patches that fix bugs in the original driver, but do not release any in-line extensions we have made.

My personal opinions on the 'right' path aside, the model of having BSD licensed kernel modules in a GPL kernel in support of proprietary development seems to be in contradiction to your position.  In 16+ years working on linux drivers at a number of companies this is both common and an expected way to retain some market advantage.  I have no problem being wrong, but there are an awful lot of BSD licensed drivers for linux that have life becuase they are both BSD licensed and Linux.

So, does a BSD licensed driver in a Linux kernel lead to a GPL license behavior of that driver?

 It was stated that linux kernel modules are undefined territory but you wouldn't want your customers to be the test case.  Then, you say to release under BSD or GPL license.  How can a BSD license which does allow for propietary extension be an acceptable license option if the kernel GPL leaves that driver in an ambigious position?

Ari Jaaksi of Nokia Wants to Educate the Linux Community
Sun Jun 15 09:57:51 -0700 2008
manage

So, does a BSD licensed driver in a Linux kernel lead to a GPL license behavior of that driver?

Yes. The BSD license can not act as a "condom" between the GPL and proprietary code.

While the BSD license allows you to modify the licensed code in any way whatsoever, the GPL doesn't allow you to combine the proprietary modifications with the rest of a GPL work and distribute them. The entire work must be under a license with no more restrictions than the GPL.

The status of your "semi-open" drivers is essentially the same as that of a proprietary driver when it is combined with the Linux kernel. You're essentially relying on dynamic linking to protect you. It's risky, IMO, and if I were working for you, I'd tell your lawyer it's risky. I'd be happy to discuss this with you (and your attorney if you wish) informally and without charge on the phone. Please don't tell me stuff that would require an NDA if you aren't paying me, though. Just write to bruce at perens dot com if you want to make a call.

Thanks

Bruce

Ari Jaaksi of Nokia Wants to Educate the Linux Community
Thu Jun 12 04:47:53 -0700 2008
manage

So what's the problem here?

Are they saying that FOSS devs should just accept that that's how things are done or do they want to bring these things into the kernel proper?

Realistically speaking, why wouldn't the developer community want to maintain the tools that lock them out of the hardware. End up becoming like netBSD, sure it runs on anything but who really uses it.

Need to get with the program and allow companies to externalize their IP protections—just think of the market share that is being lost. Have to get those 80% savings up into the positive profits category like Mr. Lord is always going on about.

Come on guys...it's all about subsidized business models.

Ari Jaaksi of Nokia Wants to Educate the Linux Community
Thu Jun 12 14:49:35 -0700 2008
manage

I suddenly want to throw my N810 out the window, thank jeebus they've debian for it now

Nokia's attitudes & OpenMoko

Thu Jun 12 17:04:30 -0700 2008
manage

I've not acquired any of the Nokia GNU/Linux products, even though was offered a discount code. I might have overlooked Nokia's bad habit of sticking more and more non-free software (including both in-house stuff and the heavily touted third party blobs like Flash and Skype, egh), but then it became rather clear that Nokia was, overall, a strong enemy of free software (yes yes, factions exist, but if there are free software proponents inside, they're not very vocal or influential). Witness their very strong lobbying for EU swpatents and an oldie but goldie blog entry from one of their more stand-up ex-employees, as well as the smaller details like sabotaging Ogg Theora from consideration for HTML 5 recommendation status...

They say they're going to release a Linux phone in the future. This might possibly tempt me, but luckily I rather think not, because their track record says much of it will be pretty closed up anyway.

Conversely, I do hope OpenMoko progress will pick up, at least they're pretty dedicated to maximizing freedom even if it has been somewhat of a slower start than one'd hope. I use a Neo1973 currently, for me it's buggy but bearable with a known-good firmware version (and lots of charging); probably wouldn't be my main phone yet if my old Nokia N-Gage wouldn't have crapped out on me, but it did, and I didn't feel like shelling out for less free options anymore. Will buy the FreeRunner pretty much instantly as well, both for support and for its improvements.

Nokia's attitudes & OpenMoko
Sat Jun 14 10:06:38 -0700 2008
manage

Thank god.  I didn't think I could be the only one horrified by this cheerleading for closed source, DRM and software patents.  Those of us who use free software cannot support locking down, either in the software or the hardware.  Rather than being a good thing this "clear bright lines" is a Frankenstein's monster.  Maybe paid developers will build this way,  maybe manufacturers will use it but it's nothing the FOSS community is going to cheer about.  Remember, you're not just locking the consumer out, your locking out the developers too.  They are the ones who will crack your shit rather than have their usage restricted.  If they can't crack it they won't hack it so say goodbye to your development model.

Ari Jaaksi of Nokia Wants to Educate the Linux Community
Sun Jun 15 01:24:51 -0700 2008
manage

Nokia are nuts. Actually, GSM was intended to be open standard and also to give freedom of choice. And in countries where cell operators have started with GSM skipping old closed standards (where phones were without SIM cards) it looks like this:

 - You're selecting phone you're like

- Then you're selecting cell operator and subscription you're like.

That's fair.That works.And subscribers are happy while competition is at good level and quality of service rocks while prices are modest.

What exists in USA and in some Europe countries is actually form of slavery (should I say mind-slavery here?).What?Phone locked to operator and freedom of choice crippled?Cool.And while paying moneys you'll also get DRM and other stuff which f...ks you up for your own money.How incredible.Should I also pay for bullets or rope for my own execution, maybe?Or should I pay for "roaming" in the jail?No?Huh, looks like that's temporarily and will be fixed soon.

 

Where to antitrust authorities looking?Actually such schemas as sim-locking should be declared illegal IMHO.