Derivative Works And Open Source
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?
"
So we're supposed to pump out open source libraries so that giant companies like Micro$oft can write proprietary applications around them and profit from our labor? Would they like us to polish their boots while we're at it?
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.
Karma: Good (despite my invention of the Karma: sig)
Very interesting topic, and I'm sure some big fish (M$, Sun, etc) will have a LOT to say (donate $$) about this... if it goes the "non-modded is Non-derrivative" way, then M$ et al can pile in GNU stuff at will as the foundation of proprietary OS / Software.
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)
Department of Homeland Security: Removing the rights real patriots fought and died for since 2001
do we consider libraries to be part of the OS or the program?
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.
In SOVIET RUSSIA... erm...NSA AMERICA, the Internet logs onto YOU!
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
Since programming while whirling is very hard to do without felling very seasick, few Dervishes ever manage to become good coders. So, Derviative works worth the trouble are rare and far apart.
I've contracted for multiple fortune 100 companies and personally installed 1000's (literally) of GPL'd modules onto their server machines. Those modules are all critical components of their mission critical software. It would have cost tens of thousands of hours to make the software function without the GPL'd software. But you know what? These companies don't have a clue what GPL even means. As far as they are concerned, the GPL software is just free.
Sex - Find It
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 or senator. 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.
KMSMA (WWBD?)
I wish there was some there was some way that I could be outside playing basketball, in the rain, and not get wet.
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 from gnu.org.
I myself have written popular Java libraries 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.
This argument is certainly nothing new; at issue is whether merely linking to a library creates a derivative work. IME, it would be a really bad thing for open source and free software if this was the case, despite the short-term impact to proprietary software makers.
.NET APIs? Here, sign this contract, in blood if you please. And don't even think of GPLing your program.
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
I hate to sound like a Microsoft Shill... But is MS really the issue? Last I looked MS had about 10,000 programmers. And I REALLY doubt that MS needs Open Source to make them successful.
I like Open Source like the rest of us, but we really need to get over the MS (chip on the shoulder)....
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
A good overview of the issues.
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*
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.
That this is a complete mess, legally.
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.
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?
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.
Lawrence Lessig is my personal hero.
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.
Let me rephrase your first two and move on:
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.
Regarding point 2, where the GPL expressly forbids it. The question is can the GPL actually do that. The problem of the GPL in that instance is that it forbids something that cannot be clearly defined. For example it is allowed by the GPL for you to create an executable and call that executable from a propriatary program. In legal terms how does that differ from doing a library call? Ok at a technical level HUGE difference. But what I think the person was arguing is that at a legal level that distinction is not so clear.
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....
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
I'd like to suggest a pragmatic approach: What definition does more to advance the cause of promoting the use of open-source systems? If we say that linking to system libraries makes an application subject to GPL, we can expect the makers of proprietary software to avoid open-source platforms in droves. This would help M$ to maintain the "applications barrier to entry" that has so far discouraged many people from switching to Linux.
In my opinion, we should say that calling library routines does not make the calling program subject to GPL.
I thought the original intent was that the GPL'ed program can always be fixed or enhanced by one who wishes to do so.
.o file. The source pieces do include some Linux headers. But the essence is that one can fix/enhance the GPL'ed parts of the system, and then rebuild the nVidia drivers with the components they have given.
.o files are a bit more accessable than executables, hence the obfuscation.
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.
The living have better things to do than to continue hating the dead.
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.