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?
"
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!
Derviative is derived from Derivative...
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
..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"
If the free software project is smaller than what your boss is doing, your boss's project is a derivative of the free software project, which can stay open.
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.
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.
Really? Name five. Let me get you started:
1. It's probably gratis.
2. It offers an alternative to Microsoft.
Please, continue.
-
Inventor of the term 'pardon my French'.
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.
1) No one need worry that linking to GPL'd works will force them to release their source. That can't happen. At absolute worst they might be required to destroy all copies of the infringing derivative and pay damages.
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.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
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?
Roving Web-Teleoperated Robot
Seems there are two camps in the world in terms of using open-source libraries, such as GPL licensed libraries, in proprietary software.
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
Larry, this post you did (if that's really you, because I don't recognize any digital signature in here) is a graveous disservice to us ALL.
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.
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.
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.
As I read the GPL Rosen's wrong. A GPL'd library can not be used in non-GPL software, here's one reason:
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.
Look a monkey!
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"
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.
You should see today's "daily digest" on the kernel mailing list. It gave me a decent heartburn to wade through a few hundred K of advocacy, in between bits and pieces of code. The code is pretty cool looking, btw.
C|N>K
To distribute a work, with the included GPL code would require licensing under the GPL.
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.
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.
Some people argue that inclusion of the header files makes something a derivative. This is utter nonsense.
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.
If you distribute GPL code under terms other then those the GPL allows you are committing a copyright violation.
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.
If the GPL was clear as to linking is a derivative work people would avoid using GPL code. But they want the exposure in order to claim large numbers of GPL code users. It also give them a trap to spring some day, the same way some companies patent software, but not announce the patent till useful to do so.
BSD license rocks! .
In this essay, 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.
My argument is twofold: a) Microsoft is aware of and probably covetous of some pieces of OSS software and b) there are a number of writers of GPL software who do not want Microsoft to ever commercially exploit their work.
Their use of the BSD stack is a good example of their attention to the OSS field. BSD will have to do for now, because if anyone had proof of Microsoft's use of GPL software in one of their proprietary programs, there would probably already have been a lawsuit.
If dynamic linking == deriving...Why wouldn't invoking microcode be deriving? Wouldn't Intel be able to claim that all GPL'ed code compiled for an Intel chip was derivative of Intel's processor instructions and their code? It certainly depends on the presence of code written by Intel in order to function, even if it could be run on a chip without Intel's code (just as a program that relied on a GPL'ed library could be run against a any functionally equivalent library) . I haven't seen any theory that suggests a legal difference ...
Take two scenarios in books:
Which of those uses would be a derivative work? The first corresponds, IMO, to static linking, the second to linking a shared-object library. I'd guess the courts would consider the first to definitely be a derivative work, the second not. Note that in the article's quote from copyright law, it explicitly says that annotations and elaborations are derivative works and those can be done without modifying the original.
Even if it isn't a derivative work, the same line winds up being drawn. If it's not a derivative work, then the license for the original library (the GPL) still applies to it. Since term 2 grants the right to modify the copy the recipient received, you could argue that if the recipient cannot modify (by modifying the code, recompiling and relinking) the copy in your program you're not complying with term 2 of the GPL when you distributed the library as part of your program. I'm sure the lawyers would love to argue that in court, it'd provide endless billable hours.
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 GPL only applies at all if the work is a derivative work, as it gets all of its legal authority from copyright law. If a program that uses a GPL'd library is not a derivative work then it doesn't matter what the GPL says about use or redistribution because you are not bound by its terms. Since this is a legal issue and will be resolved only by sufficient case history, it will ultimately be exposed to the test of what a 'reasonable person' would think several times before there is sufficient precedent to make a strong argument for either position, making it a matter of public opinion whether your proprietary program is a derivative work or not. When that happens, the decision can go either way because even programmers are often uncertain of whether something is a 'derivative work' or not. Only copyright law restricts your ability to use the code however you want, and it only applies if certain legal conditions are met.
Does merely linking to a program without any change to the original source code create a derivative work of that program? Almost every program links to library routines. Surely, one doesn't create a derivative work of a library simply by calling a sqrt function in the library. Why should it be any different when you link to something as complex as an enterprise server or database engine? What about linking from a software program, such as when linking your device driver into a GPL- or OSL-licensed program like Linux?
Very good questions indeed! They point out the futility of applying something like copyright to software in the first place. Until the law catches up, we must use its flaws to promote free software.
This is not a dificult proposition. Many confusing and silly things have been written above by those who wish to write propriatory code. Bah! Free code can and does call non-free code. Non-free code can and does call free code. It should be obvious that a VB script that calls M$ Word and types "Hello World" can be GPL, though it exists at the mercy of greiviously non free software. Conversly, someone could write a silly CLI porgram that prints a menue and parses input to GNU find and grep and call it easyfind. The only real question is, why bother? Do you thing you can sell it? Someone will write a free version if they have not done so already.
All of those silly people who would like to plunder the free world to support their abusive and failing software model can simply sick it. Go away, I don't appreciate the way your companies do business, don't need your work, and don't ever think I'll link to it. You can't have your cake and eat it too. The same things that would happen to me if I tried to sell my Hello World program on a CD that contained M$ Word will happen to you if you try to sell a CD that includes binary only grep. Well, not really, you could just make the source code to grep, including your modifications, available and all will be well.
Friends don't help friends install M$ junk.
Other legal concepts than 'derivative work' can be applied to limit closed-source exploitation of open source programs. If I write a program that needs a GPL library to run, that doesn't make my program a derivative work of the GPL library. But the GPL license on the library can still prohibit me from distributing the library with non-GPL code, derivative or otherwise. I'd have to tell my users to obtain the GPL library separately in some dynamically linkable form, tell them to install it, etc, etc. All that, along with fears of version mismatches, etc, would pretty well kill my application's chance of commercial success.
The GPL only applies if the work is a derivative work. And this is NOT decided by what the GPL defines, but by what caselaw aimed at books will eventually decide. Copyright law is the only thing that restricts your ability to use the code however you want. If copyright law applies, then you must abide by the terms of the license and agree to its definitions. But if copyright law does not apply, then you don't have to care about the license at all.
In general, I believe that references to linking in the GPL refer to operations of the linker (ln) either static or dynamic. In the case of Java, look at the analogous situation.
Does the Java app depend on the class in the same way a c program depends on a library? If so, it's linking.
I'd guess that runtime class binding is like linking. The XML/HTTP/SOAP case probably isn't.
A good rule of thumb would be if you had to use a componant of the GPL work that is not part of the binary package (or normally copied elsewhere by make install or in the INSTALL instructions), it's probably a derivative work. If you had to change it to make it fit into your software it's probably derivative. If you made a heroic effort to avoid doing the above out of fear that it would be derivative, it's probably derivative! Otherwise, you're probably O.K.
I do see your point though. It might be a good idea to contact the author of the work (or the FSF) for clarification on that point if it comes up in the real world.
The problem is, copyright law (and much of the law in general) is based on loose definitions (such as would a reasonable person... where reasonable is not, itself, defined) that tend to make technical people cringe. It doesn't help that technology evolves much faster than law. There wasn't much JIT compiling and run time type checking by a VM that incorperated the linker (or rough equivilant) going on when the GPL was written.
Licenses assert restrictions on the use of a copyrighted work. The question comes down to whether any shrink-wrap, click-wrap, or "embedded" (e.g., the GPL-ish) license that asserts "unusual" use restrictions is enforceable.
IANAL (but I find this subject interesting) so take what I say with a grain of salt. While the RMSs of the world may wish to sweep away proprietary software with "viral" licensing, the courts will be loath to support such activism. Proprietary software and the legality of creating even competing products using someone else's libraries is a well established precedent. Given this, most judges would probably agree with Larry Rosen's interpretation of what constitutes a derivative work and only extend GPL disclosure requirements to those who actually modify GPLed code and not to people who create works that use GPLed code unmodified.
On the other side of this issue, a judge is also unlikely to uphold some of the unusual requirements folks like Microsoft have been ptting into their EULAs. Interpretation of law is based on precendent which is another way of saying that laws are *usually*interpreted to mean what people think they mean.
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
The rule in music is 12 consequitive notes. My guess is that the line was pretty complex and so I'd assume you probably did violate the license.
The GPL doesn't contain the word "link" or anything like it. Take a look. It's only mentioned once very briefly in an epilogue recommending how the GPL should be applied to new software.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
3) It allows you to safely collaborate with potential compitors.
This has been the key advantage of GPL over BSD for many companies. SGI for example could safely release XFS under GPL because they know that any improvements to XFS would have to be returned to SGI. The types of people that would be willing to spend time and money developing a better file system for very large files are exactly the types of people who might compete with SGI. OTOH all of them benefit from being able to share: knowledge, experience, technique... it creating enough of an added value to get their customers to upgrade.
4) It allows you to use other GPLed programs easily and safely.
GPL is rapidly becoming the single most heavily used software license; using other licenses with programs drawing from multiple sources often results in complex legal issues.
5) You want to eliminate an artifical economy based on intellectual property.
I.E. why should things that are cheaply reproducable but difficult to construct initial be sold on a cost per reproduction basis? It would seem much more logical to raise money for the initial effort in some other way.
The interest of Linux becoming the majority operating system; and the interests of FSF in changing the way software is written and used are very different. It is easy for me to imagine commercial distributions filled with propietary apps running on top of the Linux kernel. Its also possible for me to imagine the whole range of GPLed software running on top of an entirely different kernel; perhaps even something very different than a Unix (like Eros).
What's best for Linuxes widespread adoption and what is best for the GPL's widespread adoption are not similar criteria and very well might disagree more than they agree (though I wouldn't go this far). As an aside you can even say the same things about Linux vs. Unix. What's best for Linux becoming a heavily used desktop OS may not be good for Unix (traditionally a developers OS). Already the tension between what's needed for mainstream acceptence and features that make Unix such a wonderful environment (like almost all files all being streams of ASCII text which can be piped to one another) are conflicting greatly.
That's actually another good point in favor of the more restrictive GPL interpretation by courts. Given the existence of the LGPL and the fact that both licenses are well known to the same people a developer choosing to release under the GPL could be said to be actively requiring the more heavy restrictions as a requirement of using his code.
I knew you could.
I have discovered a truly marvelous sig, unfortunately the sig limit is too small to contain i
From the GPL FAQ:
If a library is released under the GPL (not the LGPL), does that mean that any program which uses it has to be under the GPL?
Yes, because the program as it is actually run includes the library.
Do you think Neverwinter Nights is going to link to any GPL-licensed libraries? I'd love to get my hands on the source code for that...
I think the point is that in some ways dynamic linking could be considered to be similar to citing anothers work in a new book you are writing. An essay on "Wuthering Heights" might just be uncomprehensible if the reader had never read "Wuthering Heights". **
;-)
One could use small fair-use quotations, but that may not be sufficient to discuss the twists in plot that occur over several chapters, etc. and therefore one simply cites "pp120-150", effectivly creating a dynamic link into the book. The citation may even be larger than the entire text of the essay but the essay isn't a derivative work of the book. Dependant, yes; derivative, no.
**(a better example might be "an essay on victorian romance", which happens to use "Wuthering Heights" as a major reference. This avoids the question of when an essay becomes a condensation or "Cliff Notes" for the book.)
Disclaimer: I've never read "Wuthering Heights."
McFly777
- - -
"What do people mean when they say the computer went down on them?" -Marilyn Pittman