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?
"
Derviative!! Gah! I know its only two characters transposed, but it sounds so messed up. Remember, always, no wait, never.... no, always click on the Preview button first (especially editors)
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!
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
It is either encumbered, or unencumbered.
A benevolent dictator is still a dictator, and you are still not free.
the work derives from previous code
geeks and nerds rejoice
RMS picks crumbs from his beard
microsoft profits
Trolling is a art,
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.
It looks like... the GPL needs to be amended.
if I GPL my turds, do corn farmers get to claim prior art?
Trolling is a art,
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.
maybe she's actually a he and he's actually drdink
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*
Correct me if i am wrong but the GPL gives you the right to the source code so you can tweak the code to make it work on your own machine. That being said If Microsoft decided to use the GPL'ed Libraries (Or any other large Closed Source Code Shop, Yes Oracle and Sun and Novell I am looking at you) wouldnt they be in violation of said License Agreement? Thereby giving the FSF a legal case? Now if these big companies would use the Libraries and then give the source code for distrobution, it would be easier, and I would look more kindly upon it. But since that will never happen, I can not support this, and will fight against it, and join whomever else is against it. --
---
There are as many reasons to use the GPL as there are open source developers ...
Regardless of why people want to use the GPL they will all agree it has the basic effect that any project which depends on GPLd code and is distributed with it should also be GPL.
We all know what the GPL is supposed to result in, only a lawyer would find it difficult to understand.
Steal her monitor. Give her a 15" -- clearly that is all she needs...
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.
The classic case of GPL abuse being TrollTech. They have attempted, through lies, subterfuge, organised rah-rah campaigns everytime Qt is mention on Slashdot and theft of other's code to make their dire little C++ library an integral part of the Linux desktop. Thus allowing them to act as gateway and Tax collector (approx $2000 per-developer, for the moment... a large increase is expected soon) for any non-open source desktop apps moving to Linux.
Of course, they haven't managed this yet. You can prevent it by not using KDE (no great loss to be honest) and instead using GNOME. GNOME libraries are licensed under the LGPL, allowing free use by anyone under any license. You can also help by fighting back against the shills filling slashdot with propaganda and lies -- and the "useful idiots" unknowingly spreading shite in their desperate attempt to rescue KDE from eventual obscurity.
What is RMS's stance on whether linking to a GPL binary invokes the GPL, anyway?
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.
This is what you'd consider a target rich environment. These people need to know why they're all wrong. Come on, teach us some stuff!
I assert ownership of all trademarks and copyrights on this page.
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
I think we all know what the GPL is supposed to mean, for people who cant see through the legalese it is clearly described in the FAQ on the GNU website ... the justice system might not allow a license to distribute to have the kind of reach most of us would like it to have, and that would be a crying shame, but that is a different matter.
... now I dont know what the deal is with OSL, but if he doesnt understand that the VAST majority of people who release software under the GPL intend for any software which is linked to it and distributed with it it should also be GPL (yes it is that simple) he is a fool.
... what are his true intentions? Why is he pretending there is a lack of clarity from open source developers who use the GPL when there is none?
Mr. Rosen says he is worried that lack of clarity will stand in the way of proprietary software users embracing our software
We can however be relatively certain he is no fool, so that makes you wonder
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.
any other license agreement.
MS EULA, Borland license, anything.
Is this what a straw man proposal means?
payper liesense hostage ransom stock markup FUDgePeddlers, up on the pacific crest.
nice won daze 10% "haul", so far today. happy gnu year? i DOWt it. george/bill/robbIE et AL, must "partner" to revive/re-incarnate the evile larcenious "bull", lest fuddle's owned "gnu" poutoll go under, in a wash of MiStrust/bank fraud investigations. so IT goes.
look for: va.msn.net, ticker symbol (VAST)?
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!
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.
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.
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.
A library of objects is by definition (or certainly should be by design) intended to allow derivation via inheritance.
So, should you be in the clear if don't don't modify the objects provided via inheritance and additional functionality, just use what you're given ?
For me this is a grey area. If I developed and released an open source library of objects (wish I had the time), I'd certainly *like* (I know I could demand) generically useful enhancements to be open sourced in order to enhance the library, however as a proprietary developer who uses open source where applicable and legal, I am in a position where any enhancements I might make to such a library would have to remain proprietary.
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.
open-source software and closed-source proprietary
programs.
The fact is that I would like to use the same
libraries in both cases, because I don't want
to spend my time learning different APIs.
That's why I like LGPL.
Regarding the notion of derivative work: if just by linking to a library your program can be considered a derivative work from the original library, then there isn't really any piece of original software except the linux kernel (or windows kerenl).
Even the kernel could be considered a derivative work because processor instructions make calls to the processor internal microcode/nanocode and that could be considered a form of linkage.
Intel: all your base are belong to us.
In that case, Microsoft would have legal rights over any program that Runs on WIN32 because any such program is linked to the kernel/DLLs and
every Linux program would have to be GPLed because
the Kernel itself is GPLed.
Check these out:
GNU FAQ
FSF Endorses New GPL+Webservices License
Where the binary goes, the source must follow.
well, it doesn't have to follow, but it has to be available to the end-user of the software.
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.
IMO, we need to have the equivalent of an open/free software constitutional convention to write a new GPL. It needs to be as wide-open a process as possible, without generating into an endless food fight, and it must produce a license that virtually any software developer or user, or manager or a software user or develop, can understand after a single reading.
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.
The GPL FAQ is fundamentally dishonest. Why doesn't it just say, right up front, before the table of contents: "If you don't want to give away everything you create, for free, and also all the source code, again for free, fuck straight off to Pluto, because the GPL is your sworn enemy."
All the true believers would stand up and cheer, and people trying to make a buck wouldn't waste their time on the Obfuscated RMS Philosophy Contest.
It's so simple: you want to get paid, you pay for the tools. If you don't want to get paid for whatever reason, fuck around with free software. There it is.
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.
Suppose I have a script for a play.
I modify it by adding a character/villian
and leaving everything else the same. This
is a derivative work of the original play.
But, the modified play is NOT a derivative
work of the wooden pencil or typewriter
used to type out the new play. They are
tools (like software libraries) orthogonal to
the work itself. The typewriter company does
NOT get royalties for the derivative work
that was created using that typewriter.
The fact that so many are opposed to using any sort of non-free software with free software might miss the point that besides the underlying error of ethos, actions derived from those thoughts will make it much less likely that proprietary shops will either A) work with standards and B) release their own API's, libraries and the like free of charge (not to mention being cross platform and application dependent). Its like watching little kids make their pathetic little cliques. By clearly saying that non-free software cannot even LINK (static or dynamic) to free software you first and formost limit the choice of users. Thanks a lot buddy, but if I want limitations I will stick with Microsoft and Sun.
Why dont I care? Linus made Linux as a Unix wannabee. It was "fun". He took and mutlitated Minix till even the Minix engineers said it wasnt theirs. Simply, it was HIS toy.
Times passes....
Lots of people like it and donated time, knowing the newer licensing was GPL. Donaters didnt care. If they did, they didnt donate.
Now...
Now companies use it quite a bit, in one place or another. You have Linux fanboys bitching about binary-only drivers when they should be jumping for joy that they are even recognized that Linux exists. Then there's, of course GPL biching-- BSD vs. GPL. Feh. That's why companies have Layers on demand: they should be able to tell what a license is, how it affects business, and wether to use it, and with what.
Companies should consider ramifications wether to deal with the Linux kernel (GPL) or make their FUCKING OWN KERNEL. That's the cost.
DEAL WITH IT.
end of rant
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.
Let's face it, a lot of proprietary technology is damn good. BeOS still in many ways (as an OS only) rocks Linux's world as a desktop. And that's really funny because there's been no official updates in 2 years and it was a closed source product. ICC whips GCC in x86 peformance. .NET and Java are proprietary. And don't give me that shit about programming in PERL or C beating both hands down in anything other than maintainence and system-building respectively.
If you lock out closed source vendors (surprise, surprise, they're not all evil!) they'll lock you out. They won't promote Mozilla, OpenOffice, Apache, etc. Does it occur to you rabid numbskulls that they might actually put some of their guys to work helping the library builders fix bugs, port them to new platforms and stuff like that? I bet you'd object to Apple writing a native GLIB/GTK clone for OSX and releasing it under the BSD license so anyone can use it.
GPL advocates seem to be more and more like "punks." A bunch of elitist fucks who are just a low-budget version of what they hate.
Click here or a puppy gets stomped!
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.
- 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!
Free as in, "Do what I say, how I say it and you will LIKE IT!" Ahh, liberal agenda and its hypocritical notion of "Freedom through tyranny."
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?
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.
And with good reason. If you allow this a company could take *any* GPL code, re-write it into a library form which is itself GPL (trivial), and then link to that library because it is allowed by that second point.
There is a good reason for the distinction between GPL and LGPL.
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.
We all know that RMS intends the GPL to prohibit the distribution of proprietary software that links with a GPL'd library. What is less clear is whether or not the GPL can actually accomplish that. Mr. Rosen's article merely discusses the legal issues.
The GPL is only relevant when you distribute GPL'd code or a derivative work. (See paragraph 5 of the GPL: You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works.) For the sake of simplifying this conversation, let's avoid distributing the GPL'd code by using dynamically linked libraries. Then we can focus on whether or not a program that dynamically links in a library is "derivative".
Mr. Rosen maintains that it is not, which is clearly at odds with RMS' position. I personally agree with Mr. Rosen. I also feel that RMS' view is hypocritical. Code which makes use a a library is only dependent on that library to the extent that it supports an interface. It is not dependent on the specific implementation of that interface. Remember, the idea is not copyrighted, only the specific expression of the idea. It is this freedom to re-implement that allowed the FSF to reimplement many of the UNIX and libraries while preserving the interface. The first version of many GPL'd software packages were almost certainly originally linked with proprietary libraries. Does this mean that they are derivative works? Is the whole FSF code base tainted by that first linking? Does my code stop or start being derivative because one user dynamically links it with a GPL'd library and another does not?
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
if you love then protect it(and please be there in person to protect it).
Read it here!!
As the GPL license grants an unusual high level of rights to its licencesees (right to redistribute, change,...), the conditions under which these rights are granted are very stricly to be followed.
Section 2b clearly states:You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
This clearly means you cannot link your proprietary program to a GPLed library as it is including a part of the Program. SO MISTER LAWER IS ABSOLUTELY WRONG!
But, on the other hand, one can for example make out of a GPLed program a GPLed version which has a plugin architecture or allows some kind of communication with another program which is not GPLed.
Then a company can make a proprietary plugin to be used with this GPLed plugin-aware program. The combination of the two can then be distributed, and the goals of the capitalist company reached. But it is very important that the plugin-addition to the GPLed program is released under the GPL to not violate the GPL.
Clearly they have to be completely seperate code bases.
As a reminder for the new kids: this is why the choice of Linus to not allow proprietary kernel modules is a personal kernel-maintainer policy and not something automatically delivered by the GPL. Personally, I think it was a great decision which annoyed quiet a few companies (something which hardly ever hurts)
You are free (GPL) however to branch of the regular kernel tree with a seperate one who does allow proprietary kernel modules. But the success of your move will not be very likely (unless you're a maybe a company such as Microsoft).
Am I afraid of such a potential Microsoft Linux? Nah, it would make life a lot more simple and be a big step forward for the spread and adoption of Open Source software. I just hope that some of you guys wouldn't act too emotionally irrational, I guess it's a natural move.
Even Apple has a UNIX kernel these days! Why does MS always have to be the last to adopt great technologies?
How does Rosen propose to explain Micro Star v. Formgen? That case held that new map files for Duke Nukem, which included no portions of the original map files, were derivative works of DN because (among other reasons) they incorporated *BY REFERENCE* textures from DN. How is this different from dynamic linking?
Comment removed based on user account deletion
Then what are the implications for Cygnus, which requires one to pay for propriatary use of Cygwin.dll, while making it free for GPL code? I have always both admired and loathed this scheme as a professional developer.
But if linking to the dll does not make it a derivative work, Cygwin's dual licensing scheme seems to fall apart. There is no need to pay Cygwin anymore to protect your code from the GPL requirements on a derivative work!
-ralvek
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.
What if the end user does the linking?
m ic_link.html.
How can he be in violation of the GPL if, ONE, internal use is unrestricted by the GPL(?), and TWO, the end user doesn't even have the source code available?
Steps to "downgrade" a GPL'ed library to LGPL and keeping your source code a secret would therefore be:
1) Compile (and don't link) your code to object code.
2) Supply end-user with the object code (without source code) together with instructions to download the GPL'ed library and link it with the object code (statically or dynamically doesn't matter). A batch file could even do this automatically for convenience.
3) The mandatory "Profit!"
The only act which could be argued to be a violation is the inclusion of a header file by the author of the object code, but that is just a specification and an interface to the real part of the library (and claiming restrictions in using that is to me just as evil as software patents).
Add to that the possibility of linking with a different library instead (which could even be written LATER ON just to ridicule the whole issue) and it seems clear to me that the GPL and the LGPL are not only MORALLY EQUIVALENT, but LEGALLY as well.
Finally I would ask if anyone actually know of ANY specific example of a LGPL'ed piece of software which was "abused" in a way which would not be possible under the GPL.
Partially inspired by http://www.brouhaha.com/~eric/editorials/gpl_dyna
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.
GPL:ed software is NOT free to copy.
Since it is copyrighted you are NOT allowed to distribute the code.
However, if you make an optional contract with the author of the software, you may redistribute it. But you are then bound to the terms of the contract between you and the copyrightowner.
This contract really has nothing to do with copyright law.
There are terms in the GPL concerning patents. If there are patents prohibiting the user to use the software without a fee or other obligation you are not allowed to redistribute the software. This since it is not possible for you to give the proper freedom over the software as stipulated in the contract with the copyrightholder.
My interpretation would be that you could be in deep shit if you redistributed code for creating gifs with patented algorithms. You party in your agreement could claim breach of contract as you gannot give the users the right to use the software freely. The copyrightholder of the GD-library *could* sue you for redistributing their code since you cannot grant the correct freedoms required by your contract.
Even BSD-licenses are copyrighted requiring a "contract" to redistribute or modify..
The only option without the "contract" is Public Domain AFAIK.
(Yes. I am aware of that contract is a poor word. Agreement would be more correct but not as illustrative)
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.
No one, it seems, has any idea what the GPL was intended to accomplish.
1) Insure that software source code was distributed?
2) Prevent such source code from being used in proprietary (i.e., source code NOT distributed) applications?
3) "Prevent people from profiting" from source code (distributed or not)?
4) Use copyright to subvert copyright?
Clearly, there is no definitive answer here or anywhere else. I read through the GPL and still don't understand the nuances. I do understand that it says they have no problem with people charging money for software. That would seem to let out all the "don't profit" or "free as in beer" people...
What isn't clear is why, having said they don't care if people profit from code, they set it up so that apparently people CAN'T profit from code even if they distribute the code (of the GPL'd source, not the proprietary souce).
I submit that the GPL is a contradictory piece of crap like everything else in the law and that the goal of using copyright to subvert copyright has merely reinforced copyright by making it too hard for people who might otherwise use open-source code to use it.
This restricts open source's applications and conflicts with the whole point of open source which is, IMHO, to better software technology and its uses by people by allowing source code to be obtained, analyzed, modified, and used by anyone.
Distinguishing between "anyone" and proprietary companies makes no sense. Who cares if Microsoft uses GPL'd code in their products as long as the GPL'd code source is provided by them (but not their proprietary code - unless they want to).
If the goal is to REPLACE proprietary code with open source code everywhere by using a licensing "trick", then fine - a lot of people simply won't use GPL code. Which will restrict GPL code's penetration in the market, which is obviously counter to the idea that it should replace proprietary code. So the "trick" has failed...
Which again demonstrates why reliance on a coercive process like the law does not serve the cause of freedom...
Open source code should compete with proprietary code on the basis of technical and economic superiority and nothing more. Therefore the GPL and all such licenses are no different than patents and copyrights - unnecessary interventions in the free market by the state.
If you want freedom, pursue the path of freedom - don't rely on coercive "tricks" like a new form of copyright...
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
Iraq Peace Team
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...
what is relevant is the author's intent.
An author of software gives rights to software's users by selecting an apropriate license. Motivation can be fame or fortune, political or practical. And all of the above are ok. What's not ok is saying that someone who released software under GPL actually meant LGPL. He meant what he meant!
Different licences give authors different levels of control, they attract different users, developers and supporters, have different comercial and political implications... Choosing a license is like a bet. It may backfire, but the choice should be respected.
-- forgot my nick
Static linking will not work with GPL.
If you are distributing a non-derivative work, GPL "and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License"
So, even if the work is non-derivative, GPL binds it. Just find a LGPLd library, if you feel troubled.
I remember reading on the kernel mailing list about Linus' comment on derived work. Essentially, if I remember it right, Linus explained that if the companies/developers can prove to the court that the program is NOT derived work, it doesn't matter whether it links to the GPLed libraries or not.
Now how can it be accomplished? This is one possible scenario:
To prove that such program already existed on a non-GPL platform: eg: Windows or Mac OS X. The existence of such program is a lively example that it is original on its own, for instance some non-GPL file system and other programs ported from Windows. As far as the _extreme_ logic goes, this is still dependent work - call it derived if you like, but its sole existence on other platforms proved it is original in a _common sense_. So which point of view the court will be convinced of? Go figure.
Personally I will be very amused if the program becomes derived work simply because it is ported to Linux using some GPLed libraries over there. If this is the case, no commercial software or games might be interested in the Linux platform. And the interlinking between libraries (such as SDL calling ALSA/OSS and Xlib and such) will becomes pretty messy - since they might use different licenses. Perhaps people will need to call for more dual license (GPL+LGPL) if they want more software for the Linux platform, otherwise it could prove to become self-isolating and self-defeating, to certain point.
To me - a compiler with appropriate libraries for a language standard combine into a single tool.
:p
When I build a desk and use a Craftsman hammer and a nail from the Home Despot, my desk is neither a derivative work of Craftsman or the Home Despot.
If I include stdlib.c while writing software that runs under Linux, my program is not a derivative of GNU's work.
Sure, GNU may have written the C libraries for Linux that fit the general standards of C.
However, if we want to play the blame game - Oops, those GNU libraries are a derivative of the work done by the people who came up with C.
If we keep going back far enough, we find that everything computerized is a derivative of the work of Babbage.
Who here can say with veracity that I don't have Babbage's permission to write programs?
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
Mr. Rosen however wasnt making a legal arguement ... he was discussing how open source developers should be clear about their intentions so they wouldnt scare proprietary software users away.
... we do not need mr. Rosen to reiterate that.
GPL developers on the whole are crystal clear however about their intentions.
That the GPL might not reach its intended goal because judges (NOT lawyers) will not let copyright law extend far enough has been known for a long time