Slashdot Mirror
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?
"
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
I wish there was some there was some way that I could be outside playing basketball, in the rain, and not get wet.
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*
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.
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?
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...
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.
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.