There's been a lot of talk about GPL version 3: whether it
goes too far to be acceptable to business, whether the Linux
kernel developers will ever switch to it, whether our
community will fork or undergo unrest over it. Much of that
talk is based on a poor understanding of the GPL3 terms, and
with release of the new license imminent, it's time to clear
that up.
Some of the bad publicity about GPL3 is deliberate. A
particularly bad article by Dan Lyons of Forbes magazine
painted an offensive picture of GPL3 and Richard Stallman,
even accusing Stallman of having sex with flowers (!!!) after
Lyons failed to comprehend a scientific joke [1]. The article was "pitched" to Lyons and Forbes
[2] by then OSDL director Stuart Cohen.
ODSL was abruptly shut down by its own members, eliminating
Cohen's job, after Lyons' article and another odious incident
[3]. To save face, it was announced that
OSDL would be "merged" with Free Standards Group.
Confused objectors to GPL3 state that it won't allow the
Linux kernel to be used on a system that implements DRM, and
that GPL3 will compel manufacturers to "give away their
keys". If Linus Torvalds and the kernel developers still
believe this, they're wrong.
The intent of GPL3 (and most other Free Software licenses) is
to give you the right to modify the covered software. GPL
version 3 takes more trouble than other licenses to make sure
that this right actually works with embedded systems. It
essentially trades the makers of those systems the right to
base their devices on our great GPL software, in exchange for
the consumer's right to make that hardware run new and
innovative programs that weren't envisioned by its
manufacturer.
GPL3 does not prohibit DRM, and does not require that the DRM
be insecure or unreliable. What it requires is that the DRM
must not break the GPL software or lock it down, and must
continue to work to play media if the GPL software is
modified.
A system with GPL3 software and DRM would have to allow the
GPL software, for example the operating system kernel, to be
replaced. It would have to allow the system to boot after
such a change, and it would have to continue to allow the
system to play media or do whatever the DRM would otherwise
do before the change. It would not have to provide access to
the unencrypted media stream, and there would be no
requirement to release cryptographic keys as long as the DRM
was implemented to comply with GPL3's requirements.
If the Linux kernel was under GPL3, a manufacturer would be
prohibited from using DRM to lock down that kernel so
severely that we'd be unable to change it, as the Tivo locks
it down today. But that doesn't mean that you can't have
bullet-proof DRM to restrict media using Linux and GPL3, and
it wouldn't prevent Tivo from using new kernels. It just says
where that DRM must be located: anywhere that it can
live without removing the user's right to change the GPL
software.
If GPL3 is applied to the operating system kernel of a
system, there are four places where you can put DRM in that
system and remain within compliance with GPL3. Those places
also happen to be the best, most secure and reliable places
to put the DRM from a technical standpoint, regardless
of the license:
In hardware: This would usually be an
application-specific integrated circuit or a programmable
logic array that interprets encrypted streams on the way to
an audio or display device.
In a coprocessor: Most cellular telephones that
offer PDA functions (and PDAs containing wireless devices)
have two or more CPUs, generally an ARM9 running the user
interface and applications, and an ARM7 that runs the
wireless data-link layer or the GSM stack.
You can put the DRM in the processor that isn't
running the kernel, and then the GPL component just talks
to a well-defined interprocessor link to the external CPU
that runs the DRM. The GPL obligations don't cross that
link.
In a kernel under the kernel: Microsoft XP and Vista
have used this architecture: the core of the DRM system
lives in a microkernel called the "nib" that lives under
the real kernel, and hosts the real kernel as the kernel
would host a user-mode application.
In a user-mode program: The GPL obligations on the
license of the kernel don't transmit across the system-call
interface from the kernel to an application hosted by that
kernel.
Many have interpreted that the GPL 2 has always made
the same restriction on DRM that is stated more explicitly in
GPL 3. I've always advised my strategic consulting customers
to make their technical plans assuming this is so, rather
than have it decided in an expensive lawsuit. The four places
for DRM that I state above apply equally to GPL 2.
Another oft-heard objection to GPL3 is "GPL 2 is good
enough!". But GPL has never stood alone, it has always
depended on the local interpretation of copyright and other
law to give it force, and those things change over time.
When the GPL was written, there was no web, music came from
phonograph records, video from tape, and rather than DRM
there was rudimentary software "copy protection". The
renaissance of microprocessors, software, the web and digital
media worked a tremendous change in the law with many changes
to copyright, patents, the nature of consent, contracts,
tear-open licenses, and copyright permissions. And there have
been many trials over those years that added interpretation
to laws that GPL 2 depends upon. As the law changes, GPL must
change to keep up with it, or it will become increasingly
un-enforcible.
In the Novell-Microsoft agreement, a loophole was constructed
by Microsoft and Novell's attorneys, one so new to us that
the first two public drafts of GPL3 contained no provision to
repair it. This experience shows that GPL must continue to
grow just to stand still. To freeze on one version would act
to erode its protections over time.
And what about Novell-Microsoft? Will there be a provision to
block that deal in GPL3? How will it work? Richard Stallman
announced on Monday March 19 that GPL3 will contain a
provision that blocks the Novell-Microsoft deal. It works
this way: if any entity that distributes the software
arranges to protect a particular group from patents regarding
that software, it must protect everyone. This mends
the loophole exploited in the Novell-Microsoft agreement
without being discriminatory or unfair.
What does this mean to Novell? It won't keep them from using
existing GPL 2 software in its present versions. But it may
freeze them in amber as an example of the state of software
in early 2007, as the rest of the Free Software community and
Linux distributions move into the future. Torvalds is loath
to change the license on Linux right away, but critical
programs in the Novell system are directly owned by FSF:
GLibC, the fundamental library that every program
depends upon, the C compiler and other key components.
Projects not owned by FSF will also make the switch: the
motivation of Open Source programmers to release new
code to the public is in part dependent on the enforceability
of the GPL's share-and-share-alike terms, and GPL3
will offer the best continued enforceability.
A majority of Open Source projects choose the GPL, and a
share-and-share-alike paradigm, rather than the
BSD/Apache flavor of license which is an unconditional
gift. Many developers would just stop writing if they
couldn't enforce the sharing part of the equation,
they'd feel as if they were being taken advantage of by
corporations and Linux distributions, like some sort of
unpaid employee. The majority that feels that way will tend
to switch their projects to GPL3.
The GPL is also a very good license for businesses like
MySQL, because it facilitates a dual-licensing
paradigm in which a customer can pay a software creator
rather than share additions that the customer makes to the
software. Expect those companies and projects to switch to
GPL3, once they study the final version.
But how can the Linux kernel project, with its thousands of
developers, change its license? We can't even reach them all,
and some of those developers are dead and their estates don't
know software licenses from driver's licenses. But changing
the license is easier than most people think.
First, it's not a fundamental change: the intent of GPL 3 is
that of GPL 2, the change is in the implementation. Given
that, what would be required for such a change would be for
Torvalds (or someone else) to publish his intent to start
making releases with the new license, as a legal notice. A
certain number of people would object, and they would have
the right to require that their contributions be removed from
the new release.
The kernel team has never been loath to replace code when
necessary, and never slow to handle the job, no matter how
large the item to be replaced. Just look at the replacement
of Bitkeeper with "git", a big job that took a ground-up
rewrite and yet was working in five weeks. So, code belonging
to GPL3-objectors would be swiftly dealt with.
After some time passed, the release would happen under the
new license, and life would go on. There is precedent for
this, as Torvalds has already made two significant changes to
the prelude to GPL2 on the kernel, publishing his intent and
then making a release.
But will the kernel team ever switch to GPL3? Linus Torvalds
and some other kernel team members don't like it today. But
as I've presented above, their reasons to dislike might not
really be valid. One thing to Torvalds' credit: when he's
wrong, he can be convinced of that eventually. But sometimes
it takes years. Going by history, I think that we could wait
one or two years to see the kernel team see fit to switch to
GPL3. Even if they don't, so many other important projects
will switch to GPL3 that it is sure to be an important factor
in our future lives.
Footnotes
1. Lyons' "sex with flowers" thing:
Stallman had been noted, upon sniffing a flower or
observing someone else to do so, to utter "Aah,
rhinophytophilia", and wrote about it on his web site.
This is a scientific joke. A flower is a plant's sexual
organ, and pollen is its sperm. When you sniff a "male"
flower (one that emits pollen), you invariably take
thousands or millions of pollen granules, little packages
of plant DNA, into your body. And thus "rhino": nose,
"phyto": flower, "philia": love :-) . It gives some
people allergies, but it gave Lyons the creeps when,
somehow lacking a 5th-grade knowledge of biology once
he'd looked up the Greek, the confused reporter thought
that Stallman had been getting hot with flowers!
FYI: Stallman's many girlfriends have been attractive, he
does suprisingly well in that regard. Lyons and his ilk
should take note: from a scientific perspective, most of
the food that everybody eats are the sexual organs of
plants. Grain, fruit, and nuts are the wombs and embryos
of the plant world, flowers are genitalia.
2. Pitching a story to the press:
Many, perhaps most stories in the news are not the result
of reporters and editors thinking them up by themselves.
Instead, parties that have a reason to want a particular
story covered try to entice the press to cover them. The
"pitch" is the story that public relations people tell
the press to get them to write a story.
There are many people who make their living doing this,
providing public relations and publicity services that
include acting as intermediaries between organizations
and the press, and constructing messages and campaigns.
Although Open Source has had excellent luck placing
stories without professional assistance, our community
has also had much benefit from the work of the inimitable
Open Source enthusiast and tech public relations
executive Jill Ratkevic. Jill has helped me to promote
the interests of our community for years, usually asking
for nothing in return. When I finally got in a position
where I could pay her, I had to work hard to get
her to take the money!
3. Odious incident #2:
Cohen, speaking as OSDL's director, made a public
statement endorsing the Novell-Microsoft agreement, and
his statement was used in Novell's press release.
Microsoft has used the agreement as a new license to
spread lawsuit FUD about Linux and Open Source. Imagine
how that made OSDL member and FUD victim Red Hat feel,
but they were hardly the only OSDL member to be offended,
or the only one damaged by FUD from that agreement.
The Novell-Microsoft agreement also expresses very bad
faith toward Novell's own developers, because Novell and
Microsoft engineered a legal circumvention of the GPL's
patent terms. And that's hardly what OSDL should have
stood behind. Of course the deal, with its implied
lawsuit threat toward anyone who isn't a Novell customer,
is very much against the interest of almost everyone
involved in Open Source, especially OSDL's former
members.
I agree that an update to the GPL is needed. The "Bittorrent" clause is a good example of the paradigm of computing changing enough to necessitate a change. The concept of patent retaliation is also an appropriate addition IMO. Also, I am no fan of DRM, so anybody who takes a sock in the gut because of that clause will have no sympathy from me.
However, the implementation of the DRM clause does not seem to match the GPL's role as a software distribution license. To the point, the Tivoization problem described by Stallman has, in and of itself, nothing to do with GPL'd software. If a piece of hardware (the TiVo in this example) requires that its firmware be signed in order to load, that seems to me to be a problem with the hardware, not the software. Any user has the ability to obtain, modify, and redistribute the TiVo's GPL'd code, though a user could presumably only use that software on a different piece of hardware. Still the fact that the current draft of the GPLv3 has implicit hardware requirements is, I think, stepping outside of the proper bounds of what a software distribution license should be.
I hold Tivo and other companies in contempt for requiring signed firmware. However, I just cannot see how it is appropriate to address this issue in a software distribution license, especially in the retaliatory fashion that the FSF has acted. After listening to several of Stallman's talks on the issue, I am still not convinced (and it is rare that RMS is not able to convince me of something). The GPL needs an update, and I am sure that it will be fully and willingly adopted if this DRM clause is left out.
It seems to me that the Tivo is not just a piece of hardware, but a licensed copy of the software. It is an alterable copy, it's either a hard disk or FLASH copy. But it is a copy that uses technical measures to restrict rights that are otherwise guaranteed by the software.
Consider that in the future of computers with the Trusted Platform Module, it might become the norm for programs to be locked down this way, and for unsigned programs to be locked out, and this would effect GPL software much more than it does today.
Thus, it does not seem to me that we can afford to allow technical measures to remove rights that the GPL otherwise guarantees, any longer.
The conundrum of whether GPLV3 steps outside the bounds of a software license in the Tivo case is caused by the blurry line between hardware and software generally, and particularly in embedded systems. Our devices harness physics to represent abstract reasoning. Physical motions and positions of electrons and photons are assigned logical values. We then combine these values into operational sequences that we call software. The layers of abstraction, piled one on top of the other in neat folds, or jumbled together in chaotic mixtures, have the remarkable to disappear beneath the problem we are trying to solve. But when we need to understand those layers, not just for technical purposes, but to decide what a software license can equitably require of its users, then confusion - and honest disagreement - is the result.
I wouldn't agree that our licences are an inappropriate place to tackle problems such as tivoisation. We're not restricting how the devices are distributed, we're only restricting how our software can be distributed. It's the device manufacturer's choice whether they want to bundle our software with their hardware. If they bundle them in a way that they know will result in the buyer sitting infront of a free software box they can't modify, then that's purposely undermining the spirit of the licence and it should be stopped.
I also think that we should try to do more with our licences. We only have three ways to improve our legal environment:
Lobbying: Change legislation.
Market: Don't support people who give us legal troubles.
Our licences.
My background is in lobbying against software patents in the EU, and I can tell you that that was a lot of work just to maintain a status quo that we don't even particularly like.
In the market, we could be effective but we're not organised and most free software users are not sufficiently aware of the issues and the importance of exercising their market power. So we can't rely on this.
Then there's our licences. This is the only option that we control. We don't have to convince politicians or companies who don't share our values. In a copyright system geared towards our opponents, one power we do get is to set the terms of distribution for our software. We would be negligent if we didn't help ourselves in this area.
The overstepping into the hardware realm is still my biggest philosophical problem with GPL 3, although I must admit it has been cleaned up quite a bit. While I know others worked hard to make a better draft, I really have to thank Linus for his stubborn rejection of the earlier drafts. I think he really put the brakes on some of the excesses.
And while I respect RMS, Moglen, and the FSF for all they have done, I find something a bit Big Brother-ish about their long term aims.
I am certain that you know this already, but Dan Lyons has been characterised as an Open Source foe for quite some time. Groklaw readers would go as far as calling him an SCO shill.
...the purpose of the GPL, which is to protect users' freedom to change the software.
Ok, yes, very nice...
2, paragraph 2
This License permits you to make and run privately modified versions of the Program, or have others make and run them on your behalf. However, this permission terminates, as to all such versions, if you bring suit against anyone for patent infringement of any of your essential patent claims in any such version, for making, using, selling or otherwise conveying a work based on the Program in compliance with this License.
...except, apparently, that you can *lose* this freedom.
7b (allowed additional restrictions) .5
# 5) terms that wholly or partially terminate, or allow termination of, permission for use of the material they cover, for a user who files a software patent lawsuit (that is, a lawsuit alleging that some software infringes a patent) not filed in retaliation or defense against the earlier filing of another software patent lawsuit, or in which the allegedly infringing software includes some of the covered material, possibly in combination with other software; or
And sometimes, you can't use the software at all. Hello, EULA!
IIRC, tit-for-tat remains the unbeaten champion strategy for the anonymous prisoner's dilemma. The GPL is playing that game, and implements that strategy.
So, that puts it midway on the spectrum between doormat and predator.
...except, apparently, that you can *lose* this freedom.
It's not an unreasonable provision. Essentially it says if you're not going to be a good neighbor, you cannot borrow my lawn mower.
There have been far too many attempts to honor the GPL in name while constructively violating it. For example by modifying GPL code, releasing the source as required, but patenting something in it so that it cannot actually be freely passed on to others and freely used by them as required.
The situation is not unlike the one where some former copyright holders are now using trademarks to keep works now in the public domain effectively under their control exactly as if they had a perpetual copyright.
Paragraph 2 simply says that sort of loophole is not acceptable here. I would prefer that it simply prohibit such a suit, but a license cannot do that, so the next best thing is to make the grant of license contingent on refraining from such underhanded tactics.
The only way to lose the freedom is by trying to take it away from someone else. That seems fair enough.
No, that loophole is covered in section 11, which I very much agree with.
What I don't like is how it says that you can't modify it *for your own use* if you start a patent suit. "We believe that you should have the right to modify the software you use. Unless you piss us off, in which case we'll take away this "right"."
(I also think this is kinda dumb, since now no patent-holding company can safely customize GPL software for their own use... all someone would have to do is somehow implement one of their patents in upstream for the software they use, and then they have to either ignore that infringement or forfeit the use of their modified software. So congratulations, the GPL *really is* a minefield now. Even if you don't distribute anything.)
It's much less broad than that unless the copyright holder implements the optional clause.
They can customize for their own use all they want. As long as they don't incorporate their patent into the GPL code, then sue someone for THAT patent in THAT program or its derivitives. If someone copies the patented technique in their own original code, you may freely sue them for that infringement. You may freely sue for infringing on your other patents (if any).
7b5 is the one that effectively prevents a patent-holding company from safely customizing GPL software iff the copyright holder chooses to use that option. Even then, it's not a problem if the patents are used only defensively.
This License permits you to make and run privately modified versions of the Program, or have others make and run them on your behalf. However, this permission terminates, as to all such versions, if you bring suit against anyone for patent infringement of any of your essential patent claims in any such version, for making, using, selling or otherwise conveying a work based on the Program in compliance with this License.
I parse this as:
This License permits you to make and run privately modified versions[a] of the Program[b; what you would call "upstream"], or have others make and run them on your behalf. However, this permission terminates, as to all such versions[ref a], if you bring suit against anyone for patent infringement of (any of your essential patent claims in any such version[ref a]), for making, using, selling or otherwise conveying a work based on the Program[ref b, which is "upstream"] in compliance with this License.
, which is, if your privately modified version uses your patents, and Joe uses those same patents in something based on the same upstream, then you lose modification rights if you sue Joe.
The key phrase is "for making, using, selling or otherwise conveying a work based on the Program[ref b, which is "upstream"] in compliance with this License."
In other words, if you're not suing over your patent being used IN THAT PROGRAM, your permission doesn't terminate. It's the reasonable statement "You can't both sue me for writing it and benefit because I did".
Perhaps the language needs to be made more clear since we're parsing it differently.
"One thing to Torvalds' credit: when he's wrong, he can be convinced of that eventually."
About 6 months ago I had an email exchange with Linus. He seemed convinced that GPL3 went too far in regard to DRM. He stated that if users wanted "hackable hardware", they should vote with their wallets and demand that hardware be manufactured. I responded with...
"You say buyers should make clear their desire for hackable hardware and that they should not pay for hardware they cannot modify. Fine, but I the copyright holder am going to take you, the hardware manufacturer, to court if you dare make this "hackable hardware" and have you charged for "circumvention" under the DMCA. How is the buyer who desires "hackable hardware" going to stop me?"
Linus never responded. Bruce, I hope you are right that he can be convinced eventually. We could use his help and support with regard to this license.
But, your argument isn't a response to Torvalds' comment. If you have an issue with the DMCA or with laws enabling mandatory DRM, then you need to speak to the people who make the laws.
The license used for Linux cannot have ANY impact on those laws - it can't give you permission to circumvent DRM (only the copyright holder can) and it can't change the law or the market. Only buying and voting power can do that.
"If you have an issue with the DMCA or with laws enabling mandatory DRM, then you need to speak to the people who make the laws."
If they are not listening, then we need to consider alternative solutions.
"The license used for Linux cannot have ANY impact on those laws - it can't give you permission to circumvent DRM (only the copyright holder can) and it can't change the law or the market."
Strictly speaking you are correct. But, GPL3 sets up a stalemate and opens up a door. What it does is shift the anti-circumvention issue to the intent of a license rather than the manfacturing of hardware. I don't see Big Media having any success trying to declare GPL3 itself an illegal circumventor of DRM. I'm sure the FSF would love it if they tried. So when you say "cannot have ANY impact on those laws" I disagree. Sure, the impact is not direct - GPL3 doesn't change the DMCA itself, but it shifts the battle and takes the pressure off HW manufacturers. You are right that GPL3 doesn't give us "permission", but under the circumstances it is not realistic to believe we will get such permission anytime soon through mere lobbying. GPL3 gives us a way to freedom even if that freedom is technically underground due to oppressive laws. It's not ideal, but it is better than mere protest.
Linus is not respecting what the actual circumstances are right now. It would be easy for Big Media to take a hardware manufacturer to court - even the threat is enough to keep them at bay. But GPL3 allows hardware manufacturers to keep on making TC devices by lifting the pressure off them and shifting the circumvention to a copyright license. HW manufacturers would no longer be the ones breaking the DMCA.
Because GPL3 demands complete corresponding source code, the user is then free to modify their copy as they like. Without GPL3 and given the DMCA, "buying and voting power" are useless as the law takes that power away. In a fair world, I agree with Linus...but our world (or at least the U.S. world) is not fair now. Of course, HW manufacturers may not be allowed to ship software that allows the copying of media, but with GPL3 we who want the freedom to do this should be able to easily download patches - much like we do with DeCSS. A GPL2 program however, that doesn't give us the complete code is useless as any applied patch would be detected by a TC machine and shut down.
If you can offer a better suggestion than "protest the DMCA" and "vote with your dollars", I'm all ears. But relying on that alone - I think - is not realisitc.
"But GPL3 allows hardware manufacturers to keep on making TC devices by lifting the pressure off them and shifting the circumvention to a copyright license. HW manufacturers would no longer be the ones breaking the DMCA."
This makes no sense at all. The manufacturers would still be the ones who chose to use insecure (i.e., untrusted) software. In effect you're just saying "If you need to meet content owner's requirements for DRM, you can't use GPLv3 software."
If that's what you WANT to say, then that's fine. The Linux developers clearly don't want to say that.
Again, the ONLY solutions to DRM are in the marketplace and legislation. I can't guarantee success there - if people don't care enough, DRM will continue. And, most people probably will prefer some degree of TC to the current insecurity of most computers, so that's likely to become common, too.
"The manufacturers would still be the ones who chose to use insecure
(i.e., untrusted) software."
Not true. The fact is, the manufacturers would be the ones who chose to convey, not use the software. If they use the software, they are not required to give the complete corresponding source code and therefore the DRM provision is rendered meaningless. In fact, in such an environment, DRM enforced through TC is perfectly acceptable. In fact, as a user of GPL software you are not even required to accept the license agreement to use the software! Doing so would be a violation of your freedom. I think it is really interesting when I see GPL licensed software on Windows machines (never seen it on a GNU/Linux machine though I guess it could happen) that actually requires one to agree to the GPL just to install and use it. The fact is, if you just use GPL software, you are not under any restrictions at all. You are under restrictions when you convey it.
And therefore your statement that -
"In effect you're just saying "If you need to meet content owner's requirements for DRM, you can't use GPLv3 software."
- makes no sense to me as it is based upon a false perception of what GPL3 demands.
"If that's what you WANT to say, then that's fine. The Linux developers clearly don't want to say that."
It's not what I want to say. It's just a fact. Therefore, if the kernel developers don't wish to say that, then they shouldn't as doing so would be based on a misunderstanding of the intent of the GPL. That intent has not changed at all dating back to GPLv1. What has changed is the innovation of some to exploit the unforseen holes that existed in earlier GPL licenses.
"Again, the ONLY solutions to DRM are in the marketplace and legislation."
The marketplace is negated by legislation in some places. This is a fact. So essentially, what you are saying is -
"The ONLY way to have freedom is through legislation."
And you are correct. And given the landscape, the only realistic way to do so is through a license of intent. Perhaps one day the law will change allowing the marketplace to open up, but it is absurd to suggest to someone to sit around and wait until (if?) it does.
"most people probably will prefer some degree of TC to the current insecurity of most computers, so that's likely to become common, too."
I don't think so. I think TC may be wanted by some organizations/families, but I would venture to guess that they would be in the minority. Your average user has no need for TC. For most people who want to keep private records, encryption is enough. But this is all a moot point as those organizations/families that want TC devices are not going to be denied that freedom by GPL3 anyway. Go ahead, use TC devices! Anyone continuing to spread that rumor is either confused and/or is trying to confuse others.
I apologize for using "use" in the generic sense rather than the legal sense. I meant "choose to build their systems with unsecure..." As DRM schemes harden, I think it is increasingly unlikely that DRM mechanisms will be licensed to manufacturers for implementation on untrusted (i.e., user-replaceable) system software.
I disagre with your analysis of the marketplace/legislation issue. Customers elect legislatures as well as buying systems. The market will determine what approaches are economically viable (there is some evidence that, for music, at least, the tide may be turning towards non-DRM distribution, largely driven by market forces). If customers are unwilling to accept mandated solutions, they WILL complain to their representatives in legislatures. So far, there's little sign of such a movement, but it may happen. Or it may not - people can be surprisingly accepting of restrictions.
But I see no logic behind your argument that "the only realistic way to [influence legislation] is through a license of intent." How does a software license influence legislation?
"As DRM schemes harden, I think it is increasingly unlikely that DRM mechanisms will be licensed to manufacturers for implementation on untrusted (i.e., user-replaceable) system software."
I don't agree with your definition of untrusted software. To me, if a TC environment is not oppressive, then "untrusted" software is software that I had no choice in allowing into *my* system. A TC environment may help keep such unwanted software off of *my* computer, but an untrusted system is not merely defined as a machine with "user-replaceable" software. This is exactly how Big Media want us to think of TC. But I reject that and refuse to speak on those terms. I will speak about TC on its "original" terms - for more on that, see this video here -
http://www.lafkon.net/tc/
If you would like a .ogg copy of this video I have one if you'd like to send me your contact information. But VLC should be able to play some of the formats at that site.
"So far, there's little sign of such a movement, but [change] may happen."
I don't disagree that change "may happen", but when freedom is at stake, passivity is not realistic. We have been very active in trying to bring about change. The key thing here is that this legal change must be done throughout the world...NOT just the U.S. The DMCA is a good case study in understanding this issue, but if there is even one place on the planet that makes it illegal for HW manufacturers to sell circumventing machines, then there is a need for GPL3. This issue is a world-wide issue, not just an american one.
"But I see no logic behind your argument that "the only realistic way to [influence legislation] is through a license of intent." How does a software license influence legislation?"
A software license IS legislation! It is law. And it now places the intent of the GPL in direct opposition with the DMCA. I like this strategy as anyone who is thinking clearly about this issue will plainly see that it is the intent of the DMCA that is extreme - not the GPL. What is extreme about protecting the freedom to use, modify, distribute, and run for any purpose *my* software?
Note that I said "untrusted", not non-TC. By untrusted, I simply mean any software that the manufacturer (or service provider) has no information about and therefore has no reason to trust. In particular I said "system software", meaning software that runs with privileges beyond those of user software and, in particular, software that mediates and has the opportunity to alter data passing through the system's internal communication channels.
I do agree with Bruce that it is possible to conduct trusted communications over untrusted paths, but it raises the risk. Again, remember that the manufacturers are required to indemnify the content owners against breaches in the DRM.
I completely agree that the DMCA overreaches and should be repealed. I have mentioned that to legislators.
I personally have issues with the FSF's using the term "freedom", which has connotations based in human rights, with respect to software, which I do not believe to be an element in those human rights, but I don't really want to debate that here and now.
A software license is not, in any sense, legislation. Nor is it a law. It grants to a licensee certain rights that legislation reserved to the copyright holder. It offers no possible opposition to the DMCA, which criminalizes certain activities, supposedly in order to protect those rights reserved to copyright holders. [Again, I believe it goes way too far.]
As I have said elsewhere, I completely support your right to put any restrictions on your software that you feel appropriate. I am simply unhappy to see the primary FLOSS license adopt restrictions that go beyond what I consider appropriate. I believe the DRM and anti-tivoization aspects of GPLv3 are simply a waste of time and effort that make the license less clear and more complicated thatn it needs to be to protect the aspects of FLOSS development that I consider most important. YMMV.
Because I genuinely do not want to upset anyone or appear like I am trolling.
I downloaded all the links, looked at all the pictures and listened to all the audio.
It is an exaggeration to say "I could have cried", but not a huge one.
I imagine that a secreted x10 spy webcam somewhere in Redmond capturing the regular Thursday meeting of the Vista Start button design committee would have sounded the same and given the same overall impression, but MS would never have released it as official press release material.
The audio was abysmal quality, it wasn't edited so the pregnant pauses while people entered the room were removed, it wasn't synced with any presentation material or a button pointed list, you'd have to plough through it to get any morsels out.
For the sake of a little effort, more posed and therefore more media acceptable pictures could have been taken, radio broadcast quality audio could have been recorded and edited together, and the whole thing could have been made a lot more slick.
Yeah, I know, this won't have changed the importance of anything discussed, but it would have changed the apparent gravitas of what was said, and the accessibility of it to the mainstream media.
MS "wow" campaign sucked dead donkeys, but it _worked_, it had all the pre-requisites for further media dissemination....
Go to http://www.fsf.org/resources, where are the media ready graphics?
Where are the soundbites?
Go to http://www.microsoft.com/presspass/gallery.mspx, more than you can shake a stick at
And it is not like the Open Source community doesn't have the talent, or that is requires much effort compared to coding the next kernel iteration, it seems like the Open Source community is happy to content itself with preaching to the choir.
-------------------------
Please do not think I am trying to denigrate the efforts of sincere people, I am not, and we would not be here without you, I am merely playing devils advocate and asking why the Open Source community always appears to place PR last on the list.
The second audio file, made by a Brazilian reporter who cleaned it up with Audacity, is said to be better. I didn't really expect this to be treated as a webinar, all of the files there are from volunteers who just made them and uploaded them. Perhaps I should put more effort into making it work as a webinar next time.
It gets worse. According to
this story, a reporter who tried to hear the FSF's side of the debate was told that he couldn't interview anyone unless he called Linux GNU/Linux.
The first rule of positive publicity is: don't shut out the media.
Clearing up anti-GPL3 FUD
There's been a lot of talk about GPL version 3: whether it goes too far to be acceptable to business, whether the Linux kernel developers will ever switch to it, whether our community will fork or undergo unrest over it. Much of that talk is based on a poor understanding of the GPL3 terms, and with release of the new license imminent, it's time to clear that up.
Some of the bad publicity about GPL3 is deliberate. A particularly bad article by Dan Lyons of Forbes magazine painted an offensive picture of GPL3 and Richard Stallman, even accusing Stallman of having sex with flowers (!!!) after Lyons failed to comprehend a scientific joke [1]. The article was "pitched" to Lyons and Forbes [2] by then OSDL director Stuart Cohen. ODSL was abruptly shut down by its own members, eliminating Cohen's job, after Lyons' article and another odious incident [3]. To save face, it was announced that OSDL would be "merged" with Free Standards Group.
Confused objectors to GPL3 state that it won't allow the Linux kernel to be used on a system that implements DRM, and that GPL3 will compel manufacturers to "give away their keys". If Linus Torvalds and the kernel developers still believe this, they're wrong.
The intent of GPL3 (and most other Free Software licenses) is to give you the right to modify the covered software. GPL version 3 takes more trouble than other licenses to make sure that this right actually works with embedded systems. It essentially trades the makers of those systems the right to base their devices on our great GPL software, in exchange for the consumer's right to make that hardware run new and innovative programs that weren't envisioned by its manufacturer.
GPL3 does not prohibit DRM, and does not require that the DRM be insecure or unreliable. What it requires is that the DRM must not break the GPL software or lock it down, and must continue to work to play media if the GPL software is modified.
A system with GPL3 software and DRM would have to allow the GPL software, for example the operating system kernel, to be replaced. It would have to allow the system to boot after such a change, and it would have to continue to allow the system to play media or do whatever the DRM would otherwise do before the change. It would not have to provide access to the unencrypted media stream, and there would be no requirement to release cryptographic keys as long as the DRM was implemented to comply with GPL3's requirements.
If the Linux kernel was under GPL3, a manufacturer would be prohibited from using DRM to lock down that kernel so severely that we'd be unable to change it, as the Tivo locks it down today. But that doesn't mean that you can't have bullet-proof DRM to restrict media using Linux and GPL3, and it wouldn't prevent Tivo from using new kernels. It just says where that DRM must be located: anywhere that it can live without removing the user's right to change the GPL software.
If GPL3 is applied to the operating system kernel of a system, there are four places where you can put DRM in that system and remain within compliance with GPL3. Those places also happen to be the best, most secure and reliable places to put the DRM from a technical standpoint, regardless of the license:
You can put the DRM in the processor that isn't running the kernel, and then the GPL component just talks to a well-defined interprocessor link to the external CPU that runs the DRM. The GPL obligations don't cross that link.
Many have interpreted that the GPL 2 has always made the same restriction on DRM that is stated more explicitly in GPL 3. I've always advised my strategic consulting customers to make their technical plans assuming this is so, rather than have it decided in an expensive lawsuit. The four places for DRM that I state above apply equally to GPL 2.
Another oft-heard objection to GPL3 is "GPL 2 is good enough!". But GPL has never stood alone, it has always depended on the local interpretation of copyright and other law to give it force, and those things change over time.
When the GPL was written, there was no web, music came from phonograph records, video from tape, and rather than DRM there was rudimentary software "copy protection". The renaissance of microprocessors, software, the web and digital media worked a tremendous change in the law with many changes to copyright, patents, the nature of consent, contracts, tear-open licenses, and copyright permissions. And there have been many trials over those years that added interpretation to laws that GPL 2 depends upon. As the law changes, GPL must change to keep up with it, or it will become increasingly un-enforcible.
In the Novell-Microsoft agreement, a loophole was constructed by Microsoft and Novell's attorneys, one so new to us that the first two public drafts of GPL3 contained no provision to repair it. This experience shows that GPL must continue to grow just to stand still. To freeze on one version would act to erode its protections over time.
And what about Novell-Microsoft? Will there be a provision to block that deal in GPL3? How will it work? Richard Stallman announced on Monday March 19 that GPL3 will contain a provision that blocks the Novell-Microsoft deal. It works this way: if any entity that distributes the software arranges to protect a particular group from patents regarding that software, it must protect everyone. This mends the loophole exploited in the Novell-Microsoft agreement without being discriminatory or unfair.
What does this mean to Novell? It won't keep them from using existing GPL 2 software in its present versions. But it may freeze them in amber as an example of the state of software in early 2007, as the rest of the Free Software community and Linux distributions move into the future. Torvalds is loath to change the license on Linux right away, but critical programs in the Novell system are directly owned by FSF: GLibC, the fundamental library that every program depends upon, the C compiler and other key components.
Projects not owned by FSF will also make the switch: the motivation of Open Source programmers to release new code to the public is in part dependent on the enforceability of the GPL's share-and-share-alike terms, and GPL3 will offer the best continued enforceability.
A majority of Open Source projects choose the GPL, and a share-and-share-alike paradigm, rather than the BSD/Apache flavor of license which is an unconditional gift. Many developers would just stop writing if they couldn't enforce the sharing part of the equation, they'd feel as if they were being taken advantage of by corporations and Linux distributions, like some sort of unpaid employee. The majority that feels that way will tend to switch their projects to GPL3.
The GPL is also a very good license for businesses like MySQL, because it facilitates a dual-licensing paradigm in which a customer can pay a software creator rather than share additions that the customer makes to the software. Expect those companies and projects to switch to GPL3, once they study the final version.
But how can the Linux kernel project, with its thousands of developers, change its license? We can't even reach them all, and some of those developers are dead and their estates don't know software licenses from driver's licenses. But changing the license is easier than most people think.
First, it's not a fundamental change: the intent of GPL 3 is that of GPL 2, the change is in the implementation. Given that, what would be required for such a change would be for Torvalds (or someone else) to publish his intent to start making releases with the new license, as a legal notice. A certain number of people would object, and they would have the right to require that their contributions be removed from the new release.
The kernel team has never been loath to replace code when necessary, and never slow to handle the job, no matter how large the item to be replaced. Just look at the replacement of Bitkeeper with "git", a big job that took a ground-up rewrite and yet was working in five weeks. So, code belonging to GPL3-objectors would be swiftly dealt with.
After some time passed, the release would happen under the new license, and life would go on. There is precedent for this, as Torvalds has already made two significant changes to the prelude to GPL2 on the kernel, publishing his intent and then making a release.
But will the kernel team ever switch to GPL3? Linus Torvalds and some other kernel team members don't like it today. But as I've presented above, their reasons to dislike might not really be valid. One thing to Torvalds' credit: when he's wrong, he can be convinced of that eventually. But sometimes it takes years. Going by history, I think that we could wait one or two years to see the kernel team see fit to switch to GPL3. Even if they don't, so many other important projects will switch to GPL3 that it is sure to be an important factor in our future lives.
Footnotes
Stallman had been noted, upon sniffing a flower or observing someone else to do so, to utter "Aah, rhinophytophilia", and wrote about it on his web site. This is a scientific joke. A flower is a plant's sexual organ, and pollen is its sperm. When you sniff a "male" flower (one that emits pollen), you invariably take thousands or millions of pollen granules, little packages of plant DNA, into your body. And thus "rhino": nose, "phyto": flower, "philia": love :-) . It gives some people allergies, but it gave Lyons the creeps when, somehow lacking a 5th-grade knowledge of biology once he'd looked up the Greek, the confused reporter thought that Stallman had been getting hot with flowers!
FYI: Stallman's many girlfriends have been attractive, he does suprisingly well in that regard. Lyons and his ilk should take note: from a scientific perspective, most of the food that everybody eats are the sexual organs of plants. Grain, fruit, and nuts are the wombs and embryos of the plant world, flowers are genitalia.
Many, perhaps most stories in the news are not the result of reporters and editors thinking them up by themselves. Instead, parties that have a reason to want a particular story covered try to entice the press to cover them. The "pitch" is the story that public relations people tell the press to get them to write a story.
There are many people who make their living doing this, providing public relations and publicity services that include acting as intermediaries between organizations and the press, and constructing messages and campaigns. Although Open Source has had excellent luck placing stories without professional assistance, our community has also had much benefit from the work of the inimitable Open Source enthusiast and tech public relations executive Jill Ratkevic. Jill has helped me to promote the interests of our community for years, usually asking for nothing in return. When I finally got in a position where I could pay her, I had to work hard to get her to take the money!
Cohen, speaking as OSDL's director, made a public statement endorsing the Novell-Microsoft agreement, and his statement was used in Novell's press release. Microsoft has used the agreement as a new license to spread lawsuit FUD about Linux and Open Source. Imagine how that made OSDL member and FUD victim Red Hat feel, but they were hardly the only OSDL member to be offended, or the only one damaged by FUD from that agreement.
The Novell-Microsoft agreement also expresses very bad faith toward Novell's own developers, because Novell and Microsoft engineered a legal circumvention of the GPL's patent terms. And that's hardly what OSDL should have stood behind. Of course the deal, with its implied lawsuit threat toward anyone who isn't a Novell customer, is very much against the interest of almost everyone involved in Open Source, especially OSDL's former members.