Misunderstanding of embedded system designers [LWN.net]

Misunderstanding of embedded system designers

Posted Jan 16, 2006 22:01 UTC (Mon) by karim (subscriber, #114)
Parent article: GPLv3: a first look

Clearly the FSF once again fails to understand the realities of
embedded system designers. Many embedded engineers have no love
for DRM, but must ensure that the products they build cannot run
anything but "authorized" applications in order to protect the
copyrighted material others will allow to play on their devices.

They don't personally own such material, and neither does their
company. They just need to build a product that protects the
belongings of others.

What this version of the GPL does, in as far as I'm reading it
right, is close an entire segment of computerized products from
software licensed under it -- and for the wrong reasons.

Fighting DRM is a worthy goal, and I do encourage the FSF's
strong stance on many issues, but they are wrong on this one.
Having this sort of provision will not free the engineers I
allude to above from having to meet a certain requirement. It's
their job and they will have to carry it out. What it will do
though is:
a) require those engineers to use proprietary software, which
-- as has been demonstrated time and again -- can put the user
at risk.
b) alianate those engineers from the free software community
by making their job much harder and ensuring that they cannot
justifiably contribute to free software projects as part of
their job.

Just my 0.02$

Karim

(Log in to post comments)

Misunderstanding of embedded system designers

Posted Jan 16, 2006 22:31 UTC (Mon) by cyd (subscriber, #4153) [Link]

Interestingly, there is a rather permissive new clause that seems relevant for embedded systems. Under "basic permissions":

Propagation of covered works is permitted without limitation provided it does not enable parties other than you to make or receive copies. Propagation which does enable them to do so is permitted, as "distribution", under the conditions of sections 4-6 below.

I believe the GPLv2 didn't have such a clause. It seems to be saying that there is no need for the source to accompany the executable if the software is distributed in a system where the user can't copy it out, like a non-flashable chip in a toaster. I wonder if this is really the intention.

Misunderstanding of embedded system designers

Posted Jan 16, 2006 23:11 UTC (Mon) by alriddoch (guest, #2249) [Link]

The clause you quote includes the wording "... to make or receive copies". I think it is clear that when you distribute software on a non-flashable chip in a toaster, the user is receiving a copy, even though they are unable to make copies from it.

I believe this clause is intended to make it clear that copying the software between multiple systems, or from a CD onto your hard drive does not count as distribution, and thus does not require you to accept the license.

Misunderstanding of embedded system designers

Posted Jan 16, 2006 22:33 UTC (Mon) by foom (subscriber, #14868) [Link]

While it may be true that such embedded systems require that the user not be able to modify the
supplied system, such a requirement is directly in conflict with the FSF's goals.

The FSF is promoting Free Software -- that is, in their words "software that respects the user's
essential freedoms". One of those essential freedoms is the ability to modify the software. Providing
the source code for a system but designing the system such that the user cannot modify the code
makes it unfree. While the GPLv2 let you get away with this, the GPLv3 closes the hole, such that it's
no longer possible to subvert free software in this way.

It does not matter whether or not you *like* DRM, if you are designing a product that uses it, you
should not expect the FSF (and others who agree with them) to help you in that task any more than
if you were creating any other proprietary product.

Misunderstanding of embedded system designers

Posted Jan 16, 2006 23:44 UTC (Mon) by karim (subscriber, #114) [Link]

The folly of all great ideals is to blindely follow clear
successes with short-sighted and stuborn policies, thereby
forgetting the initial goal (communism vs. the peasants'
greater good, bureaucracy vs. having structured government
services, etc.)

I understand the FSF's intent. I just think that this is
the kind of thing that hurts the FSF's goal instead of
helping it.

Karim

Misunderstanding of embedded system designers

Posted Jan 17, 2006 0:49 UTC (Tue) by cventers (subscriber, #31465) [Link]

Karim,

I have to disagree. I've just finished reading Stallman's "Free
Software, Free Society" lately (it's a collection of essays and speeches
he's done throughout the year).

When I saw the new GPL license draft, I felt very much like the FSF
was adhering to the principles on which it, and the free software
movement it advances, were founded.

By contrast, I think the accusation of "short-sighted and stubborn
policies" indicates a desire that they yield in some part of their core
mission. If I look at the landscape on which we now sit, I see the FSF as
being the organization responsible for maintaining the uncompromising
idealism on which our modern software society is now based. If someone
wants to make compromises, perhaps it can be OSI? (small jab :P)

Remember that no one has any 'duty' to support business with their
free software. The FSF, in its documents, makes this clear. However, they
do concede that once they satisfy freedoms, they can work to satisfy
business as well.

Just some random thoughts.

- Chase

Misunderstanding of embedded system designers

Posted Jan 17, 2006 9:34 UTC (Tue) by nix (subscriber, #2304) [Link]

I concur. I can see very little wrong with this GPL revision: I was fearing a repeat of the GFDL fiasco, but it seems my fears were unfounded. Bravo!

(Oh, and if there's one thing nobody can describe RMS as, it's `blind'. He's shown a consistent record over the last few decades of foreseeing threats to software freedom a decade or so before they become obvious to most people.)

Misunderstanding of embedded system designers

Posted Jan 17, 2006 6:56 UTC (Tue) by jae (guest, #2369) [Link]

The "folly" of all (great) ideals is that they have some "vision", and won't budge to short-sighted interests.

Fell free to take this as a flame if you want to.

Misunderstanding of embedded system designers

Posted Jan 16, 2006 22:36 UTC (Mon) by melevittfl (guest, #5409) [Link]

and

c) Will make systems that include DRM more expensive to build and more likely to be buggy.

This may lead to DRM-encumbered products costing more to consumers and proving less reliable.

This leads to consumers rejecting products that include DRM in favor of sticking to reliable technologies like CDs until such time the technology companies find their spine again.

Seems like this clause works for me.

Misunderstanding of embedded system designers

Posted Jan 16, 2006 23:19 UTC (Mon) by karim (subscriber, #114) [Link]

I disagree with your conclusion, but you're not entirely off track.

First, from what I have seen DRM is not going away any time soon.
Partly due to the fact that those producing copyrighted material
(i.e. the artists) have very little understanding of the technology,
its impact, and the rest, which makes them very easily convinced
that they must use every possible means to protect their turf. If
you can scare someone into believing that a foreigner (someone of
a different skin color, religion or -- closer to home -- more
technologically apt) will take away their bread and butter or
put their livelyhood in danger, you can bet they'll use every and
any possible means that this doesn't happen, including requiring
that those he entrusts his "work" to provide firm guarantees.

That's just human nature. And whether free software developers want
to allow developers caught in the crossfire to use a piece of
software or not won't really change much. DRM will remain until
the fear I describe above is present, there's nothing any
software license can do about it -- and that's partly why the
DRM clause in GPL3 is wrong.

You want to make DRM go away? Just don't buy DRM'ed material. It's
as simple as that. The one thing the "creators" will hate more than
the fear of not making money, is actually not making any.

Karim

Paraphrasing you

Posted Jan 17, 2006 4:30 UTC (Tue) by proski (subscriber, #104) [Link]

I disagree with your conclusion, but you're not entirely off track.

First, from what I have seen spam is not going away any time soon. Partly due to the fact that those advertizing by the means of spam (i.e. those who hire spammers) have very little understanding of the technology, its impact, and the rest, which makes them very easily convinced that they must use every possible means to protect their turf. If you can scare someone into believing that a foreigner (someone of a different skin color, religion or -- closer to home -- more technologically apt) will take away their bread and butter or put their livelyhood in danger, you can bet they'll use every and any possible means that this doesn't happen, including requiring that those he entrusts his "work" to provide firm guarantees.

That's just human nature. And whether free software developers want to allow spammers caught in the crossfire to use a piece of software or not won't really change much. Spam will remain until the fear I describe above is present, there's nothing any software license can do about it.

You want to make spam go away? Just don't buy stuff advertized by spam. It's as simple as that. The one thing the "creators" of spam will hate more than the fear of not making money, is actually not making any.

Misunderstanding of embedded system designers

Posted Jan 17, 2006 18:33 UTC (Tue) by davecb (subscriber, #1574) [Link]

karim said:... those producing copyrighted material (i.e. the artists) have very little understanding of the technology

I'm one of those producers, and I and my (book) publisher found that free, non-DRM'd electronic distribution of our work drove book sales.

Baen has now followed O'Reilly in this, shipping completeley unrestricted PDFs of their back catalog with recent publications...

Some artists in the graphic and performing arts have seen this, though their publishers haven't

--dave

Misunderstanding of embedded system designers

Posted Jan 18, 2006 14:25 UTC (Wed) by nix (subscriber, #2304) [Link]

Baen has been doing this for a long time: I think longer than ORA. I have a book I bought in 2001 with a CD-full of other books at the back, in HTML and RTF...

Misunderstanding of embedded system designers

Posted Jan 16, 2006 22:39 UTC (Mon) by bk (guest, #25617) [Link]

Many embedded engineers have no love for DRM, but must ensure that the products they build cannot run anything but "authorized" applications in order to protect the copyrighted material others will allow to play on their devices.

This sounds like a very oblique way of saying: "I am involved in the development of media player(s) that are locked down to prevent installation of anything other than factory-authorized firmware/software. This is so that the device can only be used with 'properly' restricted (DRMed) content."

Am I right? Can't your employer license some proprietary embedded OS for their locked-down device? Such development should be as difficult and expensive as possible, I see no reason to accomodate it with our free licenses.

Misunderstanding of embedded system designers

Posted Jan 16, 2006 23:06 UTC (Mon) by karim (subscriber, #114) [Link]

Please cut the us-vs-them crap and check who you're talking to first:
http://www.oreilly.com/catalog/belinuxsys/

Being in my position, you kind'a meet a lot of people on both
sides of the fence, you kind'a see a lot of designs, and it kind'a
gives you a better view from a distance.

Coold heads (and philosophy 101) would tell you that making personal
attacks does not diminish your opponent's arguments.

And if I may suggest ... please don't present yourself in public
claiming to defend my view of software freedom.

Karim

Misunderstanding of embedded system designers

Posted Jan 16, 2006 23:11 UTC (Mon) by bk (guest, #25617) [Link]

In no way did I personally attack you. Nor did I question (or even bring up) your abilities or expertise in embedded design (thank you, however, for crudely insulting my philosophy erudition). Perhaps you should consider your own advice regarding cold heads.

Plaining speaking (rather than hiding behind mealy-mouthed apologetics) will make me respect your viewpoints more. All the publishing credits in the world won't change that.

Misunderstanding of embedded system designers

Posted Jan 16, 2006 23:27 UTC (Mon) by karim (subscriber, #114) [Link]

My publishing credits weren't meant to convince you of my viewpoint.
Rather, it was meant to demonstrate that there can be other reasons
for voicing an opinion that those you hinted at.

And no, you're right, I did not react with a cold head. It just
really gets to me when I see the kind of "us-vs-them" attitude. We
all have a responsibility for the greater good and we all have the
duty -- at least that's my belief -- to make an effort in
understanding others' viewpoints.

Karim

Misunderstanding of embedded system designers

Posted Jan 17, 2006 0:55 UTC (Tue) by cventers (subscriber, #31465) [Link]

"Us-vs-them" is looking at things the wrong way, I think. I could see
someone using the same term to describe the fact that the GPL isn't
becoming, say, BSD-like in that it still doesn't allow Microsoft to link
parts of Linux into their proprietary Windows kernel.

If you're going to create a better world, you have to, at times, draw
lines in the sand. This is the difference between public domain and
copyleft.

Misunderstanding of embedded system designers

Posted Jan 19, 2006 20:40 UTC (Thu) by Fats (subscriber, #14882) [Link]

It's not "us-vs-them". What you say is that it is OK to have somebody make a device running a linux kernel but I can't compile a new kernel for that device and run it with the new code. This just doesn't feel right to me and I agree with RMS on this one (which doesn't happen that often). People who don't want to allow that should not use GPL software for their kernel.

Misunderstanding of embedded system designers

Posted Jan 16, 2006 23:40 UTC (Mon) by bronson (subscriber, #4806) [Link]

Take a few breaths, bk. There's enough hypocrisy in this thread for everybody.

I see no reason to accomodate it with our free licenses.

"our"?

Misunderstanding of embedded system designers

Posted Jan 17, 2006 9:43 UTC (Tue) by nix (subscriber, #2304) [Link]

'Free licenses that are better than anything I could have written and that I wholeheartedly support'.

I use 'we' that way too, quite often. Perhaps it's a bit mendacious. :/

Misunderstanding of embedded system designers

Posted Jan 19, 2006 10:37 UTC (Thu) by jschrod (subscriber, #1646) [Link]

OK, so you think you're famous because you're active in the Embedded Linux area and have written an ORA book.

Does that make your view right by means of `I am better than you'?

From my impression, bk attacked your viewpoint. As a reaction, you attack him personally and don't answer his actual points factually. And then you advise him to have `coold[sic!] heads'. Well, cold heads, indeed.

This is just a feedback that you know how that exchange looks to others.

Cheers, Joachim

Misunderstanding of embedded system designers

Posted Jan 19, 2006 18:17 UTC (Thu) by karim (subscriber, #114) [Link]

Please go back and read the exchange.

His initial post clearly questioned my motivations, insinuating that
my viewpoint was tainted by my work. Like you, he thought my mention
of my book was meant to convince him of my viewpoint. It wasn't. As
I pointed out to him, the main goal was to show that there can be
other motivations for defending a viewpoint. If you'd care to follow
the thread, you would've also seen that I did ack my hot-head comments
... everyone's got his buttons ... some of us are self-aware, others
are less so inclined ...

Karim

Misunderstanding of embedded system designers

Posted Jan 16, 2006 23:40 UTC (Mon) by JoeBuck (subscriber, #2330) [Link]

You are correct that the FSF intends not to support the particular set of embedded systems designs you describe (those that implement DRM). If the free software developer community accepts this concept, then yes, it is true that engineers that have the job of building such systems will have to either write their own software, or buy proprietary software. And that's OK: the free software world doesn't owe these people any free help.

But systems that include DRM are currently a very small subset of all embedded designs. Most embedded systems could continue to use GPLv3 code.

The terms you use ("They just need to build a product that protects the belongings of others") suggest that you're taking the DRM side in the coming war, and that you aren't just a neutral open source journalist. DRM protects "rights" that copyright holders do not have, by, for example, making it near-impossible for scholars and reviewers to include portions of the work in their reviews, a fair use right protected by law. They also protect unilateral take-aways of user rights, as restrictions are added to works that weren't in place when the customer paid for the right to enter the DRM jail.

Maybe we'll see a split among the Linux kernel developers on this issue: many hate DRM, others (like part of the audience for your book) may be eager to build DRM systems out of free software. We'll see.

Misunderstanding of embedded system designers

Posted Jan 17, 2006 0:04 UTC (Tue) by karim (subscriber, #114) [Link]

First, I would like to say that I contest the idea that DRMed systems
are but a subset of devices out there. I would say, in fact, that
DRM is increasingly found everywhere. Heck, some would even like us to
watch TV on our cell phones ... In as far as "consumer devices" go,
then for sure they're all on the DRM road already in some way, shape,
or form. What portion "consumer devices" has in "embedded devices"
is another debate altogether. Not that other "embedded devices", such
are your car's brake controller, don't need to be "protected" from
the person receiving the software (i.e. the consumer).

With regards to the cause of DRM, I'm really not much of a conspiracy
believer. The reason DRM can fly is because someone, somewhere is
afraid he'll stop making money. Whether others retrofit this to other
uses, including some which you hint at, is another issue altogether.
Note that I don't believe the latter could hold if the former did not
exist.

In as far as my position goes vis-a-vis DRM, please read my other
posting which explains the real thrust behind DRM. If you want to
kill DRM, then don't by DRM'ed products.

Karim

Getting embedded system designers fired

Posted Jan 17, 2006 0:28 UTC (Tue) by man_ls (subscriber, #15091) [Link]

So some engineers waste their time and efforts building stupid restrictions into devices. So for some reason (other than avoiding crappy hardware) we should care about them by making their jobs easier; and then altogether getting them fired by not buying the result of their work.

Sorry, but I don't feel that way about members of the free software community. Either I want to help them, and then I want them to have good jobs; or I don't want them in the community. In my case, I don't want free software near e.g. the nauseating LIBRIe. It would give people the wrong message about free software and copyrights: that sharing information is wrong.

[OT] Librie

Posted Jan 18, 2006 9:39 UTC (Wed) by ikm (subscriber, #493) [Link]

Librie was "liberated" by SONY long ago -- by providing all the tools to produce unencumbered texts -- apparently after they have found no one bought the device without it.

Misunderstanding of embedded system designers

Posted Jan 17, 2006 5:14 UTC (Tue) by akumria (subscriber, #7773) [Link]

"If you want to kill DRM, then don't by [sic] DRM'ed products."

You suggestion only addresses the demand side of the problem. Yes, once manufacturers realise that people don't demand DRM they will stop bundling it.

Another mechanism to slow-down DRM is to look at the supply side of the problem. The intent is to make it more expensive to develop products which have DRM in then.

Hopefully entertainment expenditure is price elastic, in that as the price of entertainment (and associated equipment) rises less people purchase it. When manufacturers see less demand (because things are now more expensive) they are less likely to continue producing those items.

If we want to counter DRM successfully I think it is vital to address both the demand and the supply side of things.

Misunderstanding of embedded system designers

Posted Jan 17, 2006 13:41 UTC (Tue) by RobSeace (subscriber, #4435) [Link]

> I would say, in fact, that DRM is increasingly found everywhere.
...
> If you want to kill DRM, then don't by DRM'ed products.

Sounds like some kind of cognitive disconnect... If it's everywhere, then
how can we avoid buying it? Unless you suggest we not buy ANYTHING?? And,
that's not a very realistic suggestion, of course... So, either your first
statement above was extreme hyperbole or your "Just don't buy it!" strategy
isn't very realistic/effective... I tend to suspect a bit of both... But,
I think your first statement is indeed indicative of where things are
headed, even if we're not quite there yet... So, in such a world, I think
we need to find a much more realistic and effective method of killing DRM
than simplistically saying "Just don't buy it", something which is being
made increasingly impossible to do...

Misunderstanding of embedded system designers

Posted Jan 17, 2006 9:47 UTC (Tue) by nix (subscriber, #2304) [Link]

Furthermore, of course, even if the DRM vendors were trying to protect fair use rights and the like, they couldn't. It is impossible to build DRM that constrains users in one country to obey that country's laws without constraining users in other countries more than their law allows, and some countries have laws that vary dependent on your intent when copying, or even on your profession. There's no way that any software could verify that.

(of course IANAL, I just typed stuff up for them and am related to some)

Misunderstanding of embedded system designers

Posted Jan 17, 2006 0:13 UTC (Tue) by nchip (guest, #13292) [Link]

FSF just wants to close the "Device will only boot the that is signed with Key X" loophole. Embedded engineers could reap the fruits from Free Software movement, while deny access to same fruits to end-users. They distribute the source code of their kernel as GPL requires in word, but fail the spirit - user can build their own kernel, but it will not run on the device.

There is better ways out, for example having a "official key" that can decrypt the DRM codecs and can be used to verify that only authorized apps are running. And the provide with GPL sources a "GPL key" (GPL3 allows different keys), that allows using the hardware with any code of will, but can't decrypt DRM codecs (which aren't free software anyway).

Of course, currently Linux has GPL-2 only code, so your worries are not current yet. You still have time to convinience kernel developers that they should not relicense those parts to GPL >= 2. Unfortunatly there is not much evidence that engineers of DRM-restricted Linux systems have brought important features to mainline kernel...

Now to more philosophical matters: where are we actually going? Users despice DRM-locked hardware (see the bad press every time TiVo bends over and makes something a bit more restricting). Users are increasingly going to HTPC's because provide more freedom - ironically often to Microsoft Media Center. Will PC's get similar "authorized applications only" policy as media producers enforce now on embedded makers? Or will PC's replace restricted embedded devices completly? First Choice is bad for Embedded Linux engineers. Second is really bad for everyone. And BOTH of those might happen!!

Misunderstanding of embedded system designers

Posted Jan 17, 2006 1:52 UTC (Tue) by karim (subscriber, #114) [Link]

Well, if we're going to discuss "other ways" of doing DRM, here's a basic
example applied to the kernel (not that the kernel developers have
agreed to use GPL3 for the kernel, but just for the sake of argument):

Prior to booting kernel, let the firmware verify the kernel's signature.
Whether or not the signature is valid, boot the thing. But, if it isn't
valid, lock up or disable or just don't enable those hardware components
that control access to the "stuff" -- and do this in a way that requires
a hard reset for another pass at lock/don't-lock. Then package all the
proprietary/DRM software into individual applications. So everything just
runs as normal up to the time these apps try to access the hardware,
and now because it's disabled, the device is useless.

Using the words of the draft, there are no codes for you to "install and/
or execute" the work. In fact, you're free to install and execute any
kernel you wish. Plus, the kernel's "functioning in all circumstances is
identical". It's just that hardware beneath it just doesn't work any more,
and that, consequently, the proprietary applications running on top can't
do anything because the hardware is disabled.

There you have it, GPL3-compatible DRM -- to the best of my understanding
of course, and mind you I'm not a lawyer.

Again, fighting DRM is a worthy goal, but this is the wrong venue.

Karim

Misunderstanding of embedded system designers

Posted Jan 17, 2006 7:11 UTC (Tue) by foom (subscriber, #14868) [Link]

I think it is clear that the GPL can only protect the works that it covers. So, if you can fully use the
hypothetical GPLv3'd kernel but some proprietary app is protected by DRM, there can be nothing
wrong with that. Yes, you cannot use the proprietary application, but, you must be able to fully use
everything on the system protected by the GPL.

However, note one further wrinkle. Let's assume that there will be an LGPLv3 similar to the current
LGPL + GPLv3 changes. Then, said proprietary app must allow the replacement of LGPL'd
subcomponents and still function. Such as...GNU libc. So, you can build your proprietary app with a
DRM checksum, but, I have to be able to replace the GNU libc and have the app still function.

Of course, you can build your app without libc, too...

Misunderstanding of embedded system designers

Posted Jan 17, 2006 8:22 UTC (Tue) by phip (subscriber, #1715) [Link]

It may be a small victory, but at least the pre-boot firmware could not be derived from free (GPL3) signature-checking code.

Another small benefit is it makes life more difficult for developers of locked-down hardware. They need to pay careful attention to how the lock-down is implemented to avoid violating the license, and if they slip up, it will be clear that they had every intention of violating the spirit of the license, even if the violation of the letter may be accidental.

Every little bit helps.

-Phil

'cannot be part of an effective prevention measure'

Posted Jan 18, 2006 0:54 UTC (Wed) by xoddam (subscriber, #2322) [Link]

That use case would be compatible with this draft of the GPLv3, yes.
Thankyou for pointing out the loophole; the final licence may close it.

Supposing some OS kernel is licensed under a GPLv3 which retains this
loophole and used in a system such as you describe -- the GPLv3 kernel is
constrained not to be part of an 'effective prevention measure', meaning
that it is explicitly permitted to use the kernel (modified or not) as a
tool to reverse-engineer the DRM-enabled firmware, devices and
applications.

An OS kernel is fairly well positioned to do this job. I think DRM
device developers would be best advised not to use a GPLv3 kernel.

'cannot be part of an effective prevention measure'

Posted Jan 18, 2006 16:23 UTC (Wed) by karim (subscriber, #114) [Link]

FWIW, you'd be amazed what can be done by a piece of
hardware. So a scenario where the hardware has a latch
that can only be set once until hard-reset or power
down is very possible. Whether you can get the OS to
boot or not, and regardless of what that OS tries to
do, that hardware won't change state ... that's one
thing that's nice about hardware, you actually get to
control what software can and cannot do ...

Karim

'cannot be part of an effective prevention measure'

Posted Jan 20, 2006 3:24 UTC (Fri) by xoddam (subscriber, #2322) [Link]

> Whether you can get the OS to boot or not, and regardless
> of what that OS tries to do, that hardware won't change state ...

So I fisrt boot the unmodified, signed kernel to which I have the source
(six months behind the current free version) and have the hardware fully
enabled. Now I use some kernel exploit (reported and promptly fixed some
time in the last six months) to kexec an updated kernel, configured as I
please. Voilà! I 0wn my own box.

'cannot be part of an effective prevention measure'

Posted Jan 20, 2006 3:48 UTC (Fri) by karim (subscriber, #114) [Link]

Ah ... yes ... thanks for bitting ... At last someone steps
up to the challenge ;D

It's worthy to note that the problem you allude to is
something a designer of such a system would absolutely need
to catter for even today. IOW, this is not an unknown issue.

Think no glibc ... think selinux ...

Not that it's easy to get it right. The hacks we've seen on
some consoles are based on similar ideas ...

Karim

'cannot be part of an effective prevention measure'

Posted Jan 20, 2006 8:04 UTC (Fri) by xoddam (subscriber, #2322) [Link]

"the problem you allude to"

There's a problem? I'm not alluding to a problem, I'm working out how to
exercise my rights under the GPL :-)

I understand that if I receive a box with a differently-licenced
operating system then such exploits may violate the DMCA and its
equivalents in countries (such as my own) which have free-trade
agreements with the USA. The purpose of the DRM clause in the draft
GPLv3 is to ensure that GPL software is not used to take away the rights
of its users to use the software as they please.

Given that there is no GPLv3-licenced kernel, and that if there ever is
one it is not likely to be used inside such restricted devices,
*somebody* has to break bad laws and put up a spirited defence to them in
court or a time will come when they are considered normal and therefore
proper.

Misunderstanding of embedded system designers

Posted Jan 19, 2006 9:12 UTC (Thu) by hingo (subscriber, #14792) [Link]

In contrast with other commentors, I'm not at all convinced your scenario is allowed by this draft of v3. It seems that that kind of thing is exactly what it tries to prevent and in my opinion there is no loophole: If the key the manufacturer possesses is needed to use features of the hardware, and features can't be used without it, then it is part of the source code. If your interpretation was correct, one could ship binary-only kernel modules by saying "sure, you can do whatever you want with the kernel sources, you just won't have wireless lan (or whatever) anymore. The hardware will boot the kernel, just with less features."

Now on the other hand, it is true that you could make an embedded Linux device and install non-gpl applications on it (Real Player, even Wine + MS Media Player in theory at least) that do the DRM in userspace. That is not forbidden, although such drm won't last very long. Fortunately!

Misunderstanding of embedded system designers

Posted Jan 19, 2006 15:08 UTC (Thu) by karim (subscriber, #114) [Link]

Are you telling me that in your view a software license can actually
dictate a hardware license?

Sorry, as a software publisher you have the right to dictate how
your work is being used, not other people's work -- lest you are
telling me that the GPL3 is a DRM tool itself.

Given that the kernel is not touched in any way and that no part of
it is implementing the software-side of the DRM, there is nothing
that precludes a designer to control the layer beneath the kernel
(i.e. the hardware) and the layer that's over the kernel (i.e. his
applications) as he sees fit. In fact, I'm pretty sure (though I'm
not a lawyer and this is not legal counsel) that if you did try
what you allude to -- using the kernel to circumvent the user-
space DRM -- you'd probably fall under the DMCA ...

Have all the fun you want, but this isn't a loophole, it's just
something the GPL cannot, to the best of my understanding, legally
cover.

Karim

Misunderstanding of embedded system designers

Posted Jan 19, 2006 20:52 UTC (Thu) by Fats (subscriber, #14882) [Link]

"Sorry, as a software publisher you have the right to dictate how
your work is being used, not other people's work -- lest you are
telling me that the GPL3 is a DRM tool itself."

You distribute the GPL3 code with the hardware. If you do something in the hardware that is incompatible with the GPL3 license of the software there is a provision in the license that forces you to not distribute the GPL3 software. You are free to distribute the hardware but not the accompanying GPL3 software. Don't know if this applies to this specific case though.

Misunderstanding of embedded system designers

Posted Jan 19, 2006 23:12 UTC (Thu) by im14u2c (subscriber, #5246) [Link]

Huh? How can the GPL say "You are not allowed to design hardware or software that recognizes only a single binary compilation of this program code."

That simply doesn't make sense. What if I wanted a Linux Security Module that verified all binaries on a system against a write-protected set of binary signatures, to verify no one's intruded on my system? Are you saying I can't do that for GPLv3 programs? That simply makes no sense.

The GPL doesn't say you can't design anything.

Posted Jan 20, 2006 3:28 UTC (Fri) by xoddam (subscriber, #2322) [Link]

The GPL does say you can't sell a version of GPLd software that is not
modifiable by the end-user. Draft GPLv3 says that if you need to sign
the software to run it, you must also provide the necessary key to the
end user -- it is considered part of the source code, and properly so.

Misunderstanding of embedded system designers

Posted Jan 20, 2006 6:36 UTC (Fri) by hingo (subscriber, #14792) [Link]

You mean you have take a hash of the final executable and the hardware will only run that and nothing else? I'm not sure on this one, but that may in fact be allowable (there is no secret key to give away, so you have given the user everything there is). It may not be very wise however, because if there is a bug in your software you cannot update it anymore, you'd have to replace the entire device. (If there is a non-hardware way to update it, the license requires you to provide the user with that mecanism.)

Therefore the wiser thing to do is what Karim above wants to do, have the firmware check whether the executable is signed with a particular key. This way you can later produce updates and sign them. On this issue the v3 is very clear. You have to either a) provide the user with the secret key needed, or (more likely) b) enable the user to alter the device such that he can use another key of his own without losing any functionality because of that.

While I'm writing here, I'll reply to Karim as well: Obviously, the GPL cannot dictate the hardware license. You can build such hardware if you want, and if your software is GPLv3 you'll have to include the secret key. Sorry boy, you are just worng and confused, and you should let go already. (For the benefit of everybody, I don't intend to continue this thread although I fully expect Karim will do so.)

Misunderstanding of embedded system designers

Posted Jan 20, 2006 20:50 UTC (Fri) by karim (subscriber, #114) [Link]

Feel free to paint my position in whichever color makes you feel better. But here's the quote from the license:

"Complete Corresponding Source Code also includes any encryption or authorization codes necessary to install and/or execute the source code of the work, perhaps modified by you, in the recommended or principal context of use, such that its functioning in all circumstances is identical to that of the work, except as altered by your modifications."

And what I suggest does exactly that. The kernel's behavior hasn't changed, its functioning is identical. It's the hardware beneath that isn't functioning the same way from the point of view of the user space applications accessing it ...

If confusion there is, I don't believe it's on my side.

Karim

Misunderstanding of embedded system designers

Posted Jan 17, 2006 14:43 UTC (Tue) by Los__D (subscriber, #15263) [Link]

If they make their own software semi-proprietary (By making it impossible to replace it in the system), then they might as well use proprietary tools.

We don't want to bring free software to DRM handicapped platforms, we want DRM handicapped platforms to either go away completely, or keep the hell away from the free software!

Misunderstanding of embedded system designers

Posted Jan 19, 2006 11:51 UTC (Thu) by ohanssen (subscriber, #2761) [Link]

There may actually be another reason for restricting replacement of software components, than DRM: Security, and control of our own computers.

I am of course against the spirit of DRM. However, I want freedom to control what software are allowed to be installed an run on *my* computer, and what that software are allowed to do. I dont want Sony CDs to install hidden rootkits. I want to give unsigned and unauthorised applets from the web, only very limited access to my system.

Misunderstanding of embedded system designers

Posted Jan 19, 2006 20:50 UTC (Thu) by Los__D (subscriber, #15263) [Link]

That doesn't change that the software should be replacable by the user...

We already have standard, and completely open systems for that, i.e. Unix authentication and authorization.

Misunderstanding of embedded system designers

Posted Jan 17, 2006 18:46 UTC (Tue) by jpick (subscriber, #29470) [Link]

My current employer is in the same boat. They will not be able to use GPLv3 code in their Linux-based settop box.

The FSF knows what it is doing. That's the intent of the license. I'm quite happy to see them taking on this battle.

If the Linux kernel goes to GPLv3, I'm sure somebody will maintain a GPLv2 fork. And embedded developers may look towards NetBSD or other projects with less restrictions.

The net effect of this is that it's going to be a bit trickier to build a DRM product from open source components. Many free software developers will now choose to not allow their code into DRM products.

Misunderstanding of embedded system designers

Posted Jan 19, 2006 14:18 UTC (Thu) by rwmj (subscriber, #5474) [Link]

Good. I wrote some of that GPL code, and I resent you ripping it of in such foolish and unfriendly schemes as DRM. When my code moves to GPL3, you won't be able to use it (or at least not the latest, bug fixed, optimized, featureful version), and I'll be very glad.

Rich.

Misunderstanding of embedded system designers

Posted Jan 18, 2006 7:27 UTC (Wed) by opennw (guest, #29001) [Link]

Hi Karim,

> Clearly the FSF once again fails to understand the realities of
> embedded system designers.

I would consider that Richard feels particularly strongly about embedded devices, since the original catalyst for the GNU project was a printer for which he couldn't get free source:

http://www.gnu.org/gnu/thegnuproject.html

> What it will do though is:
> a) require those engineers to use proprietary software, which [...]
> can put the user at risk.
> b) alianate those engineers from the free software community

Exactly, but you make it sound like it's a bad thing. "Sorry, our insecure DRM-using product was late because we couldn't find engineers to work on it".

Meanwhile a GPLv3 non-DRM product takes the market.

Mitch.

Misunderstanding of embedded system designers

Posted Jan 18, 2006 16:34 UTC (Wed) by karim (subscriber, #114) [Link]

I would love to be able to post a private exchange I had
with Richard a few years back, but it's private, so I
won't. But it does clearly demonstrate the inverse of
your first statement.

Frankly, and again I can't go into too much detail, it
looks pretty clear to me that the FSF's realization that
embedded systems are an issue is only recent, and that
there hasn't been as much contact between their efforts
and a community of embedded system developers (as opposed
to their involvement in many efforts which have to do
with workstations and servers) -- yes, I'm aware GCC has
been cross-compiling for a while, but that's different
than having the actual software run on the gizmo ...

Karim

Misunderstanding of embedded system designers

Posted Jan 19, 2006 9:16 UTC (Thu) by hingo (subscriber, #14792) [Link]

Actually, I've always thought the "control program" of that printer refers to it's drivers or some other program used on the computer side, not some embedded code in the printer. I could be wrong of course.

Irrelevant

Posted Jan 19, 2006 21:00 UTC (Thu) by tjw.org (guest, #20716) [Link]

Clearly the FSF once again fails to understand the realities of embedded system designers.

We all know that embedded system designers will go on ignoring the GPL regarless of what new clauses it has.