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."
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.
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.
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
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.
:)
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..)
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.)
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.
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?
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.
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.
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.
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.
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.
Ari Jaaksi of Nokia Wants to Educate the Linux Community
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:
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 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.