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/
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.
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;
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.
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.''
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.
"Why fix it then?"
It is getting broken. The current actions of certain companies to use the freedom of GPL code without passing on that same freedom to recepients of that code, through the use of, for example, DRM hardware detecting and preventing modification of the code, essentially is an example of 'broken'.
Anyone vaguely familiar with the history of the FSF and RMS can recall one of the origin stories of the FSF, involving RMS recieving a buggy printer driver he wasnt allowed to fix due to its proprietary nature and closed source. Had he recieved the source, but then the printer had refused to use the updated drivers, nobody can reasonably come to any other conclusion than that DRM restrictions on the running of GPL code would be just as disallowed in GPL v2.
The changes are exactly in line with the FSF reasoning, like it or not, and a natural evolution of the GPL to cope with new issues. Anyone more concerned with the freedom of those wanting to restrict others has a perfectly good selection of BSD type licenses to use. For those deliberatly and knowingly placing code under GPL these updates come as no surprise, and are not at all unwelcome.
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
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.
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.
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.
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.
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).
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.
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.
apparantly
Boffoonery - downloadable Comedy Benefit for Bletchley Park
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]
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.
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.