Slashdot Mirror
Plugging Holes In The GPL
For the last several weeks I've been thinking about the word "distribution" because the meaning of that word and the way we interpret are going to be one of the most important debates for the free software movement in the next several years. The problem is that a loose definition of the word opens up many loopholes in the GNU General Public License, both for corporations and average Internet users.
The word is crucial because it lies at the core of one of the most distinctive requirements of one of the most distinctive open source licenses. If you modify software protected by the GNU General Public License and then distribute the new version, you must also distribute the source code.
On the face of it, this requirement sounds pretty easy to satisfy. Every time you give someone a copy of the binary version of the code, you give them a copy of the source code. The two should travel together or at least in close proximity.
The main reason the clause is part of the GNU GPL is because Richard Stallman, the license's principal author, believes that anyone who drinks from the commonweal should give back. If you benefit from the sharing of others, then you should make sure to give something back.
But, if you dig a bit deeper, the notion of distribution becomes a convoluted. Some of the ways that people share software with each other may not really count as distributions.
The distribution requirement is one of the concessions that Stallman made to the users and their sanity. You don't need to share all of the changes you make to the code -- only the code you distribute. Sharing everything might unleash a painful process, one that would push too much untested code on the world. Do we really want everyone sharing their files everytime they save a copy to do a new compile? The compromise, which sounds reasonable, only requires you to share the source code when you share the software.
The problem is that the act of giving someone a copy is getting a bit harder to define, because of the new features embedded in operating systems, the near omnipresence of the Internet, and the new interest by corporations in the phenomenon of open source software. Many of these new wrinkles are confusing because they push the boundaries of both technology and license.
The biggest problem is that new features are making it easier and easier for two programs to work in synchrony without being formally linked together. You might use one piece of GPL protected software to edit files and one proprietary program to process them. The GPL embraces these sorts of bright lines between programs; mixing closed source programs with open source ones is not forbidden.
However, it's easy now for people to write scripts that link seemingly disparate programs -- thousands of them, even -- and then execute them in concert. I know one company that uses Adobe Photoshop to process images created by a proprietary, in-house tool. Is the software linked together? The process is entirely automated and works with no human intervention once initiated.
The line blurs elsewhere, too. On some cool multiprocessor machines, two supposedly separate and independent programs can execute on different processors and send messages back and forth. Where do we draw the line?
The process is getting even more confusing when the Web gets involved. Imagine one programmer who creates a tight weather prediction package for the Web that stores the forecast in a GPL-protected database. The programmer links all of the proprietary code together with the database. The result is a new package that extends the database and thus must be shared completely with the world according to the GPL. This is certainly fair. If anything, the GPL-protected database code is doing the bulk of the work. The programmer succeeded by standing on the shoulders of giants.
Now, consider a different programmer who, for the sake of example, stores the database of forecasting information on one Web server in California. The main website which dispenses the data to the world sits in NYC on the other end of a fast backbone. The main Web site uses the proprietary code to look up data in California before publishing it on the Web.
Should this programmer be forced to share the NYC code with the world? Let's say the programmer starts selling the package as a $10,000 proprietary package for adding cool weather graphics to a Web site. Anyone who buys it must install the GPL-protected database and make sure that it's always running. But are the two programs technically linked together? The California server might be GPL-protected, but does this extend to NYC? The NYC site certainly can't operate without the California server, right? What would happen if the server was right next door? What if it was running on the same machine under a different user's login?
Stallman anticipated this problem and offered a Lesser version of the GPL which would let people link with GPL-protected libraries without releasing the software to the larger program. But that lesser version, known by the acronym LGPL, is a bit rare.
I don't envy the people who try to make sensible decisions about what counts as a distribution and what doesn't. Stallman has done as good a job as he possibly can. He sensibly recognized that GPL-protected code was going to have to live in close proximity to non-GPL code. He realized that these programs might be linked together by shell scripts and other tools. But where do you draw the line?
The problem is being stretched as the world of corporate computing discovers open source software. In the past, the definition of "distribution" was easy because everyone was just an individual hacker. If you gave a program to your buddy, you distributed it.
But imagine that MegaSoft decides that it really needs an internal editing system for filling out proprietary MegaSoft paperwork. The programmers love Emacs so they take GNU Emacs and add a few tweaks for providing the user with forms. Some of it is written in Emacs LISP and some of it requires a few neat extensions to the basic Emacs module. Everyone loves the software and they start shipping it to all of the PCs in the corporations.
Is this a distribution? Some might argue that it isn't. A corporation is just a legal fiction for a single person. It's not much different than Bob the hacker writing the code for his own use. Bob doesn't need to share the source code until Bob starts giving it to Alice, the other hacker. By this argument, MegaSoft doesn't need to share the source unless MegaSoft ships the software to another company or non-employee. Even if there are 100,000 employees in MegaSoft, there hasn't been a distribution.
There are millions of problems with thinking of a corporation as a single hacker. What if the corporation splits in three like AT&T? Do all three get the code? Should only one? What if the corporation is aquired by SuperMegaSoft? Is this a distribution? What if the form-enabled Emacs was the only reason that MegaSoft was worth anything because the rest of MegaSoft wasted the rest of their VC money on a plan to sell clothing advice to fashion victims? (www.DrBoo.com)
But there are other problems with forcing corporations to share all of the code all of the time. Are corporate teams that much different than free software teams? Shouldn't they have the freedom to work for several months without distributing the changes? It saves us from buggy pre-alpha code and it saves them from repetitive bug reports. ("It crashes when I start it.") Where do we draw the line? Why can't they enjoy the same freedom as individual hackers to make a few, krufty changes to the source code and leave it at that?
There are deeper problems in corporations. By many measures, Tivo is a good example of the power of free software. The digital video recorder for television signals runs on top of the Linux kernel. The only reason anyone knows this is because Tivo gives Linux credit and it shares copies of the changes it made to the Linux kernel. In many ways, it's a model of a great corporate citizen in the world of free software.
But Tivo didn't share the source code to their television recording front end. It's a separate program running on the machine. No one's gotten in trouble for running proprietary code on top of a GPL-protected kernel.
The Tivo, though, is different. It starts up the proprietary code when it boots and the user has no way to communicate directly with the kernel. The user can't use any of the standard UNIX commands to control the machine. The user can't do anything that the proprietary front end doesn't allow. This will probably save millions of users the grief of reformatting their hard drive.
But is this really fair? If the user can't pry apart the Tivo front end from the Linux kernel, are the programs intertwined enough to become the same program? If so, shouldn't Tivo be releasing the source code to the front end as well?
There are deeper problems on the horizon. Some companies are now "loaning" or "renting" software. In some cases, you don't even keep copies on your local machine. You just download it from the server and use it for a bit.
Is this a distribution? On one hand, the user doesn't get to keep anything. On the other hand, who do we think they're fooling? The whole system is just ephemeral clouds of bits flying around. To think that anyone "owns" something as abstract as software is like saying that someone "owns" a cat.
In fact, we can take this one step further. What is the real difference between using the software on their server and downloading it? Is there much difference between using the Hotmail web-based email system or running Eudora on your desktop? There isn't much difference to the user, even though there are big legal differences. In one case, Hotmail still owns the software and it's all proprietary. In the other, Eudora sold you a copy. Well, maybe they sold you a license. Well, who really knows?
I won't try to find answers for any of the questions about distributions. This is, in some respects, a chicken's response. There are millions of ways to find things wrong with the world. A real leader would find solutions. But it's also important for these answers to come from the community at large. There should be a long debate that focuses on the needs of the users and the creators of free software.
The biggest problem is that the answers are more political than technical. It's easy to define what an piece of software should do if it, say, encounters a request to divide by zero. It's much harder to handle definitions of what is and is not a distribution.
The community needs to weigh two different features of free software: On one hand, there's the fun of taking apart the source code and fixing it. On the other is the responsiblity for contributing back to the common code base. Stallman chose to tie these two together by requiring programmers who benefited from GPL protected software to share their source code when they "distributed" the new version.
The notion of distribution was a simple notion that worked well when the typical coder was just an individual hacker spinning code and sharing it with his buds. Now the game is bigger, and much more complicated. We need to find a new mechanism that balances the freedom to hack with the responsibility to give back. We need to find a better, more clearly defined line to draw.
For the record, here are my proposals:
- Corporations (and everyone) should be required to release the modifications to their source code every six months to a year, if the modified versions are shared with more than, say, three people.
- Two piles of code are considered linked if one will crash or cease to provide more than 90% of its functions without the other. Note that this doesn't mean that any piece of software running on a GNU/Linux machine is considered linked to the GPL-protected kernel. If the software can be moved to a different OS, then it doesn't depend on the kernel.
Tune to http://www.wayner.org/books/ffa/ for information on Wayner's book on Free Software. It launches in July 2000.
Sure, most hackers contribute their changes because they want to. But most corporations don't even bother with the GPL, because they *don't* want to contribute their changes. If those corporations had the advantage of the GPL codebase, they would run GPL software into the ground. Their code would simply be higher quality, not because they are better programmers, but because they have the free software community doing free work for them, *plus* their own programmers. They'd always have the upper hand. Their software would always be one step ahead.
Look at the issue from this angle. If Open Source(tm) software (as understood by Mr. Perens) is supposed to be such as superior development model it should survive on it's own merit without the necessity of licensing to protect it.
GPL zealots reject any suggestions of it being similar to the communist system but it is in a way. At least the fact that GPL enforces sharing is strinkgly similar to what communists did to the farming industry. They took all farms from the private hands (with or without the owners consent) and turned them into megafarms producing food that was shared amongst those who worked on them and the surplus (if any) would be sold to the shops. Eventually they 'phased out' private ownership altogether. How well that worked we all know now.
Sharing works at times but there must be a way for someone to bail out if they feel they gave more than they received and that they can do better outside of the commune. Some may actually contributed very little but may have the enterpreneurial trait that make them believe they can add value to what the commune produced and better themselves. And that's quite OK! The reason is that that's ok is because they REALLY have to add value. Think about it. RMS tells you that without GPL a company can 'steal' our code and turn it into a product that they sell for profit. The reality is that it will not work unless said company can add a lot of value to the original code in which case they deserve to make profit in my book. On the other hand if they just shrinkwrap and add a minor improvement here and there there is no incentive for the (informed) buyer to purchase the commercial version.
Communes and sharing always seem to work great in the beginning when the enthusiasm is there and all animals seem equal (GPL community). But after the initial excitement some notice that not every pig is equal because some pigs try to get a little more from the system without giving back (think all those who use GPLd software but never write/test/document any). Eventually someone tries to ride the wave and take the credit from good horses who just quietly code all the time (Mr. Raymond comes to mind).
So GPL doesn't benefit everyone. Just like communism it benefits those who are visible and loud but not those who work hard. A BSD coder can extend their code and one day decide they want to turn their effort into a product and they can do it. The freeloaders don't have the right to complain because they still have the old version which is free. For a GPL programmer this isn't an option, once communal always communal is the name of the game here. To put it bluntly: GPL protects noone and restricts the programmer while the BSD license gives the freedom to both the programmer and the user to do whatever they like.
The GPL has been hammered over and over again, and it seems to be doing its job of encouraging people to share their source code in an attempt to give back to the community what you have recieved.
As a professional software developer, I have been the beneficiary of quite a bit of software programming gems which have been given out as a matter of public domain. I have even taken these subroutines and incorporated them into some of the software that I've written for my employer. Unfortunately, by the nature of my contracts I can't release this software even if I wanted to (sense it is a work-for-hire... copyright issues and stuff). I've been careful regarding the GPL, and my immediate supervisor is actually looking forward to releasing updates to some GPL'd software under the GPL, especially as we are moving toward using Linux as one of our major platforms.
The point that I'm trying to make is that you can always try to get around any restriction if you really wanted to. Just look at the US Tax Code and see how some of the wealthiest Americans pay less, sometimes in absolute numbers, than many people making less money. They just hire a good CPA to find the loopholes to get out of the taxes. The GPL is no different, and if a company wants to use GPL'd routines and products, there is always going to be a way to get around the restrictions, even if they are upheld in court.
Probabally the most important thing to keep in mind with the GPL is to keep it up to date with current technology and changes in the computer industry. This article mentioned distributed software applications (where software runs on multiple machines... and I'm not just talking Seti@Home either), hacked interfaces (such as the Photoshop example), and stuff like Java or Flash applets where you run something once and then throw it away when you are done. The trick here is for the developer of the software to decide just how they want people to use it. What happens with quantum computers come along? Can you GPL a quantum machine? How? What about a neural network design?
The GPL needs to be updated from time to time, and the legal profession has long been slow to react to changes in technology. As long as the GPL stays in the hands of the technology developers (working, of course with lawyers.. but I degress) I don't see that this will be much of a problem.
Is this a distribution? On one hand, the user doesn't get to keep anything. On the other hand, who do we think they're fooling? The whole system is just ephemeral clouds of bits flying around. To think that anyone "owns" something as abstract as software is like saying that someone "owns" a cat.
My cat owns me.
She flies around like an ephemeral cloud of fuzz, clinging to my head on occasion.
So can we bring this to the software world? For a period of two weeks, Unreal Tournament owned my soul and car keys. What does one do when software owns one? I don't fly around like a cloud... but yet I am owned by various games for various periods of time.
Linux also owns me. Otherwise, I wouldn't always be hitting Down-Enter at my bootloader to get in there. Linux makes me update it and it makes me recompile the latest 2.4.0.test offering and if it crashed, Linux politely informs me that it's my own damn fault.
Therefore, Linux owns me, and I may be considered by some a derivative work!
So I shall now distribute myself freely over the Internet as 100% GPL'd Talon. If sourceforge gives me a few terabytes I will upload my DNA.
Until then, enjoy this comment as a free sample.
I think the GPL is often misinterpreted to say that source code must always be available to everyone in the world who wants it, and since that's not reasonable at certain times there are loopholes. My understanding is that it doesn't in fact say that. What it does say is that each executable or object must be distributed with source, or a written offer of source.
If you read the GPL section 3, it gives you 3 options a, b, and c to comply with the distribution requirement. If you meet option a, you don't have to distribute source to any 3rd parties as required by options b or c, the written offer options.
I quote the GPL preamble:
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. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
So you have to give program recipients the same rights to source as you have, but you don't have to give non-recipients _anything_. Hypothetically Red Hat could take down their anonymous FTP servers and distribute only on CD-ROM's in boxes, so long as a copy of the source accompanied each binary or was available at a nominal charge (like magtape days of old), and their customers have full GPL rights. If a company modifies a GPL program strictly for internal use, then the source must be available internally, but not necessarily externally if they don't distribute the program externally. Limited "beta" programs by software companies are allowed, so long as at least the limited "beta" participants are provided with source on request and have full GPL rights.
I don't see where GPL is all that unclear about distributions. It can be looked at on a person by person basis. If you give a GPL software program to a person for any purpose, you must give that same person a copy of the source, either immediately or on his request, and a statement of his GPL rights, but you are not required to do anything for anybody else. Seems pretty tight to me.
Consider circumstances where the operating system becomes subsumed in application software -- suddenly the concession to reality of permitting distribution of a GPL'd application together with a proprietary application. In the context of some OODL's, this distrinction between operating system and application dissolves.
Consider Smalltalk-80 and modern day open-source derivatives, such as Squeak. In Squeak, all objects, sources and applications co-exist in a Smalltalk "image." Because of the nature of late-bound OODL programming, it is IMPOSSIBLE to combine Squeak with GPL code without infecting each and every application in the image -- this is because the image is not the operating system.
Unfortunately, this makes it legally impossible to merge GPL code with Squeak without rewriting large portions of that code, which while open source cannot co-exist with GPL. Too bad for Squeak, and too bad for the GPL. Moreover, too bad for the community, which is deprived of excellent software that could have been.
they would run GPL software into the ground
Yeah, just like nobody ever adds on to XFree86. When was the last time you heard anything about that project? Nobody uses it, everybody wants to pay for the slight improvements in proprietary versions.
FreeBSD, too. The way people are free to make proprietary versions just slaughtered that project. It isn't nearly as stable or secure as something like Linux, and there hasn't been a new feature added in years.
Boy, the GPL certainly seems to be essential, given that there are no free software projects that have survived without it, and certainly no major ones. I'm sure glad it and all the other mutually incompatible licenses are around to keep us from mixing code between free software projects, so we're not just stuck with public domain code that anyone is free to use as they please without wasting their time worrying about legal issues.
What's "fair" about it? He is USING the database, he is not changing or extending it. This is the kind of lunacy that gives the GPL a (perhaps deserved) bad name.
There is little question as to what distribution is and isn't. If the code is given to the public, it is distributed. The answer to your MegaSoft question is easy: no, it is not distribution. These supposed problems you bring up aren't problems or questions.
Using some software to distribute information on the web is not distribution, and should not be treated as such. The web is no different than any other process. If I edit a GPL'd mail program, and use it to send mail to the outside world, must I give away my changes? Of course not. So don't pretend that is any different from using GPL'd software on the web, because it isn't.
Consider your weather database example again. No modified GPL'd code is being distributed. The fact that it uses GPL software is entirely irrelevant. Using a database is not the same as linking a library. And actually, I'd argue that you couldn't legally enforce that linking to a GPL'd library makes your code GPL'd anyway. It is a separate bit of code. It is used as intended. Linking to it does not necessarily constitute derivative work. That makes no more sense than saying that code written with Emacs on Linux compiled with gcc must be GPL'd.
In other words, I think the LGPL is rarely used because few people see it as necessary.
Two piles of code are considered linked if one will crash or cease to provide more than 90% of its functions without the other.
If you want to absolutely kill the GPL and perhaps free software altogether, this is a damn fine way to do it. Basically everything that relies on Linux, Perl, gcc, etc. would now be forced to be GPL'd (except for those users who opt for the AL under Perl). Anything that relies on Postgres or MySQL is GPL'd. This is absolutely nutty and unreasonable. You think Linus would continue to use the new-and-improved GPL if this were the case? Not likely. He wants people to use Linux, not be trapped by it.
Hell, you'd rather have it so that cool innovations like Mac OS X are not possible. Apple, though not a perfect entity, has built a pretty cool thing in Mac OS X, made possible only through open software. And they are giving back all of their changes to the open source stuff they are using, which in turn helps everyone else. Right now, free software and proprietary software are coming together and helping each other. Under your plan, they would be split off and fractured permanently into two different camps, and free software would lose, because many of its sources of funding would dry up.
The GPL has no holes, except those that Stallman intended.
Although I believe we owe a lot to Stallman, and a lot to the GPL, it may be time to ditch it.
The reason is, we're losing site of why we like open-source software, of why we do it, and of the goal for better software and global peace (I just threw that in there, seems to fit).
I don't think most hackers contribute their changes back to the community because the bibl^H^H^H^HGPL told them to. They do it because they enjoy doing it, or they enjoy seeing a program get better because of their actions, or they enjoy getting recognition as being a hacker of open-source code. Whatever - I don't think Apache has much trouble getting people to contribute back to them, and their not using the GPL for their stuff.
I've seen plenty of people worrying that they don't want their code used by someone else to make money. To these people I suggest a)you're being a bit arrogant and stupid (I'll let you figure out why), and b)you're forgetting what makes open-source software "better". Why would someone be able to make money off your program by turning it proprietary? The open source version is free - it's got more development power behind it, it's more responsive to users, etc, etc.
Which leads me to the goal of the movement - free software for all. What's the best way to achieve it? Throw off all proprietary strategies and start out-producing! After, aren't we saying that open-source is superior as an economic model? ie, it's a more productive way to produce
high-quality software. Well, stop trying to win the game by "cheating" (ie using proprietary strategies like the GPL), and start winning by burying them.
Yes, if you see parallels between this and capitalism vs communism, then you're right. However, I see OSS as the new capitalism - in the sense that it is a more efficient system and will leave the old capitalism behind.
I think the GPL played a needed role in getting the movement jump-started. But, I'd like to see it be phased out by the community. I'd like to see a new license developed that, instead of putting restrictions on people, it merely informed them about the software - about where it comes from, where to contribute to, who the maintainers are, where to get tech help, etc. Not really a license, I know, but stuff like that could be standardized to good effect.
A good migration path might be for more and more developers to start using the LGPL, and then as more time goes by, just use the non-license, or even public domain (I don't like public domain as a name because it implies it's just "out there" without a specific group of people that maintain it).
First, make it work, then make it right, then make it fast, then, make it bloated!
The GPL is fairly simple. Live and let live. Or, more to the point, code, and let code. The release of the source code with the program is the heart of the GPL. As is giving those GPL rights to individual users when you release the code. In fact, every peice of code originating from a GPL core is supposed to be released under the GPL.
Manufacturers and software corporations who do not wish to release their source code, should not attempt to fall under the GPL. Such mandering is simply a marketing ploy to them, and it defeats the purpose, and the intent of the GPL.
Software manufacturers have to make money to stay afloat. No problem. They can sell their merchandise under the GPL. There is no provisions with either the GPL, or the FSF's mission that says you cannot make money off of your software. They only say that in order to release it under a GPL, you have to abide by the "un" restrictions of the GPL.
Or, in black and white, there should be no problem, because those with problems (with the GPL) shouldn't USE IT.
krystal_blade
It will be easy to motivate our fellow man; there is hardly anything people treasure more than not being annihilated.
If a corporation releases a binary to 1 person outside the corporation, they must include the source with it.
In principle, I agree with you. However, while I believe that many of the so-called ambiguities in this article are not valid, this issue - 'release to specified individuals only' could be a real hotbed of controversy. Example #4 (below) is the real killer, but you need to ride the slippery slope to see how it could read in court.
For the sake of argument, let's imagine a GPLed communications program that has been modified to use a new unpublished crypto algorithm that the author doesn't want to release yet (or may never want to release). Maybe it's "security through obscurity", "NSA paranoia", or a real breakthrough -- it doesn't matter. I'll discuss two cases: a corporate modification and a 'lone hacker' modification, since different precedents will be based on different programs
1) A corporation creates this program to access its proprietary in-house system. It makes the program available to its employees, binary only. This is internal use - no source release required
2a) The corporation now supplies the program to contractors and consultants. Note: this is controlled release, but the recipients are not company employees. (Almost any internal-use program will end up being used by consultants or contractors at some time.) By your argument, this would be a mandatory source release, but I doubt a court would agree, due to the client-agent relationship and the specific need to access the internal corporate system.
2b) a private individual writes the above modified program to controll access to, say, his private anti-gov't website. He gives copies to relatives and a few close friends. Are blood, friendship, or academic ties enough to allow him to consider this 'internal use'? Unlike a corp, where individuals can be 'parts' of the 'legal person', he is dealing with 'outside' people.
The catch in 2a and 2b is limited release. Many prominent Open Source programs were 'private hacks' that grew into something useful and then released to the community. Not everyone wants to open themselves up to criticism until they are reasonably sure they have something good.
NOTE: The 'open source' provision of GPL only guarantees source to those who already have the program, not to the universe at large,
Limited Release is a slippery slope...
3a) The company makes the program available to a partner company on a project. Arguably still 'in-house' in a court's eyes
3b) The company makes the program available to a consortium (or assigns the program in its entirety to the consortium)
3c) The individual uses the cool program he wrote for personal use to do neat-o things at work (either as employee or consultant) but he uses it as a personal tool and doesn't install it permanently on their system
3d) The individual's client company insists that he install the program permanently (or sign over his rights to the program for a fair fee) on the grounds that the contract isn't fulfilled if only he can diagnose/repair the system. What rights can he sign over. if you believe he had the right to do 3c above, why can't he assign that right? Under copyright law, he can assign *all* his rights.
There are many other examples, but I'll conclude with one final-- The Horror:
4) a company writes commercial software, which it does not *sell* to the consumer, but allows them to *use* under a contract or license, either temporary or permanent, while retaining full ownership, and perhaps even the right to shut it down remotely
SOUND FAMILIAR?
Is this distribution? A loan? A limited access? "Use within a specified business relationship"?
Look, I think 90% of us would agree what it should be, but I hope you can now see how it *might* be seen after several years of precedent
If you can go to bed, knowing you did a valuable thing today, you're very lucky. If you can't... it's not bedtime
Remember, GPL's only power comes from copyright. Under copyright law, a program that links to a library is considered a derivative work from that library. A program using code from a copyrighted program is also a derivative work. But a program that merely accepts data through a pipe from a copyrighted program is *NOT* considered a derivative work. And of course, copyright law allows the author of the original work to dictate exactly under what situations the work can or cannot be copied -- or, as the GPL puts it, "distributed".
The real problem, though, is client/server based programs -- which I think the author was trying to describe, even though I don't think he did it well. As an (unrealistic) example that I find easier to understand than the weather thing, I can take a GPL X11 program, say Emacs, make some modifications to it without releasing them, and then type "DISPLAY=some.other.computer.com:0 emacs", and the person at some.other.computer.com using my modifications to Emacs doesn't have the source code to those modifications. I can even charge for this service.
And of course this problem would more realistically crop up with something like a part-GPL CGI backend to a web site. Web sites may eventually have the functionality of client-side programs, and unfortunately the more powerful HTML is, the less powerful the GPL is, because GPL code can be mixed with proprietary code in CGI's without giving any code back.
The only solution to this problem is to do what the GPL has of yet intentionally stayed away from doing -- restricting the ways in which a program can be used (rather than copied). The legality of this is questionable (or at least some people consider it questionable), but it is the basis of software click-through/shrink-wrap licenses, so it's already common practice.
I'll give my responses to his suggestions first and then ask my own question about the GPL which I hope someone will be able to answer.
1.) Corporations (and everyone) should be required to release the modifications to their source code every six months to a year, if the modified versions are shared with more than, say, three people.
Besides the general unenforcability of this because a.)We will need GPL auditors swoop down on random Fortune 500 IT departments to do on-the-spot checks like for AutoDesk and other expensive proprietary software) b.) The specificity of certain extensions makes them meaningless to anyone but that corporation. (the company I work for has several e-lisp packages for Emacs that simplify many tasks specific to our project) Asking companies to GPL internal code, would simply make the GPL more of an anathema in the corporate world. Which would suck since I use a lot of GPL software at work.
2.) Two piles of code are considered linked if one will crash or cease to provide more than 90% of its functions without the other. Note that this doesn't mean that any piece of software running on a GNU/Linux machine is considered linked to the GPL-protected kernel. If the software can be moved to a different OS, then it doesn't depend on the kernel.
This seems even more unenforcable, how do you quantify 90%? This also seems unreasonable, if I have a script that uses grep in several places to perform a complex task, do I have to GPL the script or all the code invoked in the script, isn't a script by definition something that probably serves a specific task for a specific situation....what would be the point of asking for all scripts that invoke or use GPL code to be GPLed? Also about the "one will cease without the other argument", what exactly will this mean... if I can write a program that uses libraries that are either GPLed or proprietary, does this mean that I have escaped the "one will cease without the other" argument? On the other hand if the author actually means that the GPL code used should be extracted then the program run, more than likely the program will cease to work. After all I have lots of code that is over a thousand lines but would cease to exist if three or four lines would have to be erased.
Now my question:
With the rise of the web in general and Application Service Providers specifically...what happens when a website uses modified code to serve it's pages? If Yahoo, eBay or AOL which draw millions of visitors a day use modified GPLed software (e.g. Apache and various modules) there is no way under the current GPL to ask them to return their code modifications and the suggestions by Peter Wayner do not address this (e.g. what if it's one or two people who perform the modification, not three or more).