The library can't be linked with proprietary components. That's the first problem. The distribution of the.o files, and the library itself, didn't come with the requisite written notice about the source being available. So, yes, if they put the notice there, they'd be legal, but since they distribute the object. via FTP, they'd probably have to distribute the source that way too.
What if I want to make some money from my free software? I should be able to sell a commercial license to that person who makes a proprietary web-based front-end for my software.
Rest assured that RMS isn't going to make hasty changes to the GPL without public debate.
I agree with you that deciding where to draw the line is very important, and not terribly easy to do. For example, I don't want to have an FTP client considered derivative of the FTP server. But if somebody builds a GUI shell around my "engine", I am convinced that such a thing is derivative.
I'm concerned that GPL restrictions on derived works haven't kept up with software technology. The most pernicious example is CORBA, which lets us create derived works from components that aren't in the same address space at all, yet work seamlessly as if they were. I'd rather not see my GPL work end up in somebody's proprietary program, simply because it's been server-ized to avoid my license restrictions.
A more common problem is dynamic libraries that are distributed separately from the executable. You say that a court would hold those to be devices explicitly used to circumvent the license restrictions, but that's rather chancy, and no substitute for explicit language regarding what is, and what isn't, considered a derived work in the GPL. You seem to be hoping that copyright law will take care of that definition for you, but that doesn't seem to be happening.
There's also the problem of Application Service Providers, who make a work available for people to use without distributing it, and thus would be under no obligation to make the source code of their modifications available. Do I have to see my GPL work abused that way as well?
It seems there's a lot of new technology that the GPL isn't keeping up with. Can't we have some changes to address these things?
The fact that your graduate students could not find that problem unfortunately doesn't say much for them as Unix/Linux security auditors. That system() sticks out like a sore thumb, and execve() would as well. Checking for ways in which a setuid-root program executes another program is a very obvious thing to do.
I'd like to point out a few problems with your comment.
The Gauntlet firewall published by Trusted Information Systems was not an Open Source program. It's what we call "disclosed source-code", and that's very important because that difference means that nobody had much reason to read it or work on it. The software license didn't provide them any incentive to do so - you would have only been fixing bugs in a program that somebody else has an exclusive right to sell. Who wants to be the unpaid employee of another company? With real Open Source, you have the same right to sell the program as anyone else, or to distribute it for free, for that matter, and thus you aren't some company's unpaid dupe. For an explanation of what Open Source is, see The Open Source Definition .
At the time of the Morris Internet worm, the BSD software distribution of which Sendmail is a part was under a restrictive license and required an expensive ATT Unix license before you could get the system. This is also not what we today know as Open Source. Besides, you are writing about the epochal Internet virus, and few people even considered Internet security before that event.
Yes, all compilers have a bootstrap problem. One can avoid it by compiling the compiler with another compiler, once in a while, and then compiling the result with itself. This method can also be used to detect the Trojan: compare the generated executable with one that doesn't have another compiler in its heritage - if there's a significant difference, look for a Trojan there.
Most users do not compile their own applications, but they get them from a trusted source who has compiled them and cryptographicaly signed them. You might not be aware that in all Linux distributions of any import, the packager does compile all programs. If there is a trojan slipped in, you can trace it to the person who compiled the program and bring charges if necessary.
And what good would it do anyone to grep through source code for strcpy()? We've already done that ourselves, and have fixed obvious problems.
Sure, it's no guarantee, but it's much better than the alternative, which lets Microsoft embed snide comments (if they really aren't trap-doors, embedding a trap-door would be as easy) in their software and have them undiscovered for years.
The BSD license and public-domain are legal declarations that say "do just about anything you want with this software, including change its license to anything you want.". Some people don't understand that, but that's what they say.
If you want it to stay free for everyone, your best choice seems to be LGPL. It's the only license that sufficiently protects its own freeness.
You're making a very selective reading. The form of use you postulate is actually derivation, and thus you have to heed the language regarding derivation.
If you really made a BSD-license library that actually did the work and distributed it freely, you could get away with the postulated scenario.
However, if it happened that your library was a mere stand-in, something so insufficient that the GPL version would always be used by your customers, or if its license terms or distribution were such that you could not reasonably assume that the user would make use of your library, it would be easily demonstrable that your library is simply a device for circumventing the license.
Also, shipping a library with a product that makes use of it does not satisfy the definition of mere aggregation. Aggregation applies to unconnected products.
I am not responsible for the GPL text and have suggested several improvements to RMS, to no avail so far. If it gets bad enough I will write my own license, but I don't want to add to license proliferation unnecessarily.
Stallman and I have discussed this. Currently, the GPL doesn't handle CORBA very well at all, and I would like him to deal with the problem. Whether or not you could prove that an application is derivative would depend on the application.
I don't think this is a valid argument. If what you are saying were true then people couldn't create GPled apps that link against proprietary libraries (eg GPLed apps on windows)
With all due respect, had you read the GPL you would have seen that it explicitly makes an exception for standard facilities distirbuted with the compiler and operating system. I wish people would at least refer to the darned thing while arguing.
You argument also has an implicit assumption that executable form of the application is GPLed, and I don't believe the text of the GPL supports that. (That's another argument entirely though).
Yes, the executable is under the GPL license. That's really fundamental - there would otherwise be no compulsion do distribute source. If it's not GPL-ed, it's All Rights Reserved, so this would gain you nothing.
I am afraid I can't, at present, grant that you are competent to discuss the GPL at all. Please read up and try again.
No court has ruled on IPC vs. dynamic linking vs. static linking. I personally would like to see the GPL tightened up regarding dynamic linking and IPC. But this is complicated to do fairly, and should not be done in haste.
MIT-license works and public-domain works can be linked to GPL libraries. The key is whether or not they impose license restrictions not present in the GPL.
Did you see that Ogg Vorbis compression scheme (search Slashdot). It avoids the patent, is said to perform as well as MP3, and can be improved beyond that.
Yeah. This is not an answer that you arrive at democraticaly, at least the way democracy works around here. Some of the folks here don't know a license from a sandwich. Fortunately, you can get some idea which is which from their comments.
I think one could prove in court that this was a dodge aimed at circumventing the license terms and nothing else.
And regardless of the legal realities, it's a sleazy thing to do. You do want to be able to sleep well at night, don't you?
Isn't it funny that although libreadline is far from rocket science, it's been a stumbling block for a number of programs? Nobody's bothered to write a competent replacement, can that be right? And they call us whiners instead of coders?
Gee. Please be sure you have a clue before wielding the stick. His comment was germane - the questioner seemed to me to be confused regarding the need for the LGPL simply because something is a library.
I think you're going about this the wrong way. Instead of considering what you might be able to get away with in a court of law, please consider what the wishes of the other copyright holder are and what you can thus do ethically with his code. I would hazard a guess that he would not like what you are doing with his code in your proprietary program regardless of how you are linking or server-izing his code. Think of how you would feel if he played fast and loose with your program.
Why not contact the authors and negociate for a commercial license to their code? If that doesn't work, please consider their wishes and either GPL, LGPL, or MIT-license the whole thing, or write their property out of your program.
If the copyright holder intended his work to be used in a non-GPL work, library or not, he would have applied the LGPL to it. He didn't. Thus, you are free to library-ize the work and leave it under the GPL, and put your GPL program on top of it. Producers of proprietary software should negotiate a commercial license or request that the copyright holder LGPL his work.
Let's not forget that commercial licenses are an option. The fact that the GPL is on something doesn't prevent you from negociating for one.
The LGPL does have its uses, despite RMS' deprecation of it.
Sure it does! We use it for most of the libraries on Linux, for gosh sake! It's because we explicitly want people to be able to create proprietary applications on their Linux systems.
Was anybody arguing with that?
To me, that's what free software should be about, a way to facilitate the free sharing and communal improvement of your code, not forcing others to do the same if they don't want to.
Well, consider that there is another sort of forcing. I don't want someone to force me to participate in their proprietary product, with no compensation on my part. But that's what happens when somebody else includes my code. So I use the GPL to protect from that. If they want my code in a proprietary product, they can pay me for a commercial license. Thus, the GPL actually promotes payment for use of my code in this case! Nasty, pro-commercial GPL!:-) . Now, with most librarary work I do, I've waived that protection and used the LGPL so that producers of proprietary stuff will be able to use my code. It's a choice that I make as copyright holder every time I write something.
I'm afraid you're incorrect. Dynamic link executables contain pieces of the library and headers that they are linked against. In addition, instead of distirbuting the pieces together, you are distributing a program that contains instructions to the user's computer that cause it to put the pieces together as if you had distributed them together. This would probably be viewed by a court as a device with the express purpose of circumventing a license restriction, and thus would be considered equivalent to static linking.
The issue of API copyright is entirely separate from the copyright of the library. You could have two interchangable libraries with the same APIs, and using one could be infringement while the other would not, depending on the library licenses.
Also, the GPL claims no rights to anybody else's code. It simply disallows use of GPL code with programs under most software licenses. If you don't like the GPL, you simply should refrain form using GPL components in your programs.
I don't think his point 1 is incorrect. The LGPL is an option for libraries, or really for any code. It's not necessarily the best choice for a library or anything else. Sometimes you want to apply the GPL to a library, sometimes the LGPL, sometimes another license.
Slashdot Mirror
Thanks
Bruce
The library can't be linked with proprietary components. That's the first problem. The distribution of the .o files, and the library itself, didn't come with the requisite written notice about the source being available. So, yes, if they put the notice there, they'd be legal, but since they distribute the object. via FTP, they'd probably have to distribute the source that way too.
I think we're just talking about parity.
Thanks
Bruce
I agree with you that deciding where to draw the line is very important, and not terribly easy to do. For example, I don't want to have an FTP client considered derivative of the FTP server. But if somebody builds a GUI shell around my "engine", I am convinced that such a thing is derivative.
Thanks
Bruce
A more common problem is dynamic libraries that are distributed separately from the executable. You say that a court would hold those to be devices explicitly used to circumvent the license restrictions, but that's rather chancy, and no substitute for explicit language regarding what is, and what isn't, considered a derived work in the GPL. You seem to be hoping that copyright law will take care of that definition for you, but that doesn't seem to be happening.
There's also the problem of Application Service Providers, who make a work available for people to use without distributing it, and thus would be under no obligation to make the source code of their modifications available. Do I have to see my GPL work abused that way as well?
It seems there's a lot of new technology that the GPL isn't keeping up with. Can't we have some changes to address these things?
Thanks
Bruce Perens
Bruce
I'd like to point out a few problems with your comment.
The Gauntlet firewall published by Trusted Information Systems was not an Open Source program. It's what we call "disclosed source-code", and that's very important because that difference means that nobody had much reason to read it or work on it. The software license didn't provide them any incentive to do so - you would have only been fixing bugs in a program that somebody else has an exclusive right to sell. Who wants to be the unpaid employee of another company? With real Open Source, you have the same right to sell the program as anyone else, or to distribute it for free, for that matter, and thus you aren't some company's unpaid dupe. For an explanation of what Open Source is, see The Open Source Definition .
At the time of the Morris Internet worm, the BSD software distribution of which Sendmail is a part was under a restrictive license and required an expensive ATT Unix license before you could get the system. This is also not what we today know as Open Source. Besides, you are writing about the epochal Internet virus, and few people even considered Internet security before that event.
Yes, all compilers have a bootstrap problem. One can avoid it by compiling the compiler with another compiler, once in a while, and then compiling the result with itself. This method can also be used to detect the Trojan: compare the generated executable with one that doesn't have another compiler in its heritage - if there's a significant difference, look for a Trojan there.
Most users do not compile their own applications, but they get them from a trusted source who has compiled them and cryptographicaly signed them. You might not be aware that in all Linux distributions of any import, the packager does compile all programs. If there is a trojan slipped in, you can trace it to the person who compiled the program and bring charges if necessary.
And what good would it do anyone to grep through source code for strcpy()? We've already done that ourselves, and have fixed obvious problems.
Sure, it's no guarantee, but it's much better than the alternative, which lets Microsoft embed snide comments (if they really aren't trap-doors, embedding a trap-door would be as easy) in their software and have them undiscovered for years.
If you want it to stay free for everyone, your best choice seems to be LGPL. It's the only license that sufficiently protects its own freeness.
Thanks
Bruce
You're making a very selective reading. The form of use you postulate is actually derivation, and thus you have to heed the language regarding derivation.
If you really made a BSD-license library that actually did the work and distributed it freely, you could get away with the postulated scenario.
However, if it happened that your library was a mere stand-in, something so insufficient that the GPL version would always be used by your customers, or if its license terms or distribution were such that you could not reasonably assume that the user would make use of your library, it would be easily demonstrable that your library is simply a device for circumventing the license.
Also, shipping a library with a product that makes use of it does not satisfy the definition of mere aggregation. Aggregation applies to unconnected products.
Thanks
Bruce
You know, courts do consider intent.
I am not responsible for the GPL text and have suggested several improvements to RMS, to no avail so far. If it gets bad enough I will write my own license, but I don't want to add to license proliferation unnecessarily.
Thanks
Bruce
Thanks
Burce
With all due respect, had you read the GPL you would have seen that it explicitly makes an exception for standard facilities distirbuted with the compiler and operating system. I wish people would at least refer to the darned thing while arguing.
You argument also has an implicit assumption that executable form of the application is GPLed, and I don't believe the text of the GPL supports that. (That's another argument entirely though).
Yes, the executable is under the GPL license. That's really fundamental - there would otherwise be no compulsion do distribute source. If it's not GPL-ed, it's All Rights Reserved, so this would gain you nothing.
I am afraid I can't, at present, grant that you are competent to discuss the GPL at all. Please read up and try again.
Thanks
Bruce
Bruce
Bruce
Bruce
Bruce
And regardless of the legal realities, it's a sleazy thing to do. You do want to be able to sleep well at night, don't you?
Isn't it funny that although libreadline is far from rocket science, it's been a stumbling block for a number of programs? Nobody's bothered to write a competent replacement, can that be right? And they call us whiners instead of coders?
Bruce
Thanks
Bruce
Why not contact the authors and negociate for a commercial license to their code? If that doesn't work, please consider their wishes and either GPL, LGPL, or MIT-license the whole thing, or write their property out of your program.
Thanks
Bruce
Let's not forget that commercial licenses are an option. The fact that the GPL is on something doesn't prevent you from negociating for one.
Thanks
Bruce
Sure it does! We use it for most of the libraries on Linux, for gosh sake! It's because we explicitly want people to be able to create proprietary applications on their Linux systems.
Was anybody arguing with that?
To me, that's what free software should be about, a way to facilitate the free sharing and communal improvement of your code, not forcing others to do the same if they don't want to.
Well, consider that there is another sort of forcing. I don't want someone to force me to participate in their proprietary product, with no compensation on my part. But that's what happens when somebody else includes my code. So I use the GPL to protect from that. If they want my code in a proprietary product, they can pay me for a commercial license. Thus, the GPL actually promotes payment for use of my code in this case! Nasty, pro-commercial GPL! :-) . Now, with most librarary work I do, I've waived that protection and used the LGPL so that producers of proprietary stuff will be able to use my code. It's a choice that I make as copyright holder every time I write something.
Thanks
Bruce
Thanks
Bruce
Thanks
Bruce
Also, the GPL claims no rights to anybody else's code. It simply disallows use of GPL code with programs under most software licenses. If you don't like the GPL, you simply should refrain form using GPL components in your programs.
Thanks
Bruce
Bruce