The Great Software Schism

Following Nicholas Petreley's discussion of the GNU GPLv3 debate from one angle, I'd like to look at it from another - that of the cultures of the two groups involved - and what this implies for the future.

The constant bickering between those who talk of "free software" and those who prefer the term "open source" is hard to avoid in the computing world.  You only have to look at discussion threads on sites like Slashdot, Digg, Linux Journal or LWN.net to see the two camps rehearsing familiar themes.  This eternal disagreement can be invigorating entertainment at best, or, if you're not in the mood, enervating in its tediousness.  But this fundamental difference of viewpoint has not really been a serious danger to the overall free software/open source movement.  Until now. 

For with the recent publication of the white paper The Dangers and Problems with GPLv3 - and note that to emphasise its earnestness it is framed like an academic paper complete with alphabetical listing of authors and opening abstract - the background skirmishes threaten to escalate into a full-blown war.

On its own, the paper would have been bad enough.  But matters have been exacerbated by the publication of a poll of top kernel coders.  On a scale from 3 ("I wouldn't want to use v2") to -3 ("I wouldn't want to use v3"), 29 of the top kernel hackers were asked which version of the GNU GPL they would prefer to use.  The average was an unequivocal -2.0: "I think v3 is much worse than v2".  But what makes this "informal" poll all the more damaging is that both it and the white paper were instigated by Linus himself:

The reason the poll and the whitepaper got started was that I've obviously not been all that happy with the GPLv3

...

It wasn't meant to be really "definitive" - the poll was literally meant to get _some_ kind of view into how the top developers feel. I think the end result ended up being more definitive (just thanks to the very clear voting pattern) than we migth have expected.

So this is no mere rumbling in the ranks, but discontent at the very highest level.

Some of the problems outlined in the white paper seem to be down to misunderstandings of what the GNU GPL v3 is trying to achieve. To correct these misunderstandings, the FSF has released its own "clarification."  But even allowing for these, there remains a key issue over which the two sides differ fundamentally in their views.

This concerns the use of DRM - traditionally "Digital Rights Management", but in FSF-speak "Digital Restrictions Management".  For the FSF - and hence the GNU GPLv3 - the matter is simple:

Some computers are designed to deny users access to install or run modified versions of the software inside them. This is fundamentally incompatible with the purpose of the GPL, which is to protect users' freedom to change the software. Therefore, the GPL ensures that the software it covers will not be restricted in this way.

That is, DRM or similar is fundamentally antithetical to users' freedom, and therefore cannot be countenanced.  But the authors of the white paper see things differently:

While we find the use of DRM by media companies in their attempts to reach into user owned devices to control content deeply disturbing, our belief in the essential freedoms of section 3 [of the white paper] forbids us from ever accepting any licence which contains end use restrictions. The existence of DRM abuse is no excuse for curtailing freedoms.

And what exactly is the essential freedom they are most worried about? 

the freedom from binding the end use of the project. Without this freedom, it would be much more difficult to satisfy the objectives of the contributors, since those objectives often have expression in terms of the end use to which they wish to put the particular project. Therefore, in order to maintain the essential development synergy and consequent innovation stream it provides to Linux, we could not countenance any change to the GPL which would jeopardise this fundamental freedom.

That is, it is a freedom not so much for the users, but for the programmers.  The white paper explains why its authors believe this is so important:

individuals with disparate (and sometimes even competing) objectives can still march together a considerable distance to their mutual benefit. This synergy of effort, while not compromising dissimilar aims, is one of the reasons Linux manages to harness the efforts of not only motivated developers but also corporate and commercial interests.

So, according to this view, kernel programmers must have the freedom from end use restrictions on the project or else this "synergy of effort" that has made Linux so successful will be lost.  In other words, at the core of the kernel hackers' argument is a pragmatic concern: GNU GPL v2 is better because it will allow Linux to be more successful.  This emphasis on success is made quite clear from the very first sentence of the white paper:

Over the past decade, the Linux Operating System has shown itself to be far and away the most successful Open Source operating system in history.

Linus, in his self-described "ode to GPLv2", underlines the pragmatic viewpoint with a telling parenthetical remark.  He says:

You can use the end result any way you want (and if you want to use it for "bad" things, be my guest), but we ask the same exact thing of everybody - give your modifications back.

That's true grace. Realizing that the petty concerns don't matter, whether they are money or DRM, or patents, or anything else.

This is the heart of the difference between the free software and open source worlds.  For the latter, GPLv2 is a highly-efficient licence because it works incredibly well as a way of getting the largest number of people working together to write great code, whatever their own particular interests or agendas - that's "true grace".  But for the free software camp, using it for "bad" things is anything but "true grace" - quite the opposite, in fact; for RMS and his followers "petty concerns" like DRM or patents do matter - in fact, they matter far more than whether a project is successful.  They matter because they negate the whole point of the GNU GPL, as stated right at the start of the licence:

the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users.

Or, as RMS said when I interviewed him in 1999:

The overall purpose is to give the users freedom, by giving them free software they can use, and to extend the boundaries of what you can do with entirely free software as far as possible.  Because the idea of GNU is to make it possible for people to do things with their computers without accepting domination of somebody else. Without letting some owner of software say, I won't let you understand how this works, I'm going to keep you helplessly dependent on me and if you share with your friends I'll call you a pirate and put you in jail. I consider that immoral, and I'm working to put an end to that way of life.

There is no room for compromise in this purist world-view.  As RMS emphasised in 1999:

the only reason we have a wholly free operating system is because of the movement that said we want an operating system that's wholly free, not just 90% free.

Hitherto those in the open source world have been able to let RMS live his uncompromising life because his system has worked amazingly well, and because they are pragmatists: they didn't really care about the politics implicit in the GNU GPL provided it didn't get in the way.  But with GPLv3, it does get in the way, and the publication of the white paper and poll seems to mark an end to the truce that has existed between the two sides for nearly a decade.

The white paper ends with a plea:

we implore the FSF to re-examine the consequences of its actions and to abandon the current GPLv3 process before it becomes too late.

But as its authors surely know, there is no hope that the GPLv3 will be abandoned - not after the 16,000 emails or so that RMS and Eben Moglen, the FSF's General Counsel, have exchanged on the subject.  Modified slightly, perhaps, but not in its substance, for example to weaken the clause aimed at DRM schemes: for purists, there can be no dilution of their basic beliefs - no "90%" solutions.  Unfortunately, the pragmatists too seem to be painting themselves into a corner with their definitive rejection of the DRM clauses.

There is no obvious way out of this situation.  The kernel coders will presumably stick with GNU GPLv2, as will others who are focused on programming efficiency and success; meanwhile, the GNU project and those programmers who agree with its unbending ethical viewpoint will adopt GPLv3.  As a result, some code will be forked, with dual GPLv2 and GPLv3 licensing, and there will be growing confusion in the world of code.

The Great Software Schism will have begun.

Glyn Moody writes about free software and open source at opendotdotdot.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

im

sinau's picture

wow 16.0000 mails

Buch schreiben's picture

Thats quite a lot ;-)

wow

Deai Baba Desimama's picture

Schism semmes to be very nice piece of software..whats the download link?

Can we clear up some of this confusion?

Freeman's picture

It's clear that we're having a great difficulty discussing this issue rationally due to confusion of the issues. Glyn is trying valiantly to steer the conversation toward more productive areas of conflicting opinion, but others (well-meaning, I'm sure) keep repeating the same arguments that have no legal or moral/ethical foundation, drawing the conversation away from the big picture. I'm going to attempt for the last time to dispense with some of these arguments once and for all (because I really like banging my head against the wall) and paint the big picture in a way hopefully everyone can better understand than my previous pathetic attempts.

First, some background on the legal and moral foundation of the GPL. The GPL's legal foundation is copyright law. Copyright law says that for the term of the copyright, the author of a work has the exclusive right to control the distribution of that work and derivative works. The GPL's moral foundation recognizes the author's exlusive rights and gives the author a mechanism for granting distribution rights to his work and all derivative works to each recipient, with the stated goal of insuring that every end user has the legal right to modify the work to suit his unique needs and share the modified work with everyone for the mutual benefit of all.

The idea that a software license has "no business" dictating how the hardware works has no legal foundation in the context of this discussion. First, the way the argument is worded confuses the issue. Software licenses have no business at all, it's the author's business. Second, the GPL dictates the conditions in which the author's work are allowed to be distributed, not how any hardware works. Under copyright law, the author has the exlusive right to dictate the conditions of distribution, not the self-appointed arbiters of which conditions it is his "business" to dictate. This point exposes the fact that the argument lacks moral foundation as well, because it rests upon the false assumption that somebody other than the author has the moral authority to grant himself more rights than the author by attempting to impose veto power over the author's choice of conditions for distribution by declaring whether or not it is the author's "business" to include a given condition for distribution rights.

This brings up the "GPL doesn't need a bugfix" argument that I want to address. First, let's dispense with the legals and morals. The GPL is the work of the Free Software Foundation, they hold the copyright to it, and have clearly declared the conditions in which they authorize the license to be applied. No matter who else is excercising the right granted by the FSF to use the license for their own works, or how many of them there are, or whether or not they disagree with any provisions or proposed provisions, legally it is the FSF's exclusive right to decide if the GPL needs a revision and what the language of any new revision will be. They have also fulfilled any moral duty they might have; despite their exclusive legal rights, they have graciously solicited public comment on the proposed GPLv3, knowing full well the volume of illegitimate flack and extremism labelling they could expect, and are giving careful consideration to legitimate concerns. Given the hideously poor signal-to-noise ratio in discussions between people whom one would hope would know their facts and understand the GPL better (and I confess to generating some of the noise without meaning to myself), they are showing a fantastic measure of goodwill towards those expressing their concerns, and really should be commended for that, no matter what any criticisms of the language of the proposed GPLv3 may be.

To proponents of Free Software, the "bug" in the BSD license is that anyone can assert for themselves more rights to a work or it's derivative than they grant to end users, including the original author. When, to use a real-world example, Microsoft modifies some BSD networking-stack code for their purposes and distributes it in binary-only form (or even if they do not modify it but link it with other code before compiling, also, legally even if the source code is available i.e. "shared source") under licensing terms that do not allow modification and redistribution, they can legally assign to themselves the exclusive right to distribute the original author's work in the resulting form it takes. This defeats the purpose of any Free Software license, as nobody but Microsoft, including the original author, can legally fix a bug in the original code or modify it to work with their system on Microsoft's fork of that code. Moreover, this situation allows a forked project to lock out anybody, even the original author, from benefiting from any changes in the derivative work. If shiny new features or important bug-fixes are added to a proprietary fork, winning it popularity over the free project, and the changes are not made legally available for use and distribution, the developers of the forked project can effectively take over control of the project and alter it to their own purposes at will (embrace-and-extend strategy). These results are hardly what we'd call "freedom" for the Free Software developer or the end user nor are they particularly conducive to the Open Source development process, as evident in the "success" (read: popularity) of GNU/Linux over the *BSD's.

The proposed GPLv3 "bug-fix" addressing what has become known as (for lack of a better term) the "Tivoization bug" is intended to close a legal loophole that Tivo is currently exploiting (hence the term) and Microsoft and others are prepared to exploit, which produces results identical to those of the "BSD bug". The Tivo exploit works by signing the firmware (embedded software, largely GPLv2-licensed) with a privately-held digital key and uses a public key which only recognizes the private key's signature to verify the signature. If the verification fails, the system will not execute the code. Since the end user does not have access to the private key, he cannot sign any modified software and therefore modifications are prevented from execution within the software environment the GPL software is distributed in. Thus, Tivo is excersizing more control over the execution of GPL software than it grants to end-users, including the original authors of the code it distributes in the device, and using that control to circumvent the purpose of the GPL, with questionable legal and moral authority to do so. Like linking to non-free software and only providing the source for the free part, linking a non-free key to the execution of free software, even though the source for the free software is made available, produces results identical to those the GPLv2 is designed to prevent. As this process uses similar techniques and produces the same result as linking to non-free software, the FSF treats it the same, basically saying in the proposed GPLv3 that you can only link execution of the binaries to keys that are made available to the end user, exactly like the GPLv2 requirement that you can only link to software distributed under compliant terms.

There is nothing whatsoever to stop Microsoft or anyone else from exploiting this "bug", as the technique is implemented in software whether or not the keys/algorithms are embedded in firmware or application-specific integrated circuits. Indeed, the "Trusted Computing" initiative specifies hardware implementations (much harder for the end-user to circumvent than firmware/software) specifically designed to implement these techniques and Microsoft is very interested in the technology. The FSF is demonstrating their experience and competence in crafting effective licensing conditions by building on the success of the GPLv2, which has served us all well for decades, and their wisdom and foresight by dealing with the issue now before Trusted Computing becomes the norm. While the legality of Tivo's actions are questionable to some, the FSF is also demonstrating wisdom in not trying to procecute any claims they might have (assuming they have legal standing to make any claim) under the GPLv2; given the confusion we see among GPLv2 advocates, a legal case would have little chance of success in a jury trial.

Which brings me around to following Glyn's direction and putting the focus back on the big-picture issues. As previously noted, the definition of "success" is a point of apparent contention. Given my comments, it should be clear that my opinion is that the FSF has competently demonstrated their ability to achieve success in crafting effective Free Software licenses in the past, and I think the vast majority of interested parties will agree with the definition of success in that context. Linus and the rest of the Linux kernel developers have also competently demonstrated their ability to achieve success in the development and maintenance of a kernel which has proven extremely useful in Free / Open Source Software operating system projects, and on that definition of success I think we can agree. These two competent, successful parties have acted in successful (if not harmonious) partnership with each other to the mutual benefit of all. There is no reason that cannot continue. I am confident these highly competent organizations can define a mutually-agreeable partnership into the future, even if there is no agreement on the GPLv3.

Forking is another legitimate issue of concern that has come up. As I hope I've convincingly demonstrated, anyone can exploit the GPLv2 in a way that renders it functionally equivalent to the BSD license (in effect, a "root exploit") with the technical difference that any changes to the GPL source code must be available. As long as they provide the source code and follow the letter of the rest of the license, Microsoft can distribute digitally-signed GPLv2 code right now (without using hardware-implemented techniques) as part of a larger software environment which will not execute within the software environment it was distributed in without access to the private key. Microsoft has demonstrated competence in effectively exploiting the success of others using embrace-and-extend techniques, so we shouldn't be surprised to see them exploit GPL software in this way. As history bears witness, forked projects that are all-proprietary (Unix's) or distributed freely under an exploitable license (*BSD's) do not enjoy the "success" we all seem to be looking for to the same degree as forked projects that are GPL-licensed (GNU/Linux distributions).

Viewing it from the Open Source development cycle perspective, forked GPL-licensed projects are free to share "best practices and features" among each other, providing the "bazaar-like" environment in which Open Source development thrives. This produces very desirable results (wide variety of distributions that are roughly compatible with each other, each with it's own innovations to share with the community) and some that are less desirable (incompatibilities that do exist between distributions), but these results are normal and expected, and don't seem to be impeding the overall success of GNU/Linux in the least.

Assuming the Linux kernel developers choose to excersize their right (which nobody is denying) to continue to use GPLv2, to the extent a schism occurs, it can be expected to be similar, but not as severe (since GPLv2 is not exploited as easily as BSD), as the schism between BSD and GPLv2 licenses. As it is, GPL projects can use BSD code, but BSD projects cannot distribute GPL code under BSD conditions. After GPLv3, projects using the GPLv3 license can use GPLv2 code and distribute it under GPLv3 without violating the terms of GPLv2, but GPLv2 projects that wish to distribute GPLv3 code under a GPLv2 license would not be in compliance with all of the terms of the original GPLv3 code. Thus those who risk the most if forking occurs are those who refuse to migrate to GPLv3.

I rest my case. I hope I've made it well, because if I spend one more minute on this my wife is going to kill me!

The problem is code execution

Anonymous's picture


The Tivo exploit works by signing the firmware (embedded software, largely GPLv2-licensed) with a privately-held digital key and uses a public key which only recognizes the private key's signature to verify the signature. If the verification fails, the system will not execute the code. Since the end user does not have access to the private key, he cannot sign any modified software and therefore modifications are prevented from execution within the software environment the GPL software is distributed in. Thus, Tivo is excersizing more control over the execution of GPL software than it grants to end-users, including the original authors of the code it distributes in the device, and using that control to circumvent the purpose of the GPL, with questionable legal and moral authority to do so. Like linking to non-free software and only providing the source for the free part, linking a non-free key to the execution of free software, even though the source for the free software is made available, produces results identical to those the GPLv2 is designed to prevent.

The problem with your argument here is that you address the execution of the code. Tivo has not prevented a developer from executing his/her code. Said developer can still execute the code on their own hardware, but not on Tivo's hardware. This is an important distinction to make and understand.

Further, Tivo may not have limited code execution in this way if they weren't, for legal reasons, required to do so.

And what of other applications that may be required to verify the software that they run is "authentic"? A voting machine might be a good example; it may be a government regulation that the voting machine must validate the signature of it's software. In this case, is using Linux simply not an option, simply because the original developer cannot recompile their code and run it on their own voting machine (which may even be illegal for them posess physically)?


... Second, the GPL dictates the conditions in which the author's work are allowed to be distributed, not how any hardware works.

Why should the software license dictate what hardware the software MUST execute on? Because in the Tivo example, as well as the voting machine, this is, in fact, what it would do.

And further, software

Anonymous's picture

And further, software execution and software distribution are NOT the same thing, and that's why it should not me limited in the software license.

very good analysis

Anonymous's picture

you have a very good analysis. However, you cannot fight the way hardware is made with a software licence. The licence becomes a Hardware-Software licence.

About M$'s ability to ship GPL v2 software falls back to the users of the software. As long as any changes are open(GPL) there's no problem.

That said, i think while the GPLv3 tries to give more protection to users of free/open source software it leaves the developers somewhat in the cold.

A solution to GPL v2 vs v3

James Horton's picture

Hello Everyone,

The solution to this delima is so simple it boggles the mind
that educated folks on both sides of the issue do not see it.

first some BACKGROUND.
----------------------
I'm both an EE and a Computer Scientist, practicing for decades
so I'm very knowledgable of hardware and software issue.
Firmware, that software that is uniquely written to run
on a specifice piece of hardware (including but not limited to)
a single or multiprocessor system, can be always be design
and implemented to skirt any patents, technologies, and impediments
to building products. Therefore it is in the exclusive realm
of the hardware/firmware engineers(or those that employ their
services) to uniquely (individually) decide what if any
norms (um let's call these license either software or hardware)
that they will accept restriction from. I could go on and on
but astute hardware designer understand where I coming from.
Kernels, RTOSes, executive, state-machines or whatever your
operating system uses on top of the firmware is always possible
or prevented by the firmware.

So now that we all understatd that the FSF nor the DRM has any
hope of influencing the firmware, except as mutually aggreed to
buy the hardware/firmware designers (usually for money) it's
a huge waiste of time arguing about GPL v2 and v3. Individual
coders will decide or those that employ/hire them.

the SOLUTION
------------
Personally, the FSF look like a bunch of idiots on this matter.
They are behaving like non_believers who shake their fists at
the sky and tell GOD he's wrong and do what they want.

The smart thing for the FSF to do is mount a campaign with a
certification process that hardware is GPL-3 compliant. After
all, hardware manufactureres (particularly the chineese)
only want to sell hardware and having their hardware certified
GPL-3 so they can continue to kick the shit out of the
American and European manufactures....would be welcome.
Others with traditionally restrictive firmware based hardware
can and will continue until their business model fails.

As a suggestion, I would suggest that the geniuses at the FSF
become friends with hardware geniuses at www.opencores.org.
If many folks in the FSF became hardware/firmware creators their
problems would be solved very quickly. But somebody is going
to have to make payroll for folks with those skill sets.
Many similar efforts exist; such that prudent planning will
allow the FSF to remove the (linux) kernel devs (Linus et. al.)
permanently from their critical path (lord knows
what these FSF folks really want).

Likewise, the FSF has not been in the critical path for the
(any) kernel/firware developers for a very, very long time.

How else do you think there are so many commercial instantiations
of (embedded) linux and they do not (legally) give a rat's
ass what Linus or any of the other 'Linux kernel developers'
or patent lawyers/holders say.

sincerely,
James Horton, PE

Excellent analysis

Nicholas Petreley's picture

I agree with your analysis. And there's the fact that the FSF simply isn't going to be able to change hardware practices with a software license. It just won't work.

I think the only way to address this kind of issue is to address hardware separately from software, and in the case of things like DMCA, find ways to lobby against it directly, not by creating restrictions in software licenses that will have no practical effect.

It does not matter

dhlii's picture

Most of the Anti-GPLv3 crowd seem to think forcing the FSF to change the GPLv3 is of earth shattering importance. Much of the GPLv3 analysis cites is accurate - but in the end the whole fight does not matter. The GPLv3 is to be the License of the FSF - It is about the values of the FSF, not the kernel developers, Microsoft or the world. It would be nice if Linus liked it - though most of the arguments against the GPLv3 work fairly well against the GPLv2, the License Linus chose for Linux.

I suspect the FSF would like the GPLv3 to be successful, but the FSF is an ideological organization. Asking them to believe differently than they do is like asking the NAACP to make peace with the KKK.

The GPLv3 will happen. In one form or another it will include the provisions that those outside the FSF find objectionable - specifically because they are consistent with the beliefs and purposes of the FSF. Whether the GPLv3 is successful or not depends on individual software developers - like Linus, and the choices they make. Just as the FSF is perfectly free to craft the GPLv3 as they please, the Kernel developers are free not to use it. Whether it actually works or not is also irrelevant - though I suspect it can work quite well. From its inception the FSF has taken an uncompromising stance on software freedom. No one sane would have predicted their success. Further the GPL has accomplished more to secure software freedom - regardless of your personal definition, than any organization, lobbying group, ...

The real threat of the GPLv3 is that it will be widely accepted. And that it will work - Why should anyone care what the GPLv3 say if no one chooses to use it ? Or it is found to be ineffective ?

Thanks

Glyn Moody's picture

A good summary - and an astonishing post. Your wife should be proud of you.

...and thank you!

Freeman's picture

Thank you for the kind words.
I wish I had formulated and posted this sooner, not sure if anybody else is following along any more.

Your wife should be proud of you.

The geek-factor doesn't impress her much, I'm afraid. ("You're wasting a beautiful Sunday talking about software licenses??? When's the last time you wrote any software?") If I were at all pragmatic I would realize that she's right!

Please accept my apologies for the rather long comment (almost surprised the Comment box let me keep going on and on...), but I really felt like I needed to spell it all out in one place in the clearest terms I could come up with. Along with that, my gratitude, as your comments helped keep me focused on the bigger-picture issues and really helped me see the Open Source perspective better.

I hope I was able to get the point across that the GPLv2 exploit is a serious problem, so there WILL be a GPLv3 that addresses it, and it will come sooner rather than later. The time to work out differences of opinion with regards to it's content is NOW, but anyone hoping to influence the decision has to have a full understanding of the goals of Free Software or they are not likely to frame their arguments in a way that is aligned with the objectives of the FSF.

Free Software proponents maintain that the only secure computer is one that is under the owner's exclusive control. If you're running non-free software, someone else has more control over the operation of that software than you do, and they can make it do anything they want. Likewise, if there exists an exploitable flaw in your software, free or not, someone else can assert more control than you have over your system, executing code at will without your knowledge or consent, and it is possible to make it do very bad things that would get you in big trouble. Like exploitable flaws in your computer software, as a Free Software developer, exploitable flaws in your license that allow others to assert more control than you have over your own software is an undesirable circumstance that should be addressed at the earliest opportunity.

The Tivo exploit is like a "root exploit" of the license that allows other parties to completely subvert it and assert full control over their fork of your code. That sort of forking is very undesirable for Free / Open Source Software development and should be actively avoided. I'd worry about that more than GPLv2/v3 forking.

Freedom?

Rob Golding's picture

I thought the idea was freedom?
So, is Linus "free" to use the license of his choice or not?
Then again, am I?

I have read Linus' and RMS' remarks about this very carefully, and while I, personally, would like the changes being brought in by v3, I cannot bring myself to vilify Linus for his "choice" to remain with v2. After all, it is his choice to make, not mine.

Also, why would there be confusion, there are already many different OSS licenses, this just adds another.

Certainly

Glyn Moody's picture

Linus certainly has that freedom, as the FSF has said explicitly:

The FSF has no power to force anyone to switch from GPLv2 to GPLv3
on their own code. We intentionally wrote GPLv2 (and GPLv1) so we
would not have this power. Software developers will continue to
have the right to use GPLv2 for their code after GPLv3 is
published, and we will respect their decisions.

As to the confusion, well, it's a question of how the licences work together. There's seems to be a general view that it would be necessary to fork a lot of code, and forks are generally not a useful way to proceed.

Kernel devs had to twist meaning of 'end use'

cprise's picture

They speak as if a vendor like Tivo represented end-users. This is spinning the issue, to put it mildly.

The GPL has a liberal, not libertarian, philosophical backing. It restricts a certain *class* of actors under certain conditions in order to maximize the freedoms of those with relatively few privileges and resources at their disposal. But in this debate, those with libertarian instincts are asking us to throw all class awareness out the window in pursuit of pure "freedom". Like much else in our society, that naive kneejerk stance has become a huddle for advancing corporate despotism over public interests; all it takes is the onset of an overriding, self-interested desire to preserve one's own favorable relationship with large corporations. George W. Bush also uses "freedom" in this corporate libertarian context, incessantly.

There is also an occassional appeal to purity in the form of a "pure software license". But if the license is hamstrung from taking hardware into account, then purity would require that the software cannot do so either. Maybe this is indicative of a problematic double-standard here: One side seems to be protesting a supposed ideological purity while suggesting the other side adopt a new concept that values a purity inline with the interests of DRM purveyors.

I guess laissez-faire means never getting into the habbit of looking into your own mirror.

More than all of this nonsense, the corporate-freedom groupies yelp about the other side having coined the highly illustrative and _relevant_ term Tivoization. That reminder of the FSF's concerns being not theoretical (as often claimed), but actual, must sting indeed. If Linus himself can keep overlooking this important aspect of the debate (and using his own blindness as a basis to belittle FSF and it's supporters) then something in the OSS camp must have gone terribly wrong. They seem to have become, if not blind, then out-of-touch and callous.

Perspectives

Glyn Moody's picture

It's that difference of perspective, again. The kernel group is worried about the effects of the new licence on themselves and their work, because their main concern is practical - writing the best code. For the FSF, it is the end-users who are paramount, because its concern is ethical. Both sides are consistent in their views, just talking about different things.

Linus's perspective is inconsistent.

dhlii's picture

The freedom of Kernel developers to do what they do flows directly from the license they choose. With respect to Linus, there are numerous excellent claimants to the Operating System throne that Linux occupies. We can easily create a serious flame ware comparing their merits. Many factors contribute to the success of Linux. But the choice of the GPLv2 being very high among them. Yet Linus's own views of software freedom, are not particularly consistent with that of the GPLv2 much less the GPLv3. Linux portrays the choice of the GPLv2 for the kernel as merely an accident, and it is occasionally possible to read into his remarks a sense that today he might chose differently. I would argue that Linux under a BSD type license would be less significant today than any of the BSD's.

Consistency

Freeman's picture

Both sides are consistent in their views, just talking about different things.

Not quite, over time. Writing the best code -- OK, I'll give you that. But Linus used to say he didn't care if corporations used Linux or not. Did that attitude change, or is it that he just doesn't care what corporations do with it (could be)? But there seems now to be a greater emphasis on "success" than in the early days. The definition of success seems to be corporate-driven, and emphasis on average geek joe user doesn't seem as strong to me.

I'm not sure

Glyn Moody's picture

Is there a greater emphasis on the corporate in the open source world? Maybe in some circles - simply because many companies are open source - but I don't detect that in Linus' comments. I think the success he is talking about is purely from a programming point of view - better code, and more users (as in closer to "world domination", not bigger profits).

The main thing that has changed over time is that the implicit ethical/political ideals embodied in the GNU GPL are now more explicit. Before, Linus and his ilk could simply ignore all the stuff that RMS kept on talking about; now they can't, because it's plumbed into the GPLv3.

Linus' inclination

cprise's picture

...and that of his associates, is to back off from criticising the corporate interests to which he has grown close. He's rather brave, however, when it comes to slagging the FSF.

And you said as much yourself: It's primarily about expediency for him.

For others that would follow his early steps... well they can eat DRM and contemplate becoming criminals for the sake of experimentation for all he cares. Linus got what he wanted out of his little chunk of history, and that's what matters most.

It is also interesting to find out from him that avoiding the type of restriction that locks-out users will necessarily permit better code. GPLv2 has hobbled them, according to that logic. Perhaps OSDL should switch licenses soon, because they must have a lot of work ahead in catching-up to FreeBSD which is an OS that vendors have just been lining-up to implement their DRM on.

Implicit in the typical Linus rationalization, is that our great new coporate buddies will stop work on other parts of Linux (the desirable parts) if they don't get to implement the DRM dreck. Maybe that's correct. But if so, then they will eventually abandon an 'indifferent' project like Linux anyway, in favor of OS vendors that have learned to actively close-ranks against consumers along with the rest of corporate America.

Ask yourselves if cartel lock-down is really preferable to vendor lock-in.

hmm..

Freeman's picture

I think the success he is talking about is purely from a programming point of view - better code, and more users

I think maybe corporate adoption is seen as a necessary means to the "more users" end goal, which is what I was getting at with the comment about corporate emphasis over average joe geek. Perhaps this is seen as a "necessary evil", something like the GPL using copyright law to enforce freedom (using corporate adoption to plant the seeds for greater average joe adoption).

The main thing that has changed over time is that the implicit ethical/political ideals embodied in the GNU GPL are now more explicit.

Good way to put it. GNU's goals and emphasis on freedom downstream to the last end user haven't changed. What has, is how it is expressed in the GPL. As new challenges to software freedom arise, the GPL must naturally get more explicit in order to counter these challenges without interfering with freedom any more than necessary. Of course, the danger is that over time we could end up with a GPL looking more like a Microsoft EULA, kinda like how the tax code keeps getting more complex.

Ah, the GNU EULA...

Glyn Moody's picture

Yes, a good point: this EULA-isation of the GPL is probably another reason why Linus prefers GPLv2. It's much cleaner, and as a pragmatist hacker I think he prefers such minimalist solutions.

The bigger picture

JJSg's picture

One point that has been made in the many discussions about GPLv3 is that the choice of license belongs exclusively to the developer. For the Linux kernel developers to choose GPLv2 is the same (legally) as the BSD kernel developers choosing the BSD license.

By the same token, it is the right of the FSF to update the GPL. After they have finalized the GPLv3, updated all of their code to use it, and the world does not implode, people will see the similarity to the Gnome vs. KDE arguments.

But there is one debt that all FLOSS developers should concede to RMS and the FSF. Let me illustrate this with a story from my life. Before I got my CS degree, I worked in a chemical plant as a salaried worker. However, I was paid by the hour and received time and a half for overtime and double time for holidays. One day, someone started ragging on union workers striking at another plant. Two co-workers immediately jumped down his throat saying that if it weren't for the unions, he would be lucky to be making half of his pay--and he didn't even have to pay union dues.

When GPLv3 is finalized, it's effect will be felt regardless of how much code currently licensed under GPLv2 is switched to it. The very existence of the threat to switch will be enough to make companies hesitant to try to circumvent that spirit of the GPL.

I personally expect to license my code under GPLv3 because I do not want to allow it to be tivoized, but I will voice no opinion about the license used by the Linux kernel developers, because it is not my decision to make. I just hope that the entire FLOSS community shows respect to the FSF for their decision to change their license in a way that they believe is important.

An interesting thought

Glyn Moody's picture

I hadn't looked at it like that - with the GPLv3 as a kind of deterrent, kept in reserve.

So, programmers could continue using GPLv2 but with the proviso - maybe even made explicit - that if people start abusing that licence in the ways people are talking about then the code will in future be released under GPLv3, thus cutting off offenders from the main development branch.

As you say, coders may well be able to enjoy the benefit of GPLv3's existence without necessarily using it. But this still means that we need the FSF to finish the job on GPLv3 so that people have it as an option.

It's not Free Software vs. Open Source

t clark's picture

This isn't a Free Software vs Open Source issue. It's an intra-Free Software issue. The debate is over how best to protect freedom. If you consider Linus Torvalds' statements on the subject, he's never argued that GPLv3 is too free. He's expressed concern that it's not free enough.

Linus's definition of Software Freedom

dhlii's picture

But this fight is pretty much exactly the fight between Free and Open Source Software. The FSF makes no distinction between developers, and users. It is your computer - no one else should be able to impose artificial limitations on how you make use of it. The FSF is perfectly content for Free software to be a small niche in return for preserving their right to do as they please with their systems. Though they strive to write excellent code, they are not looking to improve the quality of their software at cost to their freedom to use it as they please.

Linus is arguing for the right of corporations to protect their investment by limiting the freedom of users.

One of the failings of that argument is that Tivo as an example was perfectly free to buy or develop their own OS. There are many choices out there - even other free choices. Further developing the minimal OS for the very narrow needs of a Tivo is not a particularly daunting task. Even Linux went from conception to most everything Tivo would need on a very specific hardware set in a few months.

In the end the FSF view is that Linux is replaceable - no matter how long that takes. Freedom is not.

For whom?

Rufus Polson's picture

For whom?
The point of this article is one I agree with: It would seem that Linus, the releasers of the "white paper", and the specific kernel hackers Linus decided to informally poll, all agree that GPL V3 doesn't give enough freedom *to programmers working for distributors*. Actual end users is not so much a group they're against giving freedom to as one they don't seem willing to notice exists.

Meanwhile, the FSF is interested in giving more freedom to people in general, the vast majority of whom are end users.

Curtailing some freedoms to preserve the rest

Karl O. Pinc's picture

If you consider Linus Torvalds' statements on the subject, he's never argued that GPLv3 is too free. He's expressed concern that it's not free enough.

Yes, a main point of the point of the article is that both sides have legitimate points concerning freedom(s). It's the same argument that the BSD and GPL camps have traditionally had. The BSD people always say that the GPL (v2) is not free enough. The question is, what freedoms are you willing to give up in order to ensure you retain the remainder? The GPL v3 proponents are willing to give up some freedoms in order to ensure that they can continue to execute modified software, the GPL v2 proponents are not.

The "Open Source Opinion", to paraphrase nobody, could probably be phrased as "hey, it's working well enough, don't mess with it" because all they're concerned about is what works. As the GPL v3 will affect both Open Source and Free Software it's legitimate to include the Open Source viewpoint when contrasting arguments and discussing who favors which license and why.

Execute on what?

Nicholas Petreley's picture

The GPL v3 proponents are willing to give up some freedoms in order to ensure that they can continue to execute modified software

With respect to tivoization, you CAN continue to execute modified software. You just can't (easily) execute it on a specific box, which is the TiVo hardware. But TiVo never agreed to open up its hardware. It agreed to abide by the GPL and keep its software open. The GPL is a software license. It has no business dictating what you have to do with hardware, especially when nobody is being forced to buy that hardware in order to get the software.

Whose hardware ?

dhlii's picture

I think RMS would argue that if you bought it, it is YOUR hardware, and that you are not obligated to run Tivo's software on it at all. That forcing you to do so, is like Ford insisting that you must put firestone tires on cars you buy from them.

It would take very little time using modern hardware development tools, to recognize that if there ever was a distinction between hardware and software - it is gone. I recently played with a tool that can be used to design FPGA's, model biological systems, or markets, or write concurrent software - or permutations of all of the above.
Hardware designers write in a collection of languages, that resemble programming languages like C - except when they are actually designing hardware in C. Uarts, CPU's FPU's, ... are available as programs that you can download, modify and impliment in FPGA's or ASIC's, or ....
And they are licensed - exactly like software. And like software some are proprietary and some are Open Source - even GPL.

RMS is not even prescient, hardware has not truly been hard for some time, but increasingly the ability to "program" your own hardware is moving out to software developers and users.

The GPLv3 only limits what vendors can do with GPLv3 software. In essence it says that if you distribute GPLv3 software, you must do so in a way that those you distribute it to have the freedom to modify it and run it in modified form on the hardware you chose to distribute it on. To turn your argument on its head - vendors are not forced to use GPLv3 software. They choose to do so, and when they do so they agree to accept its terms. Those terms limit the freedom of vendors in favor of the freedom of the users/developers/owners of software. Vendors are still free to distribute proprietary software in any way they please.

The FSF's principles on software freedom have ALWAYS been that software is not truly free if you do not have the ability to alter it and make use of the altered version. Whether Tivotization violates the GPLv2 or not, it absolutely violates the core principles of the FSF predating the GPLv1.

In essence the kernel developers are saying that the FSF needs to abandon its principles, because the software license that the FSF created appears to have a flaw that allows a use that conflicts with those principles. In essnce their arguments is "your license is right, your principles are wrong".

Eh

cprise's picture

But TiVo never agreed to open up its hardware.

You forgot who owns what, again.

Damn sloppy. Do you really care? Or is this about crazy-making for you?

I can go to Dvorak's website if I want to look at page-hit generators.

You're pretty firm in your conviction

Freeman's picture

With respect to tivoization, you CAN continue to execute modified software. You just can't (easily) execute it on a specific box, which is the TiVo hardware. But TiVo never agreed to open up its hardware. It agreed to abide by the GPL and keep its software open. The GPL is a software license. It has no business dictating what you have to do with hardware, especially when nobody is being forced to buy that hardware in order to get the software.

You must really believe this because you keep repeating it, so let me see if I understand you correctly.

A software developer has no business using license terms to dictate anything to do with the hardware it's running on (does Apple know about this?) (does this extend to encryption keys, if availability of those are dictated rather than anything about the hardware itself, as in the proposed GPLv3?). This is especially true if nobody is forced to buy any hardware to get this software, for some reason??? This is a practice that should be opposed.

A hardware vendor has the unquestioned right to dictate what software can run on that hardware after the sale by any means necessary (usually alot more draconian than "my license says you can't do that"), even if the software he distributed, embedded in the hardware, was written mostly by people outside his organization and released under license terms designed to insure that it would remain free for all usage, modification, and further distribution all the way to the last end user. It's unclear if this is especially true if people are forced to buy software to get the hardware??? (sorry, I'm confused) This is a practice worthy of vigorous defense.

Am I even close?

Yes, spot on

Mark H's picture

The hardware manufacturer has a non-zero unit cost. For high-volume products, the cost of embedded software development is negligible (even if developed totally in-house). Of course using off-the-shelf software greatly reduces time-to-market.

But hardware manufacturers need to recover both the physical cost of the hardware components, and the very expensive manufacturing facilities.
Most companies selling applicances would want to keep the embedded software must be kept safe from unapproved mofications...especially where there are regulatory compliance requirements.

My feeling is, if you buy an appliance, you shouldn't expect to be able to mess with its software. If you want to do that, get a general-purpose computer.

I'm not sure that the Apple analogy is too applicable, as if their software was GPLv2 one could make it work on any hardware (Apple-VAX, anyone).

Software cost

dhlii's picture

If software cost is non-existant amortized over bazillions of units - then write your own software. No one put a gun to Tivo's head and said they MUST use Linux. I do embedded OS work. I am perfectly willing to write and OS for Tivo that would cost less than they have spent on Linux development so far.

There are a plethora of proprietary embedded OS vendors that would have fallen all over themselves to put their product into Tivo.

And there are other Open Source OS's like the BSD's that might even be arguably superior to Linux that explicitly allow Tivo to do exactly what they chose to do.

$$$

dhlii's picture

So all that matters is money ? The vast majority of computer products are not mass market products, or are mass market products that use software for small vertical markets where the software costs dwarf the cost of the hardware. By your logic in those instances - the majority of all instances, developers get to dictate.

one of the fundamental problems with most of the arguments against the FSF is that they do not divide the world into developers and users. In the FSF world every potential users is also a potential developer. In their world if you posses free software you have the right to modify and use in any way you please. If you can not modify it yourself then you can beg, or hire someone to do it for you. It is your software running on your hardware and you may do with it as you please. The only restrictions the GPL places on your use of GPL software is if you redistribute it.

and your appliance analogy is apt. You do not feel that you should be able to make changes to the software in an appliance - but the FSF explicitly beleives you should be allowed to. The somewhat mythical story about the inspiration for the FSF and GPL, was the inability to get the source for some printer firmware to fix a collection of bugs. For the most part car makers do not to insist that you can not maintain or alter your car as you please. Their warantees may, but you can opt out of them. In some instances the law may, but that is still not dictated by the maker. Tivo was perfectly free to void their warantee if you chose to run modified software on YOUR Tivo.

The fundimental question is whether Tivo can tell you what software you will run on YOUR hardware. Can Apple dictate that I cannot run Linux on my Mac PowerBook ? Can Dell insist that I must run a copy of Windows XP purchased from Dell ? Even Microsoft has not (until now) tried to assert that I can not run third party software on Windows without their permission.

Place responsibility where it belongs

Freeman's picture

But hardware manufacturers need to recover both the physical cost of the hardware components, and the very expensive manufacturing facilities.

But as a software developer choosing a license for MY software this is not my concern or responsibility to accomodate. Whose responsibility is it to recover manufacturing costs? Right, the manufacturer. There's no legal or moral justification for your assertion that Free Software developers or the recipients of Free Software are required in any way to accomodate the whims of "appliance" manufacturers. Legally, the recipients of Free Software are allowed to modify it, execute the modification, and distribute the Free Software and/or their modifications, PERIOD. When you buy a Tivo, you are a recipient of Free Software, because the Linux kernel is distributed with the machine in it's firmware.

My feeling is, if you buy an appliance, you shouldn't expect to be able to mess with its software. If you want to do that, get a general-purpose computer.

Fine as long as you don't impose your opinion on me, because I feel differently. Linksys WRT54G router -- runs linux, satisfies requirements of GPLv2 in spirit as well as letter, has user community developing user software for it. It's an appliance by what I assume is your definition -- it's a hell of a lot smaller than a Tivo. You may think the Tivo's a wabbit because it's wearing a wabbit suit, but inside -- it looks like a duck, walks like a duck, and quacks like a duck -- it's got a motherboard, a CPU, a GPU, interfaces, hard drive, etc. It's an effing computer (so is the Linksys router), as if that matters at all in the context of this discussion, which it DOESN'T!

My feeling is (and it's backed up by copyright law, what is your opinion backed up with?), if you build an appliance and you don't want to allow your customers to mess with it's software, you shouldn't expect to be able to distribute Free Software imbedded in it. If you want to do that, use proprietary software (just like X-Box, PlayStation, etc.).

Execute on something useful

Karl O. Pinc's picture

The software has to execute on _something_ that provides comperable functionality or it's useless. I can, relatively easily -- for some value of "easy" -- build my own Tivo. (I have no idea whether building your own Tivo is even legal any more given the DMCA and the various DRM incorporated into most media these days.) By anybody's measure it's not easy for me to build my own cellphone, or "ipod", or GPU for that matter. Nobody's forcing Tivo to open up their hardware. If Linux goes to the GPL v3 they can fork like anybody else and continue to use the GPL v2.

Yes, the GPL is a software license. One that places no restrictions on what you can do with the software in your posession. The GPL does restrict your ability to re-distribute the software when your re-distribution results in the person receiving the software having fewer rights than you do. It exists for that one single purpose and always has. What makes hardware so special that it should be allowed to circumvent the purpose of the GPL? After all, nobody's forced to distribute GPLed software and no developer is forced to write GPLed software. Most significantly, the Church-Turing Thesis demonstrates, for some value of "demonstrates", that there's no difference between hardware and software at a fundamental level. Lisp programmers know this, they can see that data and program are interchangable. I'm sure the imbedded programmers are intimately familar with this too, because of the old trick of substituting a lookup table in ROM for a computation.

I'm afraid I don't understand when you write nobody is being forced to buy that hardware in order to get the software. The GPL does not require a software distributor to give the source code to just anybody, it only forces the distributor to give the source code to those to whom it distributed the binaries. In the case of a hardware manufacturer that would be those people who bought the hardware. In other words, yes, you _are_ forced to buy the hardware in order to get the software. You are without _any_ recourse if you buy the first unit, although of course those who already own the product are free to create marketplace and sell or otherwise redistribute the software and at some point you'll probably be able to obtain the software from this secondary market.

Execute on something useful

Anonymous's picture

Yes, software requires hardware in order to run, and for a lot of people that's reason enough for software requirements (terms of the GPL) to extend to the hardware. But I don't think that's quite right.

If I give you a CD with free software on it (all source included, and let's say it's software I've modified) and nothing else, I've done nothing wrong. But software requires hardware to run, so the CD I gave you is useless, right? No, probably not, because you'll get your own computer, or whatever hardware you need to make that software run, assuming you care enough to bother.

I've failed to supply you with hardware to make that software or modified versions run, but I've done nothing wrong, because I only had to give you the same freedoms I had. Only the software was supplied to me, and I had to get my own hardware (or make it); now you have to do the same. But your software freedoms are intact.

So I'm perfectly fine if I *don't* give you hardware that can run modified versions, but I'm evil if I *do* give you hardware that can't. It just doesn't make sense to me. It makes perfect sense that people would like to modify their TiVos, and it would be nice if the company that made them chose to allow that. And of course if they don't, that just makes room for some other company to offer what they don't (or some generous person who likes giving away hardware). But it just doesn't make sense that they think it's someone else's job to supply them with hardware to do what they want.

The GPL3 fans seem to think it was always intended that free software would not allowed to be run on non-free hardware, and the new DRM restrictions clarify that. The GPL2 fans seem to think the license was never intended to dictate what kind of hardware the software could run on, and there was no mistake to 'fix'.

Either way, up until GPL3, you didn't have to be in line with the FSF philosophy to benefit from free software, as long as you kept the software free. Obviously the more the GPL changes in the future, the less true that's going to be.

Still problems with the logic

Freeman's picture

First, start here (if you haven't read it already) for a clearer (I hope) explanation of the "Tivoization" problem.

Here's where I think your logic falls completely apart:
But it just doesn't make sense that they think it's someone else's job to supply them with hardware to do what they want.

You've got it backwards: it doesn't make sense that Tivo thinks it's someone else's job to supply them with software to do what they want (prohibit end users from modifying the software) and then find a way to exploit the license instead of complying with it if the Free Software they want to distribute embedded in their box doesn't accomodate their desires.

As a software developer, I am allowed to define ANY conditions I want for the legal distribution of MY software. According to copyright LAW, if I want to be stupidly obtuse I can write a license that says "you can distribute my software to anybody but (to pick on an innocent neutral party) Glyn Moody because I've heard rumors that he has a diabolical plan to execute it on a VIC-20, and distribution of this software imbedded in an ipod is also prohibited". Got a problem with that? Lobby Congress for new copyright laws.

Yes, for now...

Freeman's picture

Your point has been made, and I won't argue with it, per se.

I think the problem is not just Tivo, but what happens when (if?) general-purpose computers and peripherals adopt Tivo-like techniques to lock out unsigned code. There seems to be an industry thrust in that direction (Trusted Computing, etc.). So while your point is valid when only Tivo is considered, I think you have to admit that these lock-out techniques, applied to general-purpose computing, would make open-source development pretty much impossible without access to the keys.

As I understand it, the proposed GPLv3 doesn't say you can't use the software in a locked-down box, just that you have to make the key available if you do (which, of course, pretty much defeats the purpose of lock-down, so there are going to be conflicts of opinion on that). So if my understanding is correct, contrary to your statement, GPLv3 doesn't prevent Tivo from running it on any hardware they want as long as they abide by the requirement to provide keys if they use lock-down techniques, whether implemented in software or encoded into a hardware chip. (Two can play the "technicalities" game!) I don't see how that's so different from, say, you can link this software to any software you want and compile and distribute the result as long as the license for the other software is distributed under terms compliant with GPLv2.

Like someone already said (on your blog, I think), software you can't run is nothing more than literature.

I get your point, too

Nicholas Petreley's picture

There seems to be an industry thrust in that direction (Trusted Computing, etc.). So while your point is valid when only Tivo is considered, I think you have to admit that these lock-out techniques, applied to general-purpose computing, would make open-source development pretty much impossible without access to the keys.

I agree 100%. But first, I think it is a non-sequitur to say that because TiVo does X, it follows that it will lead to Y, which is a locked-out general purpose PC. There's no connection. TiVo is an appliance. It just happens to be an appliance that runs Linux. If it ran a proprietary OS, we wouldn't even be having this discussion.

Second, general purpose computers aren't appliances. One major reason network computing never took off, despite the fact that they would reduce TOC for end-users (esp. corporations), is because hardware companies don't want to sell them! They make a whole LOT more money selling us easily upgradeable powerhouse machines so we can browse the web on a desktop supercomputer. Why am I poking fun at that? Because it gets to the heart of the economic motive. Except for things like people who want to run Vista or hard-core gamers, people don't need quad-core machines with the latest NVidia card to do what they do. But we buy this stuff anyway, and the people who sell it love the fact that we are obsessed with running the latest and greatest, and then upgrading it, adding TV capture cards, etc.

Now suppose someone comes out with a locked-down PC. Ss long as someone ELSE sells a non-locked-down PC, I'm willing to bet people will gravitate to the non-locked-down PC, instead. The market will kill the locked-down general purpose computers because locking out anything runs counter to the philosophy of the general purpose PC. The whole point of a general purpose PC is that we can plug in whatever card we want, load up any OS we want, upgrade the RAM if we want, etc. If we couldn't do these things, it wouldn't be a general purpose computer anymore. It would be an appliance.

The market will avoid a locked-down PC. I think the only way a locked-down PC could succed is if it were forced on us by some ridiculous law, like an offshoot of some DRM law like DMCA. In that case, we should be lobbying our representatives to get rid of such laws. I don't think it will come to that. I don't think companies would ALLOW it to come to that, because they have so much money at stake. But IMO, if it DID come to that, the right approach is political.

I don't think the right approach is to hope the GPLv3 prevents it. If anything, I think if Linux became GPLv3, it wouldn't affect hardware design in the least. It would simply force hardware makers who want to avoid the hassle of GPLv3 to adopt something other than Linux. There are plenty of good alternatives, like *BSD, if they want free, and several other non-Windows OSes, if they don't care about proprietary. And there's always the bad alternative, Windows, which they don't mind supporting anyway.

Why Linux

dhlii's picture

If I beleive in preserving the environment do I lobby congress for environmental laws, or plant a tree ? Is there some special reason I can not do both ?

The GPL accomplished something amazing. It did so without alot of lobbying, and no knew laws. It changed culture world wide.
Whether the GPLv3 will have the same effect or not is an open question, but doesn't the FSF have the right to try ? Are they required to pursue only the approaches you favor ?

Much is made of the "liberal", anti-business, "evil", viral, nature of the GPL. But despite the declaimers, there are very good, capitolist, free-enterprise reasons for businesses to choose the GPL over BSD, or any other Open Source License.

Those licenses that do not include the "viral" attribute so vociferously declaimed in the GPL, allow your competitor to take any Open Source contributions you make, build upon them, directly benefiting from your work, but not returning the same benefit to you.
The exact benefits that the GPL offers to Linus, and you and I, it offers to IBM, and Sun and even Microsoft.

There are legitimate reasons for business to debate whether to pursue an Open Source or proprietary model. But on accepting a Open Source model, most not viral Open Source Licenses create an easy scenario for your competiton to bootstrap off your efforts, with no benefit to you.

Tivo's Linux maneuvers create no bar to a competitor coming out with a very similar product that capitalizes on Tivo's work. Tivo's behavior only penalizes users.

There is every reason to believe that many companies - particularly large existing ones will try to come up with locked down systems, and there might even be a few extremely narrow markets such as life safety systems, where some form of lockdown is appropriate. Whether lockdown systems will or should exist might be a legitimate political argument, but whether software developers and the FSF have the right to assert that their software can not be used on systems that do not preserve the FSF's four freedoms.

Locked down PCs

Anonymous's picture

The market will avoid a locked-down PC.

The market may not be able to avoid locked-down PCs. It is not hard to forsee a course of events that ends with Internet Service Providers in the US being required by law to have remote attestation of the identity of any computer that they allow to connect to their networks. This remote attestation feature of DRM will guarantee that no computer connected to the Internet in the US will be running an operating system that is not digitally signed by Microsoft or some equivalent. This is politically entirely viable in the current atmosphere.

Market Freedom

dhlii's picture

The internet was conceived of and initially made of a network of peers. It was not intended to be a network of clients and servers. Most every Linux distribution installs its own mail server (and usually web server, and ....) on every client machine, yet my ISP's prohibits me from running my own Web and Mail servers - and probably any other server they can think of. Further in our efforts to rid e-mail of SPAM, we have chosen to blacklist most anything but authorized mailservers. Trying to run a mail server on an APNIC assigned or ISP assigned IP, is an excercise in futility - yet if violates the spirit of everything the internet intended.

But I have not seen a huge outcry from consumers demanding home mail and web servers. Most people - even though their windoze boxen may already be zombie mail and webservers under some botmasters control, are completely ignorant of the fact that it is even possible.

on of the most fundimental problems with some of the freedoms we are debating is that few people know they have them, have any perception of their worth, or will notice if they loose them. It is easy to sacrifice unknown and unappreciated future possibilities, for the false perception of immediate security.

Appliances and GP computers / users and "users"

Anonymous's picture

I agree that it will be hard to lock down PCs completely. The hardware architecture is open enough to prevent this in the near future. But I have a feeling that PCs are more and more regarded as appliances for office and multi-media software. Try buying a consumer PC without software. Most people cannot just go to the nearest PC dealer and buy a box with no OS preinstalled. With laptops it is even worse. So the fundamental difference between an appliance and a general-purpose computer might no longer exist. Think of the X-box and you will understand what I mean.

The FSF fights for the end-users' freedom. In GPLv3 some nice provisions are taken to prevent GP computers from becoming appliances. I do not see how these provisions limit the use for a kernel developer. They are certainly limitations, but as with every border the question where it should be drawn has to be answered. Drawing it in favor of hardware manufacturers limits the users. GPLv3 draws the border in favor of the users. I feel very comfortable with that approach.

My impression is that the kernel developers are after commercial success of their software. I can see nothing bad in this attitude. Actually it is the commercial success that has made Linux very successful. Without commercializing it many people would never have taken it as seriously as they do now. So they would like to draw the border a little bit more in favor of commercial use. Fine, but what happens to this commercial success if developers are more and more locked out? For what target platforms are they going to develop? And on what platforms?

I see a fundamental flaw in their arguments when I look at the bigger picture. On one hand they would rather have more freedom for the computer manufacturers, on the other hand they lock out non-GPL kernel modules to keep Linux open. I find this rather contradictory.

I do not share the hope that a robust commercial support for Linux is the best. When it comes to hardware and Linux there is only one major player: IBM. Without a real competitor the market might be a bit sluggish when hardware lock-out techniques are becoming common.

I might be too pessimistic but I regard RMS', Lessing's and Moglen's pessimistic approach more suitable to overcome limitations imposed on end-users than the kernel developers' view. Recently Linus made some statements on GROKLAW about what he thinks a user is. I understand that he regards a company that uses Linux as some sort of "user". I have no problem with that definition. Linus concludes that these users should not be subject to more limitations. Appearently he does not understand that in his definition not all users are equal. The broad majority cannot organize to balance powers. But the commercial minority is about to run a serious, organized attack on the majority's ability to do with a computer what they want.

Why can't they see that this will happen soon?

Conflict of interest

Nicholas Petreley's picture

In GPLv3 some nice provisions are taken to prevent GP computers from becoming appliances.

Those provisions would only have an effect if GP computer OEMs depend upon the software that is GPLv3.

This is where the GPLv3 fails to mean anything. It has no power to accomplish the FSF's stated goals. If the GPLv3 conflicts with an OEM's interests, what do you think they'll do? Fix their hardware so that GPLv3 code will run? Why on earth would they do that when they already do just fine selling boxes with Windows?

I really don't think locked down general purpose PCs are the future. But assuming they are a real threat, then if you want to guarantee that locked down general purpose PCs will be our fate, the best way to do that would be for Linux to adopt GPLv3. The choice would be "build 'em the way we want to build 'em, which is how the vast majority of consumers buy them anyway, or submit to the GPLv3 for a minority of our customers".

On the other handm, if Linux remains GPLv2 and only HURD goes GPLv3, which it seems like how it'll turn out, then they'll build 'em the way they want to build 'em, and GPLv3 will have less impact than a gnat.

I honestly don't agree with you that we're headed for locked down PCs where Linux or anything else won't run. I have many reasons to believe this, but I'm not goint to rehash the ones I've listed or add new ones here. Suffice it to say that only time will tell who's right.

Here's the bottom line for me. If FSF wants to draft a highly restrictive GPLv3, then they're certainly free to do that. I have no problem with it at all. If it causes a fork, and we end up seeing Linux with GNU GPLv2 vs. HURD with GNU GPLv3, then that's fine, too.

But, regarding the future of general purpose PCs, does anyone seriously think the existence of a GPLv3 HURD/GNU is going to change the fate of PCs one way or another? I mean seriously, folks. One really has to be living in a fantasy world to think that's going to happen.

"Oh noes!" says TiVo. "The HURD is GPLv3!!! I guess we have to open up our boxes or go out of business!" Really, that'll happen.

Linux goes GPLv3

dhlii's picture

I think one of the fears of the Linux Kernel developers is that Linux will go GPLv3. Despite representations to the contrary, Linux is not GPLv2. The overwhelming majority of Linux is GPLv2, but there is a motley collection of licenses scattered through out, and infrastructure to support mixed and dual licensing.

If the GPLv3 comes into being the Kernel developers will be faced with submissions that are solely GPLv3 Licensed. In the short run they will likely reject them - there trying to find a basis could be difficult, but presuming that the GPLv3 has even moderate success, trying to exclude GPLv3 code will become increasingly difficult.
The argument that the GPLv3 is less free than the GPLv2 is particularly important. If the GPLv3 is viewed as more free than the GPLv2 then GPLv3 code does not "taint" an otherwise GPLv2 kernel - but it does limit the options of some vendors.

A single GPLv3 driver or module will not matter much, but accepting a GPLv3 driver makes accepting a GPLv3 critical component easier and more likely.

Richard Stallman will probably escape the vitrollic fights over the GPLv3 once it becomes a fait acompli. Linus and the kernel develoeprs are facing addressing GPLv3 issues continuously until they cave in.

Every future Tivotization act, will increase the preasure.

I do Linux kernel development. While Linus and other key kernel developers may be free to chose to allow Tivotization of his contributions, aren't I free to chose not to ?

Restrictions

Anonymous's picture

I agree that there are no rules in GPLv3 that could prevent simple lock-out measures like jumpers or DIP switches. But this is not the technique of choice for those trying to lock out FOSS. DRM is probably an effective measure especially when paired with DMCA or other protection laws.

Your vision is that there is nothing that can stop companies from dropping Linux in favor of something else. I guess "something else" can only mean Microsoft software because that is the only software universe with a portfolio comparable to FOSS. The industry's willingness to accept rules set by Microsoft and only Microsoft has decreased over the years. Much of Linux' success comes from this reluctance. The kernel developers are trying to fasten the screws a little bit by discouraging closed-source kernel modules and the FSF is trying the same by discouraging DRM and the like. Where is the fundamental difference? Why is the FSF's approach more detrimental?

What else protects us from DRM? What would Linux be in a DRM world? The battle between DRM and fair use has just begun. The kernel developers do not even suggest a solution to this fundamental problem yet criticize those who worked hard to legaly work around DRM.

Both the FSF and the kernel developers think their approach is the best measure. Both act arrogantly once in a while. I take the kernel developers' view very seriously as they have expressed concerns that are related to their employers' point of view (I do not suggest these expressions were suggested by their companies). In order to survive Linux needs a fair amount of commercial support and awareness. Even users which have nothing in common with software industry cannot deny that Linux got a significant boost when Oracle, SAP, IBM an others jumped on the bandwaggon but we cannot allow them fully embrace FOSS.

Any kernel developer reading this? Please read Eben Moglen's invitation for discussion and get into touch with those guys. Talking politics through the media instead of contributing to the official GPLv3 review process is something that should be stopped very soon. I find it quite unrespectful to neglect the review process and complain about GPLv3 in blogs, news feeds etc. You got no invitation? Hey, we all were invited!

OS choices

dhlii's picture

It is already fairly trivial to replace Linux with any number of other choices. There are enormous numbers of POSIX compliant OS's out there - even Windows is minimally POSIX compliant. I am quite sure there are many Open and Proprietary OS vendors that will tell your exactly how trivial it is to get the wealth of Posix conforming software running on their systems. While it MIGHT be less trivial than claimed it is still not insurmountable.

there are alot of reasons vendors choose Linux. Even if the whole kernel adopted the GPLv3 tomorrow, it is unlikely that many would change. Tivo probably would still have chosen Linux even if they felt compelled to comply with both the spirit and letter of the GPL.

RSM does not care if the provisions of the GPLv3 drive vendors away from Free Software. His objective is to create the largest body of truly free software - not the largest body of mostly free software even if that is orders of magnitude larger.

Linus's objectives may have shifted but they were never the same as Richard's.

I suspect the GPLv3 will never acheive the significance of the GPLv2 - though I will be happy to be proven wrong. But even if it did, it is not going to drive vendors to the BSD's or other OS's. The rights the GPLv3 seeks to preserve are truly important to less vendors than percieved. Very few Vendors chose GPLv2 software because that is the Open Source license they would draft on their own. The GPLv3 does not change that.

Alternatives

Nicholas Petreley's picture

Actually, there are other alternatives besides Windows. Assuming Linux went with GPLv3, anyone who feels they need to support DRM or DMCA but doesn't want to go with Windows could always pick *BSD, or in the case of embedded systems, pick one of many good embedded OSes.

Since DRM can be used in good ways, I'm more concerned about DMCA than DRM. Regardless, I don't think the GPLv3 has any power against these things, especially things like DMCA. This is especially true if an OEM is legally required to support DMCA in order to build and sell something. For that reason, I think the way to fight DMCA is through political channels. That approach would have a chance. IMO, a software license doesn't have any power over whether or not people adopt DRM/DMCA/etc. Anyone who wants to implement it, feels pressured to implement it, or is legally required to implement it will simply go with Windows, *BSD, ir other proprietary OSes. So the GPLv3 wouldn't stop anyone from locking out anything.

If Windows adopted the GPLv3 then maybe the license would have an impact. But I think we all know how likely that would be. ;)

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix