Kernel developers' position on GPLv3
The Dangers and Problems with GPLv3
James E.J. Bottomley Mauro Carvalho Chehab Thomas Gleixner Christoph Hellwig Dave Jones Greg Kroah-Hartman Tony Luck Andrew Morton Trond Myklebust David Woodhouse
Abstract
This document is a position statement on the GNU General Public License version 3 (in its current Draft 2 form) and its surrounding process issued by some of the Maintainers of the Linux Kernel speaking purely in their role as kernel maintainers. In no regard should any opinion expressed herein be construed to represent the views of any entities employing or being associated with any of the authors.
1 Linux and GPLv2
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. However, it certainly wasn't the first such open source operating system and neither is it currently the only such operating system. We believe that the pre-eminent success of Linux owes a great part to the dynamism and diversity of its community of contributors, and that one of the catalysts for creating and maintaining this community is the development contract as expressed by GPLv2.
Since GPLv2 has served us so well for so long, and since it is the foundation of our developer contract which has helped propel Linux to the successes it enjoys today, we are extremely reluctant to contemplate tampering with that licence except as bug fixes to correct exposed problems or updates counter imminent dangers. So far, in the whole history of GPLv2, including notable successes both injunctively and at trial, we have not found any bugs significant enough to warrant such corrections.
2 Linux, the Kernel and the Open Source Universe
Linux Distributions, as the Free Software Foundation (FSF) has often observed, don't only contain the kernel; they are composed of a distribution of disparate open source components of which the kernel is only a part (albeit a significant and indispensable part) which collectively make up a useful and usable system. Thus, Linux as installed by the end user, is critically dependent on entities, known as distributions, who collect all of the necessary components together and deliver them in a tested, stable form. The vast proliferation of Open Source Licences complicates the job of these distributions and forces them to spend time checking and assessing the ramifications of combining software packages distributed under different (and often mutually incompatible) licences--indeed, sometimes licensing consideration will be sufficient to exclude a potential package from a distribution altogether.
In deference to the critical role of distributions, we regard reducing the Open Source licensing profusion as a primary objective. GPLv2 has played an important role in moving towards this objective by becoming the dominant Licence in the space today, making it possible to put together a Linux Distribution from entirely GPLv2 components and thus simplify the life of a distributor. Therefore, we believe that any update to GPLv2 must be so compelling as to cause all projects currently licensed under it to switch as expediently as possible and thus not fragment the currently unified GPLv2 licensed ecosystem.
3 Linux and Freedom
Another of the planks of Linux's success rests squarely on the breadth and diversity of its community of contributors and users, without whom we wouldn't have the steady stream of innovation which drives our movement forward. However, an essential element of this is the fact that 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. This in turn is brought about by a peculiar freedom enshrined in the developer contract as represented by GPLv2, namely 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.
4 Pivotal Role of the Free Software Foundation
We have acknowledged before, projects controlled by the FSF (especially gcc, binutils and glibc) are essential components of every shipping Linux distribution. However, we also take note of the fact that the FSF operates very differently from Linux in that it requires assignment of copyright from each and every one of the thousands of contributors to its code base. These contributions have been given to the FSF not as a tribute to do with as it will but under a solemn trust, as stated in article 9 of GPLv2, only to licence the code under versions of the GPL that "... will be similar in spirit to the present version". We, like all the individual contributors to GNU projects, have taken that trust at face value and accorded the FSF a special role in the Open Source Universe because of it. It goes without saying that any updates to GPLv2 must be completely in accord with the execution of that trust.
5 GPLv3 and the Process to Date
The current version (Discussion Draft 2) of GPLv3 on first reading fails the necessity test of section 1 on the grounds that there's no substantial and identified problem with GPLv2 that it is trying to solve.
However, a deeper reading reveals several other problems with the current FSF draft:
5.1 DRM Clauses
Also referred to as the "Tivoisation" clauses.
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 forbids us from ever accepting any licence which contains end use restrictions. The existence of DRM abuse is no excuse for curtailing freedoms.
Further, the FSF's attempts at drafting and re-drafting these provisions have shown them to be a nasty minefield which keeps ensnaring innocent and beneficial uses of encryption and DRM technologies so, on such demonstrated pragmatic ground, these clauses are likewise dangerous and difficult to get right and should have no place in a well drafted update to GPLv2.
Finally, we recognise that defining what constitutes DRM abuse is essentially political in nature and as such, while we may argue forcefully for our political opinions, we may not suborn or coerce others to go along with them. Therefore, attempting to write these type of restrictions into GPLv3 and then relicense all FSF code under it is tantamount to co-opting the work of all prior contributions into the service of the FSF's political ends, and thus represents a fundamental violation of the trust outlined in section 4.
5.2 Additional Restrictions Clause
As we stated in section 2 one of the serious issues in Open Source is too many licences. The additional restrictions section in the current draft makes GPLv3 a pick and choose soup of possible restrictions which is going to be a nightmare for our distributions to sort out legally and get right. Thus, it represents a significant and unacceptable retrograde step over GPLv2 and its no additional restrictions clause.
Further, the additional restrictions create the possibility of fragmentation of the licensing universes among particular chosen restrictions, which then become difficult to combine and distribute (because of the need for keeping track of the separate restrictions). Thus, we think this potential for fragmentation will completely eliminate the needed compulsion to move quickly to a new licence as outlined in section 2
5.3 Patents Provisions
As drafted, this currently looks like it would potentially jeopardise the entire patent portfolio of a company simply by the act of placing a GPLv3 licensed programme on their website. Since the Linux software ecosystem relies on these type of contributions from companies who have lawyers who will take the broadest possible interpretation when assessing liability, we find this clause unacceptable because of the chilling effect it will have on the necessary corporate input to our innovation stream.
Further, some companies who also act as current distributors of Linux have significant patent portfolios; thus this clause represents another barrier to their distributing Linux and as such is unacceptable under section 2 because of the critical reliance our ecosystem has on these distributions.
6 Conclusions
The three key objections noted in section 5 are individually and collectively sufficient reason for us to reject the current licence proposal. However, we also note that the current draft with each of the unacceptable provisions stripped out completely represents at best marginal value over the tested and proven GPLv2. Therefore, as far as we are concerned (and insofar as we control subsystems of the kernel) we cannot foresee any drafts of GPLv3 coming out of the current drafting process that would prove acceptable to us as a licence to move the current Linux Kernel to.
Further, since the FSF is proposing to shift all of its projects to
GPLv3 and apply pressure to every other GPL licensed project to move, we
foresee the release of GPLv3 portends the Balkanisation of the entire Open
Source Universe upon which we rely. This Balkanisation, which will be
manifested by distributions being forced to fork various packages in order
to get consistent licences, has the potential to inflict massive collateral
damage upon our entire ecosystem and jeopardise the very utility and
survival of Open Source. Since we can see nothing of sufficient value in
the current drafts of the GPLv3 to justify this terrible cost, we can only
assume the FSF is unaware of the current potential for disaster of the
course on which is has embarked. Therefore, we implore the FSF to
re-examine the consequences of its actions and to abandon the current GPLv3
process before it becomes too late.
(Log in to post comments)
Kernel developers' position on GPLv3
Posted Sep 22, 2006 16:15 UTC (Fri) by Jel (guest, #22988) [Link]
This is great news. Maybe now people will start contributing more to projects that really valuesoftware freedom, like HURD :)
Re: Kernel developers' position on GPLv3
Posted Sep 23, 2006 4:10 UTC (Sat) by Jel_I_am_disappointed (guest, #40692) [Link]
This is great news. Maybe now people will start contributing only to projects that really valuetechnical merit over politics, like Linux :)
Re: Kernel developers' position on GPLv3
Posted Sep 23, 2006 6:00 UTC (Sat) by mingo (subscriber, #31122) [Link]
(Disclaimer: as a Linux kernel contributor i voted and had input into the document.)Agreed. One thing that made Linux so successful (over other GPL-licensed OS projects like Hurd): we do as little politics as possible. Even BSD OSs do more internal politics than the Linux kernel community. That is a fundamental strength that we must protect.
Is DRM evil? Yes and no - DRM is a tool and a tool can be used in good, in evil and in neutral ways, so the answer is: it depends. Such "it depends" moral scenarios we must avoid to "categorize" at all costs, because a forced, hard good/evil (no middle ground, no circumstances) definition written into the license inevitably opens Pandora's box. (The many existing iterations of the DRM section in existing GPLv3 drafts show how hard it is already to get it right to properly cover most of the existing, good FOSS projects.)
And there are more questions that need to be answered: is DRM used in support of the Bible good or evil? Is DRM used in support of Islam good or evil? Is DRM used in support of abortion good or evil? Is DRM used against abortion good or evil? Is DRM used in Pakistan's atomic bombs good or evil? Is DRM used in the USA's atomic bombs good or evil? Is DRM used to enforce movie producer's rights good or evil? Is DRM used to enforce the rights we have under the GPL good or evil?
Lets face it: some of these questions are really hard to answer, and the answer may very much depend on your political and religious viewpoint. Trying to tailor a license to the many moral viewpoints that do exist is futility, because there is no "middle ground" that everyone (or even the majority) would accept. Hence the only practical solution is, even if you dont subscribe to this concept: dont try to dictate the moral decisions of others.
Also, there is no real practical problem we are faced with. We are techies and as such we like to worry about DRM, patents, binary-only modules and alot of other things, but lets recognize that the GPLv2 already gives enough moral and legal background for people to build a community and great free software around - and people are already giving back much, much more to Linux and FOSS than the GPL forces us to do.
Where does the GPL force people to write documentation? Where does the GPL force people to support FOSS? Where does the GPL force people to write and improve FOSS to begin with? It does not. The GPL is only about keeping the source open, not about forcing our moral viewpoint on others. The moment we try to force people they will do less for FOSS, not more.
In fact, trying to dictate the morals of people, like the GPLv3 i believe does (by suggesting that DRM is fundamentally evil), can be considered immoral in itself. This might sound like nitpicking, but on a conceptual level it is a huge issue, and a license i subscribe to must be on the moral high ground to the last letter. Please think about it, we did that too.
Will there be leeches who only take and dont give back? Yes, of course, there always were and there always will be leeches. If leeching turns into outright abuse the GPLv2 has already been enforced to protect our fundamental interests. So we must be very careful to not let our natural worry to "fight" leeches get overboard and damage the very foundation our community is built upon: freedom and fairness.
Re: Kernel developers' position on GPLv3
Posted Sep 23, 2006 9:42 UTC (Sat) by bug1 (guest, #7097) [Link]
"The moment we try to force people they will do less for FOSS, not more"
Would you prefer Linux (the kernel) be under a BSD license then ?
I believe forcing people to "do the right thing" sets a standard of behaviour that is required to isolate freeloaders and develop teamwork/community.
Cosntructive criticism is usefull, and its good to clarify your objections like this, but Linux made its decsion many years ago when it excluded the "or later" clause. If GPLv3 was everything you wanted you still couldnt switch to it due to practical reasons of getting everyones permission.
Re: Kernel developers' position on GPLv3
Posted Sep 23, 2006 11:56 UTC (Sat) by mingo (subscriber, #31122) [Link]
Would you prefer Linux (the kernel) be under a BSD license then?not all. I would not contribute to the Linux kernel if it were under the BSD license. As i said in my comment, the GPLv2 gives a fabric of freedom and fairness:
[...] the GPLv2 already gives enough moral and legal background for people to build a community and great free software around - and people are already giving back much, much more to Linux and FOSS than the GPL forces us to do.
In my opinion the BSD license does not achieve that.
Ingo
Re: Kernel developers' position on GPLv3
Posted Sep 23, 2006 12:55 UTC (Sat) by man_ls (guest, #15091) [Link]
people are already giving back much, much more to Linux and FOSS than the GPL forces us to do. [...] In my opinion the BSD license does not achieve that.It is quite unfair to say that. Have you seen the wealth and breadth of documentation available for FreeBSD, OpenBSD or NetBSD (in many cases much better than for Linux)? The number of contributors for the many Apache packages? Or the SubVersion manuals? PostgreSQL documentation? I wish all GPL-licensed programs were so good in these respects.
No, the crux of the matter lies elsewhere; not in volunteer contributions, but in corporate contributions and sponsorship. Companies must justify their contributions, and a BSD-style license lets them get away with keeping them secret.
Re: Kernel developers' position on GPLv3
Posted Sep 23, 2006 9:44 UTC (Sat) by k8to (guest, #15413) [Link]
This is some weird stuff. The gist of this argument seems to be that therequirement in the GPLv2 that you share your changes, and that you also
share the other code you link with the GPLv2 code is a neutral
requirement. Meanwhile you seem to claim that the requirement that you
allow end users to modify the code for its primary use to be a moral
and/or political requirement.
How are these two different requirements substantially different that one
is neutral and the other is strongly politicized?
Personally I believe you (and others) have simply absorbed the first
requirement, while the other is new, and so the one seems neutral because
it is not a change, while the other is not-neutral because it is a
change. That doesn't really make one political and the other not. Feel
free to point out my error.
Re: Kernel developers' position on GPLv3
Posted Sep 23, 2006 13:26 UTC (Sat) by mingo (subscriber, #31122) [Link]
The gist of this argument seems to be that the requirement in the GPLv2 that you share your changes, and that you also share the other code you link with the GPLv2 code is a neutral requirement. Meanwhile you seem to claim that the requirement that you allow end users to modify the code for its primary use to be a moral and/or political requirement.The fundamental flaw in this argument is that you are somehow believing that "the requirement that you allow end users to run modified code" is universal and applies to all hardware that ships GPL-ed code.
Reality is that every piece of hardware on this planet has one or another end-user restriction. Every single one. Just try a simple experiment: take a GPL-ed piece of software that has a 100MB static array in it, "modify" that code to have a 1GB static array and try to run it on a 128MB RAM swapless system. It wont run, and it's the hardware that keeps you from running that modified code. Hey, the hardware maker cheated me! He does not allow me to run modified code! And the hardware maker could fix this situation easily: he should send me another 900MB of RAM, nobody forced that hardware maker to use GPL-ed code!
(At this point you'll probably say "but those are cases where it's impossible for the vendor too to run that modified code". But - your argument was that the GPL always allowed people to run arbitrary modified code, wasnt it? So (if you like logical arguments like me) you'll have to abandon your argument of "unconditional right to run modified software" which right does not exist because it cannot exist, and you'll have to qualify the way how end-users are limited by hardware. And such "judging" of hardware technologies, whether a given method of limiting end-users is "moral", "immoral" or "neutral" is what i believe to be 1) fundamentally immoral 2) none of our business, because we did not create that hardware.
So the "run modified code" statement only (and obviously) applies to hardware that allows you to run the code you modified. And the answer to that, if you cannot run it on the hardware that came with that GPLed piece of software: buy the right hardware! It's easy: you got the source code.
Once you accept the fundamental fact that no hardware exists that can run arbitrary modified code, you'll see why we think how unrealistic the interpretation is that "the GPL always said that all hardware that runs GPLed code must be able to run modified versions of that GPLed code". You'll also understand why we think that trying to control how hardware designers shape end-user limitations is immoral, because it uses the licensing power we have (and which power was paid for and bought by the RIAAs and MPAAs of this world) to "reach out" into a creative work that we did not write (the hardware), in potentially immoral ways.
And even if i supported an "eye for eye" position (the MPAA is trying to reach out into my creative work so i'm trying to "hit back" [which the MPAA would laugh about - they are only happy about small fish like us voluntarily excluding themselves from their market]), which i dont, it is fundamentally hard (for the reasons i outlined) to judge the "morality" of a given method of end-user limitation, because it is a deeply political and religious thing to do.
Furthermore, the GPLv2 clearly states, in Section 0, that it does not limit end-users:
The act of running the Program is not restricted [...]
And the only way the GPLv3 can "reach out" into hardware, via the vast copyright power that creators of works enjoy these days, is by using that power to limit end-users! Note how the GPLv3 removes the above crutial statement from the GPLv2. Such limiting of end-users via the license i consider to be fundamentally against the spirit of the GPLv2 outlined in Section 0. Using an immoral method to fight an immoral enemy does not make that method moral. It just sinks us to their level. I know it is hard to do, but we must not compromise on our moral high ground.
(We programmers really love to worry too much. We worry because it is our job to worry alot: programs can and do break in unexpected places, so a healthy bit of paranoia is welcome and useful, and the best programmers always expect the unexpected and consider every possible and impossible scenario. But we should not allow this natural tendency to worry let us do bad long-term decisions in licensing matters. FOSS is alot stronger today than the minimum strength the GPL enforces and the "enemy" is alot weaker than we like to think. Just look at how Apple managed to break the RIAA in 2-3 years: they created the iPod that people quickly learned to love /more/ than they love their music. That's how badness should be fought: by creating something that people like. And i strongly believe FOSS can do alot better than old-school Apple. We should just not let us defeat ourselves by damaging the foundation FOSS is built upon: freedom and fairness.)
Re: Kernel developers' position on GPLv3
Posted Sep 23, 2006 17:06 UTC (Sat) by k8to (guest, #15413) [Link]
Now you seem to be arguing that some irresolvable restrictions on useexist, and that therefore it is unreasaonble to consider some classes of
arbitrary additional restrictions on end user freedom.
There are also fundamental unresolvable restrictions on where one can run
free software that ships in source form without hardware that the GPLv2
cannot address, but yet it attempts to ensure that the end-user freedom
to modify and run that code exist without additional arbitrary
restrictions.
Again, they seem completely in parallel.
DRM is not evil, just useless.
Posted Sep 23, 2006 10:25 UTC (Sat) by hummassa (guest, #307) [Link]
And I have a hacked PlayStation Portable to prove. ;-)But I had to wait one year 'till I could install any software _I_ wanted
in _my_ PSP. And that is evil... so, it's not DRM that is intrinsically
evil, but TiVo-ization is. The revised GPL3 draft, IMHO, is not anti-DRM,
but only anti-TiVo-ization. I can't believe it doesn't make _any_ kernel
developer really angry to think that if you buy a TiVo and download the
source code to it, you _can't_ hack the source code and install on _your_
TiVo, just because _you_ don't have the cryptographic key to install your
software on your TiVo.
So, in my opinion, the TiVo-ization thing is not a DRM thing, but a way of
closing a loophole in GPLv2; it states that you can't add restrictions to
the license, but the TiVo-ization does just that: adds restrictions to
what the end user can do with the otherwise GPLd software.
HTH,
DRM is not evil, just useless.
Posted Sep 23, 2006 11:34 UTC (Sat) by JakeG (guest, #40696) [Link]
So, do you support people using whatever radio frequency they want including unlicensed ones?
Or are you one of those saying people should be allowed to shoot anyone just because they have a legal gun?
DRM is not evil, just useless.
Posted Sep 23, 2006 11:46 UTC (Sat) by JakeG (guest, #40696) [Link]
...and you know where that leads? Banning or guns.
Or technologies used to circumvent copyright. Essentially a GPLv3 Linux could be considered a tool that helps break the law, even if it's legal.
By the way, if you want to run your own code on your own hardware, they buy hardware that allows it. Fortunately there is still this so called free market economy we have. So vote with your feet.
vote with more than your feet
Posted Sep 24, 2006 23:51 UTC (Sun) by coriordan (guest, #7544) [Link]
Voting with your feet is not enough. Purchasing preference is not the only interaction we have in the free market, there is also participation. The options presented to us in the market are simply not granular enough for us to use preferences as a method of economically controlling the suppliers.
In 1983, when it was not possible to run a computer with only free software, instead of lobbying government or campaigning against proprietary software companies, Stallman participated in the free market by writing software and licensing it in a way that would give recipients some useful freedoms.
Back then, the problem was that software was being distributed as binary blobs. So GPLv2 said that distributing the source was required. Today, a new problem is rigging computers to require keys, so GPLv3 will say that if this is done, distributing a suitable key is required.
DRM and public benefit.
Posted Sep 23, 2006 12:50 UTC (Sat) by man_ls (guest, #15091) [Link]
Hacking your PSP does not harm others; it just makes a device more useful. Sony will tell you that it causes infinite harm to poor games programmers and their families, blah blah, but it is just an inference; it could be that unlicensed distribution boosts sales, as it has happened in some sectors of the music or the computer industries.On the other hand causing interference to others can directly harm others. There is a distinct public benefit in spectrum regulation, even if it can be abused for private gains. Likewise with weapon regulations. Comparing these things with DRM is fallacious and irresponsible, and a bit sad too.
DRM and public benefit.
Posted Sep 23, 2006 18:32 UTC (Sat) by sepreece (guest, #19270) [Link]
You are completely free to hack your PSP, if you can figure out how. That's completely separate from whether the manufacturer should be required to make it easy, tell you how, or guarantee that it will keep working if you do.
If you don't like the restrictions in the device, don't buy it.
DRM and public benefit.
Posted Sep 24, 2006 7:03 UTC (Sun) by man_ls (guest, #15091) [Link]
I am not free to hack it, not in USA and not in Europe.If you don't like the restrictions in the device, don't buy it.Thanks for your interest. Can I at least complain?
DRM and public benefit.
Posted Sep 25, 2006 9:23 UTC (Mon) by cate (subscriber, #1359) [Link]
????Copyright law now applies also to hardwares?
You can have license to use software, but you own the hardware.
IANAL, but I think in most countries the "buy" action implies ownership of hardware. (ownership don't implies ownership of "IP" (patents). Software licenses are a special case in copyright laws, but I don't know any special case for hardware devices.
But naturally you should follow the national law, i.e. norm for electric appliances (if you plug the console), radio frequencies (if you emit o receive data) etc. And naturally the new hardware should not be a bomb, or a dangerous item (but considering the newer exploding laptops, this maybe is an outdated norm).
DRM and public benefit.
Posted Sep 25, 2006 10:18 UTC (Mon) by man_ls (guest, #15091) [Link]
Please follow the links provided. US Code, title 17, chapter 12, para 1201:No person shall circumvent a technological measure that effectively controls access to a work protected under this title.And similarly (but convolutedly) in the EU law:
there is a need to provide for harmonised legal protection against circumvention of effective technological measures and against provision of devices and products or services to this effect.So yes, copyright law applies to hardware. DRM is a "technological measure" according to both laws; if DRM is implemented in hardware, e.g. with a TPM, then you should not circumvent it by modifying the hardware.
DRM and public benefit.
Posted Sep 25, 2006 14:24 UTC (Mon) by sepreece (guest, #19270) [Link]
"I am not free to hack it, not in USA and not in Europe."
Sorry, I had said elsewhere that the right place to fight for a right to hack is in the legal system. I completely agree that DMCA and similar laws should not have been instituted.
However, I would also not support a law that said "Users must be able to modify all devices" or "Users must be able to update the firmware in all devices". That should be a market issue, not a legal issue.
DRM and public benefit.
Posted Sep 25, 2006 21:26 UTC (Mon) by man_ls (guest, #15091) [Link]
However, I would also not support a law that said "Users must be able to modify all devices" or "Users must be able to update the firmware in all devices". That should be a market issue, not a legal issue.Nobody has asked for such a law. Remember that in this article we were originally talking about how GPLv3 does not allow such things as copyright protection measures. That is not a law; it is a license, and in a sense it is a market issue: if you don't like it, go somewhere else to get your code. So I guess we agree on this point.
DRM is not evil, just useless.
Posted Sep 23, 2006 23:33 UTC (Sat) by Arker (guest, #14205) [Link]
Tweaking your radio signals could cause actual harm, and the person that did it would be liable for that. That doesn't mean you can't distribute radios just because they can be modified inappropriately. And they all can be.
DRM is not evil, just useless.
Posted Sep 26, 2006 23:31 UTC (Tue) by Ross (guest, #4065) [Link]
That currently affects any open source driver, BSD, GPLv2, or GPLv3. Is the correct solution to have a layer of DRM and only allow drivers signed by the vendor? Obviously not as that prevents any end-user modification, not just restricting the frequency range.
I really have a difficult time thinking of any reasonable uses of DRM.
The fundamental problem occurs when it is applied to GPLed software. DRM, like the DMCA, tries to tack on extra rights for the copyright holder, yet the license is written based on the idea that the user has the right to modify code as much as they want under copyright law. Maybe the GPLv3 changes aren't following the right approach, but this isn't something which can be safely ignored.
DRM _is_ evil
Posted Jan 20, 2007 17:59 UTC (Sat) by ArneBab (guest, #42896) [Link]
I support the police and the law stopping people from shooting otherpeople or using unlicensed radio frequencies.
But I don't support technology forcing me not to shoot people or not to
use unlicensed radio frequencies, because it is not for the
technology-producer to decide, what I _can_ do with a device.
There might be a day, where I have to use an unlicensed frequency for a
higher cause, for example using my radio-transmitter to contact the police
in an emergency, when there is no phone at hand, and doing so, I take
responsibility for my action and it is only for a court to decide if I did
right or wrong.
If I save three hundred people by illegally shooting the terrorist with my
legal gun, then I might still run into problems because I killed a person,
but a court might well rule it good action and let me get away with a
fine.
Only because a device seems to have only certain good uses, it doesn't
mean there is never a moment where I might have to use a device for
something for which it wasn't originally intended.
And DRM doesn't have an override button.
The only ones who may keep me from acting freely are the police and other
state-employees, whom I gave my vote to serve _me_ that way.
A company never has that right, at least not morally and not in _my
domain_ (my computer).
DRM is not evil, just useless.
Posted Sep 23, 2006 14:16 UTC (Sat) by mingo (subscriber, #31122) [Link]
DRM is not evil, just useless.yeah, in many cases that is very much true. But stupidity we should punish with our good judgement and with our feet, not with our "machine gun": the license. Also, it might sound nitpicking, but it is not actually immoral for a hardware maker to be stupid. If a hardware maker excludes itself from the enthusiast market for no good reason, it's their stupidity (and it's their financial loss in the end).
(And we should really let the hardware designers decide. While i have a problem with monopolies doing DRM or DRM being utilized to hide GPL violations, I have no problems with DRM if for example the hardware is a laser toy for children and DRM is used to not allow above-spec voltage to be delivered to the laser diodes.)
DRM is not evil, just useless.
Posted Sep 23, 2006 19:44 UTC (Sat) by obi (guest, #5784) [Link]
Even though I mostly agree with the kernel devs side (complying with the GPL means a "god-given right to source" not a "god-given right to use it on any hardware") - I'd still take issue with "punishing with our feet".
What if all options or alternatives are equally bad, or the good ones start using DRM and "stupid" techniques because the "bad" ones get away with it. The only option we might be left with is to not use any of the alternatives - and even that might not be an option.
Case in point, we used to have quite a few options when it came to graphic cards. There was Matrox, ATI, 3dfx, and others for which you could get open drivers. These days, if you're looking for a graphic card you have no real alternatives. I need a desktop graphics card to do my job. Which one do I choose to "vote with my feet" or even "punish with my feet" - as you put it?
(By the way, I'm not saying nvidia or ATI are doing anything illegal, because after all, they don't distribute Linux with their drivers, they leave the home user to do the dirty deed - not illegal)
With DRM you might eventually get to a situation where there's no non-drm'ed hardware found any more. In a situation like that, there's little point to Free or Open Source software any more. So yes, GPLv3 is a "political" tool to stop such a situation from happening, but GPLv2 was politics too, and imho Linux clearly had benefit from the fact that GPLv2 was a political tool.
I'm not saying GPLv3 is the answer, or that DRM clauses are the right solution, but I do feel like it deserves more than blanket statements and knee-jerk reactions. From an outsider, it seems like the kernel devs haven't really put a lot of effort in participating in the GPLv3 process (which probably has plenty of flaws, but the process is made by the ones contributing to it)
DRM is not evil, just useless.
Posted Sep 25, 2006 6:22 UTC (Mon) by mst@mellanox.co.il (guest, #27097) [Link]
> These days, if you're looking for a graphic card you have no real> alternatives. I need a desktop graphics card to do my job. Which one do I
> choose to "vote with my feet" or even "punish with my feet" - as you put it?
Consider an Intel graphics card. Running quite well on my Lenovo T60,
with 2.6.18 and no binary drivers.
DRM is not evil, just useless.
Posted Sep 26, 2006 22:15 UTC (Tue) by obi (guest, #5784) [Link]
Well, that's great if you have a laptop, you don't care about good performance, and you don't care about the binary-only intel_hal.so that includes things like macrovision.
If you need a PCI-express card, need to drive multiple screens, can't find one of those mini-DVI cards that plug into your embedded motherboard that of course doesn't come with DVI, or need a bit better performance, you're out of luck.
Even though intel graphics are an alternative, for which I'm really happy and that I really am going to support, it's not always (or even most cases) a viable option.
So punishing with my feet is still hard.
graphics cards
Posted Sep 25, 2006 14:59 UTC (Mon) by mingo (subscriber, #31122) [Link]
I need a desktop graphics card to do my job. Which one do I choose to "vote with my feet" or even "punish with my feet" - as you put it?i'm using ATI cards with free drivers, or Intel cards. Intel has caught up recently and has put their whole 3D stack under the GPL, see: Intel Linux Graphics . ORG.
graphics cards
Posted Sep 26, 2006 22:28 UTC (Tue) by obi (guest, #5784) [Link]
With ATI the best you can do is an X850, which is in theory still supported with the relatively new R300 driver. I've got a number of R200 and R300-class hardware, but when I look around to replace these there's very little options available to me.
Well, maybe I'm a bit impatient - maybe there will be an effort to reverse-engineer the latest generations too.
However, the question was which manufacturer do I reward for being a good open-specs or open-driver citizen. Considering there's an R300 driver in spite of ATI, not thanks to ATI, I find it hard to justify sending cash their way.
ATI, 3dfx, Matrox and others used to be good, now they're not anymore. Intel is the only "good" one (minus a few tiny niggles), and one I'd recommend in a flash provided they have a graphics product that sort of matches your needs, however it often doesn't.
(I refer to my other post on intel graphics here: http://lwn.net/Articles/201235/ )
Re: Kernel developers' position on GPLv3
Posted Sep 23, 2006 12:21 UTC (Sat) by jeroen (guest, #12372) [Link]
GPLv3 doesn't force anyone anything as much as the GPLv2 does. If you don't like the terms, you don't have to use the software. Write your own software. But I don't want that people use the software I write for things I don't like, such as using it a tivo-like system.
That DRM is a tool is correct, but the GPLv3 doesn't go against DRM. It goes against companies who sell DRM systems without giving users the keys to modify the software on the system. That's an use of DRM that I consider evil. And of course I would like to prevent people doing that with my software.
And how many iteration did the linking clause in the GPLv2 have? We don't know, because AFAIK the drafts were never public. Maybe there have been ten or twenty. Does that make it a bad clause? I don't think so. Linux also needed several rewrites of the packet filtering framework to get it right. Does that make packet filtering a bad thing? I don't think os. The fact that something is hard to get right isn't an argument for not doing it.
The linking clause is also not tailored to the many moral viewpoints that exist, if you listen to the BSD camp. Is that a reason to remove the linking clause of the GPL?
If you would actually think about the hypothetical situation of the GPLv2 not yet existing and then evaluating the GPLv2 according to the same criteria as being done here on the GPLv3, the result would be that GPLv2 is a bad license too. It tries to dictate morals on other people (the moral of that you should give users the freedom to hack their software), there exists many moral viewpoints about it and it is hard to get right.
Re: Kernel developers' position on GPLv3
Posted Sep 23, 2006 13:45 UTC (Sat) by mingo (subscriber, #31122) [Link]
That DRM is a tool is correct, but the GPLv3 doesn't go against DRM.i used to buy this (relatively new) line of the FSF, but then i read the actual text of the GPLv3 draft, which in Section 1 says:
The Corresponding Source also includes any encryption or authorization keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances.
this attaches keys to the source, fundamentally. And since we all agree that modified source must be given out, the keys have to be given out too. The GPLv3 draft does carve out a few exceptions in later sections, but the damage has already been done here in Section 1: by attaching keys to the source we implicitly and explicitly judge the tool of hiding keys to be immoral! (because by hiding it you are "not giving out the modified source code")
if this "we attach keys to the source" definition in Section 1 is removed then all the DRM problems are solved - no need for the later exceptions either. This portion of section 1 is the big problem.
(Sidenote: this new "we dont go against DRM" position of the FSF is quite inconsistent with earlier positions they took - which questions whether they truly consider this whole issue so fundamental that no compromises are possible)
Re: Kernel developers' position on GPLv3
Posted Sep 23, 2006 14:50 UTC (Sat) by mattmelton (guest, #34842) [Link]
I'm trying to guage your view here mingo...Assuming there is a product called the MattRouter 2.2b. A Tivo'ized network router running Linux 2.6.
Would something along the lines of,
"The Corresponding Source also includes the ability to be executed, modified and installed in the recommended or principal context of use, such that it can implement all of the same functionality in the same range of circumstances"
be more up your street?
To me, such a change would mean proprietory uploaders and bootloader-compilers would have to be included with the source. These uploaders (etc) can implement the DRM provisions (such as encryption) before they are copied to ROM.
As long as I had the indirect ability to fulfill "the recommended or principal context of use, such that it can implement all of the same functionality" from source, I'd be happy.
... that is, if your agrument rests on the provision of keys alone.
GPLv3 DRM clause
Posted Sep 23, 2006 15:33 UTC (Sat) by jeroen (guest, #12372) [Link]
The whole DRM section is just a natural evolution of the GPL. But to understand that you've to look where the whole GPL is about. That's the freedom of the user.
To give an example: when I bought my wireless router that was running Linux I had the freedom to replace the firmware with my own version of Linux. I'm glad I was possible to do that, because now I've got nice set of iptables rules, QoS, etc. on it. But what if they suddenly decied that it is required that the firmware image was signed (like Tivo does)? Then I would be able to get the code, but I wouldn't be able to patch it and put it on my router. So they took away my freedom to run my own code on the router. This is what I consider immoral. It also clearly goes against the spirit of the GPL.
So what does the GPLv3 do against this? It requires that if you sell a device that requires a signature to upload firmware, the user should be able to generate that signature too, so that he is able to exercise his freedom to change the software running on his device. But this doesn't prevent a company that buys some of those devices to keep the signing keys in a safe place so that random employees can't flash the device with untested firmware or malicous people can't put a firmware with trojans on it. So the DRM functionality is still there, it just can't be used against the purchaser of the device.
If you have the opinion that users should have the right to fix bugs in their software, then you should actually like this clause. And even if you don't agree with that, I don't see any reason why you would have a problem with it. I haven't seen any arguments against it yet, except the bogus statement that you're forced to give away all your private keys.
I also didn't claim that the FSF isn't going against DRM. They clearly are, because they have the opinion that the tool itself is bad, and I agree with that (just like I think that tools like nuclear weapons are bad). But the GPLv3 itself isn't really going against DRM, only against the use of DRM to circumvent the GPL.
GPLv3 DRM clause
Posted Sep 23, 2006 20:25 UTC (Sat) by mingo (subscriber, #31122) [Link]
To give an example: when I bought my wireless router that was running Linux I had the freedom to replace the firmware with my own version of Linux. I'm glad I was possible to do that, because now I've got nice set of iptables rules, QoS, etc. on it. But what if they suddenly decied that it is required that the firmware image was signed (like Tivo does)?the big, big problem with this argument is that: this is not what Tivo did. Tivo never made their PVR "hackable". They never "benefited" from hackability, they never cycled back improvements that happened via hackability - they at most found it an annoyance. Later on they have added a special bootloader to a new generation of boxes, which would only load an OS kernel signed by Tivo. There was no stealth 'DRM-ification' of existing Tivo boxes. Furthermore, all the source code and their modifications, along with binaries (that do load on a Tivo) are made available by Tivo, just as required by the GPL. Plus, you can probably still mod your Tivo by soldering off their BIOS and putting your own BIOS in. Furthermore, a Tivo very obviously does not look like a general purpose computer, it does not smell like one and does not play one on TV. It is made, marketed and sold as a PVR, with no guarantee whatsoever that it would even contain a single screw to allow you to open the lid.
So all this vilification of Tivo is totally misplaced in my opinion.
How Tivo benefitted from hackability
Posted Sep 24, 2006 23:21 UTC (Sun) by coriordan (guest, #7544) [Link]
The problem with Tivo is not that they did a stealth operation, but that they like Linux because it's hackable, and they benefit from the freedom to tinker the software (to make it do TV stuff and to add spyware to gather data about your use of your TV), but then they rig the device to prevent the downstream recipients from benefitting from this same freedom.
This contradicts the GPLv2 world. In the nineties, the GPL made all software users of GPL'd software interact as equals. Quid pro quo. Share and share alike, etc. Then Tivo found a technology which let them distribute GPL'd software without treating the recipient as an equal. So some words need to be added to GPLv2 to restore the deal that GPLv2 gave everyone in the nineties.
Bad, bad DRM
Posted Sep 23, 2006 15:35 UTC (Sat) by man_ls (guest, #15091) [Link]
I value your contributions (or what little of them I gather from LWN) a lot, but I think you are way off here. Allow me to take this opportunity and answer you point by point.One thing that made Linux so successful (over other GPL-licensed OS projects like Hurd): we do as little politics as possible.Other GPL-licensed projects (gcc, emacs) do a lot of politics and are wildly successful. The Hurd's failure probably is more of a technical thing. Linux's success probably has more to do with good leadership.
DRM is a tool and a tool can be used in good, in evil and in neutral ways, so the answer is: it depends.This moral relativism is good for some things; in particular, it works more or less for basic science. E.g. Richard Feynman used it to relieve his conscience in "What do you care what others think?"; the good professor had participated in the Manhattan Project, and then had to watch hundreds of thousands of people die because of his work, so it is understandable that he came up with this way of thinking. Is nuclear physics good or evil? It depends; it is a valid endeavour of the human mind, and there are good uses. It does not change that he thought the consequences were completely regretful.
This relativism does not work in other fields; most human tools have their purpose written upon them in neon letters. Are fingerprint-resistant automatic assault rifles good or evil? They are patently evil. Is the atomic bomb good or evil? They are devised to decimate whole cities; it is hard to see what good they can bring. Were the bombs dropped on Hiroshima and Nagasaki good or evil? They were utterly evil, and making them "the lesser of two huge evils" is not going to change that.
Is DRM good or evil? DRM limits what you can do with your digital devices for two purposes: imposing an artificial scarcity on digital media and therefore raising prices; complementarily, it is used to control said devices and limit what people can do with them. The laws to make them possible have proven many times to have unintended consequences, as professor Felten may tell you. DRM is eminently evil; it serves a bad purpose.
Is DRM used in support of abortion good or evil? [...] Is DRM used in the USA's atomic bombs good or evil?It is neither good nor evil; it is absurd. Are you going to lock down pro-life propaganda films? Will you prevent the victims of your atomic bombs from doing radioactivity readings on the fissionable material you throw upon them, by selling them only DRM-laden Geiger readers?
Lets face it: some of these questions are really hard to answerYes, but the reason is that they are too bizarre. In a similar vein, "are atomic bombs used to avoid third-world child cannibalism good or evil?" is hard to answer too.
Hence the only practical solution is, even if you dont subscribe to this concept: dont try to dictate the moral decisions of others.This is exactly what the GPLv2 tries to do: it tries to keep you honest by dictating some moral decisions. It does not force you to use GPL'd code; in fact it allows you to do a lot more than copyright law alone, which is almost nothing. But it sets some conditions, and when they are impossible to meet you are still free to go and get your code from somewhere else. Sometimes you can even purchase the same code with a different license. Still, if you use code under the GPL the decision of sharing modifications has been taken for you.
the GPLv2 already gives enough moral and legal background for people to build a community and great free software around - and people are already giving back much, much more to Linux and FOSS than the GPL forces us to do.As I stated above, BSD-style licenses do not force you to contribute, and many still have excellent code, documentation and support. This is not a good argument.
In fact, trying to dictate the morals of people, like the GPLv3 i believe does (by suggesting that DRM is fundamentally evil), can be considered immoral in itself.How come? The GPLv3 takes a position: restrictions on what software can do are evil. The GPLv2 is much the same: closed and locked-down code is evil and must be avoided. Since the only way to achieve DRM is through closed and locked-down code, it is no surprise that DRM is considered evil now; just a natural consequence.
So we must be very careful to not let our natural worry to "fight" leeches get overboard and damage the very foundation our community is built upon: freedom and fairness.I would rather say that the community is built upon a balance; the GPLv2 states some moral goals (the famous four freedoms), and then tries to balance your freedom with some restrictions in order to achieve these goals. The GPLv3 is no different. You can disagree with those goals, but talking about generic freedom and fairness will not change that.
You sound like people who have had their moral decisions taken for them and now enjoy the freedom others have gained; but cannot cope with new situations. I think it is time we all thought about these moral decisions for our own sake. It is not just about theoretical aspects; they are practical matters that arise every time we switch on our devices, which by the way look more like computers as time goes by. Do we want those computers to work for us, or for the manufacturer? Ingo, do you like the fact that your code is used in Tivo devices? Would you like to see your code power other locked-down devices? What good is the GPL then if you cannot hack on them?
GPL-ed projects and politics
Posted Sep 23, 2006 17:48 UTC (Sat) by mingo (subscriber, #31122) [Link]
Other GPL-licensed projects (gcc, emacs) do a lot of politics and are wildly successful.Maybe my different viewpoint comes partly from the fact that i'm right in the middle of these projects. The kernel has lots of dependencies on both gcc and glibc, so we follow them with great interest and we very much want those projects to succeed. Gcc has struggled for years (commercial compilers were leagues better) because it was developed in such a political way for a long time. When the egcs and pgcc projects threatened a hard fork it has been depoliticized and gcc got alot more contribution-centric, and it is in a much better technical shape now.
For glibc i suggest you read the following announcement from Ulrich Drepper (who has contributed most of the glibc code and who has been doing this for ~10 years), from August 2001. I'd suggest for you to scroll down to the section that starts with "And now for some not so nice things": glibc 2.2.4 announcement . (This was all of course eclipsed by the sad events of 9/11.)
This stuff definitely takes some digestion, and i dont expect you to take this from me at face value, because you do seem to (honestly) believe in the opposite, but doesnt it at least raise some doubt in you, which doubt would justify some more investigation and some more pondering?
GPL-ed projects and politics
Posted Sep 24, 2006 6:45 UTC (Sun) by man_ls (guest, #15091) [Link]
doesnt it at least raise some doubt in you, which doubt would justify some more investigation and some more pondering?Sure it does. In fact now that you say it I do not think that politics are that good in a software project. Still, there are times when people have to unite against really bad ideas.
GPL-ed projects and politics
Posted Sep 25, 2006 20:55 UTC (Mon) by k8to (guest, #15413) [Link]
Yes, Stallman can be a crazy nutter unwilling to accept outside input.Still, the response I am seeing from you and the other kernel devs is
similarly simplistic. Because Stallman does "politics" which are bad,
changing proposed by Stallman are "political".
If you don't believe in politics, argue against the new controls being
added to GPLv3 from a practical viewpoint.
If you _do_ believe in politics, argue against the new controls being
added to GPLv3 from a political viewpoint.
Simply calling them "politics" comes off as a refusal to address them at
all.
DRM good or evil?
Posted Sep 23, 2006 18:19 UTC (Sat) by mingo (subscriber, #31122) [Link]
I dont think i should get into the business of trying to determine what is good, evil or silly - but you did this work for me, so my only job is to point out possible inconsistencies in your categorization:most human tools have their purpose written upon them in neon letters. Are fingerprint-resistant automatic assault rifles good or evil? They are patently evil.
is it evil even if you found it on the street (honestly, some street gang left it there), and by accident you are attacked by a drunk maniac weilding an axe, who kills your dog with a single blow and now threatens to kill you, your wife and your son? So while i'd agree with you that the production of such a rifle is probably patently evil, actual use might still be considered "good", in special circumstances.
Is the atomic bomb good or evil? They are devised to decimate whole cities; it is hard to see what good they can bring.
Here again the answer is: "it depends". For example, which atomic bomb? The russian atomic bombs were never used against civilians, and they helped create a "balance of total mutual destruction", which resulted in no other atomic bombs being used after Hiroshima and Nagasaki. (although they were very much considered militarily) Were thus those, "defensive" atomic bombs "evil" too? Or did they save humanity from total destruction?
another question here: man would have figured out the a-bomb no matter what. If not the Manhatten project then some other effort. If you had the choice, and this discovery was inevitable, which country would you have picked to discover the atomic bomb? Nazi Germany? Communist China under the rule of Mao? The Soviet Union under the rule of Stalin? Or maybe the USA?
Were the bombs dropped on Hiroshima and Nagasaki good or evil? They were utterly evil, and making them "the lesser of two huge evils" is not going to change that.
Did they save 3-4 hundreds of thousands of american lives, at the "expense" of 200,000 japanese lives? By simple, cold-blooded extrapolation from the casualty figures of Osaka's assault, probably yes. Is it evil to pick the lesser of two incredible evils? The answer depends on your fate. The Christian religion will most likely say: "yes, it was incredibly evil, man must not kill, let God decide". Under other religions it could be considered "good".
I think even these scenarios - although you picked them - are alot less clear-cut than you suggest. The same goes for DRM. It's a tool, and its morality depends on intent and other circumstances, not on the tool itself. DRM was not invented today, it was in use for more than a decade in probably every desktop chip that you used - and the use of that type of DRM was considered totally good. (the Intel microcode upload mechanism is DRM.) DRM has also been in use in probably almost every ATM that you used in your life, for over a decade. For a totally valid and non-evil purpose too. I believe you only consider DRM "evil" because you are seeing it used for evil things in things like DVD players. But even there it's not the use of DRM that is evil, but the intent of that use: the content mafia wants to preserve its monopoly.
DRM good or evil?
Posted Sep 23, 2006 21:47 UTC (Sat) by dlang (guest, #313) [Link]
actually, I've seen some reports that Truman authorized the use of the atomic bomb only after receiving a report that showed that dropping the bomb was expected to cost fewer Japanese civilian lives then an invasion of Japan would (again based on the behavior of the japanese at okinawa).
if these reports are correct (and from what I know of Japan during that timeframe I tend to believe them) then the use of the Bombs qualify as definitivly Good, not Evil.
DRM good or evil?
Posted Sep 24, 2006 2:46 UTC (Sun) by ianji (guest, #40710) [Link]
The idea that atomic bombs were dropped on Hiroshima and Nagasaki in order to saves lives iswidely believed but not neccessarily true. I have also seen reports that the terms of the eventual
Japanese surrender were essentially the same terms that they had already conceded to before the
nuclear attacks, and that the US only turned them down earlier because they wanted the world to
see a demonstration of the power they posessed. For further reading check out "The Hiroshima
Myth" by John V. Denson (I haven't read it but I have read a fairly lengthy synopsis).
Arithmetic of death
Posted Sep 24, 2006 6:02 UTC (Sun) by man_ls (guest, #15091) [Link]
Suppose I tell you I've also seen some reports that Stalin only authorized those Gulags after receiving a report that leaving those people alive would only have costed many more lives (based on the behaviour of the Russians at the previous revolution). Does it make the Gulags more palatable? Is Stalin a humanitarian now?Also, imagine the report was not true. Maybe some guy in the military slipped it to Truman because he wanted to use his new toy. I tend to think that reports made during wartime are not very trusty, but what do I know.
I cannot avoid but think that those arithmetics of death are weak as a justification.
DRM good or evil?
Posted Sep 24, 2006 13:35 UTC (Sun) by drag (guest, #31333) [Link]
There is a huge political benifit for some people to vilify the American's use of nuclear weapons at the end of WW2. So be sure to know were your getting your information before you jump to conlusions.
---------------------
There are a few concrete things to keep in mind before making up your mind:
Based on historical evidance there is every sign that invading the Japanese homeland would of been horrific in terms of lives and damage to both sides of the war. The only time the U.S. engaged in a land conflict on traditionally Japanese territory (as per my understanding) was during the Battle of Okinawa.
Total casuality counts were 7,373 men killed and 32,056 wounded on the American side on land and another 5,000 killed and 4,600 wounded at sea.
(According to Wikipedia it's 12,500 dead and 32,000 wounded, total British and American )
On the Japanese side they had a estimated 130,000 troops stationed on the island. By the end of the battle they had 107,000 of them killed. With a possible another 20,000 killed, but completely incinerated and unaccounted for by the American's tatics of burning out the Japanese emplacements with flame throwers. (Wikipedia says it's 110,000 dead and 7,455 captured total). Typically soldiers would rush at Americans holding live grenades rather then surrendering.
Okinawa had a civilian population of about 450,000 people. Of that by the end of the battle (according to Wikipedia) they suffered at least 150,000 in terms of 'losses'. Much of it was from people simply killing themselves to avoid the 'American barbarians'.
In comparision with after effects and radiation poisoning taken into account there were about 213,000 people died as a direct result with both atomic bombings.
-----------------------------
From Truman's perspective I think the question was much more simple:
Invade Japan and expect U.S. militiary casualties numbering easily over a hundred thousand even if it turned out to be a short land war. (and easily several times that if Japanese decided to drag it out)
OR
Drop the bomb, end the war now, and loose nothing. No ships. No planes. No americans dead, wounded, or dying.
The correct course of action would of been pretty obvious during that time. I think that is the simpliest and most logical explaination as to realy why he dropped the bomb.. and most likely the correct one.
We were definately going to occupy Japan one way or another. There was no way the Americans were going to accept a conditional surrender. No way that they'd give Japan a chance to rebuild itself outside of their complete control. Just not going to happen anymore then they'd let Germany rebuild itself outside of their countrol.
The real delima historically, as I understand it, is Russia. The Russians would of been poised for invading Japan along with the U.S.. Weither or not Japanese would of allowed the Russian army to invade Japan before surrendering is the deciding factor on weither or not the Nuclear bombs were nessicary. There would of been a lot of rascism and ancestoral stuff going on between the Russians and Japanese. (meaning it would of sucked worse for the Japanese then it did for the Eastern European countries.) But to me this is only a question realy asked in hindsight as a historical debating point.
Would of Japan done a unconditional surrender to the Americans just based on the threat of having part of their country subject to Russian occuption? Maybe, I don't think the answer is very obvious (one way or another) and it was much less obvious in 1945. Germany didn't follow this path. The allies had to fight through the entire country until they destroyed the seat of government before the Germans surrendered. And even then after that there was resistance groups that fought against the occupation for years and years before they finally gave up.
As for scaring Russians with nuclear weapons.. a demostration on a small island would of been enough. I think that it's likely the display of weapons on the Japanese was hoped to leave a big impression the Russians, but that would of been a tertiary goal. Primary being to scare Japan to surrender, and secondary to reduce enemy resources if that didn't work.
German resistance AFTER WWII?
Posted Sep 25, 2006 13:24 UTC (Mon) by morhippo (guest, #334) [Link]
Never heard of it. AFAICS, the Germans very pretty docile once they had surrendered. Could you give me a source that there has been German resistance for years?
I am German and I have never heard of such a thing.
DRM good or evil?
Posted Sep 24, 2006 6:35 UTC (Sun) by man_ls (guest, #15091) [Link]
is it evil even if you found it on the street (honestly, some street gang left it there), and by accident you are attacked by a drunk maniac weilding an axe, who kills your dog with a single blow and now threatens to kill you, your wife and your son?What can I tell you, yes, it is evil but it can have some good uses. Not that leaving automatic assault rifles on the street is generally a good idea, with all those little kids running around and such, but if some responsible adult found it and a drunk maniac attacked said adult at the same time, it could have a good use, yes.
In my case I would probably kill the drunk maniac, the wife, the kid and some other pedestrians based on my lack of expertise. A simple, non-automatic weapon would be better. Now, before you advocate that "combat weapon training is a good thing in some situations", just give me a good old axe and make it even. After all the maniac is drunk and I am not.
Were thus those, "defensive" atomic bombs "evil" too? Or did they save humanity from total destruction?Total destruction from bombs from the other side? Yeah, really good bombs then.
If you had the choice, and this discovery was inevitable, which country would you have picked to discover the atomic bomb? Nazi Germany? Communist China under the rule of Mao? The Soviet Union under the rule of Stalin? Or maybe the USA?Doing simple extrapolation from casualty figures, I would answer "anyone but the USA". No other country has used it against humans. This is not some communist opinion, it is cold-blooded extrapolation.
DRM was not invented today, it was in use for more than a decade in probably every desktop chip that you used - and the use of that type of DRM was considered totally good. (the Intel microcode upload mechanism is DRM.)Ahem. It is most definitely not DRM. There are no "rights" there to manage at all. I think you are confusing encryption and trusted computing with DRM. According to the wikipedia, TC is "an enabler for DRM", but it is not the same. I do not think that TC is evil all the way, even if Stallman does.
I believe you only consider DRM "evil" because you are seeing it used for evil things in things like DVD players.I believe I consider DRM evil because it is the wrong solution to the wrong problem. First you have to make TC pervasive, then you have to lock down all computers all the way for DRM to work; in the process you must shut down all those pesky researchers, or any loophole will get exploited to death. Distribution of source code is not possible and deployment of new binaries is unthinkable.
When all music is locked down, it is the day that we go back to pre-CD-ROM days. We lose the convenience of digital music, and we lose fair use. So we probably stop buying music.
Bad, bad DRM
Posted Sep 23, 2006 18:40 UTC (Sat) by mingo (subscriber, #31122) [Link]
The GPLv2 is much the same: closed and locked-down code is evil and must be avoided. Since the only way to achieve DRM is through closed and locked-down code, it is no surprise that DRM is considered evil now; just a natural consequence.actually, that is not what DRM does. DRM is a method for hardware to only execute software from a "trusted source". DRM by itself does not "close down" software: in the case of Tivo you still get the full source code, you still get the binaries, and those binaries will still run on the DRM-ed device (and probably on other devices). What the DRM-ed device does not allow is to run /other/ binaries. Not yours, not other people's software. It is a special-purpose appliance. The Tivo manufacturer, besides having made a decision to limit your software to 128MB of RAM, by limiting you to have access only to a single IDE port, by limiting you to not have a keyboard and by creating a small form factor which has no expansion slots, he also decided to in essence burn the whole OS into "virtual ROM". Note that this "virtual ROM" (the DRM-ed OS) can still be upgraded by the manufacturer rather cheaply, but not by you. The manufacturer never sold this box to you under the pretense that it's a general purpose computer. It's a PVR. The Tivo manufacturer _never made it intentionally hackable_ and never benefited from its hackability. They never wanted an "enthusiast" community around the Tivo - and while you might disagree with their decision, it's their decision to make. They could have burned it all on ROM as well, with easy-to-remove ROM cartridges, where the ROM cartridges have some weird physical form factor that only Tivo produces - which would be just as "unmodifiable" as a DRM-ed OS is. Furthermore, if you still want to hack your Tivo, you can solder out the flash ROM that included their DRM-ed bootloader and can probably replace it with some free BIOS. Furthermore, Tivo is not a monopoly in any market, and you can readily buy other appliances with similar functionality, or you can run MythTV on your PC.
So tell me please, what evil thing did Tivo do?
Bad, bad DRM
Posted Sep 24, 2006 14:24 UTC (Sun) by drag (guest, #31333) [Link]
Are you sure that is legal, replacing the BIOS like that?
I don't own one, and I don't realy want one, but isn't part of reason TiVO signs the kernel is so that it protect userland from fiddling?
Hasn't TiVO entered into legal aggrements with media companies so you can do Pay per View and stuff like that and those companies require DRM-like stuff to 'protect' their content? I mean, for instance, if I hack the board by replacing the bios and I distribute bios chips for the TiVO and this allowed users to 'unprotect' protected content then I figure this a violation of the DMCA in the united states.
Are you prepared to allow people to be arrested by hacking on machines using your code if digitally signed versions of your software are part of a DRM sceme?
If your willing then that's fine. It's your code and such. (Just like I ain't going to 'player hate' BSD license using programmers) Just as long as you realise that it's pretty likely that it will end up being illegal to hack the Linux kernel in many situations were the user owns the devices in question.
Bad, bad DRM
Posted Sep 25, 2006 15:45 UTC (Mon) by mingo (subscriber, #31122) [Link]
Hasn't TiVO entered into legal aggrements with media companies so you can do Pay per View and stuff like that and those companies require DRM-like stuff to 'protect' their content? I mean, for instance, if I hack the board by replacing the bios and I distribute bios chips for the TiVO and this allowed users to 'unprotect' protected content then I figure this a violation of the DMCA in the united states.But didnt you have the noble goal to freely modify the OS so that you could learn and be free? Or was the goal of that "hacking/modification" of the Tivo to go against the wishes of the content copyright holders and to "unprotect" their stuff, and to not pay? If it's the latter then i have no sympathy for that. If it's the former, i doubt there would be many grounds for suing you. (sure, you can be sued over just about anything and the DMCA makes it particularly easy - but the content owner could hardly claim that you did actual damage to him.)
Think about it this way: we, Linux copyright holders are content owners of a valuable piece of work. Even though I dont agree with Hollywood's monopoly position and their tactics, i do believe in their freedom of licensing too.
Bad, bad DRM
Posted Sep 25, 2006 21:22 UTC (Mon) by man_ls (guest, #15091) [Link]
You really think you don't have the right to tinker with your Tivo or any other device that enters your house -- to learn what it does and then modify it to better suit your needs. Even if it is necessary to do things other than what those content owners will let you, for example the nefarious idea of skipping commercials.You probably don't watch DVDs on your Linux desktop, since those content owners do not want you to. They explicitly protected their valuable content with CSS which you would have to, again explicitly, circumvent to watch your legally bought DVD on your legally bought computer. As you would not be using a sanctioned program, that would make you effectively an outlaw.
You probably don't listen to MP3 music either, since:
- on Linux you would be infringing upon Fraunhoffer's valuable patent portfolio, and
- even if you used Ogg Vorbis, the RIAA and friends have repeatedly stated that you do not have authorization to rip and transfer the music tracks from CD's to computers and MP3 players, and without a license you are forbidden to do so by copyright law.
Sorry, too much for me. Freedom to tinker is freedom to tinker. If you think "content" licensing is so important that they can limit what you do with your stuff, then this is probably why DRM does not look so evil to you. But this is precisely why some other people, like Stallman and Moglen, must do things which maybe you don't understand now, but will in some years' time when we see the consequences.
Bad, bad DRM
Posted Sep 26, 2006 6:36 UTC (Tue) by man_ls (guest, #15091) [Link]
Sorry, that was a bit patronizing. I don't know what else to say, I should have shut up.I also think your work is great.
Bad, bad DRM
Posted Sep 26, 2006 11:03 UTC (Tue) by mingo (subscriber, #31122) [Link]
You really think you don't have the right to tinker with your Tivo or any other device that enters your house -- to learn what it does and then modify it to better suit your needs. Even if it is necessary to do things other than what those content owners will let you, for example the nefarious idea of skipping commercials.I think i repeatedly asserted that i find the actions of the content monopoly deplorable.
All that i'm trying to point out is what i already wrote about in great detail: that (unlike the anti-DRM propaganda suggests) not all uses of DRM are evil, and that instead of worrying about the effects of other people's creative works we should rather concentrate on making our body of creative works appealing enough. Trying to fight DRM that tries to protect other people's creative works is misplaced in that respect. By doing that we'll be easily handled with in the policy debate by intentionally confusing us with "pirates who want to steal pay-for content". We are fighting the wrong war in the wrong place and at the wrong time.
I find the idea that we'll suddenly find no tools at our disposal to put free software on very far-fetched. DRM used for content is cumbersome, expensive and slow to every party involved.
Bad, bad DRM
Posted Sep 26, 2006 2:34 UTC (Tue) by drag (guest, #31333) [Link]
The DMCA doesn't cover intent.
If I was to sell preflashed BIOS to users who wish to modify their Linux kernel on the TiVO it would put me in jail just as fast as if I sold it intending to allow users to steal content.
It does not matter. Just for the fact that it CAN be used to steal content is what matters.
Anyways what TiVO is doing now is technically illegal according to the GPLv2. It's implied. You guys just aren't going to call them on it, just like you not going to stop people from distributing closed source binarie in their Linux modules. It's up to you.
You can do what you want. I still love your software and appreciate what you guys are doing.
Bad, bad DRM
Posted Sep 23, 2006 21:39 UTC (Sat) by ibukanov (subscriber, #3942) [Link]
> Is the atomic bomb good or evil? They are devised to decimate whole cities; it is hard to see what good they can bring.
Bad, bad atomic bombs
Posted Sep 24, 2006 10:41 UTC (Sun) by man_ls (guest, #15091) [Link]
Given that the USSR funded a huge program to justify atomic weapon development (as did the US) and Lake Chagan is its best result, I would say it further proves my point.Have you ever heard about construction of dams? They also create artificial water reservoirs, and the best point is: they do not turn water radioactive! You can drink it afterwards!
Re: Kernel developers' position on GPLv3
Posted Sep 25, 2006 17:53 UTC (Mon) by krishna (guest, #24080) [Link]
Is DRM evil? Yes and no ...Does DRM have the ability to prevent you, as a consumer of the software, from examining, modifying, auditing (to your satisfaction), and improving the product you are accessing? Is that a restriction of your freedom?
The GPLs and the motivations behind them are less about good and evil and more about freedom -- although freedom is cast in a very positive light in the license. Everyone will argue that the freedom itself is good/bad/evil/ugly (e.g., to bare skin to various degrees in public, or to bear arms), consistent with one's own cultural/religious/moral convictions.
But I believe the GPL v2 and v3 are both more about preserving specific developer and consumer freedoms than value judgements, and that it comes down to deciding genuinely where those freedoms fall in the priorities of FL/OSS.
Kernel developers' position on GPLv3
Posted Sep 23, 2006 15:31 UTC (Sat) by BrucePerens (guest, #2510) [Link]
Well, it's too bad, but ultimately I think the kernel developers are shooting themselves in the foot. First, on the patents issue. You can make a plausable argument that running Linux on anything is illegal in a large part of the world, including where most kernel developers reside, due to the embedded patent infringements. There are enough software patents granted that you could say the same for essentially any software, but the kernel developers have more to lose and I believe they overestimate the force that would be brought to bear in their defense. A few suits and settlements might leave them just as encumbered as any Microsoft software. But they're going to ignore that because it's political and rely on OSDL's ineffective half-measures to improve patent "quality", which ultimately just makes the patents that will be used against them better.And then the DRM thing. You really want your contributions to be locked down? It seems to be entirely against the spirit of Open Source and I doubt that in the face of widespread locked-down use of Linux that you could sustain contributions outside of the businesses that do the locking down.
Ultimately, we need to recognize that Linux is a 15-year-old kernel and that there will be another technical development to superscede it eventually. I can't say what that will be, but I think the best chance of mobilizing individual contribution to it would be to use GPL 3.
Bruce
Kernel developers' position on GPLv3
Posted Sep 23, 2006 20:27 UTC (Sat) by steelpillow (guest, #40703) [Link]
Bruce Perens wrote, "Ultimately, we need to recognize that Linux is a 15-year-old kernel and that there will be another technical development to superscede it eventually. I can't say what that will be, but I think the best chance of mobilizing individual contribution to it would be to use GPL 3."
That made me check my crystal ball. I saw a massive fork of just about everything into -2 and -3 licensed streams. Most developers, especially the paid staffers, needed to see their stuff happen on Linux, and followed the -2 fork. The -3 forks one by one joined the HURD on the back burner. Then a new OS came along, and in order to leverage all that Linux-friendly stuff it was released under GPL v2.4.
Things got a bit blurry after that, where my tears had fallen. I wiped them away and caught someone saying, "the place to fight unwelcome licensing laws is the legislative process, not the licenses themselves." I lost contact.
Kernel developers' position on GPLv3
Posted Sep 24, 2006 17:41 UTC (Sun) by BrucePerens (guest, #2510) [Link]
Well, RMS has the best crystal ball of anyone I know. He sat down in the early eighties and envisioned a lot of what would go wrong today. So, I take him very seriously. I think his failure this time is mainly a PR failure. He's not involved the kernel developers in solving the problem.Bruce
Kernel developers' position on GPLv3
Posted Sep 25, 2006 3:45 UTC (Mon) by jstAusr (guest, #27224) [Link]
> I think his failure this time is mainly a PR failure.> He's not involved the kernel developers in solving the problem.
I really don't understand what else he could do. The kernel developers aren't interested in any changes. What do you think he could have done differently? It is rather difficult to involve those that don't want to be involved.
Kernel developers' position on GPLv3
Posted Sep 30, 2006 12:44 UTC (Sat) by Blaisorblade (guest, #25465) [Link]
> I really don't understand what else he could do. The kernel developers> aren't interested in any changes.
> What do you think he could have done differently? It is rather
> difficult to involve those that don't want to be involved.
For Linus Torvalds, this is true - he absolutely said "not" to GPLv3.
However, a set of kernel developers, in their whitepaper about this
(http://lwn.net/Articles/200422/) are pointing out significant issues in
GPLv3, and he should consider those issues and try to solve them.
For the DRM thing, that clause would stop a Linux kernel signed by any
distro. When you run a binary kernel from a distro, requiring a signature
from the kernel builder (think to Debian) would effectively stop
insertion of non-authorized modules (think to Adore or such rootkits);
but GPLv3 would disallow this (I think). Also, code for this has been
written IIRC by Fedora, so this is not "theoretical".
Developers also think the distinction between such cases and DRM abuses
is impossible to draw in a license, because it is connected to political
reasons. RMS should prove them wrong on this point.
Kernel developers' position on GPLv3
Posted Sep 25, 2006 5:01 UTC (Mon) by zorgan (guest, #4016) [Link]
Well, RMS has the best crystal ball of anyone I know. He sat down in the early eighties and envisioned a lot of what would go wrong today.True, its fantastic how right he was, and especially his creation of the GPL was amazingly innovative and successful. But that doesn't mean that he is always right, and in fact IMNSHO he has been wrong often enough. (Think: cathedral...)
Kernel developers' position on GPLv3
Posted Sep 25, 2006 13:01 UTC (Mon) by pinky0x51 (guest, #40742) [Link]
>he has been wrong often enough. (Think: cathedral...)
Can you explain this? What exactly do you mean?
"cathedral" reminds me only on "The Cathedral and the Bazaar" but that has
nothing to do with RMS, that's Eric Raymond's thing.
Kernel developers' position on GPLv3
Posted Sep 28, 2006 17:25 UTC (Thu) by smoogen (subscriber, #97) [Link]
One of the arguments behind Cathederal and Bazaar that has been lost was how development around FSF itmes seemed very insular around Boston. The Emacs/Xemacs and the gcc/ecgs forks were due to a very Cathederal take that the FSF had over its own software. The HURD/Linux "fork" was also an example. HURD was built as a cathederal and had many incarnations that booted but didn't cover everything that the people wanted back then to show. Linux booted but barely had a user environment and it went out the door.
Talking about Linux to RMS was a "forbidden" topic where one would get a nice letter chastising people over using something that was taking away effort from FSF goals. He never answered my question when I could get a bootable HURD to test this stuff with. After a while the stern lecture about hurting FSF got replaced by saying that Linux had to be called GNU/Linux.
So when ESR originally wrote C&B he was talking about how the Linux development model was better than the closed door FSF model. FSF has changed a lot since then.. so you get better access to their snapshots and stuff
Kernel developers' position on GPLv3
Posted Sep 25, 2006 5:41 UTC (Mon) by charris (guest, #13263) [Link]
I have the impression that RMS has actually antagonized the kernel developers, among others, over the years. Just because the kernel uses the GPL doesn't mean the developers owe RMS eternal gratitude and must hang on his every word. Indeed, perhaps RMS should express some gratitude to Linus. The kernel is probably the highest profile project out there using the GPL, and without the kernel there would be no GPL operating system to run the toolset on.
Kernel developers' position on GPLv3
Posted Sep 26, 2006 4:20 UTC (Tue) by drag (guest, #31333) [Link]
There are FreeBSD and NetBSD kernels, which can be forked to GPL. Debian has GNU systems using a BSD kernel. Also Hurd was also functional as a kernel until they decided go L4 on it.
Not that I'd actually want to run one of those kernels.. Linux is by far the most sophisticated and best performing kernel aviable. It's just the best.
RMS is fine. You can't seem to trust him.. but as long as your goals are the same as his then everything is cherry.
What is going on here is just different points of view.
The Kernel developers like the GPL because it compels third parties to contribute code back into the Linux kernel. They don't seem care about the freedom so much or helping to ensure the freedom of end users of products using their software.
They are dedicated to making the kernel as usefull and most effective kernel it can be.
The political nature of RMS's message of his brand of 'Freedom' is counteractive to that goal, going with the current GPLv3 draft would sacrifice some commercial interests of Linux which would benifit Linux developers with code, testing, support, etc etc.
Personally I am a end user and obviously for my own self interest I would like the kernel to go GPLv3 because it would help me avoid devices that claim they 'run linux', but are not hackable. It would help to ensure that companies won't try to sneak restrictions in on me. Anything to make DRM less attractive for hardware developers is a good thing to me.
However I doubt that that realy is the highest priority for the kernel devs. I don't blame them.
Kernel developers' position on GPLv3
Posted Sep 26, 2006 17:49 UTC (Tue) by viro (subscriber, #7872) [Link]
Right. I just can see the crowds of BSD developers jumping on thechance to work on GPLv3 forks of *BSD kernels and leaving the
original branches stranded and obsolete. Well, actually I can't,
but I guess it's just another example of kernel folks not having
sufficient proficiency with crystal balls and other fraud paraphrenalia...
Kernel developers' position on GPLv3
Posted Sep 25, 2006 20:56 UTC (Mon) by steelpillow (guest, #40703) [Link]
It seems to me that RMS has not succeeded in involving the kernel developers even in believing that there is a problem to solve - at least not a licensing problem - never mind in how to solve it.
In the end it is content (present or future) which sells the OS, and if GPL3 blocks out the content providers then GPL3-ed stuff will just not get used.
There are content-rich restrictive OS out there. The content providers can afford to just ignore us. To bring them in to line will, I suspect, need more than just a rewritten license. There are many growing movements for restriction-free content: musicians posting free downloads, ogg vorbis, and so on. The black hats are evolving a coordinated strategy against all this. We need to do the same. Maybe GPL3 will have its day - I sure hope so. But is now really the right moment? I think the gut instinct of the kernel developers is "not yet."
Someone commented that GPL3 is in essence political. Maybe. At any rate, one key ingredient of successful politics is persuasion. Another is timing.
Guy
Kernel developers' position on GPLv3
Posted Sep 29, 2006 18:51 UTC (Fri) by bronson (subscriber, #4806) [Link]
To bring them in to line will, I suspect, need more than just a rewritten license...We're talking about freedom, aren't we? Is there a need to to bring anybody into line? If you want to impose your own morals on other people then, I agree, it will take more than a license to do it!
Kernel developers' position on GPLv3
Posted Sep 24, 2006 16:21 UTC (Sun) by jejb (subscriber, #6654) [Link]
To respond to the patents statement: it was definitely the part that garnered the least agreement, so as the document goes, it's probably least representative of the global kernel community view. That said, it wasn't phrased to make any judgements about software patents. What it said was that the current patent clauses in GPLv3 could be seen by corporations as a deterrent to distribution of GPLv3 software. It's this deterrent effect that is called out as the bad thing. If it comes to a patent war over Linux, we won't entirely be relying on OSDL ... we'll also be relying on OIN and the patent portfolios of several other large Linux contributors.
On DRM ... and really, I'm getting a little tired of these muddled issues here, so let me try to separate them.
1. The Tivo case: What Tivo did (making the boot loader only accept signed kernels) was at the behest of its content providers. If GPLv3 had been in force when this came along, the stark choice would have been go out of business now; or go out of business while trying to replace the entire OS.
Firstly, the proposed changes would have affected and probably killed Tivo, but done nothing whatever to impact the people who forced the change: the content providers. It's like treating a symptom, not curing the disease
Secondly, to consider the idea that companies in this position don't give anything back lets use the example of a Tivo competitor here: Moxi (also subject to the same lock down rules by the same content providers). It's produced by a company called Digeo who, by my possibly inaccurate count provided us with several driver enhancements, some nice filesystem work and a kernel maintainer, all under the old GPLv2. Please explain the inequity here.
Finally, embedded Linux in systems as firmware is an end use by the manufacturer. It's also getting embedded further and further away from the user. The GPLv3 introduces a new requirement that wherever these uses of Linux are, you have to be able to find them and modify them ... this represents dictating to the manufacturers how they build systems. It doesn't just affect deliberate things like keyed boot loaders; it also affects people who, because they didn't think about it, didn't provide such a modification channel. This is why it alters the equation: hardware manufacturers must feed this in now as a design requirement. That's what I don't think should be in the licence.
2. All of this is a proxy battle for the real war which is the content providers who're trying to dictate the rules in the first place---and they're doing it purely because they're too stupid to find a new business model, but have the cash to try to buy one. The technological challenges in delivering a copy protected stream all the way from the media to the screen are daunting; and expensive, which is why the manufacturers keep telling the content providers to bog off purely on business grounds. The content providers won't take no for an answer and are now trying to force this by leveraging both their assets (the content) and their money (by lobbying for legal measures). Attacking the manufacturers, who are natural allies in the fight against this type of DRM on business grounds, isn't going to budge the content providers one whit, and might end up diluting the opposition to them by fragmenting it.
Linux in fifteen years? Well ... as long as we maintain the innovation stream, I don't see why not, which is why GPLv3 gets considered on the grounds of its potential impact to that innovation stream.
James
Kernel developers' position on GPLv3
Posted Sep 24, 2006 17:45 UTC (Sun) by BrucePerens (guest, #2510) [Link]
I think Richard is trying to use the weapons we have to solve the problems we have. I think he understands that this problem is a much more difficult one to solve with just political discourse. The other site had a lot of money power, while our power is in our software and we refuse to use it. It doesn't sound like we're going to be effective on the DRM problem this way.Bruce
Kernel developers' position on GPLv3
Posted Sep 24, 2006 19:44 UTC (Sun) by jejb (subscriber, #6654) [Link]
OK, and I'm saying I don't necessarily have a problem with the ends, just the means.
Just because you don't think you can reach the true culprit (the content providers) doesn't mean you should settle for shooting the messenger (or at least the people caught in the middle).
Firstly, this is wrong on purely moral grounds.
Secondly, the collateral damage from doing this is too great. Even if I accept that Tivo has made no useful contributions (which I don't) you'll end up shooting Digeo and a whole host of embedded device vendors too; entities who, I believe, have made (and continue to make) valuable contributions.
Finally, it antagonises a whole crowd of people who're unhappy about being forced to go along with the content providers and who might have more pressure to bring to bear in the cash and power arena than we do. I really see this as a vast strategic mistake.
I fully respect yours and Richard's right as private individuals to use the weapons you have available. However, I take issue when you expect to use my gun. I'm also not ready to throw in the towel on coming up with a strategy to bring this home to the content providers.
James
Kernel developers' position on GPLv3
Posted Sep 26, 2006 18:36 UTC (Tue) by ajaypal (guest, #40762) [Link]
Did i see a flash back, history repeating itself, when the original GPL was opposed and considered a crazy idea.
Only time will tell.
Kernel developers' position on GPLv3
Posted Sep 28, 2006 5:13 UTC (Thu) by AJWM (guest, #15888) [Link]
Just as an aside, a quick grep of the source turns up more TiVo than Digeo copyrights in the kernel. Admittedly that's a pretty crappy measure of relative worth, though.
One rather off-topic question -- if it's the TiVo bootloader that vetos loading an unsigned kernel, what stops someone from changing the bootloader? Maybe it needs a hardware hack (I have no idea), but that surely hasn't stopped the community before. (Xbox, as I recall, required a hardware mod to load a different OS.)
Kernel developers' position on GPLv3
Posted Sep 28, 2006 3:22 UTC (Thu) by etrusco (guest, #4227) [Link]
"I can't say what that will be, but I think the best chance of mobilizing individual contribution to it would be to use GPL 3."
LOL. Before reading the full post I thought Bruce Perens meant "use GPL v3 in Linux" and it will be the best chance of a competitor :-P
Kernel developers' position on GPLv3
Posted Sep 28, 2006 9:23 UTC (Thu) by pkern (subscriber, #32883) [Link]
Ultimately, we need to recognize that Linux is a 15-year-old kernel and that there will be another technical development to superscede it eventually.Wait, 15 years old... only 3 years until it becomes mature. In my legislation, though. SCNR.
Kernel developers' position on GPLv3
Posted Sep 28, 2006 18:31 UTC (Thu) by smoogen (subscriber, #97) [Link]
I just don't understand how changing everything to the GPLv3 will fix it when humans will come up with ways to circumvent that pretty quick to... and they will continue to do so as long as their is a strong motivation to do so that fulfills their needs. The way that you stop it is by convincing enough people that it is in their best interest to play nicely with each other and share their toys when asked.
How to accomplish this we have differing views... but I do not currently see where the middle ground that people will meet on. And without a middle ground the majority of people who aren't developers, aren't coders in any form, don't want to futz with their computer anymore than they want to change the oil on their cars, are going to congregate. And until we get them convinced, it doesnt matter if we write the worlds most perfect License that makes sure that the Four Freedoms are never put aside.. it would just be declared invalid by the paid for courts etc etc.
My view is that work on getting the public knowing why Libre software is important, what it means, and what they get out of it. AND why it makes the Four Needs (Reproduction, Sleep, Food, Safety) easier to accomplish than anything else. Then you can get the problems that stop the Four Freedoms dealt with by consensus in a political/social manner.
Kernel developers' position on GPLv3
Posted Oct 5, 2006 19:35 UTC (Thu) by linuxrocks123 (subscriber, #34648) [Link]
Offtopic but you asked for it...> AND why it makes the Four Needs (Reproduction, Sleep, Food, Safety)
> easier to accomplish than anything else.
You can live without reproducing. Many people do. Therefore, it is not a
need. In any case, bringing in made-up crap like this during a discussion
about software licenses is asinine.
Agreed: Time for the GNU/Hurd
Posted Sep 24, 2006 15:57 UTC (Sun) by accname (guest, #40717) [Link]
I completely agree with you, it *is* definately time for the rise of the GNU/Hurd.
Corporate-backed Linus has been pissing of a lot of people, and it's only
a matter of time that it blows up in his face.
Alternatives like the GNU Hurd (and others like TUD:OS, DROPS, ...).
Good ridance Linus!
Agreed: Time for the GNU/Hurd
Posted Sep 24, 2006 16:53 UTC (Sun) by charris (guest, #13263) [Link]
I find it odd that so much of the argument in favor of the GPLv3 goes along the following lines:
1) The developers are narrow techies with no political sophistication. In short, they are too stupid to know what they are doing.
2) The developers are just passing on corporate propaganda. In short, they are too stupid to have their own thoughts.
3) The developers are bought and paid for by corporations. In short, they are evil minions because corporations are evil entities.
4) The developers were once progressive, but sold out for money. In short, they are selfish and immoral.
Note that none of these arguments deal with the license itself, they are all ad hominem attacks on the developers. Folks, this sort of crap may pass muster in a political forum, but it is out of place in a technical discussion.
That's just not the case
Posted Sep 25, 2006 0:24 UTC (Mon) by coriordan (guest, #7544) [Link]
I've seen very few such comments.
There were some (very valid) comments like that at the start when Linus shocked us with his statement (to a popular business magazine) that GPLv3 would not let him use GnuPG to encrypt his diary.
But Linus' comment have been getting more and more specific. Draft 2 responded to some of his DRM comments (although not to his satisfaction, as he said to the mainstream media within an hour of Draft 2's release). Sometimes it's still hard to understand the point of some criticisms, especially when the criticisms are made to the press instead of on the gplv3.fsf.org forum which would attach the comment to an actuall word/sentence/section of the licence.
But the quality of criticism is increasing, so they should be easier to address.
Agreed: Time for the GNU/Hurd
Posted Sep 26, 2006 3:09 UTC (Tue) by viro (subscriber, #7872) [Link]
Oh, hell... thank you for the theme from "Producers" being stuck inmy ears now, you bastard...
Original link?
Posted Sep 22, 2006 16:29 UTC (Fri) by louie (guest, #3285) [Link]
Jon, in the future it would be great for these types of documents if you could link to the canonical and/or discussion list for these types of things- I assume this went to lkml or some such, and it would be great to follow the responses to it in context. If it did just come via personal email to you, and there is no such public context and no location for public discussion other than lwn, then the article should also state as much. Thanks...
Original link?
Posted Sep 22, 2006 17:04 UTC (Fri) by corbet (editor, #1) [Link]
The position statement came straight to me. Things have since been posted to linux-kernel; here's links for the poll results and the position statement. There's almost no discussion to see there so far, however.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 17:15 UTC (Fri) by alexbk (subscriber, #37839) [Link]
"As drafted, this currently looks like it would potentially jeopardise the entire patent portfolio of a company simply by the act of placing a GPLv3 licensed programme on their website. "
Does it really? I smell FUD here. GPLv3 has an explicit patent grant, but only for the functionality implemented by the distributed program.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 17:46 UTC (Fri) by minghua (guest, #39620) [Link]
"GPLv3 has an explicit patent grant, but only for the functionality implemented by the distributed program."
From what I heard, the problem is that nobody can be very sure about the functionalities in the program he distributes. Most big companies distributes Linux kernel, but does that mean they have reviewed every line of code in the kernel and compared with their patent portfolio, to make sure nothing they hold patent is implemented in the kernel? I am afraid not.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 18:16 UTC (Fri) by pyxis (guest, #15886) [Link]
If companies can't review every line of code in the kernel can the user ????
Surely not.
But GPLv3 clearly prevent an evil company to sue for patent infingment users of the code the same company distributed.
For this reason we should consider the GPLv3 a wonderful license.
Or not, if we like the power to sue innocent users...
Kernel developers' position on GPLv3
Posted Sep 22, 2006 18:31 UTC (Fri) by khim (subscriber, #9252) [Link]
Do you really imply that it's easier for the company to check all outside patents then their own patents ? They should check every line of code anyway because they should not ship anything with technologies patented by others. If they can not even check violations of their own patents - it's clear indication that the while patent mess is beyond repair... and it's also means that corporations are quite ready to ship product with unlicensed technology as long as they are not caught...
Kernel developers' position on GPLv3
Posted Sep 22, 2006 19:34 UTC (Fri) by proski (subscriber, #104) [Link]
FUD indeed. It should read "the entire software patent portfolio". Patents for mousetraps, wheels and rocket propelled broomsticks are not affected.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 17:36 UTC (Fri) by alexbk (subscriber, #37839) [Link]
Also, I do wonder if the kernel developers' employers' lawyers did have a hand in this. It's wellknown that they (the lawyers) are unsuccessfully trying to get the FSF to change the DRM and patent
provisions. Perhaps this is putting pressure on the FSF through a different channel.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 17:47 UTC (Fri) by gregkh (subscriber, #8) [Link]
No, our employers had _nothing_ to do with this, and we explicitly signedthis paper saying that we do not represent anyone other than ourselves.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 18:05 UTC (Fri) by atai (subscriber, #10977) [Link]
This article looks very like the "conclusion statement" from a lawyer in a trial arguing for a particular side. Pure kernel developers probably will not make statements in this manner.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 18:07 UTC (Fri) by gregkh (subscriber, #8) [Link]
Are you saying that we did not write this ourselves?Have we done anything to make you doubt our ability to write something
like this ourselves?
I have an inbox here full of email proving that we did this, I don't
understand why you would think otherwise.
Why this route?
Posted Sep 23, 2006 2:33 UTC (Sat) by coriordan (guest, #7544) [Link]
Have you submitted these comments through gplv3.fsf.org ? If not, why not?
(Keeping in mind that the issues reported there seem to be being listened to)
One important design feature of the gplv3.fsf.org comment portal is that it requires people to highlight what words and sentences their comments relate to. In public discussions, people can say "I/We don't like the patent bits", but at the portal, you have to say what words you disagree with. The downside is that commenters have to have actually read the draft, and they actually have to have a possibly-valid comment. It sounds like you have read the draft, so this isn't a problem in this case. The upside is that discussion starts from fact and details instead of general ideas.
One example is the length. For 15 years, people said "make it shorter", but when it is opened for revision, how many pointed out words that could be removed? Few or none.
Please, do submit your comments through gplv3.fsf.org, not just slashdot and lwn.net
Why this route?
Posted Sep 23, 2006 18:41 UTC (Sat) by sepreece (guest, #19270) [Link]
Minor nit - one of the weak things about the GPLv3 comment portal (unless they've changed it recently) is that you have to comment on a text segment no longer than one sentence, which is often narrower than the arc of a particular thought within the license.
It's not well-designed for raising philosophical or holistic objections.
commenting
Posted Sep 24, 2006 1:53 UTC (Sun) by coriordan (guest, #7544) [Link]
To comment on a whole section, attach your comment to the section title.
Why this route?
Posted Sep 25, 2006 15:21 UTC (Mon) by mingo (subscriber, #31122) [Link]
Have you submitted these comments through gplv3.fsf.org ? If not, why not?btw., this i see as another problem. The GPLv3 process is fundamentally undemocratic: the President of the FSF retains all rights to set the language of the GPLv3.
furthermore, Linus has stated that he has sent his comments to both Richard Stallman and to Eben Moglen directly, and that they were ignored, see this Groklaw comment of Linus:
Yes. I have emailed both rms and Eben directly. They know my position. They don't care. If they told you otherwise, they lied. Get over it.
Why this route?
Posted Sep 25, 2006 16:07 UTC (Mon) by alexbk (subscriber, #37839) [Link]
Wow, is that anonymous frustrated fella really Linus? Someone should really veryfy this. Posts like http://www.groklaw.net/comment.php?mode=display&sid=2... are borderline insults worthy of someone like ESR, and don't sound like Linus at all.
He's believed to be Linus
Posted Sep 25, 2006 20:24 UTC (Mon) by coriordan (guest, #7544) [Link]
PJ checked during a previous discussion (I guess she emailed him), and he was indeed Linus.
Why this route?
Posted Sep 25, 2006 23:24 UTC (Mon) by h2 (guest, #27965) [Link]
Exactly what I thought when I read that groklaw thread, but it became increasingly clear that the shrill, near hysterical, almost totally irrational voice I was reading was in fact Linus himself. If he was aiming to impress anyone with his arguments or clear reasoning he certainly failed in my case, and I used to respect him much more than I do now, after reading that thread. He showed a bit too much there if you ask me, and the fact that he had bad enough judgement to do that in the first place is also revealing.
I remember well a different Linus, who refused to take credit for the kernel, laughingly saying he just managed to get that credit by absorbing great work from others. That was a Linus I respected, this new Linus 2.0 is one I could happily never read another word from again.
The fact that the people he works with most closely agree with his position should not be surprising, and should not be considered grounds for discussion in the first place. What else would you expect? Of course the core guys more or less see eye to eye with Linus, otherwise they wouldn't be core guys. This has no more significance than polling a position at the democratic or republican or libertarian national political convention then using the results to show broad support for your position.
Why this route?
Posted Sep 26, 2006 1:19 UTC (Tue) by bronson (subscriber, #4806) [Link]
It shows broad support *among kernel developers* for Linus's position. And that certainly sounds significant to me.
depends on how seriously it was taken
Posted Sep 26, 2006 1:45 UTC (Tue) by coriordan (guest, #7544) [Link]
Well, that depends on how seriously the voters took the poll.
Why this route?
Posted Sep 25, 2006 19:08 UTC (Mon) by alexbk (subscriber, #37839) [Link]
The core of his argument seems to be that the kernel development is based on "fair trade" principleand not on "freedom for the users" one. But fair trade can be interpreted in many ways, and I don't
see why his interpretation - "I give you source code, you give me your changes" is more valid than "I
give you the right to use my source code with your hardware, you give me the same right".
Why RMS?
Posted Sep 25, 2006 21:38 UTC (Mon) by coriordan (guest, #7544) [Link]
You've raised two new issues there, but I guess the answer to my question is no, you haven't submitted your comments via the comment system. I think it would be useful if you did. Comments submitted there are reviewed by a committee of lawyers, a committee of large businesses, a committee of free software projects, and a committee of general developers who'd shown an interest. Between the four committees, there are about 130 people.
For the two separate issues you raised. Richard has acknowledged that the first needs work. He replied to questions on this in Italy in March ("... We're going to have to replace me somehow, sooner or later.") and in Barcelona in June ("...Most of our community does not appreciate freedom ... So, if we wanted to do a good job of protecting freedom with version 3 of the GNU GPL, we could not let the majority of our users decide what goes into that licence..."). A vote isn't the right thing to do (just like a vote is not the best way to land a plane or do surgery), but yes, we can't always have Richard making the decisions. We need to build a committee which can be trusted to update the GPL in the spirit of copyleft.
For your second issue, it's hard to know what Linus has been saying to Richard. It would be easier to know about Linus' comments if he submitted comments to the public gplv3.fsf.org portal, attached them to the actual licence text, and got them discussed by the committees. And the same goes equally for the other Linux developers and members of other free software projects.
People who are trying to improve GPLv3 can take some hints from the above letter, but it would be far more useful if that letter also had some comments on the text of draft 2.
For example, section 5.2 of the above letter recommends removing section 7b of GPLv3 draft 2 because of a certain list of problems. These problems are mostly known, but section 7b has the benefit of making GPLv3 compatible with more free software licences, such as the Apache licence. Licence incompatibility is a pointless bureaucratic impediment for free software developers, so removing incompatibility should be tried.
So, while highlighting the problems is useful, we should also look at each problem and decide how to minimise it and how much of a problem it is, so hopefully we can fix the problem, or fix it sufficiently, and keep the benefits. This discussion is easiest to have inside the consultation system, instead of via the community and mainstream news outlets.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 18:48 UTC (Fri) by jejb (subscriber, #6654) [Link]
I can clarify this, I suppose. I wrote the first draft of the document and maintained the subsequent updates and rewrites via feedback from the group. No lawyer anywhere had input into our process. Except in one case, which was to answer a specific legal concern raised by the group: Could releasing this document compromise the ability of people to enforce the current GPLv2 on kernel code. The answer was a qualified (as you would expect) no.
James
Kernel developers' position on GPLv3
Posted Sep 23, 2006 3:10 UTC (Sat) by jwboyer (guest, #23296) [Link]
The ability to use large words to form coherent sentences, which in turn form well written and carefully thought out ideals is not soley the talent of lawyers. On the contrary, since this _is_ such a well written and concise document, I would be much more suspicous if someone said a lawyer _did_ participate.
Questioning someone's integrity by stereo-typing kernel developers as hackers that only grok code is the mark of a simpleton.
(In layman's term, I just called you a moron)
Kernel developers' position on GPLv3
Posted Sep 23, 2006 7:53 UTC (Sat) by beoba (guest, #16942) [Link]
Yes, calling commenters morons is an excellent way to maintain a civil discussion of the issues at hand. Thank you for your valuable input.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 18:11 UTC (Fri) by cventers (guest, #31465) [Link]
Greg,
Thank you for participating in this. I'm still not sure where I stand on
GPLv3 personally - I find arguments on both sides of the fence
convincing.
I was really concerned, though, because it seemed like people really
didn't understand why Linus wasn't happy with the license, but it also
seemed like there wasn't much communication going on between Linux and
the FSF on this issue. This document does a great deal to help.
Bravo, keep up the good work.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 19:12 UTC (Fri) by alonso (guest, #2828) [Link]
Hi Greg, first of all thank you for your hard work!
I really don't understand your pro DRM position, why do you think that devices like tivo are good? Do you really think that having the source code of the kernel without the ability to run it on a device will boost or is usefull for linux?
The freedom argument is pointless, why GPLv2 is better than BSD? Because GPLv2 limit freedom of developer, they have to release modification of the code.
A big thank you to every Open Source developer.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 19:56 UTC (Fri) by gregkh (subscriber, #8) [Link]
Sorry, but we are not taking a "pro DRM" position here at all. We aremerely stating that the DRM provisions as written in the GPLv3 are nothing
that we thing should be present in a software license.
As for usefulness of having the source code, but being unable to run it on
the machine, that too is something that not all of us agree upon, but we
do agree that again, it should not be something that is dictated by the
license, as it is very different from what the GPLv2 states.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 20:34 UTC (Fri) by ajross (guest, #4563) [Link]
I think, though, that a lot of the resistance you are seeing here is because this sort of logic ("we don't think software licenses should restrict freedom") sounds very much like what we all heard 8-10 years ago from the BSD crowd about the GPLv2. A BSD-style license, as we all remember, is "more free" than the GPL because it doesn't have the awful "viral" clause.This analysis failed not only from semantic ambiguity (confusing the "freedom of action" of a single user with what I guess would be called the "freedom of opportunity" of the user base as a whole) but because it was actually wrong in a practical sense. The freedoms of the more permissive licenses led ultimately to a bunch of firewalled work behind closed doors to which the community lacked access (c.f. BSDI, or the vendor-enhanced X servers of the mid-90's, or all the fancy features of early IP networking hardware). The GPLv2 kept all this stuff on "our" side of the firewall, to all of our benefit. The end result is that Linux is a much more successful platform in the world of shipping, revenue-producing products; which is exactly the opposite result from what the "BSD freedom" argument predicted.
So I guess the real question (and I swear I'm not trolling here!) is this: how sure are you that this isn't just a reactionary response? Are you absolutely sure the "freedoms" you're espousing here are really the ones that are important to retain, or is it just that you like what you have, distrust the FSF, and basically fear change?
I don't have a really clear answer myself, but I'll be honest: the "freedom" to prevent people from running modified software on hardware I designed to run GPL software I got from someone else doesn't really sound like "freedom" to my ears. Like most of you, I read RMS's pronouncements and admonitions and roll my eyes more often than not. But I read the GPLv3 and like what I see.
An excellent point
Posted Sep 22, 2006 22:09 UTC (Fri) by emk (subscriber, #1128) [Link]
I agree that this new feature of GPLv3 is keeping with the spirit of the GPL license (as opposed to the BSD license). Whether it can be implemented cleanly, I don't know, but I think the FSF's basic desire is philosophically reasonable and a boon to users.
An excellent point
Posted Sep 23, 2006 2:38 UTC (Sat) by coriordan (guest, #7544) [Link]
Eben Moglen explalined this well in India. The new DRM clause just says that you can't use technology to add restrictions that the licence doesn't allow.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 22:09 UTC (Fri) by sepreece (guest, #19270) [Link]
I don't think anyone would disagree that the "must release source code" requirement is central to the success of Linux and other FOSS software. I think almost everyone agrees that it an essential element of fairness. It's also utterly essential to the success that FOSS has seen.
I believe the "viral" nature of GPL would probably get a less unanimous response. It seems like essential fairness that "if you use a modified version of my code, you must give back your changes", but the argument for copyleft is less clearly essential to fairness. I would not, personally, claim that fairness required that if you use my code in your product, you need to also release your own code that just uses my code. If the use is just around exposed APIs, I tend to think it's just use and shouldn't require release. I tend to think that copyleft has also been less critical to the success of FOSS - that there probably are some projects that started because they had to, in order to use GPLed code, but I think the successful FOSS projects exist and flourished because somebody wanted a particular kind of software "thing" and felt that FOSS development was a good way to get a group working together to grow it. That doesn't require copyleft.
The anti-Tivoization argument is even less broadly accepted (as the kernel developers show here). I believe it extends the notion of the first freedom unacceptably and without any roots in essential fairness. Nor is it essential to the future success of FOSS. In fact, I continue to believe that the anti-Tivoization/anti-DRM clauses will work against future success of FOSS by fragmenting the community and by driving some work, some developers, and a significant amount of investment, to a separate community around GPLv2 or another free license.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 22:22 UTC (Fri) by emk (subscriber, #1128) [Link]
Well, there was a recent interview with a founding NetBSD developer that the BSD license had caused much derivative work to disappear behind propriety walls. Similarly, much of the work on X11 from the early 80s to the mid-90s never made it back into the public code base.
So I think the pro-GPL arguments are worth listening to.
Kernel developers' position on GPLv3
Posted Sep 23, 2006 1:28 UTC (Sat) by sepreece (guest, #19270) [Link]
Nobody is arguing against the GPL! The question is whether the changes in the proposed next version of the GPL improve the license or not.
Kernel developers' position on GPLv3
Posted Sep 25, 2006 9:46 UTC (Mon) by anandsr21 (guest, #28562) [Link]
But this is a GPL argument. The only difference is whether you are allowed to use technical measures to defeat the provisions of GPL. Tivoisation is merely circumventing the GPL using DRM.
I am not sure if you know what the intent behind GPL is. I would like to remind you of the story of the Printer, and ask you to think about the Tivo again. It should be clear in a moment.
Kernel developers' position on GPLv3
Posted Sep 25, 2006 14:42 UTC (Mon) by sepreece (guest, #19270) [Link]
The kernel developers [and some of us others] seem to disagree with your contention that Tivoization violates the GPLv2. I know SOME people claim that it does, and that SOME others claim that it violates the spirit but not the letter, but there are quite a few of us who say that there is nothing in GPLv2 that requires that you be able to install on the same device.
I do know the story of the printer firmware and RMS's belief that devices should be upgradeable, I just disagree with them.
I think that there is enough opposition to this broadening that it will fragment the community and reduce its influence (and its ability to compete with, for instance, Microsoft) if GPLv3 continues in the directions taken in the current draft.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 22:27 UTC (Fri) by ajross (guest, #4563) [Link]
The anti-Tivoization argument is even less broadly accepted (as the kernel developers show here). I believe it extends the notion of the first freedom unacceptably and without any roots in essential fairness.This is the part that I just don't see. Stated as simply as possible, the philosophy behind the GPL says: "You can use this, as long as you share it." This is, to me (and maybe you see the license in a different moral light) a really, painfully obvious candidate for any definition of "essential fairness". I give it to you, so you need to be willing to give it to others. Sounds fair to me, no?
But the DRM use case breaks down here. A DRM-encumbered device clearly is not "sharing" the code in any meaningful way. None at all. But it is, at least technically, within the scope of the license as written. So the FSF has amended the license to prevent this particular loophole. What I just can't understand is how opposition to this change is being explained as support of "freedom" or "fairness". This doesn't seem like "freedom" or "fairness" to me at all. If I had to pick a word for it, it would be: "cheating".
I see a lot more validity in the practical arguments that the additions to the GPLv3 are too large, or too complicated, or too risky. But people (important people, even) are arguing here that those changes are unfair and unfree, and I'm at a total loss to understand their logic.
Kernel developers' position on GPLv3
Posted Sep 23, 2006 0:25 UTC (Sat) by Felix_the_Mac (guest, #32242) [Link]
"A DRM-encumbered device clearly is not "sharing" the code in any meaningful way. None at all."
From the point of view of the software developers the code is shared as normal. The device manufacturer takes the GPL code, modifies it, makes the modifications available to everybody and then incorporates it in the device.
It is only from the end users point of view that the company appears to be breaching the philosophy of the GPL since although the user has the source code and can use it in various ways (i.e. build their own device etc.etc.) they cannot reload it into the Tivo (or other hardware) and get it to run.
The GPL3 I believe therefore introduces the concepts of limits on the use of the software which were not present before. In doing this does it not become incompatible with version 2 thereby causing the fragmentation and great difficulties for distributions that the authors of this paper mention?
Personally I would be very happy if the GPL v3 was finalised and adopted by 98% of current GPL 2 projects. But if that is not going to happen and the new license causes the difficulties that the authors mention then it is not worth the cost.
In the circumstances I do think that a GPL3 which contained some clarifications and wording adjustments for the sake of internationalising the license would be worthwhile. BUT only if it was fully compatible with GPL 2 and therefore (a) it wouldn't matter if a particular project didn't move to GPL3 and (2) there would be no reason for any project not to move to GPL 2.
What part of the draft is that?
Posted Sep 23, 2006 2:44 UTC (Sat) by coriordan (guest, #7544) [Link]
The goal of the GPL is to ensure that when someone gets the software, they are free to help themselves and to cooperate with others. When someone gets a Tivo, they might want to remove the spyware or add a "copy" button. Unfortunately, to the user of a Tivo, the source is viewable, but cannot be modified to make the computer (the Tivo) do what they want.
More importantly, could you say what part of the draft introduces use limits?
All it says is that Tivo is free to modify the software to suit their needs, and I'm free to modify the software to suit my needs after I get it from them.
What part of the draft is that?
Posted Sep 23, 2006 8:45 UTC (Sat) by Felix_the_Mac (guest, #32242) [Link]
"More importantly, could you say what part of the draft introduces use limits?"
Quite simply the use limits are "you may not use this software in a device which will not allow modified software to be run".
It's similar to other use limits that are sometimes discussed, and rejected, such as "you may not use this software in a nuclear warhead".
GPLv3 doesn't say that
Posted Sep 23, 2006 12:24 UTC (Sat) by coriordan (guest, #7544) [Link]
Hmm, as I thought. You are complaining about something you think is in GPLv3, but which is not in GPLv3. Maybe people have these misconceptions because the media has oversimplified the issue.
GPLv3 allows people to implement DRM. I can configure my kernel to only run binaries signed by me, and then sign all the binaries on my system, and then I will be well protected against viruses. This is allowed by GPLv3 (and v2).
What GPLv3 forbids is that _you_ distribute the software in a way that _you_ have the ability to modify the software but _I_ don't. When you distribute (not use) the software, you are obliged to do so in a way that passes on the freedom for the recipient to adapt the software to do what they want.
So there is no use restriction. I think RMS explained this well in his February talk at FOSDEM, and recently in Bangalore, he explained it and Eben Moglen explained it.
It's important that people read the draft and then attach comments to the actual text (by going to gplv3.fsf.org) instead of debating things that don't exist.
GPLv3 doesn't say that
Posted Sep 23, 2006 12:55 UTC (Sat) by Felix_the_Mac (guest, #32242) [Link]
I said:"you may not use this software in a device which will not allow modified software to be run".
You said:"there is no use restriction."
Stallman said:"The basic change is that if someone, say the manufacturer of the Tivo, provides you a binary, then he must, as part of the requirement to provide the source code, give you whatever it takes to authorise your version so it will run."
Therefore the use restriction is that the manufacturer cannot use the GPL code in a device for which they are not willing to give you the signing key.
I support this position in principle, however if the practical effects are as suggested by the kernel developers in their letter, I do not believe that the risk to the GPL system is warranted.
GPLv3 doesn't say that
Posted Sep 23, 2006 13:18 UTC (Sat) by coriordan (guest, #7544) [Link]
The condition/requirement/restriction is on distribution, not use. Any recipient of the software, including a device manufacturer, can use (as in, run, execute) the software without restriction. When they distribute (give a copy to someone else), they have requirements.
v2 said that requirements were to make the source code available, and to make the recipient aware of the licence. v3 adds to this list that there is also a requirement to make sure that if there are technical measures which might prohibit modification, then the recipient must have what is necessary to avoid being restricted by that.
This is why I say there is no use requirements. If you define "use" in a really broad way that includes distribution, then there are some relevent restrictions in v3, but this is also true of v2.
GPLv3 doesn't say that
Posted Sep 27, 2006 13:52 UTC (Wed) by bignose (subscriber, #40) [Link]
> the use restriction is that the manufacturer cannot use the GPL code in a> device for which they are not willing to give you the signing key.
They can *use* the software in that device, unconditionally. They may also (under the terms of the current GPLv3 draft) *redistribute* that software to you, with the condition that they grant you all the freedoms to the software they received.
Once you receive that software under the terms of the GPLv3, you too are free to use the software in that device unconditionally, just as the party you received it from was free to do so.
No-one's use of the software is restricted by any conditions in the (current draft of the) GPLv3.
Kernel developers' position on GPLv3
Posted Sep 23, 2006 1:42 UTC (Sat) by sepreece (guest, #19270) [Link]
"This is the part that I just don't see. Stated as simply as possible, the philosophy behind the GPL says: "You can use this, as long as you share it." This is, to me (and maybe you see the license in a different moral light) a really, painfully obvious candidate for any definition of "essential fairness". I give it to you, so you need to be willing to give it to others. Sounds fair to me, no?"
Device manufacturers (well, many of them) are perfectly happy to share their work with you. But, in some cases they feel they cannot let you modify the actual device. You can still use the technology they developed, even to build a competing device. Many of think that is the essential fairness. The question of whether the device is modifiable should be a market issue, not a license issue.
Note that your argument about an encumbered device "not sharing" apparently doesn't convince the FSF, either, since they say it's perfectly OK to build a non-modifiable (ROM-based) device with free software, and it's hard to see how that would be "sharing" other than by source-code sharing.
Kernel developers' position on GPLv3
Posted Sep 23, 2006 14:45 UTC (Sat) by Kluge (subscriber, #2881) [Link]
I think the FSF's position is that the creator of the device shouldn't have any rights regarding the software that they don't also give to the users. In the case of a ROM, neither the manufacturer nor the user can modify the software, so it's still fair. But if, as in the case of Tivo, the software can be modified (and is, to upgrade the DRM) by the manufacturer, then it should also be modifiable by the user.
Sounds fair to me.
Kernel developers' position on GPLv3
Posted Sep 23, 2006 18:46 UTC (Sat) by sepreece (guest, #19270) [Link]
This argument about "can't reserve any rights that you don't pass on" seems to be to be contrived - that is, they have constructed an argument for their position that is not rooted in the four freedoms they claim to be protecting.
Kernel developers' position on GPLv3
Posted Sep 25, 2006 9:54 UTC (Mon) by anandsr21 (guest, #28562) [Link]
Which one of the freedom do you claim it violates?
To me it seems that it is inline with the general philosophy that distributors have obligations. The authors any way have all the freedoms, unless they use GPL and become distributors ;-).
Kernel developers' position on GPLv3
Posted Sep 25, 2006 14:47 UTC (Mon) by sepreece (guest, #19270) [Link]
I did not say it "violates" any of the four freedoms, just that it didn't derive from any of them.
That is, in logic, saying "A does not imply B" is not at all the same as saying "B implies not A".
It derives from freedom #1
Posted Sep 26, 2006 2:23 UTC (Tue) by coriordan (guest, #7544) [Link]
The need for the DRM-related words in the licence is derived from freedom #1: "The freedom to study how the program works, and adapt it to your needs".
If I get the software as part of a hardware+software system, but after modifying the software the hardware transforms into a brick, then I have not been given freedom #1 in a meaningful sense. It's like pulling the trigger and out pops a flag saying "BANG".
In the case of the Tivo, I might want to remove the spyware and add a "copy to my computer" button. Making these modifications and then running my new version of the software on anything but my Tivo will not fulfil my needs.
In the 1990s, to ensure that freedom #1 survived the distribution chain, the GPL had to require people to published the source of any published binaries. In 2006, the GPL also has to require people to give the recipient any codes or passwords that the distributor has made necessary to run modified versions of the software.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 21:44 UTC (Fri) by alonso (guest, #2828) [Link]
You are right, you are not pro DRM. I would had to write:"I don't understand your position against the anti DRM clause in GPLv3". Now is clear to me that you think that a licence is not the right place to assert this. But where you think is the right place?
GPLv3 allows implementing DRM
Posted Sep 23, 2006 2:47 UTC (Sat) by coriordan (guest, #7544) [Link]
Keep in mind that GPLv3 does not prohibit DRM, it just protects freedom #1 (the freedom to adapt the software you received to suit your needs) - which enables you to escape from DRM restrictions (if you want to).
Kernel developers' position on GPLv3
Posted Sep 22, 2006 20:02 UTC (Fri) by ibukanov (subscriber, #3942) [Link]
> The freedom argument is pointless, why GPLv2 is better than BSD? Because GPLv2 limit freedom of developer, they have to release modification of the code.
Very well said. I suspect that given the complexity of the current software a source that you can not modify becomes just another form of binary format. So in DRM world GPLv2 applied to a complex software becomes just another form of business-friendly BSD license.
On the other hand I wish FSF would not even mention too-political DRM in GPLv3 and just state instead that for a reasonable amount of money a user can get a box to run code with his modifications.
So if a kernel flash image requires signed code, the user should be able to sign it somehow even if that would require small fee. If the kernel resides in ROM, then the user should be able to get a chip with his modifications even if that requires to pay for another chip.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 20:46 UTC (Fri) by alexbk (subscriber, #37839) [Link]
They only mentioned DRM in the first discussion draft. The second draft changed this to "NoDenying Users' Rights through Technical Measures".
Kernel developers' position on GPLv3
Posted Sep 22, 2006 21:01 UTC (Fri) by ibukanov (subscriber, #3942) [Link]
Thanks, I missed that. It is much better term to use. Still I do not think it covers ROM chips with compiled GPL-ed code, while explicitly says about encryption keys. For example, it prevents a company from offering an option to sign the code through, for example, usb-connected box without revealing the private keys.
Kernel developers' position on GPLv3
Posted Sep 24, 2006 15:40 UTC (Sun) by paulj (subscriber, #341) [Link]
You're wrong, the GPLv3 draft allows vendors to sign code (without revealing the signing keys) just fine.
Kernel developers' position on GPLv3
Posted Sep 25, 2006 9:59 UTC (Mon) by anandsr21 (guest, #28562) [Link]
This is a misconception. GPLv2 or v3 only limits the freedom of the distributor. The don't limit the freedom of the developer unless the developers want to become a distributor. The distinction is the most important point in understanding GPLv2 or v3. It seems to me that kernel developers are too busy to really understand this whole issue. I don't know why they are taking a stand anyway.
Section 5.2 and 5.3
Posted Sep 22, 2006 18:25 UTC (Fri) by atai (subscriber, #10977) [Link]
The DRM part is an existing controversy and this article provides little new.
For section 5.2, the additional requirements allowed, excluding the ASP clause, seem reasonable and are common in some other Free Software licenses, so their combinations should not cause the type of fragmentation as stated in the article. After all, when you combine existing free software under different licenses, you need to go through the process anyway. The ASP clause clearly should not be used in the kernel but may be useful for people writing content management systems.
Section 5.3, it may seem a good idea to allow people to assert patent claims against these who assert patent claims against them... (Current GPL 3 draft does not seem to allow that possibility)
Section 5.2 and 5.3
Posted Sep 25, 2006 10:06 UTC (Mon) by anandsr21 (guest, #28562) [Link]
That I believe is not a problem. You are only not allowed to assert the claim against GPLv3 code that you distributed. But you are allowed to assert claim on other code. Ofcourse if somebody is asserting patent claim against you, you can still assert your patents on the other guys nonGPLv3 software. Ofcourse if the other person distributed the same GPLv3 code he will also not be able to assert the claim on you. Seems perfectly logical to me.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 18:46 UTC (Fri) by sp.at (guest, #36249) [Link]
Ad 4 "Pivotal Role of the Free Software Foundation":
Quoting [Kernel developer's position on GPLv3]: "However, we also take note of the fact that the FSF operates very differently from Linux in that it requires assignment of copyright from each and every one of the thousands of contributors to its code base."
This is plain wrong. The FSF does at NO POINT require you to assign copyright to them. It is more of an option to whoever applies for his project to become part of GNU.
Quoting [http://www.gnu.org/help/evaluation.html]: "For a program to be GNU software does not require transferring copyright to the FSF; that is a separate question. If you transfer the copyright to the FSF, the FSF will enforce the GPL for the program if someone violates it; if you keep the copyright, enforcement will be up to you."
Kernel developers' position on GPLv3
Posted Sep 22, 2006 19:33 UTC (Fri) by jgarzik (guest, #8364) [Link]
In practice, the vast majority of the GNU codebase requires copyright assignment, including all major projects (binutils, gcc, glibc).
Kernel developers' position on GPLv3
Posted Sep 22, 2006 21:26 UTC (Fri) by jbailey (subscriber, #16890) [Link]
Yes, but that was the choice of the original authors in every case. The trick with the major projects is that they were almost all started / funded by the FSF.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 22:55 UTC (Fri) by smoogen (subscriber, #97) [Link]
When in the past I sent in patches to FSF code, I was asked to sign over my copyright of that patch to the FSF for it to be accepted. This was listed by others I asked as the standard FSF practice. I think this is what they are referring to.
[I can patch binutils all I want, but if I want the official binutils to have those patches.. I have to reassign the copyright to the FSF.]
Kernel developers' position on GPLv3
Posted Sep 22, 2006 19:59 UTC (Fri) by ajross (guest, #4563) [Link]
It looks correct to me. The FSF requires copyright assignment for all code submissions to the GNU project.However, we also take note of the fact that the FSF operates very differently from Linux in that it requires assignment of copyright from each and every one of the thousands of contributors to its code base.This is plain wrong. The FSF does at NO POINT require you to assign copyright to them. It is more of an option to whoever applies for his project to become part of GNU.
I think you misinterpreted the text as indicating that the FSF requires all GPLed code to be assigned, which is of course incorrect. The phrase "its code base" clearly refers to GNU, not all the GPLv2 code in the world.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 21:07 UTC (Fri) by quintesse (guest, #14569) [Link]
Uhm no, it very specifically says:
"For a program to be GNU software does not require transferring copyright
to the FSF"
It says "GNU Software", not GPL. So it is wrong to say that GNU requires
all developers to sign over their copyright if they want to call it GNU
software.
There is in fact a whole list of items that GNU software has to adhere to
but signing over copyright is not one of them.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 22:58 UTC (Fri) by smoogen (subscriber, #97) [Link]
In the case of the sentance it does not say reassignment of GNU code... but FSF code. THe FSF may have changed this recently, but if a codebase was considered already to be FSF (coreutils, binutils, etc) then you had to do the copyright signover if you wanted them to look at the patch (and I mean that literally for at least one patch I sent in).
Kernel developers' position on GPLv3
Posted Sep 23, 2006 4:45 UTC (Sat) by jstAusr (guest, #27224) [Link]
That might have to do with FSF being able to insure that it can conveniently defend the code in court.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 19:25 UTC (Fri) by mattmelton (guest, #34842) [Link]
I've read and reread this. What I'm seeing is plain: the people I admire and respect, for many reasons, have a less forward thinking approach to preserving the free model and the freedem they've enjoyed than they do APIs.
When there are so many DRM-restricted devices that the FSF has to give up enforcing the GPL because it can't audit them, legally, we'll look back at this point, and at the decisive developers and say, "they didnt WANT to look forward".
There is little (if any) comprimise in the wording. eg: if end-user restrictions are against the free software philosophy - why have a bloody licence in the first place?
I've never been so saddened with some of the developers as I am today. I'm always kicking myself, because the decisions Linus (et al) make that I disagree with usually turn out for the better... but this is one of the few issues I can understand fully...
You can't scare big business away from Linux now. Look at the mile stones made in 2.6. Look at the improvement upon system after system 2.6 has made over 2.4. No company in the right mind would desert a GPLv3 2.8 if it made only half the advances as 2.6 has.
I have a sneeky suspicion (and its entirely my own feeling) that money is behind this. Linux isnt GNU/HURD. But everyone wants HURD-esqu freedom. Now we've got a HURD-like (as in free) system, in the form of Linux, we've forgotten the values. Rich with stability.
I just hope no more software hijacks the GNU bandwagon, only to jump off when it becomes profitable.
Bring back indie development!
Matt
Kernel developers' position on GPLv3
Posted Sep 22, 2006 19:36 UTC (Fri) by jgarzik (guest, #8364) [Link]
Nothing is "behind this" except the strong feelings of key kernel developers, speaking for themselves and not for their employers.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 21:46 UTC (Fri) by sepreece (guest, #19270) [Link]
"When there are so many DRM-restricted devices that the FSF has to give up enforcing the GPL because it can't audit them, legally, we'll look back at this point, and at the decisive developers and say, "they didnt WANT to look forward".
This suggests that the anti-DRM clauses in the GPLv3 can somehow block the progress of devices containing DRM and trusted-computing features. In fact, though, there are lots of such devices in the field and will be many more. The most you can hope for is that they not run Linux. If you want to fight against efforts to legally require such things, please do so! I strongly agree with that. But, good as it is, FOSS is not yet important enough to hold back the growth of such technologies.
"You can't scare big business away from Linux now. Look at the mile stones made in 2.6. Look at the improvement upon system after system 2.6 has made over 2.4. No company in the right mind would desert a GPLv3 2.8 if it made only half the advances as 2.6 has."
This is simply not true. The companies who use, or want to use, Linux and other FOSS in their devices simply have no choice. If you make it impossible to ship GPLv3 software in devices that are critical to those companies' future (players for protected content, cell phones meeting FCC type certification rules, etc.), then they won't use GPLv3 software. They weren't using it before and they can, by and large, switch to something else with much less pain that there would be in giving up those markets.
[Note - not claiming to speak for the developers or for anyone else but myself]
Kernel developers' position on GPLv3
Posted Sep 22, 2006 22:40 UTC (Fri) by Richard_J_Neill (guest, #23093) [Link]
> If you make it impossible to ship GPLv3 software in devices that are> critical to those companies' future (players for protected content, cell
> phones meeting FCC type certification rules, etc.), then they won't use
> GPLv3 software.
This is backwards. What RMS is trying to do is ensure that the user cannot be bound by such unnecessary restrictions. "Protected content" should never exist - and hardware that can, by design, bypass the protection (or be hacked to do so) is good for both the consumer and the manufacturer.
I do take your point about FCC power-level rules - but that sort of limit ought to be implemented in silicon, if for no other reason than to avoid potential harm from driver bugs.
RMS has a habit of being right in the longterm, and he has my complete trust.
Kernel developers' position on GPLv3
Posted Sep 23, 2006 1:57 UTC (Sat) by sepreece (guest, #19270) [Link]
My point is that disallowing use of free software in such devices will have essentially zero effect on whether the devices exist. The devices WILL exist, because consumers WANT them. If you want to fight DRM, the place to do it is in Congress (if you're in the US) and through public awareness.
"Protected content" exists because the content owners have said "these are the terms under which you can have our content" and most people are, apparently, willing to accept those terms. If you want to fight it, work to make people see that it's an unfair exchange. I think you'll have a hard sell, because the huge majority of them just want their TV programs, movies, and songs and don't really care about using them other than as the DRM allows, but maybe you can make some headway. Telling manufacturers "you can't use our software in this kind of device" just means they'll have to use different software, of which there is no particular shortage.
The current GPLv3 language tries to take an issue that belongs in legal and market arenas and make it a license term. This hurts the community (which benefits from the work and investment of the device manufacturers) and gains nothing in return.
The market can't fight DRM
Posted Sep 23, 2006 2:55 UTC (Sat) by coriordan (guest, #7544) [Link]
Fighting DRM in the market is a fallacy.
Purchasing choices are often too lumped together to make a definite statement.
Also, the list of options offered to people is designed as part of a strategy, not a just democracy.
Finally, the software/electronics industry can leverage a third party (such as the music industry) to make their DRM'd devices have a plus side.
The market can't fight DRM
Posted Sep 23, 2006 18:50 UTC (Sat) by sepreece (guest, #19270) [Link]
The DRM is there because the content owners insist on it. Device manufacturers have no particular desire to restrict their customers. But, if their customers want access to content that is only available under DRM restrictions, the device manufacturers are willing to do the extra work necessary to allow them to sell such devices.
[The game system market, where the manufacturers typically control the content, is a slightly special case.]
Kernel developers' position on GPLv3
Posted Sep 23, 2006 6:08 UTC (Sat) by dmantione (guest, #4640) [Link]
The devices will exist, sure. However, development costs of those deviceswill be higher than development costs of open source devices. Capitalism
is what makes free software devices exist, you get a high quality OS for
free.
If manufacturers have a cost advantage if they stay DRM free, there will
be DRM free devices. So, lets implement the GPLv3.
Kernel developers' position on GPLv3
Posted Sep 23, 2006 18:58 UTC (Sat) by sepreece (guest, #19270) [Link]
The cost of the OS is a tiny part of the development cost of a consumer device. Manufacturers do, in fact, worry about pennies of device cost, but the difference between the cost of using Linux and using a proprietary OS is a very small piece of the cost. Note that a lot of the device companies are using it to replace OSes that they wrote themselves. It's access to software that runs on Linux that is the big driver, and in many cases that is paid for under dual licenses, specifically to avoid licensing issues.
Manufacturers won't build devices they don't see a market for. A cable box that cable companies won't allow on their network won't have much market. A music player that won't work with content-owners' restrictions won't have much of a market. A cell phone that the FCC won't accept or that carriers won't sell won't have much of a market.
It's not hte manufacturers who want DRM, it's the CUSTOMERS who want the things that they can only have if they accept DRM. You can't fight that with a software license.
Kernel developers' position on GPLv3
Posted Sep 25, 2006 10:23 UTC (Mon) by anandsr21 (guest, #28562) [Link]
This is the same argument that BSD guys would give. They are the ones saying that their license is business friendly. But you know what, GPL is the more business friendly because of the prisoners dilemma. It forces all the companies to cooperate, while the BSD favours the one not playing fair. Similar is the difference between GPLv2 and GPLv3 regarding the DRM. the GPLv3 will in the long run turn out to be the one that survives better because it will again force companies to play fair rather that hiding behind DRM.
You are afraid that the big businesses will run away if they see the DRM is not allowed in Linux and Linux will suffer. But the question is again of the Prisoners Dilemma. Do you see any reason (apart from GPLv3) why they will not use DRM? And don't give me the bull**it about benefits of sharing, the prisoners dilemma guarantees that they will not share. If there will not be appreciable number of important programs that are not GPLv3 we should see very easily in the future a plethora of Tivoised devices.
You say that GPLv3 cannot block the progress of devices containing DRM. But at least it will provide an economic reason for not using DRM. Without that reason there is nothing that can block the progress of DRM.
If the kernel developers cannot be bothered to think beyond total domination of Linux they should at least let the other people think of the future.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 22:15 UTC (Fri) by emk (subscriber, #1128) [Link]
I can see two possible futures:
* In the first future, I'm surrounded by devices running Linux, but none of them are hackable. In each case, the hardware will only load the vendor's own firmware. And all each of these devices will be loyal to somebody else, and ultimately beyond my control.
* In the second future, I'm surrounded by devices running Linux, and each is (in theory) as hackable as the LinkSys routers.
Sure, the desktop may escape the ravages of DRM. But what good is that, if the 50+ little devices I'll own in 10 years are hostile to my freedom? I support the anti-DRM goals of the GPLv3, as both a developer and a user.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 23:02 UTC (Fri) by gnb (subscriber, #5132) [Link]
What about the third future where you are surrounded by devices thatare neither running Linux nor hackable? Surely this is even worse since
you don't even have access to the code for the purpose of running it on
different hardware? Pushing vendors towards completely closed systems
(which is of course an open question, some people see this as a likely
consequence of GPL v3, others don't) would seem to be a clearly bad
outcome.
Kernel developers' position on GPLv3
Posted Sep 23, 2006 8:00 UTC (Sat) by beoba (guest, #16942) [Link]
How would that be any better than an unmodifiable Linux?
Kernel developers' position on GPLv3
Posted Sep 23, 2006 10:42 UTC (Sat) by gnb (subscriber, #5132) [Link]
It would clearly be worse. That was my point: use of Linux in embeddedsystems is appealing, but it's usually not the only realistic choice (for
one thing embedded OSs are generally priced far more flexibly than desktop
ones) and simply having all the device manufacturers walk away and choose
proprietary OSs achieves nothing. It doesn't prevent the spread of DRM and
it cuts off a useful source of development effort for the kernel. As other
posters have said, changes in legislation are probably a more realistic
way of tackling DRM. There seems to be a perception that manufacturers
have no choice and therefore that relicensing the kernel can be used as a
way of forcing policy changes on them. Now, I'm less averse to that idea
than some of the kernel developers seem to be, but my experience is that
the premise is just false.
Kernel developers' position on GPLv3
Posted Sep 24, 2006 2:52 UTC (Sun) by jstAusr (guest, #27224) [Link]
The polititions are purchased by the corporations, that is likely an unrealistic way of tackling DRM. If a device isn't hackable it really doesn't matter which non-free kernel is being used. At that point the kernel is only a marketing ploy. The kernel developers are only looking at the corporations as users of the kernel, the end non-corporate users are not even being considered. Being able to purchase a bunch of devices with non-free kernels is not interesting.
Kernel developers' position on GPLv3
Posted Sep 25, 2006 10:36 UTC (Mon) by anandsr21 (guest, #28562) [Link]
So you say that you will have less to pay with if corporations don't use linux. Although for the end user it will not make a bit of a difference whether it is a GPLv2 code in the device or it is a closed source software. I can see where Stallman is going and where Kernel Developers are going. I am sure where my loyalities lie. I am just a user.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 23:09 UTC (Fri) by smoogen (subscriber, #97) [Link]
I see a third future where you will have both around you. Look at cars.. most cars/trucks/etc are not hackable in the way they were in the 50's and 60's.. but some are and those the ones that people who love to hack on hardware have in their garages. The people who really don't give a rats ass that they could put in a bigger engine will buy a car that gets them from point a to b with a DVD player in the back just like they always have (no matter how many times at Thanksgiving dinner Uncle Fred says you should buy a XYZ car becuase its one he can work on for you.)
The hackable cars exist because there is a niche money market for it... not because it is better etc. I would love to see a world where everything is hackable.. but I have also come to realize that 99.99% of the world could care less beyond their four "freedoms": sex, food, sleep, and relaxation.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 23:32 UTC (Fri) by tglx (subscriber, #31301) [Link]
> ... And all each of these devices will be loyal to somebody else, and ultimately beyond my control.
GPLv2 grants you usage when you abide to give the changes to the source code back (in form of source code). There is no distinction of user in the sense of the hardware manufactures who uses it for his product and the end user who uses the device which was made by the manufacturer using the code.
GPLv3 is trying to get influence on the way a hardware manufacturer has to do his business. Is there any substantial given right to do so ?
Where do you draw the line ? Is Intel obligated to hand you out their CPU design, just because the CPUs are able to run your code ?
I don't like DRM as the guy next door, but nobody forces me to buy hardware which I don't like.
Your 50+ little devices are a strawman argument for some kind of ethereal freedom.
My freedom is to decide what I buy and what I hack on and for this I do not need paternalism by RMS.
tglx
where in the draft?
Posted Sep 23, 2006 3:00 UTC (Sat) by coriordan (guest, #7544) [Link]
What part of the draft requires CPU designs from Intel?
Such statements are the reason that the gplv3.fsf.org requires people to attached their comments to a specific sentence.
where in the draft?
Posted Sep 23, 2006 15:52 UTC (Sat) by tglx (subscriber, #31301) [Link]
I said:
"Where do you draw the line ? Is Intel obligated to hand you out their CPU design, just because the CPUs are able to run your code ? "
I nowhere said that the GPLv3 draft is requiring this. I was pointing out in which direction this might go, if you are thinking beyond the rim of the TIVOed hardware.
tglx
where in the draft?
Posted Sep 24, 2006 1:59 UTC (Sun) by coriordan (guest, #7544) [Link]
Well, if your scenario was hypothetical, you've nothing to worry about since nobody has suggested going that far in that direction.
where in the draft?
Posted Sep 24, 2006 23:53 UTC (Sun) by PaulMcKenney (subscriber, #9624) [Link]
Not yet, anyway...
where in the draft?
Posted Sep 25, 2006 5:45 UTC (Mon) by xoddam (subscriber, #2322) [Link]
> Not yet, anyway...
If and when the FSF is in a position to go that far (in the draft of the
GPLv9, say) ... then it will have secured not only software freedom but
also design freedom. Onward and upwards!
where in the draft?
Posted Sep 25, 2006 14:55 UTC (Mon) by sepreece (guest, #19270) [Link]
And they'll still be claiming "Oh, these chages are completely in the spirit of GPLv2..", which they'll be able to do, of course, because "in the spirit of" has no legal meaning or clear definition...
Kernel developers' position on GPLv3
Posted Sep 23, 2006 8:05 UTC (Sat) by beoba (guest, #16942) [Link]
Nobody forces you to use code which you don't like, either. If you don't like software that's licensed with GPLv3, then don't pretend that you're entitled to a free ride.
Usage of GPLv3 is a decision that's ultimately left to the creator of the software, not the user. The user is left with the decision of which software to use.
Kernel developers' position on GPLv3
Posted Sep 23, 2006 19:01 UTC (Sat) by sepreece (guest, #19270) [Link]
Well, I think that's what the kernel folks just said - it's their choice and they choose GPLv2...
Kernel developers' position on GPLv3
Posted Sep 24, 2006 3:16 UTC (Sun) by jstAusr (guest, #27224) [Link]
So why are they blaming the FSF when it is the kernel hackers that are making the choice to allow the kernel to be used in non-free ways? It is their choice, it is their responsibility. The FSF hasn't changed their goals they are just responding to new circumstances and doing what they have promised their users since the beginning. I have no dought that the device manufacturers and media companies will take the kernel hackers response as a green light to use more spyware and lock down their devices even more.
Kernel developers' position on GPLv3
Posted Sep 25, 2006 15:02 UTC (Mon) by sepreece (guest, #19270) [Link]
I don't think they're "blaming the FSF" for anything except potentially fragmenting the development community. THey're just saying that GPLv3 draft 2 is not in the same spirit that they licensed their code under and they do not intend to change to use the new version if it contains the indicated additional conditions.
I do agree that the FSF is pursuing its goals as it did from the beginning, and that like every politically-oriented organization, it is interpreting success as a mandate to expand its reach. Many organizations find out that overreaching erodes their support base, eventually to the point that their community splinters and their group becomes marginal.
Kernel developers' position on GPLv3
Posted Sep 23, 2006 0:58 UTC (Sat) by Felix_the_Mac (guest, #32242) [Link]
"There is little (if any) comprimise in the wording. eg: if end-user restrictions are against the free software philosophy - why have a bloody licence in the first place?"
Because the GPL v2 is the license which has generated the ecosystem that we have today. In the terms of this ecosystem (i.e. of developers) the fact that a Tivo user cannot reprogram his device is not a major concern. The developers still have any _useful_ changes that Tivo have made to the GPL software.
Kernel developers' position on GPLv3
Posted Sep 23, 2006 3:46 UTC (Sat) by dlang (guest, #313) [Link]
besides which, tivo doesn't make it impossible to hack their devices (I have three hacked tivo's in my house right now), they do make it hard, but as the modchips for the Xbox and other game systems have shown even extreme modifications can be packaged to be relativly easy to install.
the real battle is against DMCA type laws that make it illegal to modify systems. such laws can cause far more harm then _any_ technological measures the manufacturer could impose.
and once you break through the outer shell of protection it's FAR easier to modify a device that you have the source for then one where you have to reverse engineer every step along the way.
Kernel developers' position on GPLv3
Posted Sep 25, 2006 10:41 UTC (Mon) by anandsr21 (guest, #28562) [Link]
Can you tell us what other protections they could add that would make it more difficult, without affecting their margins. I am sure they have tried as much as possible.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 20:08 UTC (Fri) by Tester (guest, #40675) [Link]
I dont know if I have missed something, but can't the DRM clause just be ignored by adding an additional permission? Like "Linux license is gplv3 + you are allowed to distribute without giving crypto keys and to implement DMCA technological protection measures". Would that solve the problem for you?
And isnt destroying software patent portfolios just what we are trying to achieve. Since software patents are considered by most Free Software developers to be BAD BAD BAD. And even if the kernel stays under the GPLv2, the FSF's code will be under gplv3, so we are pretty much guaranteed that any Linux distributor except for tiny embedded systems will have to do accept the license. Except if you plan on forking gcc, glibc, binutils, etc.
But I agree that the additionnal restrictions clause is nasty for license proliferation..
Kernel developers' position on GPLv3
Posted Sep 22, 2006 22:45 UTC (Fri) by nix (subscriber, #2304) [Link]
That would be worse than staying with GPLv2: such a license (with an`additional permission' would not be GPLv3 *nor* GPLv2 compatible.
Kernel developers' position on GPLv3
Posted Sep 23, 2006 19:30 UTC (Sat) by Tester (guest, #40675) [Link]
> That would be worse than staying with GPLv2: such a license (with an> `additional permission' would not be GPLv3 *nor* GPLv2 compatible.
If you read the GPLv3 draft, you can it would be GPLv3 compatible (and maybe only GPLv2 compatible).. Those license both state that you cannot add more restrictions, but you can always add more permissions. That's why the X11 license is GPL compatible..
Kernel developers' position on GPLv3
Posted Sep 22, 2006 23:23 UTC (Fri) by tbird20d (subscriber, #1901) [Link]
And even if the kernel stays under the GPLv2, the FSF's code will be under gplv3, so we are pretty much guaranteed that any Linux distributor except for tiny embedded systems will have to do accept the license.This is not the case. I work with several large consumer electronics companies, and I can assure you that the balkanization referred to by the kernel developers in the position statement is a very real possibility.
Kernel developers' position on GPLv3
Posted Sep 23, 2006 5:17 UTC (Sat) by lutchann (subscriber, #8872) [Link]
Agreed. It's not unlikely that the embedded market will turn to some yet-to-be-invented hybrid environment, with Linux as the kernel and something non-FSF running in userspace. I imagine we'll see various embedded vendors each selling their own closed source POSIX-compliant userspace kit (libc + basic utils) with varying degrees of support for popular non-GPLv3 packages such as Apache.
It would be sad to see the embedded market lose the benefits of commoditized software, but that's a far more likely scenario than RMS forcing the world to give up DRM. Nobody wants to see the NAS market move from Samba to six different broken CIFS packages or the STB market move from FFmpeg to six different broken AVI demuxers, but if the FSF is successful in tearing the industry in two, that's exactly where we're headed.
Kernel developers' position on GPLv3
Posted Sep 23, 2006 10:49 UTC (Sat) by gnb (subscriber, #5132) [Link]
>Linux as the kernel and something non-FSF running in userspaceIn a lot of devices this has already happened: replacing the GNU
environment with something that will fit into a sensible amount of flash
is often a high priority when trying to do something with Linux on a
cost-sensitive device. The obvious choice at the moment seems to be
busybox + uclibc. This is free software (GPL and, I think LGPL but could
be wrong) and from a look at their mailing list it seems unlikely busybox
will relicense as v3 in the near future.
Kernel developers' position on GPLv3
Posted Sep 23, 2006 19:34 UTC (Sat) by Tester (guest, #40675) [Link]
>> And even if the kernel stays under the GPLv2, the FSF's code will be under gplv3, so we are pretty much guaranteed that any Linux distributor except for tiny embedded systems will have to do accept the license.
> This is not the case. I work with several large consumer electronics companies, and I can assure you that the balkanization referred to by the kernel developers in the position statement is a very real possibility.
I was refering to the computer companies (IBM, HP, Sun, SGI, etc) and not the embedded world. And those have just started getting rid of their own OSes. So yes they could in theory replace the GPLv3 code, but they wont. Because they have discovered how costly it is to do.
Kernel developers' position on GPLv3
Posted Sep 23, 2006 19:27 UTC (Sat) by sanjoy (guest, #5026) [Link]
can't the DRM clause just be ignored by adding an additional permission
You can add additional permissions only for code you contribute, so Tivo wouldn't be able to add such a permission to most of the Linux kernel.
can they coexist?
Posted Sep 22, 2006 20:15 UTC (Fri) by b7j0c (subscriber, #27559) [Link]
i understand from the article that having fsf migrate all of its tools tov3 will create a clerical issue for distros, but in a practical sense, is
there any aspect of the gpl that precludes a distro from shipping a v2
kernel and a v3 toolchain? as far as i know, many prominent distros only
enforce that software included be freely/osi-compliant licensed, not
strictly gpl'd. can anyone clarify for me?
can they coexist?
Posted Sep 23, 2006 9:53 UTC (Sat) by k8to (guest, #15413) [Link]
The "license proliferation" concern is that there will end up somesoftware that is GPLv2 and some that is GPLv3 and that you will not be
able to use source from the one set with the other set.
If people all used GPLv2 as originally written, this would not be
a "problem" as you could always use the clause the GPLv2 license grant
which allows you to license it under a later version to create a combined
work under GPLv3 (or later). If, however, the GPLv3 is sufficiently
unpalatable to a large number of developers, more projects may adopt a
modified GPLv2 that would be uncombinable with software licensed under
GPLv3 only.
I cannot speak intelligently about whether it is kosher to combine works
under GPLv2 with the no-upgrades modified GPLv2.
However, it is true that the Linux kernel developers themselves committed
a kind of license proliferation when they modified their GPLv2 license to
disallow licensing the code under GPLv3. I don't claim that this was a
bad idea, or even unwarranted, but they are now engaging in a little bit
of pot-and-kettle.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 20:31 UTC (Fri) by mckyj57 (guest, #40678) [Link]
I want to express my support for the kernel developers and what they are doing. I too have grave doubts about the GPLv3, and my project will not change over if I have anything to do with it (which I do as original developer).
What is ironic is that at one point I wanted to put an anti-spamming end-use codicil on the GPL, and RMS talked me out of it.
My projects will be migrated to GPLv3
Posted Sep 22, 2006 22:19 UTC (Fri) by emk (subscriber, #1128) [Link]
My projects will be migrated to GPLv3 as quickly as possible, because as a developer, I'm not willing to let third parties restrict my users' freedom.
Remember, 20 years from now, we'll most likely own many smaller devices running Linux, each of which will have access to some of our private data. It's unacceptable that users be prevented from hacking these devices. Who wants to be surrounded by a hundred tattle-tales and spies?
My projects will be migrated to GPLv3
Posted Sep 22, 2006 23:30 UTC (Fri) by mattmelton (guest, #34842) [Link]
I also do not want software I create under the GPL to be altered, extended, encrypted and then sold... no one else the wiser.
While I dont want to say it, isnt not-embracing the anti-drm measures freedom-piracy?
Freedom-pirary :( It has a frightening ring to it.
If more noteworthy lkml hackers would talk openly about this, instead of being timid in the face of the hardworking developers, I'm sure people would come around.
* Actively supporting and encouraging the GPLv3 drafts doesnt mean you have less appreciation for the work done by the v2-supporting club - we owe so much, this is just politics *
My projects will be migrated to GPLv3
Posted Sep 22, 2006 23:39 UTC (Fri) by ehlarson (guest, #40687) [Link]
Third parties will restrict all users freedom; that is a given. They will select software that enables their business objectives.
What they won't be able to do is restrict it using GPLv3 licensed software. This will mean that the thrid parties will be using and funding software that uses a different license. That might be proprietary software or it might be FOSS.
What is going to be the impact of adopting GPLv3? You wont have anyone using your software.
Not willing to accept popularity at the cost of users' privacy
Posted Sep 23, 2006 11:51 UTC (Sat) by emk (subscriber, #1128) [Link]
"What is going to be the impact of adopting GPLv3? You wont have anyone using your software."
Hey, I'm giving the software away for free, right? If I'm not willing to compromise my user's freedom and privacy to make my software popular, that's my ethical choice. If TIVO wants to make DRMed spyware that logs every show a user watches, then they can do it without my help.
I'm very sensitive to privacy issues, and I don't believe that consumer electronics should tattle back to the mothership 24 hours a day. At least with the anti-DRM provisions in GPLv3, you'll always be able to buy cheapo generic hardware (from some bottom-feeder without a software budget), and hack out the spyware and tattletales.
The Linux kernel team's opinion on GPLv3 is moot, anyway--they removed the upgrade clause from the GPLv2 boilerplate, so they'll never be able to use the GPLv3, anyway. But as a developer, I'm glad that GPLv3 tries to preserve the four freedoms for my users.
Not willing to accept popularity at the cost of users' privacy
Posted Sep 24, 2006 3:26 UTC (Sun) by jstAusr (guest, #27224) [Link]
Thank you!
My projects will be migrated to GPLv3
Posted Sep 23, 2006 19:38 UTC (Sat) by Tester (guest, #40675) [Link]
Third parties will restrict all users freedom; that is a given. They will select software that enables their business objectives.What is going to be the impact of adopting GPLv3? You wont have anyone using your software.
They may choose any software they want.. If all I care was that the software be used, I'd place it in the public domain or use the BSD license. But I dont want to help them destroy my freedom and the freedom of others.
What I wish the kernel developers had actually come out and said
Posted Sep 22, 2006 22:43 UTC (Fri) by louie (guest, #3285) [Link]
I just threw a really, really long post at my blog about this, in which I go into what I think the kernel guys were really getting at. But really the critical part is that this is what they could have said, which I think was really the heart of what they wanted to say:“We believe that our particular community of GPL v2 users have come over time to a different definition of freedom than the FSF. We believe that the focus of the GPL should be on the elements that encourage collaborative participation, which include simplicity, enforced code-sharing, and end-user freedom. We reject the FSF’s attempt to define freedom in such a way as to include charged issues like DRM and patents, which our contributors disagree greatly about. As a result, we call on the FSF to stop the current discussion about GPL v3 and create a GPL v2.1, which does not seek to expand the Freedoms of GPL v2 in controversial directions, and instead focuses on strengthening and clarifying the terms of the current GPL so that we can more securely defend the rights and freedoms we believe we currently have, and which we have created a large community around.”This would have been a lot more straightforward and gotten across the true heart of their beef- which I think has a lot of merit, to be honest, even though in the end I disagree with them. I think the discussion would have been a lot better off if they would come out and say it instead of beating around the bush.
What I wish the kernel developers had actually come out and said
What I wish the kernel developers had actually come out and said
Posted Sep 23, 2006 4:25 UTC (Sat) by charris (guest, #13263) [Link]
Nicely done.
What I find odd is that many are calling the more restrictive GPL v3 license freer. It isn't. I would put public domain at the top of the free pile, and certainly the BSD, Boost license, and MIT license rank higher in that regard than the GPL v2. Now, is that sort of unfettered freedom a good thing? I would say it depends. Science and mathematics, I think, belong in the public domain, and perhaps most tax funded projects. But what about free software?
I think it generally the case that in order for a group of people to cooperate for the general good there need to be restrictions, something that prevents some version of the tragedy of the commons. But I also feel these restrictions should be the minimum required to achieve the larger end. So, what is the larger end in this case? The kernel developers seem to have the position that the code should be available and that those who benefit and build upon it should contribute their additions back to the public pool. The GPL v2 seems to achieve this as measured by its success, so why use the more restrictive GPL v3? This argument appeals to me. The GPL also seems to aim at fighting a different battle, the DRM battle, that could be considered outside the narrow goals of the kernel. Such battles would draw the kernel into a larger war that would be a distraction from its technical aims.
I would add that after the DRM there will be something else, there always is. And in the long term, individuals themselves may want the ability to lock down their hardware as a matter of privacy. So this is not just about corporations, it is about having the means to keep other people out of your stuff. We may all wish for such means in the future, so let us not limit developments up front.
Chuck
What I wish the kernel developers had actually come out and said
Posted Sep 23, 2006 8:22 UTC (Sat) by bbrv (guest, #24018) [Link]
Nicely done by you too Chuck!
For us, making DRM part of v3 was too far to reach. A better view/solution can be accomplished
by separating _security_ to be defined in technical terms from _privacy_ to be understood as a
personal choice (see obtaining a new mobile phone vs. a new computer). Privacy is another sort
of "freedom" issue that emanates from the user. The decision gate comes before our choice of
use.
As Chuck correctly observes: "in order for a group of people to cooperate for the general
good there need to be restrictions, something that prevents some version of the tragedy of the
commons." Therein is the bigger and *different* discussion.
Placing these distinctions, which DRM and "security" features become, into the devices we use
make choice an option and the leave the foundational concepts of freedom which define GPL in
tact as they apply to the overall movement. Bringing DRM into GPL was the application of _too
much of a good thing_. It is time to ask FSF to please go back to the drawing board.
Our compliments to the "kernel developers." Good work! Freedom is not free - thanks for the
effort.
R&B :)
What I wish the kernel developers had actually come out and said
Posted Sep 25, 2006 10:54 UTC (Mon) by anandsr21 (guest, #28562) [Link]
"We believe that the focus of the GPL should be on the elements that encourage collaborative participation, which include simplicity, enforced code-sharing, and end-user freedom."
Please remove the "end user freedom" from the list. It is not compatible with DRM. Thank you.
FSF is a end user concerned entity. This all started because of a Printer user. And the latest is because of a PVR user. The problems are the same. The GPL is being thwarted by a technological measure. If it is illegal to remove a technological measure for piracy, why is it legal to use a technological mesure for breaking GPL.
Kernel developers' position on GPLv3
Posted Sep 22, 2006 22:51 UTC (Fri) by k8to (guest, #15413) [Link]
Disingenuous.
That is my takeaway from this position statement. The claims that the
provisions requiring end-user modification to be possible will prevent
encryption applications seem to be wholly specious. The claims that such
a provision is political and therefore unconscionable is just nuts. The
choice of a license such as GPLv2 as opposed to some other license is
_also_ political, but yet no one is making position statements against
this.
I can understand some of the concerns raised here, but they are raised in
a sloppy and ill-considered way.
Kernel developers' position on GPLv3
Posted Sep 24, 2006 18:37 UTC (Sun) by msbrown (guest, #38262) [Link]
Refutation:
I point you to FIPS 140-2 ( http://csrc.nist.gov/cryptval/140-2.htm ).
Yes, GPLv3 (draft 2) code cannot be used in FIPS 140 environments.
You really _don't_ want crypto modules that can be modified by third-parties, not all of whom intend to _improve_ your your module.
Kernel developers' position on GPLv3
Posted Sep 24, 2006 23:04 UTC (Sun) by k8to (guest, #15413) [Link]
That GPLv3 draft two requires it be possible that code be modified andstill perform in its primary function does not require that the crypto
module itself which is used in conjunction with GPLv3 code be modifiable.
I am uncertain if that makes the code usable in a FIPS 140-2 context, but
your comment seems overbroad.
Separately it seems to me an open question whether making it possible to
run code on such a platform after modification, but with a flag that
indicates that it is not original code, would satisfy the GPLv2
provisions as writtten. It is also an interesting question whether it is
desirable that it be possible for same to satisfy these conditions.
Who is responsible for proliferation of DRM?
Posted Sep 23, 2006 0:00 UTC (Sat) by ibukanov (subscriber, #3942) [Link]
I reread the document one more time, and I think I started to understand the position against GPLv3.
A simple question, who is responsible for proliferation of DRM?
Surely it is not hardware vendors who AFAIK would love not to put DRM in most cases but are required by marked realities. Rather, it is end-users who buy DRM-ed media and do not care about their freedom.
So GPLv3 in the current form tries to protect the freedom of those who do not care about it while removing the ability to use GPL-ed software by engineers who hate DRM but forced to put the thing in their boxes by careless end users.
Who is responsible for proliferation of DRM?
Posted Sep 23, 2006 0:41 UTC (Sat) by Felix_the_Mac (guest, #32242) [Link]
Yes, I think you are correct.
The DRM clause specifically protects the end user (by placing restrictions on allowable use on the device manufacturer).
This clause will not mean that companies no longer sell devices containing DRM merely that those devices will not run GPL v3 software.
Who is responsible for proliferation of DRM?
Posted Sep 23, 2006 3:09 UTC (Sat) by coriordan (guest, #7544) [Link]
GPLv3 does not restrict "allowable use on the device manufacturer". It only places conditions (restrictions on the form) on distribution. The manufacture can use and modify the software as they wish, and after they give it to me, I can use it and modify it as I wish. Each of us has the four freedoms.
About device manufacturers not using our code, well, if their goal is to restrict us, then they would be using our code against us - so preventing our work from being turned against us is good.
Who is responsible for proliferation of DRM?
Posted Sep 23, 2006 9:14 UTC (Sat) by Felix_the_Mac (guest, #32242) [Link]
"About device manufacturers not using our code, well, if their goal is to restrict us, then they would be using our code against us - so preventing our work from being turned against us is good."
I think you have to look at the costs and benefits:
+ Your work cannot be used against you
- Manufacturers of phones, media players, DVRs, consoles will stop using Linux. Maybe also voting machines, hospital equipment, nuclear power station equipment. Any area where the maufacturer believes that it is preferable that the user not be able to modify the running software.
- Any useful input they may have had (such as improvements for embedded devices, real time operation) will not arise.
- The GPL community is fractured between GPL2 and GPL3. Distributions have to drop packages from one side or the other.
- The GPL ecosystem grinds to a halt
There'll be no halt
Posted Sep 23, 2006 12:50 UTC (Sat) by coriordan (guest, #7544) [Link]
There will be no big split. GPLv3 will lose compatibility with "v2 only" software (which there is very little of, Linux being the only big example), but it will gain compatibility with all the Apache licensed software, plus eclipse licenses software and some other free software licences. This heals splits.
We might lose the contributions of a handful of DRM-or-bust projects, but we were never dependent on them anyway. Their contributions aren't enough to tempt us to give up the 23 year idea of share and share alike, I can do what I want with the software and you can do what you want with it.
Free software is written by hundreds of thousands of people who are empowered to do so because the licence ensures they are free to do so. Development will never grind to a halt, and the most important thing we have to do to keep the development system working is to always ensure that everyone is free to become a developer and to do what they want with the software (and when they pass it along, the must pass it on with the same freedoms for the next person).
There'll be no halt
Posted Sep 23, 2006 13:13 UTC (Sat) by Felix_the_Mac (guest, #32242) [Link]
"There will be no big split. GPLv3 will lose compatibility with "v2 only" software (which there is very little of, Linux being the only big example)"
Isn't this a show-stopper if the kernel is not going to move to the current draft v3?
How do you build a distribution if everything except the kernel is GPL v3?
If that is the case, then I think the best solution is for the major sticking points of v3 to be dropped (DRM & patents??) and the useful work including increasing compatibility with other licenses, including the LGPL, clarification of meaning and changes for the purpose of internationalisation to go ahead.
This has the possible effect of reducing license proliferation and invigorating the OSS ecosystem rather than the reverse.
There'll be no halt
Posted Sep 23, 2006 13:30 UTC (Sat) by coriordan (guest, #7544) [Link]
A distribution is an aggregation of software packages, not a combined work (using copyright law definitions). The software packages are not necessarily linked. An aggregation of packages doesn't require compatible licences (this is why Apache HTTP server and GNU/Linux can be shipped on the same CD).
GPLv2 section 2 says this is ok, and so does GPLv3 in section 5 ("...Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.").
Copying code from Linux into GPLv3'd packages or vice versa is a separate issue, and there _are_ some potential issues there, but there are solutions to those too. Dual licensing is one obvious one (and this can be done without dual licensing the whole kernel), licence exceptions is another. Or, of course, the best solution would be if consensus could be formed on supporiting GPLv3 (some changes could be made to GPLv3, but protecting the four freedoms to use, study+modify, redistributed, and publish modifications are not up for compromise - but the methods for how to do this in the face of DRM and patents are up for debate and suggestions are really welcome at gplv3.fsf.org).
There'll be no halt
Posted Sep 24, 2006 1:46 UTC (Sun) by grahammm (guest, #773) [Link]
No it would not be a show stopper. There is no connection between the kernel licence and the application licences. Otherwise it would not be possible to run GPL licensed applications on proprietary, non free, operating systems, nor to run closed source applications on free operating systems.
There'll be no halt
Posted Oct 14, 2006 18:50 UTC (Sat) by kreutzm (guest, #4700) [Link]
"Free software is written by hundreds of thousands of people" - where do you get that estimate from? A few thousand, I would guess, maybe 20,000 or a little more. Debian has roughly 1000 members, I remember a figure a while back that the kernel had a few hundred serious contributors.
Unless, of course, you count every person registered on Source Forge. This maybe technically speaking correct then, but quite misleading, as even Debian ships only small fraction of this software and most people are quite happy with the free software shipped.
If you have a sound number, I'd definitly be interested.
There'll be no halt
Posted Oct 14, 2006 18:57 UTC (Sat) by halla (subscriber, #14185) [Link]
KDE alone has nearly a thousand committers, so, yes there will easily behundreds of thousands of developers working on free software projects even
if you discount the sourceforge projects that never progressed beyond an
initial idea. This world of ours is _big_.
Kernel developers' position on GPLv3
Posted Sep 23, 2006 0:25 UTC (Sat) by PaulMcKenney (subscriber, #9624) [Link]
So, is the thought that GPLv3 might be a victim of the http://en.wikipedia.org/wiki/Second_system_effect ?
Paul E. McKenney (my opinions, not necessarily those of my employer)
Kernel developers' position on GPLv3
Posted Sep 23, 2006 1:20 UTC (Sat) by vinicius.vbf (guest, #40689) [Link]
Balkanisation and jeopardise? Did you mean BalkaniZation and jeopardiZe?:)
Kernel developers' position on GPLv3
Posted Sep 23, 2006 1:39 UTC (Sat) by sbergman27 (guest, #10767) [Link]
"""Did you mean BalkaniZation and jeopardiZe?"""
http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&...
Brittish variant.
"Balkanisation" is not listed, though.
For anyone looking for GPLv3 explanations:
Posted Sep 23, 2006 2:09 UTC (Sat) by coriordan (guest, #7544) [Link]
FSFE have made and published 8 transcripts of GPLv3 talks, including the Q&A sessions.
Arguments for the changes in v3:
- Protection against patent litigation for distributors and developers
- Licence compatability - there is no beneficial reason for the GPL to be incompatible with the Apache or Eclipse licences, so v3 will not be incompatible
- Internationalised wording - unlike 1991, we can now draw on the input of hundreds of lawyers from tens of countries to make the most solid document possible
- DRM - because the GPL was never meant to let Tivo insert unremovable spyware or to let them ban adding certain features from modified versions
- Common sense fixes such as permitting BitTorrent and fixing the "automatic termination" clause
For anyone looking for GPLv3 explanations:
Posted Sep 23, 2006 14:59 UTC (Sat) by ibukanov (subscriber, #3942) [Link]
> DRM - because the GPL was never meant to let Tivo insert unremovable spyware or to let them ban adding certain features from modified versions
But GPLv3 does not fix this. Tivo uses Linux because it is cost-effetive for them. Moreover, they can get away with unremovable spyware because their users want to buy boxes with spyware and do not care about their freedom.
With GPLv3 Tivo could either use ROM chips or proprietary OS. Yes, that would be more expensive for them, but if from a business point of view having spiware and GPLv3-Linux in ROM would be more profitable, then just GPLv3 Linux in re-writable memory, they would choose ROM.
Or consider another possibility. Tivo can provide you with GPL-v3 derived sources and all the build keys, but would not provide you with a compiler. That is, their build process may require to use a particular physical box where you suppose to type the key manually to unlock the the real key. GPLv3 does not cover this AFAICS.
So GPLv3 has very narrow view on technical measures that prevent boxes from hacking. That demonstrates IMHO that it does not fully grasp the realities of embedded world. Thus FSF should really wait with touching GPL until a better picture emerges or take a different approach.
For anyone looking for GPLv3 explanations:
Posted Sep 23, 2006 17:22 UTC (Sat) by k8to (guest, #15413) [Link]
I think the point of the "anti DRM" clause is not to preventfreedom-limiting technical measures from existing, or to prevent
freedom-limiting technical measures to be used in systems that include
GPLv3 code. It is simply to prevent freedom-limiting technical measures
to remove the freedoms intended in GPLv3 code.
Thus, in a TIVO, GPLv3 components should be modifiable and replacable,
is the goal. TIVO could simply implement their logic they do not intend
to be replaced in a non-GPLv3 body of code, and apply technical measures
to prevent this code from being changed, even if the box is running GPLv3
code in other portions.
I think your argument about the ROM question in the embedded environment
is a good one, and that the idea of waiting for further understanding is
a good suggestion. However, I do think that devices with non-updatable
firmware is going to approach 0% over time.
For anyone looking for GPLv3 explanations:
Posted Sep 23, 2006 19:20 UTC (Sat) by sepreece (guest, #19270) [Link]
Since the kernel presumably isn't going to change, this is all pretty academic, but...
Changing to ROM would (as I understand it) be cheaper than flash. It would be interesting to think about whether you could put the kernel in ROM but provide a flash-based patch block for any needed updates. Lots of systems used to work that way. Not sure what the license impact would be, but it would probably be doable.
The problem with the idea of locking down the app code and leaving the kernel replaceable is that the kernel is privileged, making it hard to control what it could do to the rest of the system. It would probably be necessary to move some current kernel functionality (some of the device drivers) out of the kernel, to protect data paths from sniffing. Should be doable.
There are lots of interesting questions left around the current GPLv3 language. It talks to making keys available, but, of course, keys are not the only way you could assure that the software in the device is the software you put there...
For anyone looking for GPLv3 explanations:
Posted Sep 23, 2006 19:48 UTC (Sat) by Tester (guest, #40675) [Link]
Changing to ROM would (as I understand it) be cheaper than flash. It would be interesting to think about whether you could put the kernel in ROM but provide a flash-based patch block for any needed updates. Lots of systems used to work that way. Not sure what the license impact would be, but it would probably be doable.The license would still apply, because the code in the Flash would still most likely be derivative from the GPL code and you'd have to provide the key for the flash. The only reason to do that was that flash was much much more expensive than rom.
For anyone looking for GPLv3 explanations:
Posted Sep 24, 2006 1:56 UTC (Sun) by sepreece (guest, #19270) [Link]
First off, whether the code was derivative of the GPLed work would depend on the particular patch and, possibly, on the way the patch facility was implemented.
As to the viability of ROM vs flash, for some kinds of device (like music players) ROM might be just fine. It's unlikely a manufacturer would want to reflash them in the field. For a phone or a DVR, however, I agree that some kind of update capability is probably a necessity.
For anyone looking for GPLv3 explanations:
Posted Sep 24, 2006 23:10 UTC (Sun) by k8to (guest, #15413) [Link]
For the record, music players do regularly flash-upgrade the firmware.
One of the reasons flash was created was because to be able to create
high density programmable rom, which is not achivable via other methods
with the levels of density flash has achieved. It maybe possible to
create traditional roms with the density required, but there are massive
logistical problems that go along with non-programmable ROM in terms of
wasted parts, large runs being required, the cost of bugs, and so on.
I believe that the day of non-programmable rom has passed, and that this
is why free software ethics are now being applied to firmware, because
there is no longer the unchangeability issue that made the argument moot.
For anyone looking for GPLv3 explanations:
Posted Sep 25, 2006 15:08 UTC (Mon) by sepreece (guest, #19270) [Link]
You're right about music players - I forgot the various times I have updated my iPod's software. I do htink there are some devices small and narrowly purposed enough to be ROM-suitable, but I agree that mainstream music players were a poor example.
GPLv3 not going far enough?
Posted Sep 24, 2006 2:14 UTC (Sun) by coriordan (guest, #7544) [Link]
You are right that there will still be ways in which the freedom of GPL'd software users can be restricted. GPLv3 could go further, but each condition has to be considered in terms of how much inconvenience it adds and how effective it will be.
The clauses that are in draft 2 of GPLv3 are judged to be the minimum required in order to prevent large scale abuse of GPL'd software. They are fairly minimal and are focused on protecting developers and distributors and on reducing bureaucratic incompatibilities, and look at the number of complaints?
Stallman probably wants more freedom protecting clauses to be added, but the GPL has to be a licence that people want to use. (At the same time, the goal of protecting share-and-share-alike will not be compromised for popularity, even if Linux developers ask for it.)
GPLv3 not going far enough?
Posted Sep 24, 2006 2:44 UTC (Sun) by ibukanov (subscriber, #3942) [Link]
> The clauses that are in draft 2 of GPLv3 are judged to be the minimum required in order to prevent large scale abuse of GPL'd software.
My problem with the clause is that it would not prevent anything in the embedded world. I.e. it is possible to defeat it completely AFAICS with simple tricks that would not add any cost to the hardware. As such the clause is dangerous as it give people an illusion of anti-DRM provisions for their free software while adding extra legal complexity for already non-trivial text with unclear consequences.
Here is one detailed possibility of abusing GPLv3. A company can make a device that can run either a signed or unsigned kernel. For unsigned kernel the device would require to enter a private key, which it would then use to sign the kernel and make the kernel available for access so it can be extracted and distributed if necessary. Now the trick is that to enter the key, you would have to use an extra hardware that the company would not sell. So you would get the source, the complete build system and all the encryption keys, but still you would not be able to change the software.
theory and practice
Posted Sep 24, 2006 3:15 UTC (Sun) by coriordan (guest, #7544) [Link]
The problem tackled by GPLv3 is worth tackling because someone is already doing it (Tivo). Other cases might be being ignored either because they are not yet being exploited by anyone, or because no one has suggested a good way to prevent them.
Hopefully, no company will find a commercially viable way to do what you've suggested is possible. If it becomes a problem, hopefully someone will suggest a way to fix it in the licence.
It might happen that something cannot be addressed by the licence. In the future, we might have to lobby our legislators or the hardware manufacturers. But, for whatever problems can be solved or reduced by the licence, we should figure them out the solutions this year.
theory and practice
Posted Sep 27, 2006 9:36 UTC (Wed) by RayCromwell (guest, #40771) [Link]
I'm not sure if the loopholes could be closed. Consider for example, a device which uses virtualization to run a GPLv3 kernel. The user can replace it all they want, but it will be run inside of a protected domain without full access to the underlying hardware. So no one stops you from hacks, but they do stop you from accessing 100% of your hardware.
This is probably going to be the way the Playstation 3 runs Linux for example, so that homebrew software can be written unsigned by Sony, or signed by Sony for a small fee, and the kernel may be freely upgraded and replaced, but total access to the full power of the PS3 hardware will be blocked, especially BluRay Video access, access to all of CELL and RSX hardware features.
I'm also not sure as a user, but hacker, I would even wish Sony be forced to completely open the device, since Sony is heavily subsidizing an $800-1000 device which is nearly bankrupting them for me to play games on, and selling it for $400-500. The benefits of full access for me, as well as a vast library of high-definition movies, probably outweigh the costs of not having it hackable at all.
What if Tivo "tivo-ized" their boxes with virtualization by allowing you to upload and run whatever kernel you want, except that the components of the system which capture video systems and store them to disk, as well as dump them into the framebuffer of the display chip, were run outside the Linux kernel in a trusted module. The kernel and user applications could view information about the show database, channel guide, and could control media functions like play, rewind, fastforward, but all aspects of video decoding were delegated to special proprietary chips and protected code running in another domain?
Seems to me that there are routes for DRM devices to take where they can leverage GPL software while still locking down the media content on the device so that it cannot be circumvented by modifications to the kernel and userspace programs. As an extreme example, for a video player, they can simply stick a sufficiently powerful co-processor/media decoder chip that runs a mini-OS that does nothing but decrypt and decompress media streams. This will increase the cost of the HW, but their business model may include subsidizing hardware anyway.
This would not satisfy those clamoring for user freedom because your usage of content you purchased would still be managed on lease/rent/copy restricted rights management.
-Ray Cromwell
p.s. one other comment, is there are a number of people acting like licenses with non-viral clauses aren't successful because people make private changes and don't give back. But I use a large amount of code licensed under Apache, and I would argue strenuously with anyone who claims the Apache projects are failures or that corporate interests aren't giving back code. Perhaps it is possible to have freedom and benefits of open source without force, as long as there is a critical mass of fair minded people willing to work. The "Prisonner's Dilemma" keeps getting brought up, but this is really the "Volunteer's Dilemma". Much of our civil society rests on the fact that an astonishingly high number of people are honest and fair. Yes, there are plenty of leeches in the system, we here about abuses of government services and charity all the time, but IMHO, true freedom is also the ability to tolerate some level of failure, that some people will cheat, and some projects will fail.
Ironically, GPLv3 (and to a lesser extent, GPL overall) seems like "DRM for developers and device manufacturers". Content producers don't want to tolerate that a small percentage of people will be software pirates and take without paying authors, and it seems the GPL doesn't want to take the chance that a small number of people will be code leeches.
For anyone looking for GPLv3 explanations:
Posted Sep 24, 2006 9:26 UTC (Sun) by petegn (guest, #847) [Link]
I am not a developer apart from a minor hack of the floppy driver for my perticular Mother board (an old 386 baseed bord some years ago) but it strikes me this whole thing needs looking at in a slightly different direction
The question of the Tivo'ised software quite simple in reality
You choose to use open sourced software in your device (the maker this is to ) therefore you are not allowed to encode , encrypt or other such methods ANY part of the code or systems used no keys to do this that or other .
As for DRM well if enough people could be bothered to act on the problem it would be dealt with in short order but too many people are of the "SHEEP" breed and blindly follow ,If the "SHEEP" would remove the BLINKERS the the content providers would soon be wetting there collective nappies because there would be NO income for them because no one would be buying ther vcrap to start with .
but alas we live in a world dominated by "SHEEP" and "SHEEP SH*****S" that contine to milk said "SHEEP"
p
For anyone looking for GPLv3 explanations:
Posted Sep 25, 2006 16:01 UTC (Mon) by sepreece (guest, #19270) [Link]
Most users are just that - users. They don't particularly care about using content in ways that the DRM systems prevent (though some of the proposed next-gen systems will probably irritate more of them). But, by all means, educate the users and try to get them to push back on the content providers.
The trade off you are asking for (if you use free software, you cannot keep people from modifying it in the device) is not generally agreed to be part of GPLv2 (though some people do believe it was in the spirit or intention of v2, many others do not). The kernel developers' letter expressed their opinion that it should not be part of the mainstream GPL in the future, either.
So, the choice you posit in your third paragraph is not a fact, it is a question to be resolved in the debate over GPLv3...
Kernel developers' position on GPLv3
Posted Sep 23, 2006 8:58 UTC (Sat) by timtas (guest, #2815) [Link]
I too think that, if you replace GPLv2 with BSD and GPLv2 with GPL, this position might well be put on any randon BSD advocacy list. GPL always had the spirit of "you may use it, but you have to play fair", while BSD rather goes for "do what you want, we don't care about the freedom of the end user, we just want as many people as possible to use our work, thieves included".
While I don't agree with this position, I still understand people thinking that way and don't think it is fundamentally wrong to do so. I just wonder why Greg and all like the GPLv2 in the first place. Maybe because they have to, as Linux is GPLv2?
What I really find appalling are all the FUD threats, like "it would potentially jeopardise the entire patent portfolio of a company simply by the act of placing a GPLv3 licensed programme on their website." This is a totally speculative exaggeration out of any proportion. I'm sure you are well aware of that, since you wrap this in the usual "well, some lawyer may see it this way".
You might not have been forced by your employers to write this, but I'm sure that IBM and Novell will really like you a lot for this piece of work.
Tim
Kernel developers' position on GPLv3
Posted Sep 23, 2006 19:25 UTC (Sat) by sepreece (guest, #19270) [Link]
What you seem to be missing is that they still support GPLv2. The complaint is that GPLv3 asks for more restrictions than GPLv2 did, and the kernel developers apparently think they go too far.
As to the questions about the patent clause, I don't think it's FUD. I don't think anyone but a lawyer could tell you how serious the danger would be, but there definitely is some risk there.
I doubt that any of the kernel developers would want to apologize for hte fact that their employers are sinking millions of dollars into supporting and developing Linux and other OSS projects. You seem to be unwilling to admit that anyone could possibly just disagree with you...
Kernel developers' position on GPLv3
Posted Sep 26, 2006 13:47 UTC (Tue) by timtas (guest, #2815) [Link]
I have not missed that they still support v2, I just wondered why...
> I doubt that any of the kernel developers would want to apologize for hte
> fact that their employers are sinking millions of dollars into supporting
> and developing Linux and other OSS projects.
Sorry, but I don't quite get this sentence. I have no problem that they work for companies supporting Linux, I even have no problem with those companies at all. I only doubted they speak for themselves, because their language and their arguments sounded very much like business talk and not like personal opinions on things.
> You seem to be unwilling to admit that anyone could possibly just
> disagree with you...
Oh, really? Would I participate in this discussion, then? A lot of people disagree with the current draft of GPLv3, I have no problem with that at all. I'm not even suggesting in the least the kernel should move to GPLv3. What I didn't like was the tone of the position and generally that people put their "own" position while constantly referring to companies, distributors and all.
I think the companies should speak for themeselves in that matter, their view is certainly valid to consider.
Kernel developers' position on GPLv3
Posted Sep 23, 2006 21:44 UTC (Sat) by sepreece (guest, #19270) [Link]
Here's what I think is of concern to people who hold patents: "If you convey a covered work, you similarly covenant to all recipients, including recipients of works based on the covered work, not to assert any of your essential patent claims in the covered work."
Note that you are giving this covenant for a work based on the work you created, without knowing up-front what is in that derived work. There is nothing here that says that work could not infringe on patents you hold that were not used in the work that you released.
That is, you release work A, granting a covenant to allow downstream users to use any patented technology in that work. Downstream user creates a derivative work AB that adds to it an extension that infringes a patent that you hold, but that was not used in the work A. The current language seems to say that you are giving away the right to use ANY patents you hold that anyone uses in such a derived work.
[And, yes, I have filed a version of this at gplv3.fsf.org]
The question is how a court would read "the covered work" - whether it would take it to mean the original covered work or any downstream modification based on the original work. Most people would read it to mean the original work, but there is at least a modicum of ambiguity, and that's where lawyers live. If they mean it narrowly, they should rewrite it to make the language clearer.
Kernel developers' position on GPLv3
Posted Sep 26, 2006 1:44 UTC (Tue) by sanjoy (guest, #5026) [Link]
That is, you release work A, granting a covenant to allow downstream users to use any patented technology in that work. Downstream user creates a derivative work AB that adds to it an extension that infringes a patent that you hold, but that was not used in the work A. The current language seems to say that you are giving away the right to use ANY patents you hold that anyone uses in such a derived work.
As you quoted from the GPLv3:
If you convey a covered work, you similarly covenant to all recipients, including recipients of works based on the covered work, not to assert any of your essential patent claims in the covered work.
This language answers your objection, I believe. Here's how. Suppose that you distribute a modified version of GNU diff v8 and GNU diff v8 uses one of your patent claims. Then, yes, you've given up the right to assert that patent claim against a derivative work of GNU diff v8. And that's fair: You shouldn't be able to sue your recipients over what you distribute. You also give up the right to sue them for using your patent in GNU diff v8a, a derivative work of GNU diff v8.
But now one of the recipients makes GNU diff v9 by implementing a tricky compression method on which you hold patent claims. You can still sue him or her because you promised only "not to assert any of your essential patent claims in the covered work" (emphasis mine). You did not make the broader promise: "I will not assert any of my essential patent claims in the covered work or in any of its downstream versions."
Very ill-thought-out position
Posted Sep 23, 2006 11:35 UTC (Sat) by rmorgan11 (guest, #40695) [Link]
First, the appropriate place to discuss the GPLv3 is via gplv3.fsf.org. The FSF is doing everything it can to understand all objections people have to the current draft of GPLv3. This is not a take-it-or-leave-it draft. These kernel developers are doing the Free Software community a big disservice by grandstanding in public instead of working with the FSF and its law team.
However, when we read the misstatements and FUD in their "position", we have to wonder what their agenda is. For example:
1. "The current version (Discussion Draft 2) of GPLv3 on first reading fails the necessity test of section 1 on the grounds that there's no substantial and identified problem with GPLv2 that it is trying to solve."
It's trying to solve the thwarting of the intention of the GPL by technical means - as done by Tivo. That's an identified problem, and since it defeats one of the aims of the GPL, it's unarguably a substantial problem.
2. "As drafted, this currently looks like it would potentially jeopardise the entire patent portfolio of a company simply by the act of placing a GPLv3 licensed programme on their website."
This is complete nonsense - pure FUD. If anyone had come close to persuading Moglen that the draft really did this, he'd change it immediately, and these kernel developers know that. It's FUD-generation of the most dishonest kind.
Very ill-thought-out position
Posted Sep 23, 2006 13:32 UTC (Sat) by neilbrown (subscriber, #359) [Link]
1/ The kernel developers are not trying to "grandstand in public".Linus asked a few key developers (smaller conversations often work better
than big ones) for their opinions to see whether his opinions were in tune
with the community or not. This group found general (though not complete)
uniformity and so shared those opinions with the wider community
(lkml). Based on the response there, a community position (or more likely
range-of-positions) will probably go to a more formal forum.
2/ So it's all Tivo's fault is it?
Director of Tivo to ... whoever:
"Honey, I shrunk the GPL!"
DRM is about hardware. TIVO is making a box that cannot be hacked.
"Technical measures" are not really about what you can do with the
software, but about what you can do with the hardware. I think
trying to say what hardware GPL software may be run on is the wrong
thing to be saying in a licence. The TIVO software (that part which
derives from GPL code) is still free. But it you don't have hardware
that will run it, that is hardly their problem.
While I would prefer that all hardware I purchased was completely
open and hackable, I think that putting such a requirement in the
licence would cause trouble and solve little.
3/ I think the patent provisions in the draft are good (at least in
principle) and that is one of the reasons my name isn't on the letter.
It wasn't signed by everyone who was consulted.
We had hoped that the poll results and position paper would start
discussion of the relative merits of the GPLv3 draft in the context
of the Linux Kernel, not that it would cause flames and
claims of FUD. A naive hope maybe.
Very ill-thought-out position
Posted Sep 23, 2006 14:53 UTC (Sat) by timtas (guest, #2815) [Link]
> We had hoped that the poll results and position paper would start> discussion of the relative merits of the GPLv3 draft in the context
> of the Linux Kernel, not that it would cause flames and
> claims of FUD.
So why then do they spread FUD ? They certainly do.
I don't think the kernel should move to GPLv3, no project should. But all I read in this position on the GPLv3 draft is about ecosystem provided by kind distributors and nice companies owning substancial software patent portfolios upon which we rely and shouldn't get angry.
I would have no problem if this postion was signed by representatives of Novell, Red Hat and IBM, but it quite strange to get this from "the kernel developers", completely speaking for themselves and not in the least for their companies that pay their wages.
Everybody has to make a living, but you should at least be honest about it.
Very ill-thought-out position
Posted Sep 24, 2006 6:07 UTC (Sun) by neilbrown (subscriber, #359) [Link]
So why then do they spread FUD ? They certainly doI don't claim to speak for the people who wrote the letter, but if they are speading FUD, then maybe it is because:
- They have a real fear that this new license will be rejected by many and - as it is incompatible with GPLv2 - this will cause a balkanisation in the FLOSS arena with many GPLv2 vs GPLv3 forks. This is seriously possible and would not be a good thing.
- They are profoundly uncertain that the value added by this license is worth the cost of the destabilisation it could cause, and because
- They truely doubt that the "no technical measures" provisions will only stop unwanted measures but may also stop truely valuable technical measures (yes, there probably are some).
Very ill-thought-out position
Posted Sep 24, 2006 14:13 UTC (Sun) by cyd (guest, #4153) [Link]
> I would have no problem if this postion was signed by representatives of> Novell, Red Hat and IBM, but it quite strange to get this from "the kernel
> developers", completely speaking for themselves and not in the least for
> their companies that pay their wages.
"It is difficult to get a man to understand something when his salary depends upon his not understanding it." -- Upton Sinclair
Very ill-thought-out position
Posted Sep 25, 2006 21:14 UTC (Mon) by k8to (guest, #15413) [Link]
We had hoped that the poll results and position paper would start discussion of the relative merits of the GPLv3 draft in the context of the Linux Kernel, not that it would cause flames and claims of FUD. A naive hope maybe.
You would of course have received such regardless, but I think the field was sown with salt to start. Linus was quoted or claimed by various reports with arguments (unsubstantiated) that the GPLv3 would require developers to hand out their encryption keys and other nonsense. The GNU folks sent out a series of videos and watchables of taking questions and making very clear rationales for the changes being placed in the new license, their (initial) case was essentially made. Then this position paper was published, with some parts quite clear, but some arguments not fully made, and others totally nuts ("the new GPL is political").
The onus is on the dissenters at this point to clearly support their view that the specific new provisions are either a) impractical or b) immoral by clear arguments, not just claims.
I think that this case can be made, and I think that these dissenters have the knowledge to make them, but this article fell short of the mark, and so you are seeing a higher level of ire than you might have.
Very ill-thought-out position
Posted Sep 23, 2006 19:31 UTC (Sat) by sepreece (guest, #19270) [Link]
"irst, the appropriate place to discuss the GPLv3 is via gplv3.fsf.org. "
Well, that's one place to express opinions. However, (a) it's not "discussion", because the people you're speaking to don't anwser you except by, possibly, updating the next draft six months later, and (b) the software supporting the site is great for very narrow comments on brief phrases, but isn't designed for larger objections and comments on whole sections.
I have no idea whether they submitted the letter to the FSF; note that the draft process includes both comments entered through the site and comments provided through other channels.
Very ill-thought-out position
Posted Sep 25, 2006 0:55 UTC (Mon) by coriordan (guest, #7544) [Link]
The gplv3.fsf.org portal is designed to take all sorts of comments. To comment on a whole section, attach your comment to the section title. Comments are also accepted by email, to ensure not to exclude people who can't get the gplv3.fsf.org portal working, but this is a backup system only.
The comment procedure is that you pick a part of the licence, and make a comment on the text in that part of the licence. If you have to do this by email, that's acceptable. ...but if you want to write an open letter that makes no reference to the actual text of the licence, then it will be very hard for a meaningful discussion or reaction.
I hope that if they submit this to FSF, they make it a preamble/preface/introduction/explanation along with some comments on the actual licence text.
Intent of source code distribution
Posted Sep 23, 2006 21:25 UTC (Sat) by spinality (guest, #40705) [Link]
What a fascinating discussion, all around. I see one particular salient point. Two distinct GPL objectives are apparent in the discussion: 1. Being sure that distributors of the code share their modifications. 2. Being sure that users of the code have essentially the same ability to make modifications as the distributor. Using binary-only libraries or obfuscated source code would not fulfill the second requirement and is not permitted.
An earlier comment pointed out that, given sufficiently restrictive hardware, distributing source code is little different from distributing read-only object code. It then gives us only the ability to understand how the software works on the device – not the ability to alter its behavior. (This is how IBM used to distribute operating system source.)
If an intent of the GPL is to ensure that the end user has the same ability to modify and use the source code as the distributor, then restrictive hardware seems to defeat its spirit. If the primary intent is to ensure transparency of function and sharing of modification, but not to preserve the technical ability to make changes, then such hardware is not a circumvention.
I seem to hear both positions being argued, often as an implicit subtext.
Intent of source code distribution
Posted Sep 25, 2006 11:44 UTC (Mon) by anandsr21 (guest, #28562) [Link]
"If an intent of the GPL is to ensure that the end user has the same ability to modify and use the source code as the distributor, then restrictive hardware seems to defeat its spirit. If the primary intent is to ensure transparency of function and sharing of modification, but not to preserve the technical ability to make changes, then such hardware is not a circumvention."
The problem is that it is impossible to ensure the second without ensuring the first.
Kernel developers' position on GPLv3
Posted Sep 23, 2006 21:48 UTC (Sat) by kune (guest, #172) [Link]
Honestly I don't get the following statement:
Finally, we recognise that defining what constitutes DRM abuse is essentially political in nature and as such, while we may argue forcefully for our political opinions, we may not suborn or coerce others to go along with them.
The preamble of GPLv2 starts with:
The licenses for most software are designed to take away your freedom to share and change it.
If this is not a political statement, I don't know how a political statement should look like. It appears that the political nature of the GPLv2 didn't prevent it from being successful.
I also wonder, why this "Kernel Developers' position on GPLv3" document is published, if they authors don't want to suborn or even coerce others to go along with their political opinions --- at least about the GPLv3.
Certainly the authors of the document have contributed and are contributing substantially to the Linux kernel. But they should not assert that everybody who has contributed source code to the kernel, which I suppose is the criteria for being a kernel developer, agrees with them. I have contributed source code to a driver just recently included in 2.6.18. My position is not reflected by the document.
Ulrich Kunitz
Kernel developers' position on GPLv3
Posted Sep 23, 2006 22:27 UTC (Sat) by jake (editor, #205) [Link]
While I support the kernel developers (or the subset that agree with this position paper) right to decide whatever they wish about GPLv3, I am a bit surprised that they would be so against the 'anti-DRM' provisions.
If I write a piece of software and freely share it with the world (subject to the GPL) and some company incorporates it into their device, I would *require* the ability to modify that software and run it on that device. Companies go out of business and/or lose interest in older products frequently. If there is a critical security issue (for instance) with software that I wrote on a device and I can't fix that for myself (or my friends or family who might have purchased that device), it would be totally unacceptable.
I am essentially charging anyone who wants to use the software that I wrote by requiring them to publish any modifications that they make and to allow me (and by extension others) to modify it and run it on that device. If they don't wish to do that, they can choose to use some other software, write it themselves or pay me to re-license it so they can make it unmodifiable.
jake
Kernel developers' position on GPLv3
Posted Sep 24, 2006 9:04 UTC (Sun) by jarto (guest, #3268) [Link]
If a company builds a locked down device with GPL software, they still have to publish their modifications to the source code. If the device is successful, any competitor of theirs can also build their own and market it: "We have the same megagadget, it's cheaper, it honors your freedom and it's a lot better".
Look at Nokia 770. It's Linux based, I can hack it easily, I get lots of free features later by upgrading it and I can continue to use it for years to come. And Nokia wants us to contribute. Not locking down gadgets is a feature that benefits hardware companies.
As it's a smart thing for hardware companies to produce open devices, there's no point to force them to do it.
Kernel developers' position on GPLv3
Posted Sep 24, 2006 9:55 UTC (Sun) by man_ls (guest, #15091) [Link]
As it's a smart thing for hardware companies to produce open devices, there's no point to force them to do it.Except that big media companies can conceivably buy a law that forces all computers to be locked down and enforce DRM. It has happened before; remember Macrovision and VCR anticopy provisions in the DMCA. With this provision in place this law would effectively outlaw all GPLv3 code, and would therefore have little hope of succeeding.
Also, don't expect that all businesses follow the most rational path, even if it is in their benefit. Remember what happened with Unix? Each company wanted to have its proprietary advantage, so they collectively weakened their market. BSD versions suffered the same fate. When Linux came along, forcing companies to do the smart thing and share their modifications, it swept the competition away.
Kernel developers' position on GPLv3
Posted Sep 24, 2006 14:53 UTC (Sun) by jake (editor, #205) [Link]
> As it's a smart thing for hardware companies to produce open devices, there's no point to force them to do it.
Nobody is forcing anyone to do anything ... they are free to write their own software and license it however they like ... I don't think it's reasonable for them to take my software and lock it away from me ... free software without that restriction just gives them all the benefits with none of responsibilities (one can't even check that the modifications they publish correspond to the code they have embedded) ...
while those of us who are 'in the know' can (presumably) make smart decisions not to purchase locked down gadgets, the vast majority of folks cannot ... free software is for their benefit as well ...
jake
Kernel developers' position on GPLv3
Posted Sep 25, 2006 11:48 UTC (Mon) by anandsr21 (guest, #28562) [Link]
"As it's a smart thing for hardware companies to produce open devices, there's no point to force them to do it."
Same argument as the one that BSD guys keep giving. But apply the Prisoners Dilemma and the sentence will become.
As it's a dumb thing for hardware companies to produce open devices, nobody produces them.
Kernel developers' position on GPLv3
Posted Sep 25, 2006 1:59 UTC (Mon) by lucychili (guest, #40728) [Link]
Check out the Lessig keynote from LinuxWorldhttp://www.linuxworld.com/events/keynotes/lwsf06-lessig.html
In this speech Lessig explains about the implications of DRM on the stack from network, through computer hardware and software to user. I think it is this big picture issue which is the reason DRM is addressed in the draft of GPLv3.
I have done a customisation of the same model in order to explain to the Australian Attorney General about this issue as they work on a draft of our copyright act. If you want a copy I'll post it somewhere.
The problem is that DRM and TPM technological protection measures may not be interacted with. Developing things which interact with them can be deemed to be a felony at the whim of the owner of the product. All they have to do is 'find' a person to use a technological protection measure to infringe copyright and then the developer of the interfacing tool can be deemed a felon for making a circumvention device. This means people making new inventions and technologies which need to interact with hardware or software which is DRM can only do so with ongoing permission from the TPM company.
It will be important for the GPLv3 to help to clarify that free software is intended to be interacted with, and therefore that hardware which has either a direct or latent threat of felony lurking for people who develop interacting technologies are not a safe part of that technology stack.
At first glance it might be a concern for people who are developing on technologies which include these kinds of interfaces. I feel however that legally separating FLOSS from DRM is the only safe path for developers, who could easily be criminalised if the owner of the DRM technology is encouraged to undermine the foundations or interfaces on which a specific FLOSS resource is based.
While calling it frankly and making that a decision on our part might have initial costs with regard to interaction with existing technologies and hardware, I feel that for the security of FLOSS long term, so that developers can code safely without risk of being deemed a developer of an illegal product, this kind of clarification is the only safe path.
This also means that GPLv3 technologies would be safer for investors.
We will need open hardware at all levels of Lessig's stack, making this a clear decision means that companies can see that the benefits of free and open source software do depend on the ability for hardware and software to be available which is safe to use. Our governments need to understand this. Our communities need to understand the risks.
Some companies are likely to have some products where they leverage DRM
either against customers or competitors. This process will make it increasingly difficult for people to develop safely on proprietory systems.
For small or new independent proprietory businesses as well as for small or large FLOSS based organisations free interactive hardware will be vital. If we have critical mass of software, developers and users who think like this it makes it possible to vote with our feet. If we do not understand the risks and choose to develop code on unsure footing we will be compromised long term.
The LGPL is drafted for interfacing in mixed environments.
The GPL should be able to be trusted and used without risk.
Janet
Kernel developers' position on GPLv3
Posted Sep 25, 2006 4:50 UTC (Mon) by bojan (subscriber, #14302) [Link]
> We will need open hardware at all levels of Lessig's stack,
I hope most people understand that a chip making business requires billions of dollars in continuous investments (i.e. no backyard operators here). Intels and AMDs of the world need to sell those chips eventually to get the money back and make a profit. I honestly don't think that any kind of convincing except the one made in the marketplace will work here. And that's not anyone's fault. It's just how things work.
If these guys see that DRM is what is required of them to do in order to sell, then this is what they are going to do. And "open hardware" (i.e. hackable by anyone) will end there, IMHO. Don't get me wrong, I'm not predicting a doomsday - just pointing out that businesses generally act in their best financial interest or go bust. If market decides that DRM enabled hardware is not acceptable, then we'll continue seeing it in the future. It's just that I don't know many business people or home users that care beyond "I just want it to work". And they are the ones that a market (mostly) make.
Also note that software licensed under GPLv2 and distributed by companies like Novell, Red Hat etc. could peacefully coexist with proprietary software in this model. Such distributors could enter into agreements with hardware folks in order for their software to be officially supported (i.e. DRM signed). Small distributors would be taken out, most likely. And, we (i.e. the general public) wouldn't be able to compile our own stuff and run it on any hardware in such a scenario, although we'd have all the source.
> Our governments need to understand this.
I would not be too hopeful there. Remember, we're talking about governments that enabled DRM in the first place, as a favour to big (content providing) business. Changes to Australian copyright law are being made primarily to facilitate that same business and it is clear that DRM provisions will be used to further enforce copyright protections, not to relax them.
The story about expanding "fair use" is just a nice fairy tale for the press. For example, you'll be able to legally record TV programs and watch them later, but only once. If that's not a joke, I don't know what is.
Just pointing out the facts, not trying to assign blame or pass judgement on any one company, individual or licence :-).
Kernel developers' position on GPLv3
Posted Sep 25, 2006 5:00 UTC (Mon) by bojan (subscriber, #14302) [Link]
If market decides that DRM enabled hardware is not acceptable, then we'll continue seeing it in the future.
It, referring to open hardware, obviously.
Kernel developers' position on GPLv3
Posted Sep 25, 2006 22:28 UTC (Mon) by lucychili (guest, #40728) [Link]
IANAL but from my perspective without prejudice and all that.
Any new proprietory inventor will not be safe with DRM.
FOSS people will not be safe with DRM.
As you point out critical mass is needed.
Understanding and commitment by all FLOSS to the value of a vertically coherent open habitat will help.
Small proprietory inventors may not have the cultural background to appreciate the risks until a few people have been burned.
Investors will probably be pretty quick to respond because they are looking at those kinds of things in terms of overall industry risk.
The GPLv3 is responding to an existing threat and not making a division in itself. The division has been developed by those promoting DMCA laws which make felons of developers who interface with DRM technologies.
It isnt the same world we had with GPL2.
An LGPL is appropriate for interfacing with DRM technologies because using the L means youre aware it is a mixed environment with attendant risks.
GPL needs to be something you can identify as a safe set of technologies for developers as well as for adopters and investors in those technologies.
Kernel developers' position on GPLv3
Posted Sep 26, 2006 0:28 UTC (Tue) by bojan (subscriber, #14302) [Link]
> FOSS people will not be safe with DRM.
Actually, it would appear that kernel developers that presented this position paper believe that they can be safe with DRM. I'm guessing that they are probably counting on "they need us now" factor by the hardware companies, with Linux being widespread as it is these days. So, they are probably feeling that it is unlikely that the hardware will go DRM-or-nothing in the foreseeable future (e.g. Linus pointed out a few times that you can always get a regular PC if you want to tinker with Tivo's version of Linux).
If the hardware doesn't go DRM-or-nothing, then there will always be enough folks tinkering with Linux to keep the interest in it on the "enthusiast" side. As for corporate side, I think there is no doubt that with GPLv2 the likes of Red Hat, Novell etc. can continue what they're doing with losing just the enthusiasts that in the DRM-or-nothing world would not be able to tinker at all. Whether the development community formed purely out of corporate programmers would be sufficient to keep pushing FOSS ahead long term is something that doesn't have an easy answer. However, in the DRM-or-nothing world, Linux kernel development and distribution would most likely look more like "shared source" than "open source" - look, but don't touch.
I personally have no idea what long term plans are of hardware making companies. They are the ones that will have to pick sides eventually.
> The GPLv3 is responding to an existing threat and not making a division in itself.
Well, it's a fork in the road, no doubt about that in my mind. FSF will relicense their tools to GPLv3 the moment it is final. Then all the corporate programmers that are contributing (e.g. Red Hat folks building glibc, gcc etc.) may be at a point of picking sides. It is quite clear that the kernel will stay on GPLv2 no matter what, but there is sufficient amount of important GNU software out there that a fork could be warranted if GPLv3 is perceived an insurmountable obstacle by big distros (similar scenarios happened before: think XFree86 - X.org). I'm thinking here primarily in terms of the patent clauses that could grind to a halt all big computer vendors' Linux related activities.
All this IMHO, of course and without passing any judgement to the validity of pro-3 or pro-2 arguments (i.e. I'm still very much undecided - there are good arguments on both sides).
One thing is for sure - Bill and Steve a getting a really good laugh out of all this. DMCA may have been on their mind in their effort to prevent further Linux penetration, but they probably never thought an internal struggle in the FOSS world could help them like this...