Slashdot Mirror
Linux Kernel Developers' Position on GPLv3
diegocgteleline.es writes "A group of 29 Linux kernel developers have recently come together and produced a position statement on GPLv3 (PDF, txt) explaining why, essentially, they don't like it. 'The three key objections noted in section 5 are individually and collectively sufficient reason for us to reject the current license proposal ... we foresee the release of GPLv3 portends the Balkanization of the entire Open Source Universe upon which we rely'. They've also run a GPLv3 poll."
Anybody else?
http://outcampaign.org/
"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."
Why fix it then?
Oh You POS
All this debate over the GPLv3 has been quite useful. These are issues that the community needs to discuss and consider. One of the outcomes of this appears to be a resurgence of the BSD license. I have talked and written to many open source developers who have become quite disappointed with the FSF and its stance with regards to the GPLv3. Many developers consider it far too restrictive, uncertain, and overly complex. Most of the time, developers just don't want to get bogged down in unnecessary legalities.
A good portion of those people I have talked to have said that they are seriously considering using the BSD license for future releases (if it's within their power to make the change), or otherwise using the BSD license for new developments. Many gave their reason as being a mix of licensing simplicity, and commmercial friendliness. While it was far more difficult to take a GPL'ed application commercial, it's much easier to do with BSD-licensed software. Aside from a very small group of ideological thinkers, many in the open source community would like to be able to make a solid living off of their efforts. The BSD license allows for that quite easily.
Going with a license as simple and straightforward as the BSD license often helps everyone. The developer can just develop, without getting bogged down in answering questions about how their software may be used, or other license-related issues. Users understand what they can do with the software much easier. That likely won't be the case for the GPLv3, where even many developers are unsure as to what it will permit and not permit.
While that is true, the BSD license does allow people to take software other wrote, and profit off of it without providing anything back, GPL prevents, or at least, inhibits that kind of activity. I'm more fond of a "not-for-compensation = BSD, otherwise = GPL + small/no fee, otherwise = other + large fee"
34486853790
Connection too slow for X forwarding? Try "ssh -CX user@host"
Notable names not on the list
Yes, they are:
Name Vote
Linus Torvalds -2.5
Alan Cox -2.0
Live today, because you never know what tomorrow brings
Good job Linus deleted the 'or a later version at your discretion' clause really, isn't it?
Otherwise in 10 years time it would be licensed under a GPLv10 license, where contributors have to give up their paid jobs, move to Stallman's compound in Waco and donate all their cheetos to the communal food store next to his Sparc station.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
If they did that then they would be violating the GPL's copyright. Yes, I'm joking, but sadly it's probably still true. The real issue of course is that writing your own license means that other developers who would like to extend your work have to scrutinize that license for compatibility with their choice of license. If everyone's working under a common license then it's less work for the lawyers and easier for commercial participation in open source. Stay at home amateur keyboard bangers could probably care less, of course.
"Don't you know you're going to shock the monkey?"- Peter Gabriel
The BSD license also makes it nearly impossible to compete against proprietary software, since the proprietary software can always incorporate your improvements, but you can't incorporate its improvements.
Of course, people who licence stuff under the BSDL don't care about that (which is why they do so).
http://outcampaign.org/
I'm sorry, but I find it difficult to take a position until we poll Tuttle, Oklahoma for the definitive opinion on the fate of GPL v3.
Is this just them taking an opportunity to voice their opinions in a way that will give them a wider audience, given that version 3 is an impossible option due to the simple technical reason of being unable to contact every contributor (even dead ones) for permission? (I haven't RTFA of course)
By summer it was all gone...now shesmovedon. --
5.1 DRM Clauses
Has any of these developers actually consulted with a good IPR lawyer before making these statements? They continue to bitch about the restrictions on "encryption", but I just don't see it, and neither does PJ of Groklaw.
5.2 Additional Restrictions Clause
They sort of have a point, but on the other hand, I think it would help greatly if GPL programs could implicitly link with OpenSSL, for example.
5.3 Patents Provisions
Personally, I like this clause. Of course, the problems would go away if software patents did too.
License proliferation
I think this line is rich:
<sarcasm>Sure guys, that's why you switched to GPLv2-only licensing: to reduce licensing profusion.</sarcasm>
http://outcampaign.org/
I'm havign a hard time understanding what all the problems with GPL v3 are about. We know that Linus isn't happy with it, we know a lot of people aren't keen on it. Because of this we will see a lot of projects stay on v2, with a few (and maybe an increasing number) go to v3. But why is this a problem? I think split licences are a good thing in this context, because I support freedom of choice. That's what we're here for in the first place isn't it? More choice is better.
So long as we can make the versions work with each other then there is no problem.
The GPL, whether it is version 2 or 3 will still be a sign to all end users that you can trust that the software will not take your rights and will be free (in both ways)
*''I can't believe it's not a hyperlink.''
I haven't followed the issues with the newly drafted GPL policies closely but I am curious about it. If it's so bad, can't these developers just create a modified version or write a new license agreement that is similiar but what they want? What's keeping this from happening?
Momentum. They can create a new license, but only the copyright holder can license anything under that license and there's thousands of them. Some are unreachable, some are dead (literally) and some would want to block it anyway. The only reason a move to GPLv3 may be possible is because the standard GPLv2 text contains a section that says "GPLv2 or higher", though central sections of the kernel are licensed under "GPLV2 only". Changing to any other license is pretty much impossible and even changing to GPLv3 would be difficult at best, even if the kernel developers were massively in favor of it which they aren't.
Live today, because you never know what tomorrow brings
I wasn't aware that competition was such a key value for the F/OSS movement.
1) We dont want to change a winning formula
2) Even one more open-source license is too many
3) We need corporate contributions to linux
4) We don't own the copyright so we can't change
5.1) *NO* DRM can be restricted unless absolutely ALL innocent use is allowed.
5.2) GPL3 will fragment licenses by being compatible with more of them
5.3) Companies cannot benefit from som GPL programs without giving up patent claims against all GPL programs (and we have to keep our corporate backers happy).
6) There is no reason at all to use GPL3. It provides absolutely nothing of value over GPL2.
Sorry but these reasons are just crap... 1) fear of change is not a reason, 2) there are hundreds of open-source licenses and one more is not going to break the camel's back, 3) pleasing corporations is not a tenant of oss and never has been, 4) they can change piecemeal on new parts, 5) drm is incompatible with oss, end-of-line, qed and 6) they are just being wankers.
Personally I've looked into the kernel a lot and I'm not all that impressed... the code is good and fast, but the design choices are sometimes pretty shabby. For example the IOKit c++ based driver model in OS X is far superior. Or take their diss'ing of DTrace for instance. In fact, I would love to see a split that creates an alternative kernel for Linux. It would be a great thing in the long run.
What Stallman is trying to do is to prevent hardware from running GPL'd software if the hardware prevents its owner from running versions of the software that have been modified. Although I'm for free software as in speech, I think trying to use the software license to control what a hardware manufacturer does is inappropriate and overstepping.
If a manufacturer creates hardware that limits a person's ability to modify the software that runs on it then let the market forces apply pressure. There won't be the plethora of open source software from the community to run on it and that will give an advantage to products that do allow the community to add to the product's value.
The race isn't always to the swift... but that's the way to bet!
One wonders if Linus would've chosen a BSD license when he released Linux.
Really, tivoisation doesn't hurt Linux now because it's too big to kill that way, but it's an important point to consider. That, and the PS2/PS3 Linux, are examples of where I think the GPLv3 would help to capture the spirit of GPLv2. It's not that we care about DRM so much, it's that we don't want a corporation to be able to make a product based on Linux which doesn't allow the customer to make any changes at all. Having source code without being able to make useful changes and redistribute them makes such a Linux about as open as Java.
Which brings us to BSD -- Linus has said that he honestly doesn't care what anyone does with Linux. He really couldn't care if Tivo makes millions because they had access to his software. Which makes me wonder, again and again -- why didn't he use the BSD license, or worse, public domain it all? Because that really seems to be his attitude, and the attitude of these Linux developers.
Don't thank God, thank a doctor!
- "The additional restrictions clause will be a licensing headache for distributors and may cause splintering among the community depending on what restrictions are included."
- in the article they say that "defining what constitutes DRM abuse is essentially political in nature"; but the draft never uses the acronym DRM or anything else ambiguos: the draft has a section titled "No Denying Users' Rights through Technical Measures." and I can't see how this (and the actual content of the section) can be ambigous or political.
Everything is IMVHO, of course. And different opinions on something as important as the next GPL are extremely useful: the FSF has already demonstrated to be able to listen and change their opinion (see the changes between the first and the second draft).AFAICT all different customizations of the GPLv3 and LGPLv3 will always be compatible, no matter what restrictions you choose, so I can't see how this can be a problem for distributors;
There's a hidden treasure in Python 3.x: __prepare__()
The use of GPLv3 as a tool against DRM co-opts the work of thousands of people for the FSF's political ends, which they consider a violation of said trust (they do consider DRM a bad thing, they just don't want to be pulled into the FSF's war against it).
No one can make them change their license, can they?
Interestingly enough, your summary contains almost all of the information in the article itself, and that's dissapointing. I'd at least have liked to see links to some of the supposed problems with encryption they claim has caused so many rewrites. Just the same, I'll quote what I think is the heart of what they say:
Curtail who's freedom? Mine? No thanks and I'll see you later.
DRM is something none of us should contribute to. Restricting user rights to use and modify and change software goes against everything that made the GPL a success in the first place. One of the reasons BSD is not as used is because software licensed that way could easily be used by those who are working against everyone's freedom. When you consider something wrong but don't do anything yourself and help others who would do the wrong thing, you are waffling. The poll, if it really reflects the opinions of those listed, is disturbing. Still, it does not matter unless someone can explain how they will be prohibited from continuing to use GPL2. If they really don't mind people Tivoising their work, why don't they just BSD it and let everyone bork the user straight up?
Friends don't help friends install M$ junk.
Are you implying that the F/OSS movement is communist? That's been debunked to death already.
http://outcampaign.org/
The authors claim that the GPL V3 draft is not in the spirit of the GPL V2 license. However, I believe that the extreme liberalness of the language used within the preamble is perhaps what we should base our understanding of "spirit of" from. For instance, the Preamble states:
" To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. "
This excerpt is especially stirking when applied to DRMd software. When someone distributes a DRM'd software system that it is often the case that the maker of the software system has more rights than the reciever of them. For instance, a person recieving a TiVo software system, they have implicitly been denied certain rights due to the nature of the software distribution (which, in this case, is dependent upon a hardware system).
I believe that the article, "The Dangers of Problems with GPLv3" hinders largely upon this notion of "spirit" and upon developers' trust with the FSF and future drafts of the GPL. I belive that RMS has been more than clear about his beliefs. Furthermore, the FSF has worked hard to share as much of their philosophy as they could with the world. As a person who has spent a good deal of time with the written philosophy of the FSF, I believe that the GPL V3 is very much in the spirit of the GPL V2 and is clearly in-line with the spirit of the GNU Project and Free Software Foundation.
However, it is important that when entrusting an organization with your copyright, you should take a good look at the organization and read their beliefs and arguments and to look beyond just the clauses within the license. "The Dangers and Problems with GPLv3" fails completely to do this kind of research or background check, and as such, I believe that they have failed to make a solid argument as to why the GPL V3 is not in the spirit of the GPL v2. I will leave it to the rest of the slashdot community to closely examine the language of this article and reveal that there is a lot of huff and puff and hot air but not a lot of substance or strength to the arguments.
-Joshua Gay
It's important to the FSF. If free software cannot compete with proprietary, it will never replace it. And the FSF wants proprietary software to be nothing more than a footnote of History.
Interestingly enough, your summary contains almost all of the information in the article itself, and that's dissapointing
That, twitter, is because it's a summary of the article, and I don't feel the need to inject my own take on things into it.
By summer it was all gone...now shesmovedon. --
Ahh, I try to limit my crap output to my colon.
Anyway, I think, regardless of what I make, if you make money off of it, I should gain to, somehow. However, if you don't make money off of it, then you should be able to use it however the ---- you want.
34486853790
Connection too slow for X forwarding? Try "ssh -CX user@host"
Please mod parent up: he has made very sensible and clear points.
There's a hidden treasure in Python 3.x: __prepare__()
They list three primary reasons for not wanting to use GPL 3:
1. They are against the DRM clause because they believe it is an "end use restriction". The DRM clause prevents distributors from calling the program a 'technological "protection" measure' which ensures that others are free to distribute it. Perhaps it's redundant, but it adds no restrictions on end-use.
2. They are against the "Additional Restrictions Clause". This is one of the most sorely needed updates to the license. It helps make it compatible with other free software licenses. They're afraid that this will encourage too many alternative licensing usages. Unfortunately, reality is that there are already too many licenses out there now and this clause is trying to be as useful as possible in the current environment. If everyone agreed with and used GPL2 this clause would be unnecessary.
3. They are against the patent clause because they are afraid it will scare away corporate help. Here they may be right. However, the GPL is intended to be for "free software", not for general "open source software". This clause is certainly in the spirit of the GPL although it might make it harder for some projects to get help. Support for this clause will vary depending on how one falls on the practicality/idealism spectrum.
In summary, their reasons seem based primarily on a desire to see their work disseminated as widely as possible and not to keep the software free. I'm disappointed in them.
DRM is something none of us should contribute to.
That is YOUR morality. How dare you impose your morality on someone else? And fine, so you won't work on DRM. There is no reason why someone else can't use GPL'd software to do DRM. If they are using their own time and their own talents and the coder of the upstream software is OK with it - what is the problem? The GPL is only meant to cover redistribution of software (it is a licensing agreement not a terms-of-use).
My problem is all you people who want to impose your morality on others in a flurry of holier-than-thou richeousness. Once you take a freedom away, which freedom goes next? Taking away the ability to experiment with DRM is a freedom, I don't care if you agree with it or not. "preserving freedom" by removing freedom is hypocritical of the FSF. What freedom goes next?
Oh goodie, yet another article about the pissing match between the Linux kernel developers and the FSF.
I personally think that the kernel devs, particularly the major ones, are losing touch with their own customer base. Every single point of the open letter I dispute:
1) The anti-DRM clause is a *good* thing, as it prevents the industry giants from turning the free Linux-that-can-be-tweaked-by-the-end-user into Unix-that-can-only-be-modified-by-the-vendor. Do they even remember the craptastic state of Unix circa 1991? The FSF made a major tactical blunder in pushing HURD, yes, but they made a major strategic success in GPLv2. All these arguments against the anti-DRM clause are more deja vu of the arguments made against the GPL explicit-linking restrictions. Anti-DRM just closes a hole that someone figured out after GPLv2 was out a few years.
2) The patent clause: yay. If company X releases their own GPL version of code, they can't sue company Y for improving on it. Who could possibly complain about that? Oh wait, they're still pissed about the whole GNU/Linux thing...
3) The optional clauses: goodie also. Remember when Xfree86 had to fork? Notice how Sun CDDL is deliberately incompatible with GPLv2? GPLv3 just makes it easier to add those additional restrictions without breaking the whole license in the process. Distros won't care -- it's still GPL code. Developers WILL care, as they have to be more careful with copy-and-pasting directly from other projects into their own, but then again any developer who doesn't carefully check already is being stupid.
They threaten "balkanization" of the OSS landscape: I say it's already happened. It's happened in two areas: BSD vs GPL, and paid-for-OSS vs hobby-OSS. BSD: great license, and when I'm actually paid to write OSS code that's what it goes under so we can sell it later. But when I write MY code, it's GPL: you want it, pay me for it! Very different philosophies though, and impossible for Linux code to end up in OpenBSD unless the individual developer has a change of heart. Now who is all about sharing again?
Second: now how many OSS developers get paid to write GPL code again? Right: mainly just these people bitching about GPLv3. Notice how the survey even included an option to say "I don't like GPLv3 because MY EMPLOYER doesn't like it."
Since I'm obviously biased, let me begin the list of problems from the Linux kernel side of things:
1. They switched over to BitKeeper and got screwed, exactly like RMS said would happen. Then they had to scramble to resume development with something else.
2. The 2.6 development model that means unstable crap is now constantly being pushed out for the distros to clean up. How many releases did it take for ACPI to finally work? And why does my Adaptec SCSI system sometimes head off to lala-land when it was rock-solid on 2.4?
3. 2.6 dropped a lot of hardware support, leaving some of us in the lurch. Thanks guys, we really appreciate that. But nice to know that you'll help Tivo lock their customers out of hardware THEY OWN, that THEY BOUGHT with THEIR OWN MONEY. Wish I could go back to 1991 and tell Linus "Hey, you're only supposed to run Windows 3.1 on that 386. Don't like it? Go buy a new computer!"
Whatever. GPLv3 will come out, people will bitch and moan, and then they'll start to notice that mega-corporation never really cared what they thought all along. Watch for patents and DRM to get all out of control just as RMS has said they will and all those GPLv2-only projects will be encumbered all over again. When every DVR and wireless router out there runs Linux but not a single one is hackable, then maybe the kernel crowd will finally get annoyed.
"If a manufacturer creates hardware that limits a person's ability to modify the software that runs on it"
Then he can do that. With his own code. Not with mine.
"then let the market forces apply pressure"
Not being free to use other peoples GPLv3 licensed code is market pressure.
Quid pro quo. It really aint that hard to grasp. If you want the freedom, then you have to pass that freedom on.
This is just unfair to RMS his objectives haven't changed.
GNU the GPL and the FSF exist because he wanted software to be distributed and used in that way, so he did it and encouraged wider participation.
The Free software movement has been very successful.
Now what is happening is some loopholes in the implementation of RMSs vision have been exploited, he obviously wants to correct this.
The only reason these people worked together is that the different visions could agree on a single implementation at that time. That time is past and the different visions no longer agree on the correct implementation.
For RMS to move forward in accordance with his vision he will have to create a new implementation that won't have the large mass of current users. He doesn't want to do this because many won't move, but he will have to in order to move forward.
What bothered me was the lack of detail and supporting evidence in the orignial. Their conclusions, which you echo, may be warranted but they don't support them with anything other than opinions and generalizations.
Friends don't help friends install M$ junk.
My point is that GPL V2 the manufacturer must release his code back to the community. Nothing prevents you from taking that code, removing what you don't like and running it on hardware that you build. The GPL v3 oversteps its bounds by dictating hardware design.
The race isn't always to the swift... but that's the way to bet!
They can fork Linux all they want, and to the best of my knowledge, Linus never denied that. But they can still not cause their fork to be licensed under the GPL version 3. The many copyright holders have specifically licensed their contributions to the kernel under the GPL version 2 only, and only the copyright holders can change the license under which a work is published. That's simply a fact.
Of 29 of the top developers, 28 are opposed to the GPL3, and the other 1 doesn't care either way. And that's not counting whether they want to switch to it, but just whether or not they like it.
I never would have expected such a landslide.
There seems to be a naive belief in the free market similar to that of "god will provide".
There isn't a free market - in this case there is likely to be collusion between the hardware vendors, the proprietary software vendors and the *AA. Given the amount of money they have they can use the "free market" to purchase as many additional lawmakers they need to push through whatever restrictions they want.
Unfortunately it's not that simple. If I write a program and release it under GPLv2-only (which is probably a bad idea in the first place IMO, but it's what Linus did) and I use a library released under the "GPLv2 or any later version" and the new version of the library is released under the GPLv3 ("or any later version"), then I have to make a choice because the GPLv2-only is incompatible with the GPLv3:
Disclaimer: I really like the GPLv3 because it garantees (even better than the GPLv2 that had some loopholes) that my software will be Free for everyone to modify and reuse, forever.
There's a hidden treasure in Python 3.x: __prepare__()
That's what the GPLv3 attempts to ensure: that for example the master keys controlling which programs can run on a computer are given to the owner of that computer, as opposed to preventing the owner from modifying the computer or its programs, or running other programs on the computer. It puts decision-making in the hands of the owner of the computer, where it belongs.
The "Balkanisation of the OpenSource" is a thread we all should take seriously. It's already happening all over, e.g. Gnome versus KDE, CSS drivers versus OSS drivers, etc. We really don't need yet another balkanisation with licenses.
O. Wyss
See http://wyoguide.sf.net/papers/Cross-platform.html
Why not call it the Gnu 2nd Public Liscence? (G2PL). That way there is no feeling of "forced" updating of people that don't want to use the new liscence, and yet the DRM clause can still be there for people that want a new liscence.
Help! I'm a slashdot refugee.
No it puts the power in to the hands of the FSF.
This could really be the end of Linux as a anything but political statement. People like to hold up Tivo as an example of why we need GPLv3 however TiVO has done a lot of good for Linux. When I talk to people about Linux they always say. It is hard to use, or it is only for computer people. I simply ask, "Do you have a TiVO?" when they tell me they do I say you use Linux every day then.
This might push people to BSD or OpenSolaris. Under GPLv2 FOSS has grown bigger than just about anyone would have dreamed. It has gotten good free software in the hands of tens of millions or maybe hundreds of millions of users.
It has finally help to break Microsoft's strangle hold on the Web. Yes in case you didn't notice IE only websites are becoming a smaller percentage of the Internet thanks to Firefox.
Again this is all ego as far as I can see.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
You're welcome to hold that opinion, and you're welcome to write code and license it so that if anyone else resells your software, they owe you a royalty. You should be aware that your software and such a license would not be Open Source or "Free Software". See OSD #1.
"The human race's favorite method for being in control of the facts is to ignore them." -Celia Green
That is YOUR morality. How dare you impose your morality on someone else?
It's easy, really, I'm not going to use DRM infected stuff. I don't have to tell you about your licenses. I don't have to tell the FSF about GPL V3. I don't have to tell anyone how to do anything, and no one would listen anyway, but I won't be told what I'm going to run. If you don't fix DRM problems and all your work gets sucked up by greedy DRM publishers, you will soon be without users and none of them will be free. Do as you will, but don't blame me when your branch of code ends up, abused and stagnant. I promise, "experiments" into DRM will be avoided.
"preserving freedom" by removing freedom is hypocritical of the FSF.
The freedom preserved has always been that of the user. To preserve that freedom, developers of GPL'd code gave up the "freedom" to be anti-social and prevent the user from being able to use, modify and share their changes. Tivo has shown how GPL'd code can keep users from doing those things. Change is required and I've yet to see anything positive from anyone but the FSF.
Friends don't help friends install M$ junk.
No doubt the FSF owns computers, yes, but if I am provided the master keys to my own computer, it puts that power in my hands, not the FSF's hands.
The word is "principle". The FSF cares about certain things. It's ok if you don't; don't use GPLv3 in your software if you don't want to.
It might push corporations that way. To be honest, I'm not sure why corporations wanting the benefits of closed source software aren't already basing their products on *BSD.
By definition, competition is a key value for any successful group activity. Otherwise, the given activity would be crowded out by other more competitive activities.
The BSD license also makes it nearly impossible to compete against proprietary software, since the proprietary software can always incorporate your improvements, but you can't incorporate its improvements.
Of course, people who licence stuff under the BSDL don't care about that (which is why they do so).
For sure. I mean, look at the Apache projects. The Apache license doesn't require modifications to be released (similar to the BSDL), and look how badly it's doing in competing against proprietary software. Not that they care about that sort of thing...
Perhaps you should enlighten the people over at the Free-, Net-, and OpenBSD projects. You can save them tons of time and effort by letting them know that it's nearly impossible for them to compete with proprietary software, because I'm pretty sure they are unaware of these "facts".
Slackware
That defeats the point of DRM in a voting system. The whole point of DRM'ing a voting machine is so that a crooked elections office can't put in their own version of the code. If you force the authors to release their signing keys, you make it impossible to address that threat. So GPLv3 voting machines will always be vulnerable to this sort of attack.
This is a moot point. I think it's a given that all FSF copyrighted code will move to GPL v3 (or LGPL v3). That includes such core components of Linux distributions as gcc. So the further proliferation of licenses in Linux distributions is a given, regardless of what the Linux kernel developers do.
In other words, if manufacturers start selling PCs with Linux installed, complete source for their version of Linux, but no ability to actually modify, compile, and upgrade the kernel due to the hardware enforcing DRM authentication (and the necessary keys being kept secret), this is fine by the Linux developers. This leads to precisely the sort of problem that led RMS to create the GPL in the first place -- he wanted to fix a printer driver but couldn't because the code was proprietary. Is it any different if the code is available but you can't install your fixes anyway? The purpose of GPL v3 is to forbid certain egregious end use restrictions.
An odd statement, given that the GPL is and always has been political in nature. (I think RMS would agree with that statement.) People who don't care what happens to the source code, and what restrictions are placed on the end user, use the BSD license.
The relevant section of GPL v3 says:
In other words, you can't enfo
This follows on from my last post on here, and it was something I was thinking about only a few moments before I saw the article.
AFAIK, Autoconf's version number hasn't changed in at least two years. I can also remember looking into it a few months back and discovering that at the time anyway, GNU Make only had two maintainers.
The FSF has completely lost focus, IMHO. Core elements of the toolchain are not being actively maintained, and several of the people who were maintaining them have been employed by Red Hat, causing a conflict of interest which cannot be conducive to Linux's long-term wellbeing...or at least that of the GNU project, for those of you who like to split hairs.
I've had FSF advocates reply to me before and talk about how the anti-DRM crusade is important...fine and good, but let me mention something which I think is even more important.
For all that Stallman has written and said, and continues to say, about software freedom, said freedom isn't going to matter much if the software itself ceases to exist. I'm also not talking about KDE or anything on the surface, either...I'm talking about the core knowledge behind how to assemble a Linux system, and the tools themselves which are used to do that. Yes, I know the Linux From Scratch project will immediately be pointed to, perhaps...but aside from them and perhaps Gentoo, who else is there?
Aside from Debian, Gentoo, and Slackware, the rest of the major distributions are corporate, and created by people with far more interest in imitating Windows as closely as possible than in technical integrity. You only need to visit their forums or look at the track record for security of some of them to know that. Red Hat began Linux's decomposition process, but the other companies are continuing it. It's happened quietly, but on a number of levels, I honestly believe that Linux's roots are seriously endangered, currently...and as any botanist will be able to tell you, if the roots are compromised, although it won't happen overnight, there's a very good chance that the entire tree will eventually die.
I'd ask anyone who reads this and who cares about Linux's future to go and build Linux From Scratch at least once...as that information will only survive if it exists within a large enough group of people. I've heard about the concepts of installfests, which are great...but if it could be arranged, I think source installfests, or "compilefests" could be fantastic as well. I feel that on a technical level, rather than on a political one, there needs to be a return to some core principles:-
a) Compilation from source, so that we're actually *using* source code rather than just talking about it. Source code availability is Linux's fundamental strength...there are any number of people in the corporate world who'd love a scenario where Linux was purely binary only, a la Windows, because they know how much that would disempower Linux users if they could bring it about. For all the talk about the convenience of binary rpms and debs, use of these is actually "helping" Linux to death. Whining about binary drivers on the one hand and using apt on the other is simply rank hypocrisy, IMHO...and it also doesn't genuinely solve either problem.
b) Individuals with sufficient technical ability once more creating their own systems on a wide basis, and not merely relying on predigested, corporate distributions which are often severely crippled for the purposes of compiling source, use deeply unreliable and broken package management systems, and which do not adhere to standards. Decentralisation used to be another of Linux's major strengths...again, something else which we're losing. The ability to "roll your own," is still there, but if we don't keep using it, we *will* lose it...there are a lot of people out there who as I said are waiting for any opportunity they can get to take such an ability away from us.
c) A commitment as individuals to the adherence to such basic things a
I find it really ironic that many of the same people that say no technology say strong encryption is evil or should be controlled are so willing to declare that DRM is evil and should be controlled.
DRM!=encryption. DRM requires that "my" computer refuse to obey me. Encryption does not. DRM should not be "controlled" in the sense of made illegal, but neither should DRM schemes be protected by force of law.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
I disagree. Public Domain is more free than BSD (at least by any defition of "free" that makes BSD more free than GPL).
The reason is, there are basically two opinions here:
1) Your interpretation of the intent and effects of the licensing
2) Whether that intent agrees with your own.
The second point is certainly a pure matter of opinion that requires no qualifications, and kind of pointless to discuss or provide arguments for.
But the first point is a lot more subjective, and you need to provide arguments for why you believe your interpretation to be correct. That's where they fail, in my opinion. Mostly they just assert their interpretation without giving reason.
IMHO, they must provide further argumentation for (1). Because if you're not a lawyer, I don't really see any reason to take your interpretation of a legal document at face value. Doesn't mean I'm saying they can't have an opinion on it. Only that I for one will put higher demands on explaining the rationale.
(OTOH, they're certainly the most qualified people to give an opinion on (2). The license should serve the intent of the developers, not vice-versa.)
To be specific, I take issue with statements like:
I think that's a rather extreme, or at least non-obvious interpretation. I'd really like to know why they think it "looks like" that. Unfortunately they don't give a reason. Instead they go on to give their opinions on the consequences of that interpretation, stating their belief that it'll seriously inhibit corporate use of GPL software.
I find that also to be extreme or non-obvious, too. And it's really bad not to give an example, because the given argument could just as well support to the opposite position: That the lack of protection from patent liability in the GPLv2 could hurt corporate use. Regardless of my own opinion on the matter, it's wrong not to address the fact that other OSS licenses (e.g. ASL v2, CPL) have anti-patent clauses yet seem to have quite broad corporate use.
Not all points are bad though. For instance, the "Tivoisation" stuff, which doesn't really rely on any particular interpretation since it's clear they object to any and all restrictions on DRM use.
The only objection I can think up to that, is that I don't think you need to say more than that. People want different things, and that's why they need different licenses. RMS and Linus simply want different license obligations with respect to DRM. Talking about "freedom" (and the guaranteeing of it) is just politics and rhetoric - The game being to obscure the difference of opinion by pretending your position logically follows from some concept with positive connotations (like "freedom"). Despite that it doesn't follow, and the meaning (but not the connotation) is anything but agreed-upon.
"Freedom" in probably the all-round most useful term for that, which is why politicians love it. Everyone thinks it's a good thing but noone has a strong idea of what means. You can use it for anything!
People should react with harsh scepticism against anything argued for in terms of 'freedom'. If not for being rhetoric, then for being obvious ( =bad ) and uncreative rhetoric. If you're gonna get bullshitted, you can still demand quality bullshit!
So now it's freedom for the sake of....freedom? isn't it obvious that the goal getting more freedom should be achieved in order for everybody to move on to a higher goal instead of riding the wave of popularity or to enforce a particular view? I think it's already too late...the open source movement IS already balkanized. Not in a matter of licences, but in a matter of opinion, by the same people who should be their stewards. another dream gone down in flames.... pity
No it puts the power in to the hands of the FSF.
Don't be stupid. The GPLv3 doesn't say you have to surrender your encryption keys to the FSF. The FSF simply writes the license. You can use the license if you wish.
There is a type of "Good DRM" that many people are not familiar with. Actually it is not DRM, but rather it is exactly what is forbidden by the license, namely a system in which people who modify their code do not get exactly the same rights, privileges and abilities as people who run unmodified code.
The idea is what is sometimes called a "transparent server". It uses Trusted Computing technology to allow any client, any third party, to verify the software configuration that is running. Maybe it is an anonymity server, for example; a discussion board that is supposed to protect people's identities. By publishing its source code and using the TC technology, third parties can verify what software is running and make sure that it does in fact behave as specified.
This is the same basic technology that could potentially be used for DRM, and which GPLv3 wants to stop. In that usage, a commercial music or movie server could check what software configuration you are running, and refuse to download content if you're not running their official and approved software version.
But in the trusted server example, the tables are turned and it is the clients who judge whether the server is running software that they find acceptable. And the server is happy with this, it wants to assure the clients that it can be trusted. It (or its owner, more accurately) willingly and voluntarily publishes the data necessary to let potential clients see that the software is clean and reliable.
Yet if the server changes its software, perhaps to put in a feature to log the identities of clients, or misbehave in some other way, it will not be able to get the same access and same abilities as a server that doesn't make this change. Clients will shun a server which has made such a change.
This is precisely what is forbidden by GPLv3: software where, if you change it, you're not able to do all the same things and run in the same way. In effect, GPLv3 mandates opaque software. It forbids the ability to voluntarily reveal your software/hardware configuration in such a way that third parties can decide whether to trust you or not.
The GPLv3 authors have presumably made a personal judgement call that transparent servers are either not going to exist, or else their existence does not outweigh the potential negatives of the "bad" DRM uses which are always discussed. But is that the kind of judgement call they should be making? Should they forbid an entire class of potentially useful software, transparent servers, merely because of their belief that the technology these servers would rely on could also be used for ill?
That doesn't seem fair to people who would like to develop this technology and see if it could be used to enhance privacy and freedom on the net. We are not in a position now to know how much or whether this technology will be useful, and taking steps to hinder its development appears highly premature if not downright infringing on user freedom.
I think it's useful to distinguish between technologies that require the user's machine to disobey her, and those that don't. I only apply the DRM label to those in the first category. Encrypting files falls into the second; if an attacker gains access to my encrypted hard drive, it (hopefully) won't be of use to her not because her computer refuses to decrypt it, but because it *can't*.
Protection voluntarily placed on the content by the end-user is legitimate DRM.
Arguably true. My real problem with legally-enforced DRM is not that users can voluntarily surrender their rights (although the legal and moral validity of these sorts of "implied contracts" is questionable), but that it forbids *everyone* from creating certain classes of software, whether or not they have any interaction with copyright holders.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
The problems are that not everyone likes version 3 of the GPL, and that code not licensed under "GPLv2 and any future version" can't easily be relicensed due to practical issues. One solution is for the FSF to specifically allow mixing GPLv2 and GPLv3 code in the same linked object without applying the terms of the GPLv3 to the entire binary or to the GPLv2 source code. That way things that really do need DRM and patent protections (like drivers for proprietary hardware, video and audio cards that would otherwise require DRM, etc.) can have them without impacting the rest of the kernel, which could still be used in projects without those drivers under the GPLv2. For instance, if a video card driver is licensed under GPLv3 to protect it from future DRM abuse, only that driver would be affected. Anyone could stick a DRM module into the kernel or do whatever they wanted to other GPLv2 parts, so long as those restrictions did not impact the GPLv3 portions. Obviously, it's still possible that the dominant Linux distributions would stay GPLv2, become DRM'd, and just kill off GPLv3 portions because they were incompatible, but theoretically that would happen in any case simply by forking the kernel and letting it become the dominant version. Basically, the argument comes down to whether Linux will attempt to retain user's freedom by limiting DRM as much as possible, but at least with the option to mix licenses the individual parts licensed under GPLv3 would outlive the DRM demise of this hypothetical Linux. The biggest advantage is that mixing licenses would allow the free market to select the best balance between GPLv2 and GPLv3 protections in practice.
I think a compromise like this is probably the only way to really settle the issue. Lots of people like the GPLv3, and most likely it will be necessary at some point to protect computer owners from DRM. On the other hand, the parts of Linux that are DRM (and even patent) neutral can still be licensed under the GPLv2 for use in embedded systems or other projects where the GPLv3 isn't appropriate. In the worst case forks would be necessary to support GPLv2 and GPLv3 versions of common hardware that everyone wants to use, but where some people don't want to prevent patents and DRM from interfering and others want them or don't care. However, if the FSF allows cross linking between GPLv2 and GPLv3 it won't be as bad as having to fork the entire kernel into a GPLv2 and GPLv3 branch.
Ack. I replied already, so I can't mod this up like it deserves.
I agree wholeheartedly with this entire long post.
I do have one nit to pick though. Nothing stops a company from selling GPL software, and quite a few companies do so. Its true that many companies don't want to sell their software that way. This is just a nit though, because if you are the poor coder on the bottom rung that's essentially the same thing.
No, it ensures the point of DRM in a voting system. Crooked elections offices don't need encryption keys to rig an election, and having the keys gives an elections office (as opposed to a vendor) the final say over what software can be installed.
Don't be stupid. None of the things you listed are DRM. DRM, by definition, is hardware which prevents the user from accessing data on his own computer. Encrypting email, filesystems, etc. does not fall under that category, as the user knows the decryption key (unless he forgets it!) and can thus access the data.
DRM involves hardware which physically prevents the user from fully accessing his data. For example, the "Secure Audio Path" allows a user to play a DRM-infected media file ONLY on a certain computer, if the license is valid, and then it only allows the file to be used one way: for playback through special hardware that prevents anyone from tapping into the decrypted data stream at some point and making a digital copy. Want to make a backup copy? Too bad. Did the company you bought the file from go out of business, and now you can't play it? Too bad. That's DRM.
Or, how about a computer with a TCM chip on the motherboard which checks the operating system on boot-up, and refuses to boot an "unauthorized" OS? Yep, there's plans in the works for this too. That's DRM.
Read-only media is NOT DRM. Stop being silly.
Yeah sure. I'll get started building my own 32nm fab next week so I can make my own DRM-less CPUs. Hey Eric, I'm a little short of cash for this little project. Do you have $3 Billion I can borrow?
In reality the GPL has only a few SERIOUS packages to its name. Just as many serious packages use different licences. BIND named: BSD License Apache httpd: Apache License Firefox: Mozilla Public License To name a few. Open Source can't survive in a vacuum. GPL has got to learn to dance with the proprietary devil if it wants to live. Make it work boys!
a better question than 'what are innocent uses of DRM?' would be 'what are innocent uses of DRM that are prevented by the GPLv3?' if you take a broad definition of DRM to be anything that protects data (which is a stretch), then you have to look at what tech under this definition is prevented by the GPLv3, before you can say the GPLv3's restrictions are hurting something innocent (which you didn't explicitly say, but is what the discussion is about).
the GPLv3 is not trying to stop people from protecting the confidentiality of their data, nor is it trying to restore people's fair-use rights of digital media. it is trying to ensure that the downstream freedoms of users are maintained and that technical measures (such as DRM) may not be used to prevent the use of modified code - which is against the spirit of the original GPL. the GPLv3 is only talking about one small part of DRM, which is the part that relates to the freedoms the GPL maintains. the remaining aspects of DRM are not discussed.
if there are legitimate uses of DRM that the GPLv3 hurts (which there may be), i'd like to know. the FSF ought to know too, which is why the GPLv3 draft is open for discussion in the first place.
DRM is inherently a poor way to secure a voting machine.
If I'm a voter - how do I know the DRM securing my voting machine is intact? How do I know that instead of just reflashing the software on the machine that somebody didn't instead replace the DRM-chip and reflash the software? How do I know the folks who loaded the software in the first place are legit?
The most straightforward solution to e-voting confidence is to let the voter SEE the votes. WITH HIS EYES! Print them out on paper, and either use the paper copy as the official tally, or at least keep it around for auditing (and audit some percentage of the votes - possibly 100%). Any idiot can understand how it works, and the software keeps invalid ballots from being generated (ie votes for two people for president and a bunch of judges trying to figure out "voter intent"). The worst somebody could do by tampering with the software is to generate invalid ballots, but those will get spotted very quickly by the voters.
The goal should be to make things open and accessible - not closed and hidden. DRM does not make things open to the user.
Basically, the argument comes down to whether Linux will attempt to retain user's freedom by limiting DRM as much as possible, but at least with the option to mix licenses the individual parts licensed under GPLv3 would outlive the DRM demise of this hypothetical Linux.
;)
You're making a couple of implicit assumptions, here.
a) That DRM is ever going to become a truly serious threat in the first place. Despite all the talk about it, where I'm sitting anyway, it hasn't. (And I seriously doubt that it's going to) The only real forms of DRM that I know about are those that are used on a couple of different proprietary sound file codecs...and they're rediculously easy to avoid. Yes, I know the suggestion of dreaded CPU locks has come up a couple of times, but it gets slapped down again...because the public aren't quite as stupid as RMS thinks they are. Companies might try and fool themselves otherwise, but within capitalism, the only thing they can really control is supply...trying to control demand simply means that they lose it. Hence one area where the system genuinely is at least partly self-regulating. If companies want to continue to make money, they need to pay at least some attention to public opinion...and even among the ignorant, hardware DRM has around the same level of popularity as bird flu.
b) That RMS (by himself) has even the slightest chance of being able to issue any decrees regarding the use of DRM (and have them stick) whatsoever. The GPL v2 might very well be legally enforceable, but any concrete attempt on the part of the GPL v3 to prevent corporate world domination most certainly will *not* be. There are any number of bigger fish (both legally and financially) than the FSF swimming around, and if Stallman thinks he is going to be able to dictate their actions, he is, in a word, delusional. It would also prove what I've suspected for the last year or two; namely, that his ego has grown completely out of control.
In my own mind, the whole DRM flap in the GPL v3 isn't actually *about* DRM at all...DRM is to Stallman what the War on Terror is to George Bush; namely a wedge issue which he can use to generate fear and division, and which he hopes he can also use to gain control over people. But, as with the War on Terror itself, once you look under the white sheet that is madly floating around, you quickly realise that (for the most part, anyway) the only thing that is in fact holding it up is hot air.
Even if the future code base could be moved to GPL3, that would not stop people forking the current codebase to retain the current licensing. That would break the reasons for RMS's big motivation behind GPL3, particularly in how it applies to mobile/embedded devices. A forked codebase might lose the "official" tag, but that is not very limiting. Consider than many,many embedded devices still use 2.4.x, so being "official" is not really a big deal.
Engineering is the art of compromise.
Strange, that must be why Bind Named and Apache Httpd continue to lead by massive margins. :P
Is it any different if the code is available but you can't install your fixes anyway?
Effectively no.
But it is wrong to licence software in such a way as to try and force a behaviour on the maker of the hardware.
Wrong as in it is a bad technical solution.
If I only let my computer install and run signed binaries, I could argue that not having the keys to sign the package, I don't have the complete source and you should give me the keys too.
Some see this as the anti-Tivo clause, others see the potential for it to be a forced insecurity clause.
People violating copyrights and other applicable licenses in the name of sticking it to The Man is good.
The Man violating copyright and other applicable licenses in the name of sticking it to the people is bad.
"Ask not what your country can do for you." --John F. Kennedy
This group of kernel developers is clearly advocating the "Open Source" (as opposed to "Free Software") position. Recall that Open Source seeks power and reliability of software by access to source code, whereas Free Software seeks to defend freedoms involving the use, modification, and redistribution of software. Note that in this opinion piece they do not mention "free software" or freedom, apart from just spelling out FSF. This is not only due to the amoral stance of Open Source advocates, but also because freedom is incompatible with the imposition of DRM by HW manufacturers. Naturally, these firms can choose whatever software they want, regardless of this debate. Why cry over the Tivo's of the world?
Throughout the GPLv3 debate Torvalds has played up an "optimistic" viewpoint, as opposed to the "pessimistic" FSF one. Another optimistic bet is the OSDL attempt against software patents. I am trying really hard to see the basis of such optimism, but how can the impressions of the governments and corporations of today do anything but kill it? In particular, think of how much harm the RIAA, MPAA, and BSA have brought upon society through abominations such as the DMCA, the Mickey Mouse Protection Act, etc. You can bet that our rights are obstacles from their POV, and that naturally they oppose the GPLv3, which seeks to preserve some of our "inconvenient" rights. Indeed, the GPLv3 is but one step in a very real fight for our rights, a fight which must involve analyzing the worst-case behavior out there.
Oh yeah, the market forces will totally help because the majority of users want to run open source and other alternative operating systems on their hardware. The overwhelming popularity of Linux among the average computer user proves this, doesn't it? This should really be modded funny. I wouldn't depend on the market forces for preserving our freedoms. Seems to have worked out *really* well with DVDs, HDMI, etc. and the general populace just isn't interested in installing alternate OSes and the geeks are really just a tiny part of the market.
People who choose the GPL license (or at least the people who drafted the GPL license!) regard it as an ESSENTIAL FREEDOM FOR END USERS OF THE SOFTWARE that they should be allowed to change it and run the changed versions instead of the original version.
If hardware vendors are allowed to take GPL'd code, make changes and release their changes but PREVENT END USERS FROM MAKING ANY MODIFIED VERSIONS OF THEIR OWN that run on the hardware, then the hardware vendors are able to TAKE AWAY the essential freedom mentioned above.
Because, the software ONLY runs on one piece of hardware---the Tivo, for example---and that hardware REFUSES to run modified versions on equal terms with the version produced by the hardware vendor.
Source code is not much use without a system to run it on. Don't you think that requiring users to rewrite large parts of the software just to get it running on *some other* hardware so that they can enjoy the ESSENTIAL FREEDOM the GPL was supposed to guarantee them, is a bit much?
Freedom given to me must be balanced against freedom given to you. Put another way, a lot of the freedoms a person may have can not be exercised without trampling the freedoms of other people. The BSD license refuses to address this, and lets receivers of the code do whatever they want with it. The GPL license tries to strike a balance between developers, modifiers and end users and tries to ensure that freedoms are preserved for all of them. If you're willing to let a hardware vendor subvert that, maybe you should be using a different license, since allowing them to subvert it was never part of the intention of the GPL.
P.S. there are an extreme number of ignorant and trollish comments on this article. Maybe some of you should learn a bit about Stallman and the FSF and their point of view, before you attack them ad-hominem.
And if they do, how does that hurt anyone? If they wanted to contribute back, they would anyway. If they didn't, they wouldn't use the GPL'd code.
Or, how about a computer with a TCM chip on the motherboard which checks the operating system on boot-up, and refuses to boot an "unauthorized" OS? Yep, there's plans in the works for this too. That's DRM.
;)
Gee...you mean like the encryption chips and various other forms of hardware protection that console makers have used, which have been fairly easily subverted? Or perhaps like the hardware dongles as a means of copy protection that have been used by a number of software companies, which have been subverted in around a day and a half, on average?
The day corporations come up with a means of copy protection or hardware control that some renegade 14 year old from Vladivostok can't get around is the day the world literally will end...and I don't mean simply in terms of politically, either...I mean the planet literally blowing up.
If you're in such desperate need to be afraid of something, then do yourself a favour and at least find something remotely credible.
DRM is a bogeyman, in exactly the same sense as Communists and men with turbans and large quantities of C4 strapped to their chests. For all the fear, wailing and gnashing of teeth they generate, they're seen maybe 1% of the times they're expected.
As I recall, this is a huge misunderstanding. The "newer version" clause is not part of the gpl itself. It is instead something that the FSF itself recommends people publish on their works. Something like "you may use the gpl version 2 or any later version at your option." I'd look it up for you, but don't have the time. You can find it yourself here.
I won't join Slashcott. OTOH, If Beta goes live, I just won't be back until it's fixed. Sorry Dice.
There is actually a simple compromise within the GPL 3 itself that could satisfy both of you. The GPL 3 has a clause that says something to the effect that if you write a GPLed app that provides the source code of the program through a webservice, then anyone who uses your code can't take out that feature. This closes the "ASP hole" for application developers who care about it, and leaves the "ASP hole" open for the rest of us who don't care if you customize your application and don't make your changes public.
Suppose the GPL3 contained a similar clause wrt to DRM? If your original application allows private keys to be kept *without providing a key generator with the source* (I'm not sure the best way of specifying it) then DRM to lock out your source is okay. Otherwise, the pro-keygen clause kicks in.
The trick is to make the GPL3 virtually idential to the GPL2 so as to make adoption a no brainer, but provide additional features that allow you the flexibility to provide more protection for your code if you desire.
So lets assume the next Tivo only runs a Redhat signed kernel.
Tivo can't distribute the kernel they don't have the key.
Redhat can't distribute the kernel without the source, under the GPLv3 this would include the key to sign the binary.
This is the problem, they are trying to license the software to prevent a behaviour in the hardware or other software.
This is wrong, the FSF insists this is not the case, but there is no accounting for the hardware and software vendor being the same or different people.
Well. Put your foot into the devil's maw if that's what you want. Tivoization for everyone! Just try running a GNU/Linux system with a custom (as in one that you built) kernel in a few years' time. Or try opening a document in That Proprietary Format that someone sent you in OpenOffice, if you do manage to boot a custom kernel -- or did you just break the attestation chain, you dirty little boy? Tut tut, no next-generation planned popstars for you.
In a nutshell, my point is this: Richard Stallman is doing the right thing here. The third version of the GNU GPL is not only simpler than the previous one, but also clearer, with fewer passages that are readily misinterpretable than version 2, and in addition serves to not only further license compatibility to things like the Apache license, but incorporates countermeasures against recent threats to software freedom, threats that are either not adequately defended against in version 2, or for which defence would depend on interpretation of the licensor's intent (which, if done in a court of law virtually anywhere, is iffy and expensive). If your RMS-bashing reflex is getting in your way of understanding the license outside your knee-jerk "COMMUNISM! KILL KILL KILL! FOR OUR PRECIOUS BODILY FLUIDS!" reaction, then please just shut the fuck up and let people who can actually up and read the document have the goddamn podium.
DRM isn't the *only* tool you should use to protect an election...of course. But, it's a useful safeguard for one threat. Dismissing it just because there are other attack vectors is silly.
The elections office does have final say over what *version* of the software is installed, but they do not have personal and private control over what goes in that version. Again, giving them direct control of the software in the voting machine would give them direct control over whether their party wins the election they are overseeing (and therefore whether they keep a job in many cases), which is a conflict of interest.
With DRM, to compromise a given version, you need the elections officials and the vendor to act in tandem, which is still possible, but much harder.
DRM does not mean that things are hidden, just verified. DRM and paper reciepts are not mutually exclusive. I don't see why you assume they are.
Well, in any case GPLv3 does not prevent voting machines running GPLv3 code from having hardware that verifies them against keys that are not publicly disclosed. You only need to disclose the key if you distribute the software. If you distribute the software so that it can run on any hardware, and then on one specific piece of hardware you require signed binaries, but you don't distribute this hardware to the public, then you shouldn't have to distribute the keys to the public, because the keys aren't required for the intended use of the software to the people it is being distributed to. Ie, you essentially have two different products - one is a software-only product that you're distributing that runs anywhere (no keys needed), and one is a software/hardware hybrid that you're only distributing to state governments, and those states get a copy of the necessary keys. Each product includes all the keys necessary to run it.
Only the owner of the machines need receive the keys (which is fine - that would be the state board of elections most likely). The machines aren't being sold to the public, so the public doesn't need to have the ability to modify the machines.
According to Netcraft, Apache has lost significant marketshare to IIS/.NET this year:
e mber_2006_web_server_survey.html
http://news.netcraft.com/archives/2006/09/05/sept
apparantly
Boffoonery - downloadable Comedy Benefit for Bletchley Park
I'm not dismissing DRM at all. I'm saying that the client needs to be in control, not the vendor. If anything, I'm relatively pro-DRM, under circumstances which I believe will never come about.
It is essential that they do have public oversight and control over what goes in each version of the software running on voting machines. They are the ones certifying the software, after all.
First of all, I am one of those people who believe industrial pursuits should have a reward and a carrot approach for those who can start up a company and come up with a product. Protections of some sort should be in place to protect small companies entering markets. Using a different patent system than what we have now, which puts large limits on the time you can lock up a copyright or patent. 2 years max for high tech for example, and 5 years for literary works, print, film etc.
However, in the two sections of the document as posted the authors give no supporting examples for thier arguments.
I for one, would have liked to see them address the issue or counter the GPL v3 documents on Submarine Patents as well as the growing problem of Intellectual Property/Copyright/Patent forever and ever direction the US is taking.
Furthermore, the patent system as setup in the USA is specifically designed around who has the most cash to give to lawyers.
The Blackberry dabacle was just an example.
Second, I would like to have seen the authors address the growing lets patent everything, and not make anything, and prevent others from making anything companies.
This is EVIL because it is sheer GREED and is a complete slap in the face of what the Patent system was originally intended to do: Provide a means to protect REAL inventions and spur investment so that the inventor can get his carrot for being so inventive/innovative.
In short, I would make it illegal to collect patents. If you can't build a protoype, you don't get a patent period.
The authors seem to be more concerned about the issue of patents and protecting a huge amount of patent IP property. Yet turn around and totally ignore the fact that the GPLv2 technically can't work in a patent system as defined now, critique the v3 of the license which attempts to weed out any participation from said companies to protect open source ideas and the people who participate in open source projects.
Finally, lets not forget the entire Open Source movement as defined by the GPL doesn't have a use for patents, has no use for DRM or "trusted" computing and continues to innovate and march forward leaving most US companies in the dust where they belong selling crappy windows products which are "patent pending".
-Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
I think LGPL is not really practical in a truly hostile situation. Here's a scenario --and please correct me if I'm wrong.
You, the hard-working, altruistic FLOSS coder, produce SuperLibrary v1.0, and license it under LGPL.
Big Evil Corporation comes along, takes your LGPL, modifies and improves it, and makes SuperLibrary v2.0. They link it with TheirMoneyMakingSoftware, and sells their program. People buy it, they make a lot of money, take vacations in the South Pacific, etc.
You say to Big Evil Corporation, "Hey, let's see the source for your new improved SuperLibrary."
Big Evil Corporation just gives you the source for SuperLibrary v1.0 and says, "We never changed your library. We just added new functionality in our part of the program, the proprietary part, and you can't have it."
How are you going to prove them wrong? Is there a way to dissect a binary and see if the modules are intact?
With the GPL, you have everything. So, you can try compiling the complete source code and see if you get the same binary. If you don't, then there may be some hanky panky going around. But until you can get a complete binary and compare the two, you never know if there's some back door or hidden function in their binary that doesn't show up in the source code because they're not giving you the full source code.
Can someone tell me that I'm wrong? Is there in fact a way to look into the modules in a binary and do a binary comparison of just certain portions of the code? (And can Big Evil Corporation defeat this by linking in BOTH your SuperLibrary v1.0 AND their own SuperLibrary v2.0, so that you can see your own modules but you don't recognize that a different version of your modules is also contained in their supposedly proprietary version of their binary code?) Any insight here would be appreciated.
404555974007725459910684486621289147856453481154 in hex is "You sank my Battleship?"
[GPG key in journal]
You have it wrong. Hardware manufacturers are not subject to the GPL, therefore it is blatantly impossible for the GPL to tell hardware manufacturers what to do. Q.E.D.
No, the issue here is about preserving the original intent and operation of the GPL. And TiVo is a perfect case in point. TiVo is distributing a GPL'd executable. TiVo is required to supply the full and complete source code to that executable. TiVo is violating the intent and operation of the original GPL, and arguably violating the literal text of the original GPL, by deliberately shipping INCOMPLETE SOURCE for that executable.
TiVo executables do not run unless they contain a signature. A signature which TiVi is attaching to the executable during the compilation process for that executable. A signature created using a key code during compilation.
That key code used to compile and create that executable is part of the source code for that executable. The GPL means that they may not distribute that executable without supplying the full source code - including that key code.
If the source TiVo gives you is incapable of recreating that IDENTICAL distributed executable - including the signature in that executable - then the source is obviously incomplete.
Either TiVo is in violation of the current GPL and the GPLv3 needs to explicitly adress this point to clarify the confusion that it might be possible to circumvent the GPL in this manner, or the FSF is obligated to update the GPLv3 to address and explcitly close this loophole in the original intent and operation of the GPL, if such a hole in the previous language does in fact exist. Ether way this point needs to be addressed and resolved as the GPLv3 is doing.
So this has nothing to do with hardware manufacturers. The issue is that hardware may check for a signature, and that a key may be required to generate that signature during the compilation of executables for that platform, and that SOFTWARE DISTRIBUTERS (who may or may not also be distributing hardware) may attempt to VIOLATE THE GPL by keeping that part of the source secret. In an effort to deny people the ability to modify and compile that software for that platform they need to deny people the ability to compile that source into that exact same executable (in volation of the GPL).
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
The easiest (non-technical) answer? Sue them and subpoena all of the relevant source code.
Show the court that their propietary code linked with your lgpl'ed code doesn't work.
Everything I need to know I learned by killing smart people and eating their brains.
I've rather meant that if say some "smart TV box" vendor takes MythTV, polishes its features and puts it on a DRM'd hardware, the MythTV guys will still be able to take the vendor improvements and integrate them in the stock MythTV version. Of course you'll be still stuck with the vendor MythTV version on your DRM'd smart TV box, but that's _your_ fault you went for crappy hardware, just as it would be your fault if you complained after you went for closed software on no-matter-how-cool hardware. The net community benefit still raises.
I don't say bad DRM is good thing or not a danger. But fighting it by changing software licence is not the way. You are fighting it in the wrong field and you are actually not likely to win, since the big corporations want DRM that badly that they won't care about GPLv3 software and rather invest in going some other way; alternatively, they may not have a choice in the first place and the restriction is placed by law or a regulation authority (think FCC in the case of the scanner).
Or look for it from another way. Suppose a DVD drive vendor made a driver supporting some cool features, and now you are thinking about releasing drivers for a GPLv3 OS. But GPLv3 says you can't unless you make your DVD drive region-free. *Bang*
Of course if the OS was in the position that the market base lost for the vendor would overshadow the losses coming from ruined bussiness relations and likely contract breaches, having that would be good thing, but that's not the case at all.
Alternatively, you can just say "screw corporate support". But please face it, huge amount of the free software development is now backed by corporations and without their support, Linux would be far from where it is today.
It's not the fall that kills you. It's the sudden stop at the end. -Douglas Adams
"By definition, competition is a key value for any successful group activity."
What definition are you referring to? Social Darwinism?
"Otherwise, the given activity would be crowded out by other more competitive activities"
I didn't realize there was a limited space in which activities take place.
oh no.
"Are you implying that the F/OSS movement is communist?"
No. How did you conclude that?
Communism isn't so much as a political movement as it is ad hominem label like "troll".
Just as proprietary software will never be able to eliminate "free" software, the FSF will never eliminate proprietary software.
I`m from Balkans, you insensitive clod!
Linus should change the COPYING file such that anyone can re-license the code to use GPLv3 if they want. Let RMS try to fork if he wants. If he succeeds, great, no more bloody DRM.
If he doesn't, great, little harm done.
The definition that I explained in my second sentence.
The total available space == 6 billion people * 24 hours/dayI think trying to use the software license to control what a hardware manufacturer does is inappropriate and overstepping.
He isn't. Hardware manufacturers can still do all that they were doing before, just not with GPLv3'ed code. It is restricting a use of the software, not the hardware. You can use the exact same DRM hardware with GPLv3'ed code and any other code, you just have to release any signing keys necessary to run the code if you use code licenced under the GPLv3. It is not required to modify hardware to be GPLv3 compliant.
http://marriedmansexlife.com/
Oh I agree that the DMCA is totally bogus and a stupid law. But that doesn't make GPL v3 is a great idea.
The real issue comes down to GPL isn't broken. It doesn't need a v3 and I feel as do many other people that v3 will break it.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
can be done. Software hackers/crackers do it every day. I don't think it's trivial (unless the corporation is really clumsy, i.e. adding reams of new code/functions). e.g., a common way to crack a game is to start with the demo .exe and compare it to the one off the box. Use that to track down the code that checks for the CD and remove it (this is why game companies are copy protecting demos lately). A clever OS programmer ( or a member of his/her community ), could do the same with your libraries and thiers. Once that's done, it wouldn't be hard to threaten suite, and if all else failed sue and win.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
That company could take a GPL program and use it and then claim "no, it's something we wrote ourselves" just as easily, or even easier.
If you assumme the company is going to lie and get away with it, then it does not matter if it is LGPL or GPL or if it is commercial software that they are supposed to buy a license for.
I agree.
What's equally disturbing is all the clucking being heard on behalf of preserving maximum freedom for.... who? Users? No! Large corporations!
The GPL was inspired by a lack of USER freedom.
I think this post says it best.
It's difficult to reply when comments are published as a news story instead of submitted to the gplv3.fsf.org forum. Using the forum attaches your comments to a part of the draft text.
Here are transcripts of eight GPL3 talks plus Q+A sessions. Many arguments for using GPLv3 can be found in those. Some specific points:
(This is a repost of a comment I made on another site.)
Please help publicise swpat.org - the software patents wiki
To all you whiney Raymondists: GTFO, sellouts.
Staring at a white background [on a computer screen] while you read is like staring at a light bulb — Maddox
A) Pointless
DRM stuff is almost all done at the kernel level or in close source software. The kernel is never going be GPLv3 because of the reasons in this article. So the anti-DRM clause won't have any effect.
B) Stupid
People who do pointless things are stupid.
You are looking at it from the wrong direction. People are being asked to change the licence they are using, so you have to give them a good reason to change to version 3. "So we can play politics with your work" is not a suffiently good reason for many. I think we have a bit of a single tool problem here - the one where the story goes that if you are used to a hammer you just thump on nails. Personally I think the FSF should take a more mature approach and consider talking to elected officials, academics and a lot of other people that are already half convinced about software patents instead trying to use a licence as a blunt instrument where it will only be noticed by the people already on their side who will be inconvenienced by it. If you can't even have a private encryption key on an embedded device there is something seriously wrong with the current draft of the new GPL - so it's time to stop the hero worship of the guy that thinks computers shouldn't have any restriction such as log in passwords and get on with the next draft with a bit more thought.
I didn't conclude that; that's why I asked. Good.
If you want to stay relevant, you have to have advantages against your competitors. The FSF very much wants users to have real freedom. If nobody can run free software in the real world because it all sucks, then what good is that?
http://outcampaign.org/
If they use an LGPL'ed binary, they have to dynamically link it (otherwise their own code will be considered a "derived work", and fall under LGPL). Therefore, you can just compare their version of libmylib.so with the one built from pristine SuperLibrary v1.0 sources, and if it is different, you have a case. Well, there's also an issue of various compile flags which can change the binary, but then it is up to them to show that there is a certain flag flag combo that, when applied to v1.0 sources, will produce the exact same binary as the one they distribute.
But in this case DRM can be used as a legal hack to get around the intended restrictions of the GPLv2 license (to protect users rights to get access to and modify the source).
If you are happy relying on market forces rather than the software license to uphold users rights/freedoms then you don't need GPLv2 either, you just need a BSD license and to pray a lot.
Matt.
If a manufacturer creates hardware that limits a person's ability to modify the software that runs on it then let the market forces apply pressure.
One of those market forces being that they should pay for using Free software in non-Free ways, if the developer is willing to license it to them on non-Free terms.
If the source TiVo gives you is incapable of recreating that IDENTICAL distributed executable - including the signature in that executable - then the source is obviously incomplete.
If the source RedHat gives you is incapable of recreating the IDENTICAL distributed RPMs - including the signature on them - then the source is obviously incomplete. Therefore, RedHat must distribute their code-signing keys to anyone who asks. See why that's not a good argument now?
GPLv3 is supposedly bad because while it is a software license it sais what the hardware should do (not beeing locked to run modified versions of the software). Seperating software from hardware is like seperating mind from body. The one doesn't work without the other. They are one.
You could compare the binaries. The point the GP is making is that there is no way to do that for statically linked libraries.
Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
Decision making is only in the hands of the owner iff the owner is educated and willing to download, modify, compile, and probably debug code. The percentage of computer owners who actually have that skillset is very, very small, so I'd argue that in most cases the freedom of code has little or nothing to do with the freedoms of the hardware owner.
This is not about functionality or freedom; it's about a few people who want to run modified software as the client of a secured delivery service. There is no reason that a seperate hobbyist key could be delivered with hardware so you can run whatever custom software you want, but which does not enable the software to participate in the secured service.
There is nothing in any version of the GPL to guarantee access to a runtime service or it's data. The code does not own the content, but GPLv3 tries to treat the possibility of encrypted services and data as being relevant to the licensing of the code.
In fact, GPLv2 was rather explicit about the output of programs not being restricted by the licensing of the code itself.
I do not fail; I succeed at finding out what does not work.
Apparently don't understand what a definition is.
Being relevent is all about how others view you or your work. If you have a worthwhile project you're doing out of faith, it doesn't matter what people think.
And I didn't understand where to put the "you" in my last post.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
Copyright (C)
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
[SNIP]
So, as you can see, the people who handle the GPL lead developers who are unfamiliar with licenses to the "correct path" -- i.e., that which makes the license GPL version x or later.
I've seen that a missunderstanding a lot, and I semi-suspect there may be a FUD source somewhere deliberately pushing things like the (false) idea that this GPL issue would force people to release keys that it shouldn't. It's just not true.
There is a very specific and very GPL-critical difference beetwen what Redhat does and what TiVo does.
If the source RedHat gives you is incapable of recreating the IDENTICAL distributed RPMs - including the signature on them - then the source is obviously incomplete.
Which is perfectly OK. Redhat must supply the source for the executable they distribute, and they do. Redhat can incidentally ship that executable packaged in an RPM or packed in a Porche, and they just have to supply the source to that executable. They don't need to supply the source to the Porche or to the RPM. Shipping an MP3 incidentally alongside a GPL'd program does not "infect" the MP3 with the GPL. Does not make the MP3 subject to the GPL.
How is TiVo's situation any different?
Obviously I cannot ship an office suite executable and supply source for a different tic-tac-toe program. Equally, I cannot ship a Cray mainframe executable and supply DIFFERENT source for compiling a similar (but DIFFERENT) executable for an Atari 2600.
If I am creating an executable for a Cray, and there is some Cray specific element in that source needed and used to create that complete executable, and I ship that Cray executable including the functional Cray specific elements of that executable, then I need to supply the full source complete with the Cray specifc source I used in making that executable. I cannot leave out parts of it and supply source that would happen to be adaquate for making a DIFFERENT executable that happens to be able to run on an Atari.
Redhat's intent and Redhat's actions are is to create that full and complete executable that have no signatures. Redhat can and does full well intend to distribute signature-free executables and properly supplies source for those signature-free executables. The fact that Redhat incidentally may choose to also supply signature files along side them... signature files supplied for a purpose OTHER than as a functional component of the executable.. does not make those other files a part of the executable. Just as shipping a Redhat street address file along side it in the RPM would not be part of the executable.
TiVo is intending and acting to create executables where the signature is in fact intended and used as a functional element of that executable. TiVo is using the key as a part of the source to create the executable they want and need. From TiVo's own point of view the signature is in fact a REQUIRED functional element of the executable they are compiling and distributing. TiVo can not claim to be intending and acting to distribute a signature-free executable that is incidentally packaged along side a signature file. If the signature were left out, TiVo themselves would consider it an incomplete nonfunctional executable.
TiVo knows and considers that signature to be functional element the intended executable they are distributing. TiVo acts to use that key AS needed source to create their intended executable they are shipping. TiVo is required to supply the full source they used to create that exact and entire shipped executable. Which means that key.
If Redhat were to compile an executable intended for some bizarre platform that USED a street address as a functional element of executing an executable, and Redhat shipped their street address in the RPM with an executable for that platform and Redhat intended and used the address as a functional element of that executable for that platform, then Redhat's street address would be part of that source.
The law routinely looks at intent and how you use something. If you use a key AS source to make your intended executable, then it IS source and is covered by the GPL. If you use the key for some purpose OTHER than as source for an executable, then the key is not source and is not seen by the GPL. Either TiVo is violating the existing GPL, or they are slipping through an arguable linguistic loophole in the existing wording of the GPL in violation of the original intent.
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
"(think FCC in the case of the scanner)."
There's nothing preventing you from complying with the FCC. The GPLv3 would just prevent you from refusing to run modified drivers for the scanner.
"But GPLv3 says you can't unless you make your DVD drive region-free."
It doesn't say that. It says you cant use GPL code, unless you dont prevent someone else from modifying and running it. _You_ dont have to ship region-free code, you're just not allowed to prevent anyone else from doing it.
"But please face it, huge amount of the free software development is now backed by corporations and without their support, Linux would be far from where it is today."
The corporate support Linux has today is _because_ of the GPL's forced levelled playing field. If you want an example of what happens without that enforcement, take a look at the BSD history and the UNIX flavour wars.
Corporate management is full of cover-your-ass control freaks who'd rather go down fighting over a piece of a shrinking pie they want total control over, rather than live with a free market where they have to live with the uncertainty of the much bigger pie.
The GPL enforces a free market and a level playing field, preventing the free riders who'd force the big corporate supporters out in protection of their competetive advantage. With the GPL equality, the corporate supporters cant use the code as a proprietary weapon, but neither can they get their donations used against them by someone else, allowing them instead to compete in other fields they find more attractive.
There is a tool called "nm", which examines a library or executable, and lists every function name in your library or executable. If they have distributed SuperLibrary as a shared library, any new functions are definitive evidence that they have modified it.
.dll or .so, causes the executable to be GPL'd. If you see a list of function names that you know are in SuperLibrary 1.0, you can use your judgement to decide how likely it is that they have named all of their functions the same as yours.
Static linking, where you take the superlibrary code and put it in the executable instead of a
There is another tool called "strings", which performs similar to nm, except it prints a list of all the text strings in the application. this would tell you every text string which shows up in menus, dialog boxes, error messages, etc.
These tools are both common on linux/gcc. I assume similar tools exist for windows.
Neither of these is 100% definitive, but they are pretty good evidence, and certainly enough to start a lawsuit and sopena, as sibiling poster mentioned.
A few ingrates would benefit from other people's efforts, all the rest would lose access to the improvements.
Been there, no thanks.
IANAL but write like a drunk one.
We humans improve on things and stop reinventing the wheel when we can learn from the experiences of others.
Human culture is based on the sharing of knowledge.
BSD licenses go against this healthy trend, condemning people to reinvent the wheel forever when they could be doing something more productive, useful or fun.
If you want to kill human culture in the best sense of the term, contribute by releasing software under the BSD license: no code, no questions, no progress.
IANAL but write like a drunk one.
Don't dress your prejudices as opinions.
If you don't know what the difference is, well, bad for you.
IANAL but write like a drunk one.
I'm I'm not free to rip it off, then it's not free, is it?
Play all the language lawyering you like, but GPL software is by definition not free.