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.
The GPL may have its flaws but they're not exposed by trying to come up with weird definitions of "distribution"
Rich
Give me a break; forcing companies to release source code removes *their* freedom. Remember, they, like individuals, have freedom, too. Legally they are classified as individuals, with their own EIN (an SSN for businesses). If they want to modify source for internal use, let them. The examples are not convincing. I don't see that they are particularly vague enough to inspire a change to the GPL. If "MegaSoft" decides to put their modified programs onto PCs and send them out, this is distribution. Simply because a few people don't understand what "distribute" means (taking lessons from Clinton, perhaps) doesn't mean the law or the GPL is vague.
And if you are correct then people can switch to FreeBSD. It's license already fits your ideals -- why should we change the GPL when what you want to change it too already exists.
The choice is there. Personaly I will stick to the GPL.
A revision of the GPL would be a good opportunity to shield open source authors from the increasing threat posed by software patents.
...
On the other hand, look how pissy RMS gets over the patent litigation provisions in the APSL, which Apple's lawyers stand firm on as the minimum that could possibly shield Apple from de facto contempt of court in case litigation ever does arise.
How he thinks that the shareholders/board members of Apple would ever stand for something that left Apple as open to legal attack as the pure GPL would, I dunno
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.
I don't think that multiplying the damages that were originally sought, as a deterrent to litigation, will have the intended effect.
A large corporation could easily risk three times the losses that it may wish to intimidate a smaller entity with.
flossie
Write now. Defend liberty
While many people think that too much time is spent on arguing about licenses, to me the arguing all seems to stem from so many attempts to get around the simple/extra/viral requirement of the GPL by people who don't like the requirement. People who don't like this requirement are constantly slanging the GPL because of it. I do see vociferous defense of the GPL in return, but I don't see GPLers getting bitter about the other opened source licenses. The FSF does have pages up offering critiques of the other licenses, but the critiques are reasonably rational, whereas, the folks criticizing the GPL use pejorative language ("viral", "restricting freedom", etc) rather than just sticking with the simpler and more honest "we don't believe that everyone should have to give up their source". In their defense, I suppose the resentment comes from the huge marketshare that the GPL has acheived.
Slashdotters, do you think that the GPL has been partly responsible for the success of GNU and linux, or the other way round?
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.
He probably believes this, but IIRC, the main reason is that Richard Stallman believes that users of software have a right to the source so they can fix bugs. He got started on the idea out of frustration with buggy laser printer software he was using but couldn't get a copy of. I point it out because I'm intrigued by the idea of the practicality of [purely as an example] commercial software like Microsoft Office being sold for exactly the price and with exactly the terms that it has today, but including the source so you could make modifications yourself (with no right to redistribute). Not likely to happen in the course of events, but it would be cool anyway.
onlinephotolab.com which, if I remember right, uses a hacked version of the gimp for backend processing of images. Last time I checked they weren't distributing their changes, (I haven't checked in a while though). They don't "distribute" the software either, they just let their customers run the software via a web interface. (Is that a distribution?) As I recall one of the major players at this company is also one of the major authors of the Gimp, so you can't really fault the guy too much, he's done more than most people ever did for "the open source movement" whatever that is.
Bang the head that doesn't bang!
where does the GPL talk about that?
whoever receives a copy of a program under GPL is entiteld to receive the source
no more, no less! if you didin't get the binary, you have no right to receive the source either.
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.
released to whom?
those three or four people are the only ones who have any right to get the source, nobody else has
the GPL does not require to release anything anywhere anytime.
there never was a requirement for a public release.
only a requirement to give the source to whomever you give the binary
greetings, eMBee.
--
Gnu is Not Unix / Linux Is Not UniX
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.
Absolutly no doubt at all. (assuming the "close enough" licence really is like the GPL - I haven't read it)
They are not distributing the software, and there is nothing at all in the GPL that say they can't charge for the use of the software, because they aren't redistributing it.
I don't know if this is fair or not - but that's not the point. It is allowed by the GPL.
I personally believe there is room for another, new licence that is designed for online apps like that.
Okay I should say that I had something specific in mind. I was imagining someone writing, say, a 3D polygon transformation library, and then have that used by a games company or something. I think it's fair to say that everyone would agree that CORBA, piping or even shared memory would not be acceptable in this case.
You're right, though; CORBA would get around the problem quite well in many cases.
It's a new paradyne - "Capitalism thru Communism." Or may be "Capitalism thru Equitable Socialism." Strange bedfellows.
lf.o
And I'm not *complaining* about it, just *pointing it out* as a counter-example to the original poster's assertion.
You point out four examples: XFree, Apache, FreeBSD, and Kerberos. Well, three of those actually emphasize my point. XFree's proprietary competition is higher quality and very popular. FreeBSD is a niche product at best -- proprietary competition runs it into the ground. Around slashdot people come under the delusion that free software is a lot more popular than it is. Sun is still #1. And Kerberos! My god, the proprietary versions of that are undoubtedly more popular than the straight BSD code. Why did you even bring that one up??
You're right about the "free beer" being a powerful motivator... but then, the proprietary versions can also be free, if they are included in a product that the user needs anyway.
That wasn't really all that well thought-out was it? It takes a lot less work to understand another person's code than to re-implement it yourself. At least most of the timeAnd of course, the proprietary vendors have the option to do either, whereas free software developers have only the option to re-implement. Even if re-implementation was *usually* easier, free software would still have the disadvantage.
You missed my point entirely. I wasn't talking about a case where a company developed an entire product from scratch, but one in which they built one on currently existing code *written by someone else*. If this original codebase is under the BSD license, the company can build a product on it, sell it for a while, and then contribute back to the original project. I'm not saying this will necessarily happen, just that it can and does. If the original codebase was GPV-licensed there would be little incentive for the company to use it in the first place.
But was the license a disadvantage compared to the GPV? If so, then it most certainly is whether the BSDs are behind Linux.
So you are teaching him what a troll really is? ;)
The problem is those companies that don't want to have to abide to all of the GPL rules will still try to do as much as they possibly can to get the advantages of GPLed software without any of the disadvantages. This isn't a problem for companies trying to exploit GPLed software for their own uses. The problem is that there may be loopholes in the GPL that allow those companies to exploit the GPLed software and not give back to the community.
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.
You are the author of Phorum, are you not!
Either that or you are Wayners who wrote the article.
...Or maybe... It's old man Withers from the Amusement Park!
>And I'd have gotten away with it, too, if it weren't for you meddling kids.
Hey, IANAL, but since the word "distribution" is used in all kinds of proprietary EULAs, how can its meaning possibly be so unclear ? I mean, these companies have lawyers, right ? So I wouldn't expect them to use that word if it isn't clearly defined by the law.
I don't law where to look for that kind of information, but I would expect that word to have been defined a long time ago in this or that lawsuit.
In my opinion, this is a strawman argument. Security (design/implementation/whatever) permitting, users cannot access the guts of a remote web server. It could be apache on linux, it could be IIS on Win2K, it could be Netscape on Solaris. To the average idiot on the web, the server is an abstract, sealed, information providing appliance. The point is that suitably empowered people can access the internals of the remote web server (in the case of open source systems, right down to the code level). In the case of the TiVo, I am sure that there are ways that suitably empowered/educated people can access the low levels of the system.
If TiVo were to release the source code for everything, it would be useless without a way for the interested parties to make changes and then use them even if only on their own systems. Would you hold the TiVo company responsible for providing source, compilers, and object code conduits? I think not.
I think that devices which are not intended to be generically programmable do not fit in to the GPL world.
--
you should read everything on the internet as if it had "but I'm probably talking out of my ass" appended to it.
Define a program that is legally linked to GPL as a program that does not use a publically documented (GPL) API. If the program can "envelope" GPL software in a privitised and parasidic way it does not enjoy being covered by a seprate licence. If it communicates through a publically documented and maintained API then it is fine for it to enjoy whatever licence it chooses. Hopefully if it falls into disrepair or is pulled from public distribution having the API will allow anyone who needs to Repair whatever hole is left by it's absence to plug something else in. It seems pretty simple to use an API (or standard) the way MegaSoft does, as a barrier and legal tool. In this case it is a good idea to do so, perhaps even right in the moral sense. It establishes a clearer definition of what is and is not GPL software. This clause might help make a better fence between Free and unfree software allowing them to work togather. It protects corperations from some of the Viral parts of the GPL and protects the GPL from some of the dumb and paracidic behavior and ideas of corperations (hey, its ground water that doesn't smell bad, I bet we can sell it for $1.50 a bottle to yuppies! I've done research there's nothin to it dude! Can you loan me the money to buy the well from the park service before someone else does?) -note to self, think of good sig...
But like with porn, you'll find a dozen other people with differing intuition who'll disagree with yours. That's precisely the problem with Justice Stewart's formulation of the principle. (You do know whose quote you've paraphrased, right?)
"If one is really a superior person, the fact is likely to leak out without too much assistance" -- John Andrew Holmes
A revision of the GPL would be a good opportunity to shield open source authors from the increasing threat posed by software patents. This should be possible because the same companies that are playing nasty games with software patents also are generally also using GPL software. Why should they enjoy the benefits of the work of open source authors while using software patents to threaten and attack those same authors? They can do this now because the GPL does nothing to stop them, but it could.
IBM does something like this in its open-source license. The IBM Public License is at http://www10.software.ibm.com/developerworks/opens ource/license10.html. Here is a relevant snippet:
Similarly, the GPL could be amended to add something like the following:This is a purely defensive approach, which works for IBM because it is a big company. Open-source authors are not huge companies, which means that it would be a good idea for the language to create a counter-claim in their favor, in addition to protecting them against liability. Defensive language does little to deter intimidation lawsuits, but if the open-source author can also counter-claim for significant damages, then potential plaintiffs will think twice. An example:
It's the same problem I had with Jackson's remedy in the MS litigation, that OEMs who don't want to include a bundled MS app must be refunded the percentage of the fee corresponding to the percentage of operating system's total bytes that the app constitutes. What happens when MS includes a ten-DVD "tutorial" with its distribution, thereby severly diluting the byte-percentage of any of the functional parts of the OS (IE and the rest, not to call them functional ;).
In this case, what if the company increases the total amount of "functionality" that the app performs, diluting the amount that won't perform if the linked-to code isn't present? How can you possibly account for such a scenario in such a definition?
"If one is really a superior person, the fact is likely to leak out without too much assistance" -- John Andrew Holmes
Your argument only goes so far. The reason free software is better than non-free is because it is protected. If freedom is not protected, then anyone can come in and take advantage of your freedom and abuse it. Software needs to be free, like speech, not really because it is better in a sense that the software is inherently better, but because it keeps any central authority from lording power over all the rest of us. The great thing about Linux coming of age for instance, is that suddenly no one is inherently under the tight fist of Microsoft or Apple any more. It's not simply that the software is "better" (in many ways it's not) but that I, as a user, am totally free to use it without any real restrictions.
However, if freedom isn't protected, as is the case with Microsoft's "embrace and extend" policies, then suddenly we are once again under the iron fist of corporations that don't give a crap about the user except to move more product. What you are saying, is that we give up our freedom and go back to complete anarchy. It's akin to stepping back to Adam Smith's Invisible Hand system of economics after the Great Depression. Such complete freedom without protection doesn't work, becuase the overwhelming force will be towards those in power, and they will win if we don't protect our freedom now that we've got it.
"I may not have morals, but I have standards." - Marcin
"I may not have morals, but I have standards."
As is now, the GPL works. Sure we may need to define a few points in the license to keep up, but I believe if your recommendations took effect, you would see companies abandoning it.
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.
This article is ridiculous. Since the GPL is based on copyright, how does the author expect it to be applied to cases such as the proprietary program using a GPL'd database, or a proprietary front end calling a GPL'd program to process data?
Not only would the author's idea of a new GPL have to be based on an entirely different aspect of law than copyright, but should such a new GPL be legally possible, it would only dissuade people from incorporating GPL'd programs, not force them to open up their goodie-bags.
GPL is supposed to be about the benefits of code sharing, and protecting the rights of those who do release their source, not about trying to stake claim to every k3wl program or system like some pack of warez droolers.
All kings is mostly rapscallions. -Mark Twain, The Adventures of Huckleberry Finn
But the linking clause is really hard to figure out. Any code depends on abstractions (e.g., specifed by a header file, admittedly partially), and the code doesn't really care whether the implementation of that abstraction (e.g., a library) is GPLed or not. Actually, the header file might be GPLed, too, but the code doesn't care about that either. foo.h might or might not be GPLed.
And, of course, a script links programs together in a different way.
My view is that the LGPL is a viable way of looking at the software world. The GPL wants to limit usage only by other GPL code, but again code doesn't really care about that. I guess RMS sure cares and that is why not much change can be expected.
Presumably, Tivo uses a LGPLed libc, and their user code links (staticly -- dynamically?) to that. Although the LGPL is a little unclear (at least to me) wrt embedded devices, I think that the intent is to let users update the LGPL'ed library (i.e. libc) independently of the application. Clearly, we can't do that with our Tivo's, for a number of reasons. Doesn't this violate at least the spirit of the LGPL?
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.
There are all sorts of freedom for all sorts of people. Some developers want to be free to include any corporate modification of their code into their version. It seems to me that the GPL tries to balance the freedom of ordinary users, business and free software developers, with a heavy slant to users and developers. With all sorts of possible conflicting "freedoms" to maintain, arguing which license is most free seems rather silly.
Be real. How the heck you can sell software that anybody can copy afterwards ? There is no example proving that a company was able to survive following this model.Perhaps not. But the fact is that GPL software provides a resource for all sorts of businesses whose primary business will not be selling modified versions of the software. How many companies are saving money by using Linux servers or in-house modified versions of GPL software? And in any event, most programmers have jobs working on in-house, unmarketed software anyway; this is the largest part of the software "market". They are getting a lot of free help and IMO companies shouldn't look a gift horse in the mouth.
IMO, the real strength of the GPL is in areas where issues of vendor lock-in and interoperability are so compelling that you are forced to wonder if it's a huge loss for consumers for companies to be selling proprietary versions of that type of product at all. This includes proprietary OSs with hidden API calls and word processors with poorly documented document formats. Core functional software of a computer shall be GPL; or I'll never use it. A library shall be LGPL; or I'll never link to it. And all other software I use of what license please God or its developers.
That's a particularly bad example, because XFree86 is under the BSD license, which has _no_ limitations on restriction of source or binary, aside from including credit.
The big difference with a EULA is that it says "Just because you paid money for this doesn't mean you have the right to use it. You also have to agree to the following terms, which we assert are a binding contract even though the transaction which put this box into your hands was over before you even started to read this document." The GPL says "You don't have to agree to this, but if you don't, then copyright law (not any particular conract) prohibits you from copying it. Use it all you want, but if you want to create a derivative work (which, according to copyright law requires the permision of the copyright holder of the base work) then this document spells out the conditions under which you are allowed to do so."
That's certainly what software companies would like us to believe. My view is that it (used to be) just like buying a book: buying a copy of a book doesn't give you the right to publish it, any more than buying a copy of Photoshop gives you the right to publish it. What you do get, though, is the right to use it for its intended purpose. In the case of the book, to read it. In the case of Photoshop, to run it.
It gets hairy because you have to copy software (to hard drive and/or memory) to run it. So, the software companies decided to try to change things around so that instead of buying a copy of Photoshop, you are buying a "license to use Photoshop." Never mind that you still buy a copy of Cryptonomicon, not a "license to read" Cryptonomicon. Then, after people get used to these little pieces of paper stuck into the software box pretending to be binding contracts, you just pay off some policymakers, and *poof*, they suddenly ARE binding contracts.
In the case of books, there was a court case involving a publisher which printed a clause on the book jacket attempting to place a price floor on sales of used copies of the book. It was ruled unenforceable.
Maybe you'd be stupid enough to pay for it, I certainly wouldn't.
I don't understand why this fantasy keeps coming up in defense of the GPV. If MS was stupid enough to give up their enormous investment in the development and marketing of Windows NT in favor of linux, the GPV would provide no protection whatsover. All they would have to do is provide Office or completely functional Windows File/Print services or whatever, licensed only for use with Microsoft Linux, which is available free under the current licensing. None of their additions would necessarily fall under the GPV, but the availability of popular MS software would do a lot to divert interest away from the non-MS Linuxes.
I think you are missing that there is a difference between distributed Open Source projects and Free Software. There is nothing in GPL about contributing changes back to the community. The reasons for contributing back are for status, and to prevent forking, not to comply with the license.
GPL isn't there to make things better for developers. It exists to protect users, so that they don't ever get stuck with a binary that they have no means of maintaining. In that respect, GPL is excellent and most certainly does not need to be scrapped. Maybe it just needs a few patches, that's all.
I think the Tivo may violate the spirit of GPL if not the letter. Is a Tivo user able to modify or update the GPLed parts of the Tivo? If not, then I'm not sure if it can truly be said that the source is "available." OTOH, if it is possible for a user to do that, then there's no problem.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Now combine that with the (true) observation that others have already made here: that the distribution requirement of the GPL is not, and has never been, about distribution to the "public". It is merely, and simply, that if you distribute a copy to some (specific) individual, that you must also provide source to that someone. Not other folks, just that person. (Practically speaking, this does tend to end up as anon ftp to the world, but that is not there in the GPL.)
There, I solved your problems.
The company that want to charge for a xhosted session of moddied emacs? It's not a distribution. End of story.
The company that want to rent you a copy of moddied emacs? It is a distribution, so they have to provide source.
Note the important difference here: it is not in the functionality that is provided; that is the same. It is in who owns the place where the software runs. Why should ownership of physical things make a difference? Well, give me all your salary for this year if you think it does not. :)
Given that courts are likely to come to an understanding of "distribution" like mine above, in order to change it you would have to change the GPL, which (a) only the FSF can do, and (b) would risk forking GPLed code. I don't think the "problem" is that big.
...saying the APSL has a "disrespect for privacy"?
Will I retire or break 10K?
The point is that development still goes on.
Who cares whether everybody uses it? Enough people obviously use it, and respect free software principles, to keep developing it.
Sounds good, but something's missing: what about kernel modules or Linux-specific code?
--
Error: password can't contain reverse spelling of ancient Chinese emperor
If a corporation releases a binary to 1 person outside the corporation, they must include the source with it.
However, Linux has lots of other disadvantages unrelated to its license, for instance that it's only existed for a decade, whereas *BSD has existed for three (also, it had/has some design flaws that have slowed/do slow development).
But this is not relevant to the original topic -- BSD licensed programs competing against commercial outfits -- which is why I didn't mention it.
The general proposition on which Wayner's comments rest is that there is ambiguity concerning the meaning of "distribution" under the GPL. The first thing to be said is that the GPL is a copyright license, and when it refers to distribution it is using a term of art. "Distribution" under the GPL is distribution as copyright law understands it. Many people use the GPL to distribute software in many different places, but in what follows, for the sake of simplicity, I'm going to assume that the program being distributed is a copyrighted work of the Free Software Foundation, such as emacs or gcc. I'm also going to assume that the applicable copyright law is US copyright law. What I'm going to say is more general, but this will do for illustration.
To begin with, some of the problems Wayner associates with ambiguity about distribution are not about distribution at all. These problem are about whether code is part of a single GPL'd work when it is meant to communicate with, or operate in sequence or in parallel with, GPL'd code.
These questions are not being raised for the first time, and the Foundation has a single consistent position. Code which is statically or dynamically linked to GPL'd code constitutes a single derivative work of the GPL'd code, and must be distributed under the terms of the GPL. Code that is not linked to GPL'd code, but is distributed as part of a "mere aggregation" of works is not subject to the GPL, as section 2 makes clear. So when Wayner says that
he is describing an aggregation of works. If one or more of them are GPL'd, they must be redistributed in keeping with the GPL. Other works that are part of the same aggregation are not covered. The same is true with respect to processes running simultaneously, whether on a single multiprocessor cluster or in multiple machines communicating across a network. In order for code to be covered by the GPL it must be part of a work derived from GPL'd code. If it is aggregated with GPL'd code, or communicates across defined interfaces with GPL'd code, it is not part of the same work.Wayner presents a lengthy example concerning a weather database the purport of which isn't clear to me. The point seems to be that data produced by a GPL'd program might also be employed, through ordinary open network protocols, by non-GPL'd code. This situation also presents no ambiguity under the GPL. The GPL, again, is a copyright license, and it ony applies to copyrightable works which authors or assignees chose to license under its terms. Data compilations are not in general copyrighted works, and data produced as a result of the execution of GPL'd code is not in general subject to or controlled by the license on the code that produces it. There is nothing to prevent someone from writing and distributing non-GPL'd code that makes use of data produced, whether in real time or in stored form, by GPL'd programs. And there is nothing that prevents people from passing data between GPL'd programs and non-GPL'd programs, or from selling combinations of programs or services that mix GPL'd and non-GPL'd code.
Some of the questions Wayner raises are, however, about distribution. They are not more difficult than the non-distribution questions, but the legal background should again be slightly clarified.
Emacs, for example, is a copyrighted program, and unless you have a license from the FSF to engage in "distribution" of emacs, you can't do it at all. Under 17 U.S.C sect. 1001, the definitional provision of US copyright law,
So that's it. Anything that constitutes selling, leasing, or assigning a program within the United States or for ultimate sale, lease or assignment to an end user in the United States is distribution. As you would expect, there are loads of cases explaining what that implies in particular factual settings, and as you would also expect, those cases by and large take an expansive view of the copyright owner's right to control distribution, so doubt is resolved in favor of inclusion.Against that background, let me take up the specific questions Mr Wayner raised.
Not quite. MegaSoft is not yet distributing its modified emacs to consumers. Its internal modifications are covered by the GPL, however, because it is copying as well as modifying the software, activities which are only permitted if you have a license, and the terms of the license specify what MegaSoft must do. If it keeps these modified copies on its own computers, it has no further responsibilities under its license. If it allows employees to remove the copies to their own computers, it is then engaged in distribution, and it must provide source and allow those employees to redistribute the modified software under the terms of the GPL.
The same principles explain the situation regarding acquisitions and divisions of the MegaSoft Corporation, as well as the question supposedly presented by the free software assets of the company in the event of insolvency or sale. All the code is covered by the GPL from the moment of its copying, modification, or distribution, and any distribution must occur under the GPL's terms.
Wayner also asks about the embedding situation, presenting the example of Tivo. Tivo distributes a quasi-embedded system in which a free software kernel is used to execute unfree software. This is an aggregation of components, and Tivo is responsible under the GPL for the compliant distribution of the free software components of that aggregation. It is not responsible for releasing any of its own code under the GPL. The test is not whether the user can "pry" them apart in the particular circumstances of an embedded system.
These situations present no problem. Under the statute, leasing a work is distribution, and such technical arrangements are plainly covered by the GPL. Anyone offering execution access to GPL'd code, or code based on GPL'd code, must do so in a compliant fashion, wherever the leased copy is delivered or executed. Maybe we can clear up this confusion most easily if we step away from software for a moment. Let's use a copyrighted movie instead. From the point of view of what constitutes "distribution," is there a difference between broadcasting a pay-per-view movie over a cable system, so customers only get to watch the movie, or selling them the movie on videocasette? No. Both are distributions, and in both cases the entity making the distribution must have a license and comply with its terms.The most important thing to note about all these situations is that the "loopholes" Wayner is wondering about don't have anything to do with the drafting of the GPL itself. The GPL simply uses the concept of distribution defined in the general copyright statute. If there is a "loophole" it is a matter of general copyright law and the GPL is neither more nor less affected than any other copyright license. Wayner has kind things to say about Richard Stallman's drafting, and as the lawyer who has assisted the FSF for a decade in the use and enforcement of the GPL, I entirely agree with him about the document's elegance and utility. But he gives the GPL too much credit and assigns it too much blame when he supposes that the questions he is asking are questions about the GPL and not about copyright law in general. Fortunately for copyright law, it is not quite as fragile a system (in this respect) as Wayner seems to think.
I also feel I ought to comment, on FSF's behalf, on a statement made in the course of the discussion by Matthew Smith:
This proposition is not correct. The person who holds the copyright on a program can choose to license it under the GPL if she wants, but when she does so she can also license it, simultaneously or sequentially, on non-GPL terms. If she later wants, as Mr Smith suggests, to enhance it further as a non-GPL product, nothing whatever prevents her from doing so. She owns the copyright and is not somehow bound by the terms on which she licenses to others. The version released under the GPL is still free, of course, and can be modified and redistributed by anyone else. Those people, who do not own the copyright, cannot make their modifications proprietary. But that's because they have to obey the terms of the license that allows them to modify and redistribute in the first place.I don't happen to agree with the way Mr Smith threw the word "communism" around. As I have mentioned in an essay on these subjects that a few people may have read, called Anarchism Triumphant: Free Software and the Death of Copyright , I think there are closer political analogues to what's going on here. But in any event it should be clear that people who choose to employ the GPL are not having their farms, their computers, or their programs forcibly collectivized.
/* Prof. Eben Moglen, Columbia Law School, FSF General Counsel */
MyComputer.com's Boardserver uses the Phorum discussion software (which technically isn't the GPL, but close enough). Now MyComputer.com charges for the software in a round-abouts way (pay us and we'll take off the banner ads). They have not released the source to this nor have they contributed back to the development of Phorum. Now the question I have is what they are doing legal or not? BTW I'm anonymous for a reason, If you can't figure out why then don't bother responding. :)
1) If you don't modify the source code, then obviously you don't have anything you need to distribute. If, for example, you use the Linux kernel intact (i.e. the kernel would still run just happily without your code), then nothing needs to be distributed.
.class files out of a GPL program, link them with my proprietary code (but neither recompile nor modify the GPL code!) and keep my code proprietary? My suggestion: avoid the gray areas. If you're not sure, and don't want to abide by the GPL, don't use GPL'd code in questionable ways.
2) So long as the source code is publically available and under the GPL, the deal is satisified. Take an old P-90 box with a few hundred meg of HD space, throw Linux and an anonymous FTP server up, put code on server, forget to publish the fact that the software exists. Nothing in the license requires a Freshmeat announcement, or postings to the correct newsgroups or maillists (although this is encouraged!).
3) I thought the GPL explicitly dealt with content editing. You can edit proprietary documents with Emacs, compile proprietary code with gcc, and store proprietary information in MySQL. Just like you can write public domain documents in Word, compile GPL code with Visual C++, and store public information in Oracle.
4) There are gray areas still- just not the ones you list. Consider a GPL'd Java program- can I take pre-compiled
5) There is a lot of concern, and rightfully so, over this legal challenge. But a license which isn't defended is tantamount to no license whatsoever.
6) Do you think your average contract lawyer can write good code? Then why do you think that _you_ can write a contract that will hold up in a court of law if you're not a contract lawyer? The one huge advantage the BSD license has over the GPL license IMHO is that it has already stood up to the worst a large corporation (AT&T) could do. But of even greater concern to me than the future of the GPL is the horde of programmer-licenses that have shown up. How many of them have even been run past a contract lawyer, let alone a court of law? How many of them are just the pseudo-legalesse of a programmer way out of his depth and not knowing it?
The more dangerous legal challenge to open source may not be to the GPL, but to all of the programmer-licenses out there. But what of Apache or Perl? Perl's "pick your license" stunt makes it (mind you, IANAL) seem more vulnerable- at best, any action which is legal under either license is legal (i.e. the set of restricted behaviors is the intersection of the sets of restricted behaviours of the two licenses).
Workers already have to observe the rules of the workplace regarding dress, attendance, behavior, confidentiality and so on. Why worry about their freedoms regarding free software, given that they don't have a whole bunch of other more fundamental freedoms? Moreover, the workers have *chosen* to trade their freedoms for money,
and they can also choose to get them back by quitting.
Thus I think that we should not worry whether internal distribution within a corporation counts as distribution for the purposes of interpreting the GPL.
It is only the corporation that suffers if they don't provide their workers with all the materials they need in order to be fully effective! What does it matter to the worker that he or she doesn't have the source code to some proprietary enhancement his or her company made to some free software? Having access to the code would not mean that the worker could give that code to outsiders; it would only mean that the worker could perhaps do his or her job more effectively, in order to make more money for the corporation and make it more competitive. So if the powers that be do not see that, screw them!
I'm not terribly convinced that these examples are as vague as he is trying to suggest. It is possible, as people have suggested, for people to rewrite entire programs, and thus avoid GPL protection - surely what this shows is that all the matters for something to be a single program is the basic codebase - i.e. if a program shares any executable code with the GPL originator, it is GPLed - therefore other programs, regardless of how they interact, are not...
Your argument that it would be impractical to make money off a proprietary version of free software may work for end products, but most definitely not for libraries. The restrictions in the GPL make it extremely attractive for use with libraries if you're concerned about someone using your code in a proprietary product without giving you money.
"The limit is wherever copyright law puts the limit. If the proprietary weather application is not, under copyright law, considered a derivative work, then the GPL can't touch it.
Remember, GPL's only power comes from copyright."
At least one of the points brought up in the article could be solved within the GPL, even though copyright law would not consider it a derivative work: Tivo. If the GPL stated that when the covered product is distributed for a fee as part of a larger aggregation, all other works within that aggregation must also be licensed under the GPL (IANAL, so this would probably have to be worded better). Of course, this would also force every GNU/Linux distribution to consist of only GPLed products. Whether this would be a Good Thing is left as an excercise to the reader.
ok then your [sic] infringing on my copyright! Could you as [sic] me next time before STEALING my comments for your own?
"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."
Not without permission. This is illegal under the Computer Software Rental Amendments Act of 1990:
(b)(1)(A) Notwithstanding the provisions of subsection (a), unless authorized by the owners of copyright in the sound recording or the owner of copyright in a computer program (including any tape, disk, or other medium embodying such program), and in the case of a sound recording in the musical works embodied therein, neither the owner of a particular phonorecord nor any person in possession of a particular copy of a computer program (including any tape, disk, or other medium embodying such program), may, for the purposes of direct or indirect commercial advantage, dispose of, or authorize the disposal of, the possession of that phonorecord or computer program (including any tape, disk, or other medium embodying such program) by rental, lease, or lending.
ok then your [sic] infringing on my copyright! Could you as [sic] me next time before STEALING my comments for your own?
It's not based on the derivative work clause, but it's still copyright. What is at issue is the right to copy GPL'd programs onto the Tivo and then distribute them. GPL currently draws *all* of its power from copyright.
So yeah, the entire point is that the XFree team's work has been used in proprietary products, which are considered by most to be higher quality.
This is really the story of unix. The free BSDs are certainly quality OS, but they're not serious contenders against proprietary unices on the market that unix was meant for (servers). (Of course, they may frequently prove sufficient -- often the OS doesn't really matter. When it does, *BSD is rarely the better choice). If they ever became serious server contendors, I wouldn't be surprised to see their work ripped off by the commercial unices. Likewise, if unix ever became viable on the desktop, I wouldn't be surprised if some commercial company took FreeBSD and removed the source, made a few modifications, and slapped a "value added" sticker on the box.
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".
You've got a good idea here, but haven't expressed it very well. Indeed it is a myth that GPL will protect developers from being exploited. The reason it is a myth is because taking source and making it proprietary is only one of many ways to exploit somebody.
Just look at all the GPL'd software that is used to run corporate servers.
In economic terms, the BSD team helping Apple write an OS (by maintaining the BSD kernel) is no different than Linux hackers helping ISPs run web servers (by maintaining the Linux kernel).
The real difference here is that Linux hackers are helping all corporations except those who sell proprietary software.
Now, their reasoning for this is centered around the idea that proprietary software is evil. If they want to say that, fine, but don't go telling us that writing under the GPL will prevent us from being exploited. It simply isn't true.
#VRML V2.0 utf8
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
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.
...and add a line requiring that everybody who modifies the source must send them a copy on physical media. Preferably, for each user the modified version is distributed to.
This way, they could build their houses using archive cassettes as bricks, and shingle them with CD-Rs (how will they connect them? simple, the typical hacker easily spills enough sugary caffeinated drinks every year to stick his house together, they'd just have to be more careful about where they spill).
Don't you think the least these great altruists deserve? When somebody selflessly gives a gift to humanity, it only makes sense that everybody who benefits from their gift be legally obligated to give something back. Then they are free to be selfless and giving, without worrying about all the freeloaders who might be profiting from their altruistic, selfless gifts, created without any thought of reward.
This is another example of the simplistic and fallacious thinking of the GPV apologist. A more likely scenario one in which, of features z,q,r,s,t,u and v, only q and t are truly worthwhile. While XF is implementing these, they are also implementing a,b,c. It may be that the authors of XP really want b, so they have to integrate it. As the two codebases become more divergent it becomes increasingly more difficult for XP to maintain their separate enhancements. The cost of this maintenance may actually cause XP to contribute back to XF (this has been known to happen in the real world).
Of course, hypothetically, it could be that XF is incapable of anything more than copying XP's enhancements (as is the case with much GPV'd software, which tends to stagnate when there's nothing left to copy), in which case they deserve to lose and might as well pack it in.
Question: if XFree have such a problem with their license, why do they prefer it to the extent of refusing to allow any GPV'd code into their distribution? And why do the free BSDs only grudgingly allow GPV'd code into their systems, and almost always only when there is no free alternative? And why aren't the BSDs far behind Linux in most respects, instead of a little bit ahead in many and far ahead in some?
I disagree. The real purpose of the GPV is to allow the original contributor to eternally profit, albeit in a warm and fuzzy nonmonetary sense, from the creativity and resourcefulness of others. This is the real reason companies don't contribute to GPV'd software unless first bludgeoned by RMS, Bruce Perens and their teeming minions; there's proportionately very little in it for them, a good idea often being worth more than an initial codebase. That good idea may only be salable for a year or two, but the company's inability to build it on GPV'd software renders "contributing back to the community" at a later date a moot point.
I think you've got a strange idea of what "exploitation" is. What is given away cannot be stolen.
I think that the BSD and Linux kernel developers, and the members other Free software projects would characterize that "exploitation" as "use." All sofware was written to be used by the people who have it. The GPL doesn't dictate how you use code it licenses. It does tell you what you have to do to be permitted to distribute the code, or code based on it. This is something that you cannot do at all with most software.
What developers are saying, in a sense, when they release their code under the GPL, is "This software is the best damned thing out there, or at least, we think it has the potential to be the best (at whatever). Please use it. Please read the source, and make changes to it. Use whatever changes you make. But we made it, so if you want to distrubute your changed version, you must follow our terms, which are stated in the GPL."
So, corperate use of Open Source software is no "exploitation." It is a use of the software, probably as the it's author desired (though not always). The author's decision to use the GPL to distribute his code gave his permission to use it. Apple using BSD or an ISP using Linux and Apache, all are perfectly valid uses.
None of this addresses the issues of what the GPL should protect, rather than what it currently does. I think that future versions of the GPL should address issues surrounding networked use of software, and if such uses should cound as "distribution." I think they should err on the side of requiring source to be release more often, rather than less often. Bad source doesn't hurt anyone, but binaries without source could do just about anything (literally). I think source should be made available inside corperations when they use versions of GPL'd code (though employees might be prevented from distributing that source outside the company). I also think that some types of networked software should be considered distributed when they are used.
Anyway, I'm sure the GPL will gradually evolve as views on Free Software change. I hope it will always remain true to it's underlying philosophies.
Steve
However, it seems that it is not clear that operating a web page with software is considered a distribution under the GPL. I think this is essential if the GPL is to have any meaning whatsoever for web applications. As an example, consider the case of MySQL. Their old "free for non-commercial use" allowed corporations to run a MySQL database behind a webserver for free, because that was considered "internal" use, and not a redistribution. Although that allowed MySQL to get a significant market share among, say, mod_php users, it probably meant a lot of lost revenue for their parent company.
Now, since their parent company didn't really care (AFAIK) about this lost revenue, it was no big deal, but for a small company like mine, this could be utterly disastrous. OTOH, we have a pretty substantial HR application that I think the OSS community could really benefit from. Maybe it could be integrated into a scheme like the GNU Enterprise suite.
But first, we have to be sure the GPL will protect us from being blatantly ripped off. Any suggestions? Should we just take our chances with the GPL? Does it cover this case? Is there another license that addresses this concern?
Can your IM do this?
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.
Come ON, slashdot! You can do better then this fuzzy thinking and, well, stupidity.
./ has to have fresh content on a regular basis, but why not just links to something uninteresting so I can shrug and say "slow news day, eh..." to myself, instead of a frightfull article like this...
I've encountered people in my workplace who have claimed the GPL and it's adherents are socialist, and I have vehemently disagreed, arguing that it is a legally codified "public grounds" that provides an excellent (upgradable, debug-able) grounds to build software upon/with... and you are only giving people like that amunition with this silliness. The GPL is beutifull in providing the freedom for software to be used by all.
If anyone were to attempt enforce the type of contamination you are talking about, no one would use it any GPL'd software in the real world.
I mean, I know
---
the pen is mightier then the sword. the sword is mightier then the court. the court is mightier then the pen.
"After, aren't we saying that open-source is superior as an economic model?"
;) It seems to me they are both flip sides of the same coin...because Open Source is economically feasible it allows us to make Good Free Software.
No. Perhaps open-source advocates are. But open-source != free software. Stallman's position is that free software is better morally and ethically, not economically. In fact free software may very well be worse economically, but like other things like foreign aid, and social welfare, it is the Right Thing to do. However, coincidentally, free software under the moniker "open source" has actually turned out to support a decent economic model. This is what open source activists trumpet. However, to free software, this is a secondary and beneficial side-effect, not the main reason. The point is that Free Software is Good. Not that Open Source can make us Rich and Famous.
In any case, I don't know if I'm really in either camp. I'm just an observer
It's 10 PM. Do you know if you're un-American?
My question is one that seems a possible conclusion at the end of this article, but one that is neither explored nor is fully stated. Does a "license to use" software that is otherwise still "owned" by the licensee constitute a "distribution"? This would seem to be
the most relevant and dangerous question in regards to the GPL, as most software now claims not to be "given" or "sold" but mearly "licensed".
If I license (loan, rent, whatever) you software, as a corporation, which is technically a legal "individual", have I actually "distributed" software to you? Since UCITA seems to enforce and further legalize this notion, I have to wonder if this does directly allow one to bypass the protections of the GPL in a way that could be exploited for mass market software sales.
You state problems that are all theoretical and have yet to be a source of conflict in the community and then recommend slowing the distribution of the source. Let's not get the cart in front of the horse. I say that given a reasonable understanding of software engineering and it's design principals/practices a court could "draw the line" in a manner that's reasonable to all parties in a conflict. I would agree that there is no shortage of thought experiment examples that one could imagine, but they are just that, imagined.
You're trying to solve a problem that you've failed to properly define.
___
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 will discourage people from writing software for the Linux platform. Virtually all programs contain some system-level function calls, and some of them are Linux specific. No company can remain in business if they are forced to give the source code of their primary product away for free; none of the companies selling Linux distributions are even remotely profitable, even though they do sell media and service.
This clause, alone, will discourage people from supporting the Linux platform. Let's say a company wants to release one of its own products under the GPL and sign the copyright over to the FSF. If they have other software that interoperates in any way with the portion they want to open source, they cannot sell it, and must OS those code-bases as well!
The GPL should allow a company the flexibility of developing proprietary software that interoperates with free software. Otherwise the GNU/Linux platform will stop receiving the corporate support that it has in recent months.
ByteMyCode.com: A Web 2.0 code sharing community.
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.
I don't know how to do define linking, but I know it when I see it. :)
--
Sometimes it's best to just let stupid people be stupid.
The real problem, though, is client/server based programs ... , I can take a GPL X11 program, say Emacs
First of all, I'm not sure if running Emacs over X11 is really a 'client/server' relationship -- X is client/server, but Emacs is oblivious to what display it's running on.
So, this doesn't seem to be too much of a problem. The licence file is clearly called COPYING, and not RUNNING. (And don't give me any nonsense about "RUNNING = COPYING into RAM", because if that's the intent the GPL is essentially a big lie.)
So the database example is a more appropriate confusion -- Can my proprietary VisualBasic front end talk (via ODBC) to the GPL MySQL DBMS? Is RPC OK? What about a simpler protocol like SOAP which is similar to text I/O?
It gets more confusing when you throw additional layers like CORBA in -- What if you had a GPL program which talked to a proprietary CORBA ORB which then talked to a GPL ORB (maybe on the same machine) which then talked to a proprietary back-end. Let's throw Java in there - did it come with your OS, or did you download it? Are you legal? (Better call a lawyer, who will probably tell you to play it safe and don't do that.)
Since KDE and Gnome are implementing COM-like in-process component support, there's going to be some interesting flamewars ahead. Is it "linking" (not exactly)? Is it a seperate "program" (no fork - not exactly either)?
The fallback answer seems to be "original intent" -- Are you using technology just to try to get around the GPL? I'm just not sure if that angle will hold up in court,
I'm not an expert in any of the legal stuff, so maybe I'm off-base. Just trying to point out that we live in an increasing interconnected world, and the software technology to go along with it. Meanwhile we have a licence designed in the old mini-computing days, and seems to have many of the assumptions of those days to go along with it.
When I hear the word 'innovation', I reach for my pistol.
It's the same problem I had with Jackson's remedy in the MS litigation, that OEMs who don't want to include a bundled MS app must be refunded the percentage of the fee corresponding to the percentage of operating system's total bytes that the app constitutes. What happens when MS includes a ten-DVD "tutorial" with its distribution, thereby severly diluting the byte-percentage of any of the functional parts of the OS (IE and the rest, not to call them functional ;).
If Microsoft did this, couldn't OEMs just opt out of including this "tutorial", and thereby get a refund of almost the entire price of the operating system, effectively getting a serious discount?
Maybe I'm missing something, but it seems that such a scenario wouldn't be in Microsoft's best interests.
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.
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.
Your suggestions are very interesting and timely, given the current environment. This "90% of its functions" will be difficult to define in a transparent manner, however. What constitutes a function? Do trivial functions count? If we act on simply "number of features that are disabled if we unlink," then I think we are missing the point--one could in principle just code up a bunch of meaningless buttons on a hidden panel in a front end to circumvent the license. What you may want is to define something along the lines of "core functionality" and determine whether maintaining such functionality requires the GPL-licenced linking--of course then we are left with more terms to define.
Good luck fleshing out your straw man.
IANAL but here are some previous thoughts of mine on the GPL.
One of the things that software blurs is the distinction between software distribution and a public performance. Indeed in today's world an increasingly common use of GPLed software is public performance. (Think of slash!)
Unfortunately the GPL nowhere explicitly tackles the issues of public performance. From my reading, term 0 explicitly disclaims any relevance to public performance. Others may disagree. But I think that with the direction that this industry is heading it would be extremely useful to have a version 3 produced that explicitly addressed the question of public performance.
Cheers,
Ben
PS I would also like to see section 3 of the GPL replace "operating system" with the more general "basic operating environment". Why? Well can you GPL a Java applet? Look at the definition of "source code for a work". The standard Java libraries are often not part of the OS. But they are probably distributed with your JVM, and it makes no sense to make you worry about it!
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
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).