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.
..with the clauses of the LGPL, wherein it guarantees the right to reverse engineer the software linked to it--proprietary or no--and that any proprietary license that tries to revoke that right is in violation of the LGPL.
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.
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...
What concerns me is the possibility of one-sided finger pointing. Say for example, that the vendor of a large ClosedSource GUI OS or OfficeSuite improperly understands the intended interface of a OpenSource library, and starts saying "this OpenSource library sucks" (because it does not do things in our preferred proprietary manner) and refuses to supply evidence (their source code) to demonstrate that they actually comprehend the library API and have good intent. This situation would probably make me uncomfortable as an advocate of OpenSource products.
This situation does exist to some extent between vendors of ClosedSource software. It's how ClosedSource library vendors obtain support funding from their (developer) users.
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.
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...
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.
It was only within the last two years a case was decided that "referencing" a function in another (linked) library was NOT the same as inserting that code in place (hence, traditional linking of external libraries was NOT construed as a derivitive work). That could could have easily ruled the other way...
This is just one place where existing copyright law as a concept that makes sense for 16-19th century books, and 21st century software clearly collide. What does one make of C++ (vs simpler C libraries which the above case illustrated), where headers may include inline member functions, transformative templates, and in fact invites the user to "derive" a new class object from the core library? I suspect, current copyright, as it's interpreted would make it IMPOSSIBLE to have a C++ (or Java, C#, or whatever) "application" that does not legally become a derivite work of a class library. What does does say about Java classlibs? Or even using the LGPL for object oriented libraries?
None of these questions have been effectivily answered or even properly addressed as far as I can determine. Certainly they are not in this article.
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.
- 13. more likely to follow standards.
- 14. More likely to BECOME a standard
- 15. Easier to integrate and extend (as opposed to the "embrace and extenguish" or "change then embed" philosphy of a certain Washington based organization)
- 16. encourages interaction of services (see: 13 and 14)
- 17. Encourages good coding and documentation techniques (crapware will become even more embarrasing for big companies)
I integrate various parts and am frankly damn tired of seeing non-library applications... why should I have to actually write code to hack apart a poorly written (hard coded) program suite or end up giving in and not having the features I desire? This crap of companies saying "we use open standards" then actually trashing them through the use of proprietary implemantations of API's and wrappers... how is this considered open standards anymore? Oh yeah, I utilize FTP, SSH and HTTP yet I crap them up so that a remote device must have my particular (read: limited) tool that will probably be forcing features people don't want or would rather have something else do (much less adding to the complexity, throughput and security risk) No thanks, I will stick to real open implementations. Otherwise it is like buying a car that only works on partular subsets of roads, rare forms of fuel (and expensive), has a hard coded yet totally non-standard interface (driving controlls), does not allow me to drive at certain times of the day and all this for a crap load more than other cars... gee thanks!Reminds me of MS philosphy, "Sure you can use our implementation of this... of course you must use SQL server, and of course use Windows (and thus x86 architecture often) and all its buggy and bloated "glory" plus if you want to have office application tie in then you must use MS Office. Oh, did we forget to mention that you must use IE for internet browing, VB for scripting and ASP for embedded Web page scripting?" A good car company sells vehicles by making them better... MS and those like them sell cars by forcing the roads to be changed to only work with their brand of car. This is not "good business" but to many it is seen as so, however their reasons clearly show that they are mistaken from a semantic point of view. I therefore suggest they use the term, "Financially sound business for the short term." After all, our Founding Fathers (evil US) chose to give us freedom and liberty while they could have supported a despotism or dictatorship in order to force everyone to be "free" based on a definition that holds to "protecting everyone from themselves"... you know, liberals! Ahhh, liberals... what a pretty road to hell we pave!
I think the article makes a mistake in focusing the legality of the issue on the definition of "derivative works". While the GPL does cover the allowed uses of derivative works, the issue of 'linking' is addressed seperately. Even if a work is not "derived" from the GPL'd source, the GPL does still prohibit linking to it by commercial products. Whether or not that is enforceable and/or fair is another matter.
Someone else mentioned on this thread that linking to another library was like playing someone else's movie in the background of your own movie without consent. I disagree, if the commercial product is not specifically distributing the GPL'd library as a bundled component, then your situation is much more analagous to selling someone a car and telling the industry they can't make paint that will be used on said car. This is a completely unenforceable situation - you mean to tell me that my call to sqrt() in math.h is in breach of your license because the user happened to have the GNU math.h installed? I don't think so. Not to mention that this is a limitation of the end user's freedoms equal to those of the commercial EULAs to which we so vehemently object.
So while your barking to keep commercial software from even thinking about GPL'd code, remember not to complain when Blizzard can't release the next installation of StarCraft on Linux because they can't spend the time to duplicate all of your GPL'd libraries.
And now I'm going to rant about the GPL in general. You can skip this part as it's not technically on topic.
What used to be a hobby has become a religious movement. This segregationist attitude toward Free and Commercial software will only hinder the adoption of free software. Unfortunately GNU has become such a buzzword that developers are releasing their code under the GPL without fully understanding the limits they are imposing on the usefullness of their code. I also personally enjoy being able to get paid for coding and am not inclined to contribute to a world where that would not be impossible. I also feel that GNU's GPL statement is not made in the interest of the world at-large, but instead in the interest of spreading the name of their particular clique.
I prefer to use my talents to contribute to the world instead of a particular group. That means producing code that is usable by both individual developers and corporate entities who wish to use their resources to make greater improvements. Providing this freedom does not allow a corporate body to steal control of the project from me any more than forking my own branch of the OpenBSD kernel allows me to steal control of OpenBSD from Theo. Indeed, it gives me even more leverage over those that use my product as a recognized producer of worthwhile software.
To those of you pondering how to release your own works I would pose a more extreme example; would you want advances in cancer research to be licensed as off-limits to coporate entities? How quickly do you think that would kill all research in that area?
The point of the whole matter is whether or not we want our libraries to be used as a standard or not. The more open the source is, the better we are all off in the end. I can agree that, ideally, applications that use open libraries should be open themselves, but the LGPL would not have been made if there wasn't some good in allowing for proprietary code. -Kp2
Take the white suppository, and I'll show you how deep the rabbit hole goes...