Derivative Works And Open Source 369
marvin826 writes "
Larry Rosen has a nice article in the current issue of the Linux Journal about the legal interpretation of derivative works. Seems there are two camps in the world in terms of using open-source libraries, such as GPL licensed libraries, in proprietary software. Read this article and see which camp you are in! Having people working full-time on proprietary software, using open-source libraries, can only help the open-source software get better?
"
please (Score:3, Insightful)
I don't trust this "article" a bit. $1000000 says it was funded by some big company looking to milk open source advocates for all they're worth.
Re:please (Score:4, Insightful)
Unless the Open Source advocates have lost faith in their "superior" software model, this really shouldn't be a problem.
Re:please (Score:5, Insightful)
The problem is that Rosen propose 4 points:
1) The primary indication of whether a new program is a derivative work is whether the source code of the original program was used, modified, translated or otherwise changed in any way to create the new program. If not, then I would argue that it is not a derivative work.
This I agree.
2) The meaning of derivative work will not be broadened to include software created by linking to library programs that were designed and intended to be used as library programs. When a company releases a scientific subroutine library, or a library of objects, for example, people who merely use the library, unmodified, perhaps without even looking at the source code, are not thereby creating derivative works of the library.
If I understand correctly, this is expressly prohibited in GPL, but is allowed in LGPL. So, I disagree with his point here. If we allow this, companies will extort this and take advantages as much as possible -- which, of course we don't want.
3) Derivative works are not going to encompass plugins and device drivers that are designed to be linked from off-the-shelf, unmodified, programs. If a GPL-covered program is designed to accept separately designed plugin programs, you don't create a derivative work by merely running such a plugin under it, even if you have to look at the source code to learn how.
I think this is also expressly prohibited in GPL, but allowed in LGPL. So, I believe plugin system should also be discouraged in GPL, otherwise it will make a "major loophole" (like making a main program out of a plugin).
4) In most cases we shouldn't care how the linkage between separate programs was technically done, unless that fact helps determine whether the creators of the programs designed them with some apparent common understanding of what a derivative work would look like. We should consider subtle market-based factors as indicators of intent, such as whether the resulting program is being sold as an ``enhanced'' version of the original, or whether the original was designed and advertised to be improvable ``like a library''.
See reason #2 & #3. If we allow companies sell enhanced versions of GPL programs: We're in a *deep* trouble. Imagine MS taking Advanced Gnome for their own... Golly!
Re:please (Score:5, Insightful)
3) Derivative works are not going to encompass plugins and device drivers that are designed to be linked from off-the-shelf, unmodified, programs. If a GPL-covered program is designed to accept separately designed plugin programs, you don't create a derivative work by merely running such a plugin under it, even if you have to look at the source code to learn how.
I think this is also expressly prohibited in GPL, but allowed in LGPL. So, I believe plugin system should also be discouraged in GPL, otherwise it will make a "major loophole" (like making a main program out of a plugin).
No, this sort of means that when you code a GPL program and specifically define a "plug-in" interface, that any binary that "plugs" in is not a derivative. In copyright terms, the fact that a "plug-in" interface is well-defined is enough to remove derivative status. In fact, a guiding principle here is that if there is a wall separating dependences (like a defined plug-in interface), then that wall removes derivative status.
You have already argued that this creates a loophole - I think the legal view will be that you cannot take GPL'd software and make a plug-in interface out of an existing interface for the purpose of removing derivative status. However, adding a novel plug-in interface to GPL'd software would be seen in a different light.
Remember, you have to take the point of view of someone looking at copyright history and trying to apply its law to software, and not the view of someone who wants to make the GPL as powerful as possible. A well-defined dependence "wall" is adequate to remove derivative status. If that creates loopholes, there are other ways to address that. I can't help it if the law ends up looking like a mess.
Point 2 (Score:3, Informative)
And in part GPL decision (I think MySQL) a judge made the decision that if the program could be substituded with another then there is no binding. Therefore it could be concluded that if I create a neutral API a'la ODBC I could bind to a GPL program, without having to give up my sources.
Of course all of this is yet to be decided in a court of law....
Re:Bullshit (Score:2)
Really? Name five. Let me get you started:
1. It's probably gratis.
2. It offers an alternative to Microsoft.
Please, continue.
Re:Bullshit (Score:3, Interesting)
1. Maybe gratis. Definitely libre.
2. People aren't just rejecting MS software, they are rejecting their licensing. So it's better to say "It offers an alternative to proprietary software."
3. It prevents people from profiting on other people's labor.
4. It ensures innovation based on pre-existing work is shared with the folks who did the pre-existing work.
5. Protects a developers work from being dispositioned in a fashion other than what (s)he wants.
6. 99.999% less likely to suck
7. Allows for friendly security analysis, can be certified as secure.
8. Users not beholden to magnanimy of vendor.
9. Users not stuck if vendor goes under.
10. Rapid innovation
11. Bug stomping
12. Allows for the rules of governing dynamics, where individuals AND the group (company) can gain.
Re:please (Score:5, Informative)
Did you RTFA? It's as much descriptive as prescriptive; as I read it, he's basically saying, "Here are some of the legal issues to be considered in deciding what constitutes a 'derivative work,' and they're tricky issues, so define your terms carefully." Which is entirely reasonable, especially in light of the mindless GPL-vs.-BSD flamewars.
Re:please (Score:3, Interesting)
Re:please (Score:2)
The old (and maybe current, I haven't read it lately) license for MySQL clearly stated that MySQL could be used for software NOT developed for resale!!
Just add one line to your license agreement
Is Microsoft Really the Issue? (Score:3, Interesting)
I like Open Source like the rest of us, but we really need to get over the MS (chip on the shoulder)....
Not centrally, but it IS an issue (Score:3, Informative)
They would quite likely love to cut costs by using GPL'd software of various sorts as the foundation for their proprietary software. Their railing against the cancerous nature of the GPL seems to indicate their frustration at not being given free reign to do with such software as they wish.
I would guess that there are a number of programmers who GPL specifically to ensure that their work is never legally usable by Microsoft. I think they would be quite displeased with this interpretation.
Re:please (Score:4, Insightful)
Know what else? Commercial software companies write programs that use MS libraries too. And they profit from MS labor. And if they don't give any money to MS in the process (such as buying VS.NET or something) then MS don't get crap from it.
The problem here is determining whether using a program withing a program is derivitive. And is a library a seperate piece of software or part of the software that uses it, or part of the OS. If you were to argue technically it could go on for days. What we need is to know legally which it is. Which wont happen until we upgrade our laws to better ones that take into account modern technology.
Re:please (Score:2)
That's not true. Each Microsoft library comes with or runs on a copy of Windows. Each copy of Windows is supposed to be individually licensed and paid for. The more popular your MS library using app is, the more copies of Windows get sold, and Microsoft makes more money.
Re:please (Score:5, Insightful)
By your logic, virtually every peice of software written for windows belongs to microsoft, as it uses their libraries. And a book report on Cujo belongs to Stephen King because his work is quoted and listed in the bibliography.
Making calls to a library that already exists on a system does not make a derivative work. IMO static vs dynamic linking should be a non-issue as well.
This is where the GPL turns to shit.
I write and maintain one app where I work, which uses proprietary libraries to generate maps. I know going in if a specific client wants to use the mapping features, he/she must either buy the mapping component seperately, or through me.
Never is there any notion that the company creating the 3rd party libraries I use gets any rights at all to my software. Yet, if the library was GPL'ed tomorrow, all of a sudden my work should be free?
Re:please (Score:4, Insightful)
Only if you wanted to redistribute the library for free. Today, you can't distribute the library for free at all: you or your customer must buy it.
If the library was GPLed, it would not change the situation one bit. You would still have to buy it from the author under a different license in order to distribute it with your binary app. Some other people could use the library for free under different circumstances, but that wouldn't affect your usage. How is this a problem?
Re:please (Score:3, Insightful)
Re:please (Score:2)
When you develop a piece of software that uses someone elses library, you have to observe the licensing terms of that other library. That's the way it is.
When you write a piece of software that uses windows include files, you are obligated to follow the license terms of those.
That much is perfectly clear. You may not like it, but that's just tough. Copyright law is pretty darned clear about it, and alas, your opinion doesn't end up counting for squat in court. (Seriously - there are some very depressing legal precedents which ultimately mean that our opinions or interpretations of a license are worth less than nothing.)
Where it becomes messy is in the definition of a derived work. And the linked article is almost certainly wrong about how to define that.
For example: a library that provides a binding for gtk to a new programming language is probably legally a derived work of gtk. Even though it doesn't modify a single line of code from gtk, and only links against it.
The key question is always how far can you go, as the client of a library, before you become a derivative. And the only answer there comes from talking to a knowledgeable lawyer, following thier advice, and hoping for the best.
-Mark
Re:please (Score:3, Insightful)
Logic does not apply here. I can write software and stipulate that users must give me their first-born as payment. You are free to choose my software, or if you think the licensing terms are unreasonable, go buy someone elses package.
Microsoft requires you give them money for their software, it is their right. BSD does not require you to distribute modifications, it is their right as well.
Your right is to pick the software package that has a license that suits your purposes most.
Never is there any notion that the company creating the 3rd party libraries I use gets any rights at all to my software. Yet, if the library was GPL'ed tomorrow, all of a sudden my work should be free?
You always have the option of not using the GPL software. Nobody's forcing you too.
Re:please (Score:2)
No, because the GPL is a license which you have to accept. Even if it is only accepting in your mind. You've paid(or they've paid) and accepted the license that you paid for, just because they GPL it doesn't change it with you. This is one thing people forget. If I program something, release it as GPL, I can take it down, and re-release it as LGPL. Those who have accepted it as GPL still get to keep it as GPL.
Of course, it does get a little tricky with all of the legal advice coming from everywhere also, and IANAL.
Example: If you give your customers a right to use your software, and they use the 3rd party libraries(assume that they are GPL), the libraries, by GPL definition, would demand that your program be GPL also. Except, you own the copyright on your program and they can not release it as GPL. This leads to a copyright battle in which they, not you, are at fault with the GPL and can only use it with regular copyright permissions. But it all depends on the GPL wording, and I'm probably wrong, but I believe it reverts back to regular copyright, and you can not use it without getting it under another license.
Re:please (Score:2)
Re:please (Score:2)
I always get a good laugh when someone worries that companies might profit from open source labor. Do these people ever bother to read the licenses, and the supporting documents?
If you don't want companies profiting from your labor, then do not use an open source license. It is that simple. Almost every open source license allows, by design, people to profit from open source who are not the authors of the program. E.g., by selling support. If you write a program and GPL it, and I make a good living selling support for it, that is profiting from your labor just as much as it would be if I were to use your program in a proprietary program.
Re:please (Score:2)
If the GPL was so perfect, then all the C libraries would be GPL too.
Re:please (Score:2, Insightful)
Great, now my brain hurts (Score:3, Interesting)
That then begs the quest, is taht bad?? At least then you know *some* of the OS is stable =)
I'd have to say that (IANAL) review of the article / law, it woud seem that you can link w/o violating GNU... as long as you distibute the source to the things you linked to (but not YOUR code taht actually calls it)
What this boils down to: (Score:4, Insightful)
Personally, I'd consider anything that's part of another program installed on the computer as a dependency to be fair game. If I see that Program X requires me to have GAIM installed, fine. if Program X takes GAIM source, closes, and sells it in their program that way, that's bad. So as long as it only utilizes your install of GAIM rather than including it itself, then it's all good.
Note, I also don't object to them putting it on the CD with the software, as long as it's clearly seperate from their software, even if it's a dependency, as long as they provide it within GPL terms.
Derviative Works (Score:3, Funny)
Noone really understands the GPL... (Score:5, Informative)
Re:Noone really understands the GPL... (Score:5, Interesting)
That's right. I consider myself to fall into the above. I mean, I think I understand the GPL, I understand the concepts behind the contract, but it is fucking vague. Concepts like linking - what does linking mean when you are referring to a Java program? If two classes are in the same jar, are they linked? Is it a derivative work? Are they part of a single "work"? If an interface is BSD-licensed or just public domain, but an implementation is GPLed, can I use runtime class binding to invoke it from a piece of commercial software? What about if I use RMI or some godawful XML/HTTP/SOAP mechanism to invoke it?
Now the usual Slashdot response when somebody submits an Ask Slashdot on these topics is "Don't ask us, call your lawyer"! The problem is that while lawyers are experienced and generally skilled at reading contracts, you know a fuck of a lot more about software construction, components and the like than your lawyer does. And though IANAL, I have many friends who are, and you'd be shocked at how much jurisprudence out there is based on concepts like "would a reasonable person expect that..." and so on. If a reasonable person doesn't know what the word "link" means or doesn't understand what a "derivative work" is, even a reasonable person who IS a practitioner of the art in question, then the contract is, IMHO, on shaky grounds when it comes to enforcement in a court of law.
But that's just my opinion. Feel free to prove me wrong.
Re:Noone really understands the GPL... (Score:2)
Re:Noone really understands the GPL... (Score:2)
If the GPL doesn't hold up, wouldn't we just revert back to normal copyright law? Either what you are doing with GPLed code is explicitly allowed by the license, or you have no right to use that code.
Re:Noone really understands the GPL... (Score:2)
There is the language in the GPL about 'mere aggregation' not counting as a derivative work, and I guess this could cover your two-classes-in-the-same-jar example.
The FSF's opinion, I think, is that linking (whether run-time or compile-time) makes a derived work, but calling via an XML-RPC interface or similar does not. (Otherwise my web browser would be a derivative work of Slashdot.) In the worst case, you can ask the software's copyright holder for clarification of what he or she counts as a derivative work.
I don't understand it either (Score:3, Interesting)
Was that program a derivitive works? Did I violate the licence? I don't exactly lose sleep over it, but I'm curious and IANAL. Can someone clarify this for me?
Re:I don't understand it either (Score:3, Informative)
There's a certain minimum amount of copied material required before it becomes copyright infringement, isn't there? If it's only one line you might be OK, since there can't be that much creativity in just one line of code.
Out of curiosity, how did they do it?
Re:I don't understand it either (Score:2)
The real question is what people would consider significant enough to go after you for the violation.
Re:Noone really understands the GPL... (Score:3, Insightful)
If a company is using GPL'ed software and/or libraries in a commercial product, you might want to talk to the FSF lawyer.
Re:Noone really understands the GPL... (Score:5, Insightful)
The GPL doesn't say that you can't create derivative works without giving them away. It says you can't
*distribute* derivative works without giving them
away.
If you're building proprietary software for use internally by the company, then they are not, legally, distributing it! In effect, it is purely free, so long as you don't distribute your derivative works.
-Mark
My concerns about collaboration and derivations (Score:3, Insightful)
The GPL was created for a specific aim - to ensure that there would be a base of software that is, for want of a better term, free to the end user. That means that the end user need not care about how the software is created and the aims of the person creating it, but is able to use the software for their own personal use to the best of its capabilities. If the software needs to support something new, they can change it. But in itself, this promotes a non-collaborative paradigm. And this creates - as you can see from some of the heated discussions of GPL vs BSD/X11, etc, discussions on Slashdot - an ironic dichotomy where the aims of those who use GPL'd software may be at odds with those of the original developers, almost my definition.
This quagmire of free software frustrating a small minority of those who are uninvolved in its development who in many ways wish to remove the very freedoms the GPL provides to users of their own derived software will not go away by itself. Unless people are prepared to actually act, not just talk about it on Slashdot, nothing will ever get done. Apathy is not an option.
You can help by getting off your rear and writing to your congressman [house.gov] or senator [senate.gov]. Tell them you believe that collaboration and the use of derivation is something you want to encourage. Tell them that you appreciate the work being done by the free software and open source communities, but if the freedoms they introduce end up being compromised by incompatable derived software that removes those freedoms you will be forced to use less and less secure and intelligently designed alternatives. Let them know that SMP may make or break whether you can efficiently deploy OpenBSD on your workstations and servers. Explain the concerns you have about freedom, openness, and choice, and how we need to work together to create a world where collaboration and derivation is a norm that can be relied upon to exist. Let them know that this is an issue that effects YOU directly, that YOU vote, and that your vote will be influenced, indeed dependent, on your legislator's policy towards free and open software.
You CAN make a difference. Don't treat voting as a right, treat it as a duty. Keep informed, keep your political representatives informed on how you feel. And, most importantly of all, vote.
Quoth the attorney (Score:5, Interesting)
Re:Quoth the attorney (Score:2)
Linking to a library is quite arguably use, not derivation. Of course, distributing the library definitely falls under the terms of the GPL, but that doesn't make it clear that the GPL can require anything about the program being linked, only the library.
-Billy
Re:Quoth the attorney (Score:2)
However I am now failing to see how a program could simply "use" a library. If someone could enlighten me I would appreciate it.
Re:Quoth the attorney (Score:4, Insightful)
Okay, let's imagine a hypothetical GPL'd glibc. Then you write a generic "Hello World" program. Your program merely uses glibc. It does not derive from it.
When someone asks you which libraries are involved in running your "Hello World" program, they will say "what libraries do you use", and not "what libraries have you derived from."
1) The C API is essentially in the public domain. There are many implementations of it, and your program has no way of knowing which implementation it is linking to.
2) The linkage happens at run time. It is the end user who actually shoves the program and the library into the same process space. Not the developer. What you are distributing has zero glibc code in it.
3) glibc was *meant* to be used in such a manner. It has been created and distributed for wide general use by people outside of the GNU project. This is the main point of the second bulletted item in the article.
4) Dependency is not derivation. It may seem so in some software languages, but they are two distinct things when it comes to copyright.
linking (Score:3, Interesting)
By linking you first have to differentiate between static and dynamic. I don't think anyone's going to argue against dynamic linking. At that point, you may as well say no proprietary programs on Linux, at all.
So back to static linking. I seem to remember reading once that this could still be handled, if the proprietary portion were supplied in some linkable form. In other words, the GPL'ed portion could be fixed or enhanced, and then re-linked with the proprietary portion.
This looks to me like what nVidia does with their tarball distributions. There is some source and a *big*
One exposure is that
I seem to have gotten the impression years ago reading GNAT documentation. They chose to release their library components under LGPL, so I'm not sure if I've described GPL or LGPL behavior, but I thought it was the former.
Re:Quoth the attorney (Score:2)
This article is not legal advice (Score:5, Insightful)
For an interesting read of why usage constituting a derivative work would be important to free software (and is part of the GPL) read Why you shouldn't use the Library GPL for your next library [gnu.org] from gnu.org.
I myself have written popular Java libraries [ostermiller.org] that I license under the GPL (not the LGPL) because I want to encourage free software development.
If you wanted to make a movie, and in your movie you had another movie playing in the background on a tv on the set, do you think you should have the right to distribute your movie containing somebody else's movie? (Ignoring fair use such as parody) I don't think you should be able to.
The article seems to be written to allay fears of business leaders that they occur legal risk by using open source software. The article does not offer good advice. I would recommend, that if you were to use open source software in closed source, look for a license that specifically allows you to do so (such as the LGPL) rather than relying on an untested definition of derivative work.
Re:This article is not legal advice (Score:2)
Re:This article is not legal advice (Score:2)
Re:This article is not legal advice (Score:4, Insightful)
So we win both ways: if the companies claim that the GPL is unenforcable for simple linking, then much of the commercial EULA and licensing that is similar is also invalid. If they claim otherwise, then the GPL is totally enforceable and we also win.
Pure genius.
However, it is meaningful, and you aren't quite informed as to what the courts will or won't allow.
Re:This article is not legal advice (Score:2)
If linking isn't enforceable (Score:2)
If you don't agree to the GPL definition of derivative work, you wouldn't have accepted the redistribution license and to redistribute would be a GPL violation.
If a court rules that distributing something or part of something without the copyright owners permission is legal, we would have an interesting situation.
I truely hope that a judge won't rule that "I only copied a small part of their work" is a valid defense.
Re:This article is not legal advice (Score:2)
But it DOES matter! I'm not distributing the library when I distribute the application that links to it!
Re:This article is not legal advice (Score:3, Interesting)
The GPL assumes that a derivative work is any work that uses another work. (In the GPLs case, by linking to it).
No, see, it really doesn't. What the GPL says about it is this (emphasis mine):
It's fine and dandy that RMS thinks that dynamic linking makes a derivative work, but all too often we seem to lose sight of the fact that the GPL is a license. No matter what RMS thinks the GPL means, it means what it says, nothing more or nothing less. It's far from clear that dynamically linking to a library creates a derivitive work. There are lots of ways where this kind of thinking is problematic:
Stating the obvious, but a dynamic library is nothing more than a set of entry points with documented behavior. By design. That's what it's intended to do. Calling something that uses a tool to do something a derivation of the original work is on shaky ground. That's like arguing a novel written in emacs is GPL. Anyway, I'm not arguing that a license couldn't provent this sort of thing; I just think version 2 of the GPL doesn't.
If you wanted to make a movie, and in your movie you had another movie playing in the background on a tv on the set, do you think you should have the right to distribute your movie containing somebody else's movie?
No, but I don't think that's a fair analogy anyway. I hope it's obvious why...
Re:This article is not legal advice (Score:2)
The GPL uses linking to define acceptable uses for what might be considered derivative works under the law.
With your first point about a Winamp plugin making Winamp GPL: This could never happen as Winamp is a standalone product, the plugin is not. Since Winamp does not depend on the plugin, it is not a derivative work. It doesn't matter what the GPL says because copyright law takes precedent.
As to your second point, this is where the article and I disagree. The article says that the plugin to winamp would not be a derivative work, I say it would. To my knowledge this has never been tested in a court of law.
As to your third point, you try to show a contradition, but the missed sublety about copright law being stronger than the GPL in your first point makes the contradition dissappear. In this case, if a plugin can function without the GPLed software (it was originally written as a plugin for something else) then under copyright law it would not be considered a plugin and GPL would have no say. It has not been tested in court to my knowle
Re:This article is not legal advice (Score:2)
Re:This article is not legal advice (Score:2)
Ok there is a GPL'd Web Server. Kickass and fast. So I develop an ISAPI interface onto the GPL'd Web Server. The ISAPI interface can then execute plugin's from both IIS and this kickass Web Server. So now comes the question, does the ISAPI plugins need to be Open Source? According to your previous comment no. But yet I linked into the Web Server, albeit a standard interface. Therefore I can sell my product with both IIS and the Kick Ass Web Server since IIS is already distributed for free.
In other words I have found a loophole? And I think this is the issue that the original article is trying to raise.
BTW a part decision in this has already been made by a judge. She said that using standard interfaces to interact with a GPL program does not constitute a breech of contract. This is because the program does not depend on the other program.
Therefore all you have to do is create standard interfaces for public consumption....
Re:This article is not legal advice (Score:2)
However, as others have pointed out in other comments here, the GPL has a clause to fall back on even if the linking does not make a derivative work (as is almost certainly the case here.) In this case, the GPL forbids your from distributing the GPLed server.
You could sell your product, but you would have to tell people to buy a copy of IIS or download the GPLed web server separately from a different source.
My Opinion of Proprietary Modules (Score:2)
If you distribute your work without any GPL code, it would not be required to license it under the GPL.
If for that code to be made usable, it MUST use/include/integrate some portion of GPL licenced source or binary it is in some way a derivative work when that GPL code is included.
If you include a GPL header file, it has integrated GPL code into that work.
If you wish to distribute it without any GPL code at all you wouldn't be bound, and the user could compile it themselves. The distribute under GPL clause only comes into play IF you distribute the GPL code, don't distribute it, you don't have to agree to it.
Re:My Opinion of Proprietary Modules (Score:2)
Expect in the cases of macros and inlines, including a header file does not include any code. You are merely accessing the public API. C/C++ is not English. Do not confuse C's "#include" with English "include".
As for the case of macros and inlines, it's more probematic. For some macros, fair use definitely comes into play. For others it's hard to say.
Re:This article is not legal advice (Score:2)
Not if they are just being used. It is only an issue if they are being distributed. I wouldn't have the right to distribute my propietary plugin with the gpl-ed player. However, someone could download both and use both together.
Re:This article is not legal advice (Score:2)
1. If I create a GPL'd plugin for WinAmp, does that make WinAmp GPL? I think most reasonable people think the answer is no.
Does WinAmp need the GPLed plugin code to compile? No, therefore it is not a derivitive work, and not covered by the GPL.
2. If I create a GPL'd media player, and a third party makes a proprietary plug in, is this illegal? This is really the case that's up in the air here... the answer only depends on whether the plug in is legally a "derivative work" or not.
Do I need your GPLed code on my machine to compile my plugin? Most likely, yes, at least a header file. If I need to incorporate your GPLed work into my program, my program must be licensed under the GPL. If, however, your plugin interface is declared in a file that is not GPLed, say public domain, then my plugin can be licensed in any way I want.
3. But if it is... then what happens if I create a GPL'd media player that can use WinAmp plugins? Do all proprietary WinAmp plugins become GPL? Well, of course not, but doesn't this make case two problematic?
Not really. If a plugin needs WinAmp code to compile, it must be licensed according to the terms of the WinAmp license. Since the plugin will compile happily without your GPLed media player, it is not a derivitive work, and not covered byt he GPL.
Re:This article is not legal advice (Score:2)
Of course, I've never been in a situation where a GPL'd library was the *only* solution. If I were, what's to stop me from using it to write an "interpreter" for a "language" that uses the library, and then having all the "programs" that I write in that "language" be proprietary? For example, my language has one command, gnufu and the only program written in my language just calls gnufu. OK, a trivial case like that is obviously contrived to violate the GPL, but what about something more complicated like a Java implementation?
Re:This article is not legal advice (Score:2)
Although you would think I cut and pasted this out of a transcript from a church, I did not. Find it
here [gnu.org].
It's from this paragraph specifically:
"But we should not listen to these temptations, because we can achieve much more if we stand together. We free software developers should support one another. By releasing libraries that are limited to free software only, we can help each other's free software packages outdo the proprietary alternatives. The whole free software movement will have more popularity, because free software as a whole will stack up better against the competition."
Hallelujah! Hallelujah!
--
On subject though, I am a diverse person and believe everything should be licensed in an appropriate manner, and that should be up to the author entirely(which, thankfully, it is). Yes, Proprietary Developers have money with which to develop, you know, big, faceless corporations do, smaller companies who can only eek out $1000 for a project do not have all of the money to re-implement these things. If there are FREE solutions that they can use, then there are. GPL is not FREE in the sense of FREE, but in the sense of FREE with Restrictions.
Mind you, I believe in GPL'ed software. I believe there is software that should be GPL'ed and should stay that way. But I don't call it free, it's Free With Restrictions.
I believe in Free Software, I believe in Commercial Software. I prefer free software, but sometimes when it's taken 100's of people 1000's of hours to create a large, complex program, that they should eat. If the use a Free library, then they should get paid a little less, but I still think they should eat.
Been going on for years... (Score:3, Insightful)
If linking DOES create a derivative work, this means that the very act of USING a library in the normal way is an act covered by the copyright code. This applies to everything -- including system libraries. Makers of computer systems could thus legally prevent anyone from writing programs for them by refusing to allow them to create derivative works. Want to write a program which links with the
Re:Been going on for years... (Score:2)
Hrm. What he says is at odds.. (Score:2, Interesting)
This means, of course, that the glibc library (which is under the LGPL) is the enabler for any reverse engineering that happens on pretty much any Linux system, anywhere.
Cool, IMHO. No so cool if this fellow is right and that simply linking to an LGPL'd library does not constitute a derivative work.
Basically, if Rosen's right, then the LGPL is invalidated at its core, and the GPL and the LGPL aren't allowed to dictate--in any fashion whatsoever--how end users are allowed to make use of software provided they make no modifications.
That would seriously SUCK.
Re:Hrm. What he says is at odds.. (Score:2)
First of all, the LGPL only says that reverse engineering needs to be allowed to debug modification of the work for the customer's own use. It doesn't sound like reverse engineering for other purposes needs to be allowed. It also does not say that you need to allow any and all modifications, and in fact sections 6a and 6b specifically state what modifications need to be possible (essentially, being able to modify the LGPL'ed library). So I think this could be intrepretted to mean that you must allow the modifications stated in 6a or 6b and reverse engineering to debug those modifications, but that additional reverse engineering or modifications do not need to be permitted.
Furthermore, section 6 is an "exception" section anyway. My take on this is that section 6 does not apply if you are not distributing LGPL'ed code with your program (e.g., if you require the user to have a particular DLL or .so on his system beforehand), in which case I don't see any restriction on limitting reverse engineering.
Of course, I'm not a lawyer, so I could be off the mark on all this.
Re:Hrm. What he says is at odds.. (Score:2)
Real world definition of derivative work (Score:2)
If the free software project is bigger than what your boss is doing, the free software project is a derivative of your boss's project and has to be taken down.
Impressed, but reserved... (Score:5, Interesting)
However, I think that the classic issue that has stumped the traditional wisdom is not coverdd. That is the case of "interface definitions" that must be loaded and merged with your source code at compile time. These include C or C++ "header files", or the "modules" of Perl. In interpreted languages the issue gets really sticky because you can modify those external libraries at run-time.
For example, is this Perl module a derivative work?
package CGIOverride;
use CGI;
sub import {}
package CGI;
sub params { die }
sub new { die }
sub start_html { die }
1;
__END__
Here I basically edit the CGI module, but I do it at compile-time. If the law has to start getting into compile-time vs. pre-compile-time distinctions, I think we're going to be in for a bumpy ride!
Even worse... one way to resolve the above is to say that I'm not editing CGI, I'm editing the CGI namespace. At that point, we have to decide if a namespace is something that is protected under copyright law! Are namepsaces just a loosely maintained analog of the domain name system? Is a Perl module or a C++ header analogous to a programmer's Web site? *shudder*
Re:Impressed, but reserved... (Score:2)
Hm, might seem silly to us, but try explaining to a judge that com.mycompany.app.SomeClass is actually just a Java class that has nothing to do with the company's website.
Re:Impressed, but reserved... (Score:3, Informative)
Either that, or the GPL and LGPL are unenforceable. If they were unenforceable, then why aren't more companies challenging the GPL? Or any companies for that matter? Answer: they don't want to invlidate their own licenses that make similar end-user restrictions.
By validating the GPL's ability to enforce such restrictions, they are affirming their own ability to enforce their own restrictions.
So it seems to me that the companies disagree with our man Rosen here.
Re:Impressed, but reserved... (Score:2)
The question here is, what am I modifying? Is it ultimately perfectly reasonable to write the code I did, and distribute it as my own work? Personally, I think the answer is yes. Why? Because, the entity making the change to the software is the compiler.
Imagine an artist requiring royaltees from a filter-maker for "modifying" the image of their art when photographers take a picture! That's pretty much the same thing as is going on here. The compiler provides the filter attachment, I provide the filter. CGI.pm itself is never modified.
Re:Impressed, but reserved... (Score:2)
So I think the answer is no, it is not reasonable to write that code and claim it as your own unless you are also the author of the CGI library.
And an artist can't require royalties each time someome looks at his painting--he can just restrict access to the original. Also, many museums don't allow photographs. But the act of looking itself?
Re:Impressed, but reserved... (Score:2)
Oh! Oh! Passive tense in english! Oh the humanity!
"regardless of the actual mechanism that does it, you're the one that's causing it to actually be done. So that part of your thesis needs a little work"
I'm not so sure that holds water. You say that my work is a derivative of yours (casting you as the CGI author here for simplicity)? What if I say, "No, no! I wrote an API-compatible module for doing CGI stuff! Your module was crap. My CGIOverride is designed to alter my module, but if someone wants to use it with yours, that's ok with me too."
Now what happens? I've caused the compiler to modify my module, but it can just as easily modify yours, and in fact I encourage the users of my software to do so. That's why I mentioned the idea of questioning the copyrightability of namespaces in programming languages.
This is where copyright law is lagging decades behind the real world. The hew and cry from people like me to fix this kind of mess was answered with the DMCA, which introduced a host of new problems and solved non of the real ones. Sigh.
Re:Impressed, but reserved... (Score:2)
In your example, your module, standalone (i.e. without the CGI module) does not obtain anything from the CGI module, and is therefore not derivative. If you were to copy verbatim bits of the CGI module into yours, and maybe then modify those bits, then your module would be derivative.
I also don't see how there can be a legal distinction between verbatim and modified that affects the issue derivation, as both entail obtaining material.
Re:Impressed, but reserved... (Score:2)
Thus, I may have developed this against my own "CGI" module, and it just happens to work with the better-known version that ships with Perl.
If that gives you a headache imagine how bad it gets when we get to OO programming where "deriving" is actually part of the programming paradigm! When I create an object that derives from yours, is it a derived work in the copyright sense? If not, why not?
My answer is similar to Rosen's, but goes deeper. If your modification to or derivation from my code is made through an API that I provided, then you're not creating a derived work, you're using my tool as I intended it to be used (and stated in the license that you were allowed to "use" it). The issue will have to be resolved for the case where there is no license (e.g. if you have not accepted the terms of the GPL), but I think the answer should be the same.
scaring proprietary software users away? (Score:4, Insightful)
And why shouldn't they be scared away? If they want to make proprietary software, then let them. They just can't use GPL'd software programs or libraries as a replacement for paying for development of their own. There is always BSD licensed work to explore, if they are so inclined.
It should be REALLY clear (Score:5, Informative)
There are, however, some guiding principles. One of the is that of the non-unique well-defined interface. For example, if a program only used POSIX libc calls, it is not a derivative work of any C library it uses. This independence is because you can change the C library freely, and the program's function doesn't change. So we can easily establish that libraries that adhere to a spec, for which multiple DIFFERENT libraries exist to fulfill that spec, do not make derivatives of programs that dynamically link to them.
Static linking I think is highly likely to make the calling program a derivative, since the library forms part of the functional binary.
Now, on to dynamic linking with a unique library. This case is the REALLY interesting one. Some people argue that inclusion of the header files makes something a derivative. This is utter nonsense. A header file is made specifically so that a calling program may include it. Also, you could replace the header file with another file that provided the same functionality trivially (it defines an interface, a function, and it not really expression in the same sense that the main program is). I don't think this argument will ever fly. But, in this case the program cannot function at all without one specific library. So, it is likely a judge would rule that it is dependent in copyright, and a derivative. Note that if someone coded a clone replacement library, then the dependence vanishes, as does the derivative nature of the work. Larry Rosen disagrees with this point of view, b/c he claims libraries are MADE to be linked with. But, this point is still to be decided by a judge.
There are other cases that are clear. Plug-in interfaces, for example, are like walls that separate dependences. The interface is well-defined so that no one on either side of the interface needs to know anything except the interface itself. Not a derivative.
As you can see, the rules are not hard and fast, and there is a slippery slope to tread.
Inclusion and Derivation (Score:2)
I am one of those people who disagree.
If you MUST include GPL licensed code (ie the header file in question) to make the binary you wish to distribute, you have created a (partially) derivative work.
If you don't agree with the GPL restrictions on distribution, don't distribute GPL code, or any part of it.
I would think anything would be derivative (Score:3, Insightful)
This opinion is probably not legally sound, but it would seem to me that anything would be derivative. Linking to a library, calling a function of a library, etc. The lawyer in the article says (paraphrasing since I can't get an exact quote since the site is
Why not? If it is a sqrt() function in a free software library, I think that does count. If the author of the package doesn't want it to count, he can write his own sqrt() function and own library. If he write it from scratch, no copyright, and no legal problem. Then he can call sqrt() all day long.
As has been said previously, if we had open software package X that "accidentally" used a library copyrighted by Microsoft, does anyone thing that Microsoft wouldn't sue us? Write your own code. If you "use" someone else's code, it only seems logical that you have to agree to their terms, no matter how small the piece of code. If it is truly that small, write it yourself, and there are no issues.
Re:I would think anything would be derivative (Score:2)
Can you really write a win32 application using only your code? Without linking to any library?
I wouldn't know, since I don't develop programs, but I would think that the terms of use for those libraries allow you to use them "freely". I was saying that if you used a library, you had to use the terms that the library was created under. I would suspect the terms for MS library allow for relativly free use, so there is no conflict against what I said earlier. The GPL library terms are not a "free" in this sense, so if you use a GPL library, I would think that means you must have your program be GPLed, whereas if you used a Microsoft library, I suspect there is no such quid pro quo.
Two Points (Score:2)
2) While a source package designed to be statically linked to a GPL'd library might not be a derivative of said library, I see no way that the binary resulting from compiling and linking that package would not be as it will contain an actual copy of the library.
The meaning of "derivative work" ? (Score:2)
So is the implication of the article that the GPL's definition is somehow invalid (or potentially invalid) in light of existing law? I mean, the GPL provides a rather specific definition of a "derivative work" that while perhaps controversial, would appear to be legally binding and specifically prohibits linking by closed source programs. It was this restriction that spawned the LGPL, correct?
The article appears to imply, however, that the term "derivative" has a potential definition in existing law which would take precedence. Is this the case?
Excuse me? (Score:4, Insightful)
If a licensor defines the meaning of "derivative work" in some particular way, you are free to disagree with the definition and the license, but we would like to remind you that only the license grants you the right to use this work.
This attorney needs to think more and write less.
C//
not exactly (Score:3, Interesting)
Re:not exactly (Score:3, Informative)
This is not correct. If you do not accept the definition of derivative work in the license, the license does not offer you the right to distribute the original work at all. You will then risk explaining to a court from where you acquired distribution rights to a product that you were distributing without permission. A tough one, that.
Of course, you can dodge the issue by not distributing the original, in which case the license is irrelevant, as you say, except to the extent that the legal definition of derivative applies.
C//
Two Camps (Score:2)
As I understand it this is the difference between the BSDish licenses and the GPL. That is why MS has a decent tcp/ip stack
Rosen, please stop making a disservice! (Score:2)
Please, allow me to technically shatter point number two:
2) The meaning of derivative work will not be broadened to include software created by linking to library programs that were designed and intended to be used as library programs. When a company releases a scientific subroutine library, or a library of objects, for example, people who merely use the library, unmodified, perhaps without even looking at the source code, are not thereby creating derivative works of the library.
When you link to library, you can do it dynamically or statically. I suppose I really don't have to explain much about the static linking, since it's extremely obvious that the library code that is used is being distributed, so let's concentrate on dynamic linking.
When you link dynamically, you aren't distributing, as such, any linked code... however, dynamic linking is just a facilty to reduce memory size, and facilitate distribution: you are effectively including the code when you run the program. You just don't distribute it due to technical artifacts that make programming and distribution much simpler. It's a techincal feat, that changes nothing and is completely olrthogonal to copyright issues.
That said, when you use a function of a library, you are basing your work on that library (a third party's work); without it, the program won't run. So, unless you carry your own version of those certain functions you need, yes, you are making a work based upon one or more pre-existing works, HENCE: DERIVATIVE, as you, yourself, quoted.
Please, don't add to the confusion. You are a recognized person who has the power to form opinions. Casting such graveous comments only adds power to a confusion that would certainly be usefully exploited by big powers unfriendly to Free Software. Or "open source", or whatever you rather call it.
Re:Rosen, please stop making a disservice! (Score:3, Interesting)
FUD (Score:4, Insightful)
The article disingenuously ignores cases where works were held to be derived even when they did not include any part of the original work, but only (e.g.) recycled characters from the original. When the second work makes sense only in light of the original, it's derivative. A program that works only when a GPLed library is present is derivative of that library.
Claiming that dependency other than copying doesn't count is a disservice to Mr. Rosen's clients, and to readers at large. An honest article would have at least acknowledged that serious legal scholars disagree with him.
Re:FUD (Score:2)
The article claims that the extra permissions offered in the LGPL are implicit in the GPL, and that any library offered under the GPL may be used as if it were released under the LGPL. Right or wrong, it's the topic under discussion here.
You must (Score:2)
From the GPL
You must pass the rights you were given to anyone you give (with our without payment) the software to.
not an exact quote
For me that says it all. Anything can be derived, anything can be sold, but, if you got it for free, and you got the gold (source code) for free, as in GPL, then what you pass on must be as free as it was when you got it.
US Copyright law gives a lot of hooey about percentages of change. GPL, says no mater what you do, you cannot steal.
License awareness (Score:2)
Considering the release of the LGPL it's clear that the author of the GPL didn't want any linking to GPL software from proprietary -/non GPL software. And there is - IIRC - in US law a clause about understanding a license based on it's intent or something like that. (IANAL)
Now, the only solution to this trouble is for programmers to become more license aware. They should know what limitations they are putting on a program and especially on a library. It's OK to license programs under the GPL, but IMHO libraries should be licensed under the LGPL (which is a good license) or a BSD-like.
Sadly it seems that today many people put things under the GPL without thinking, it's become the de-facto license for OSS and that's not good, at all. IMHO the worst example is - dare I say it - the Linux kernel. The Linux kernel requires external modules to link to it thus making a legal quagmire. The GPL was suited when Linux was small, but to get widespread adapting (embedded devices and better commercial driver support) it should change to a less restrictive license. (The LGPL's reverse engineering clause would rule it out, but something BSD-like with some restrictions could be nice. And, luckily, tracking down all kernel authors wouldn't be my job.)
Proprietary software is OK, as long as it gets the job done well.
Interface SPecific License (Score:2, Interesting)
Why not have a license that specifically indicates which interfaces may be accessed by programs under which license; the Linux kernel already has something similar with EXPORT_SYMBOL_GPL. It wouldn't change the primary indication of a derivative work, but it would certainly clear up linking issues?
Secondly, the purpose of the GPL seems to be such that anything so much as looking at it without being GPL compatible is against the license ; as such it is the purpose of the LGPL to allow proprietary programs to link with the program in question...
What do we *want* the answer to be? (Score:4, Interesting)
In my opinion, we should say that calling library routines does not make the calling program subject to GPL.
derivative works discussion (Score:2)
Intentionally confusing? (Score:2)
BSD license rocks! .
Not consistent with Rosen's other writings (Score:2, Informative)
In this essay [rosenlaw.com], where he condemns Microsoft's "Shared Source" initiative, he points out (correctly!) that if you so much as look at Microsoft source code, anything similar that you write later could be declared to be a derivative work. (He uses, as an example, the George Harrison "My Sweet Lord" case, in which Harrison was convicted of "unconscious" copyright infringement because he had once heard a song with a similar melody.)
However, in the essay cited in this Slashdot article, Rosen doesn't warn of this danger. What's more, he does not warn in either essay that it's just as much a danger when one looks at GPLed code as when one looks at Microsoft code.
This is an issue which both Rosen and the FSF have consistently ducked. If you look at GPLed source, and later write something similar, you could potentially be sued for infringement and required to release your work under the GPL -- forfeiting any payment you might have been able to get for licensing it. (The GPL requires that you license derivative works "at no cost.")
In short, in the essay mentioned in this Slashdot item, Rosen both omits vital information and fails to warn of a serious danger. Worse still, he shows inappropriate bias: he points out that danger in the case of Microsoft's "shared source," but not in the case of the GPL. This brings his objectivity and reliability as a source into question. His advice to software authors on the subject of copyrights and derivative works should be factual and based on concrete principles. It shouldn't be biased by who -- the FSF or Microsoft -- happens to own the software.
Re:Derviative (Score:2)
Re:Derviative (Score:3, Funny)