Posted on 05/26/2004 9:21:39 AM PDT by ShadowAce
The copyright laws give an author exclusive rights to make derivative works. Creating a derivative work is a copyright infringement absent some license from the author -- or current copyright holder -- of the original work. Software is no different.
Most of us are afraid of getting infected with a virus, whether it comes from a common cold or an attachment in our e-mail. Are open-source licenses viral in nature? Can they infect downstream users? The question is the subject of considerable debate.
Companies refer to open-source software as "potentially viral software" in the end-user licenses that accompany their proprietary software. The end-user license includes limitations against using the proprietary software with open-source licensed software. On the other hand, advocates of open-source licensing argue that drafters of those end-user licenses have a vested interest in creating fear of using open-source software. Just as a computer virus cannot jump out and infect a person, license terms that apply to one software program cannot simply jump to another software program.
The viral nature of open-source licensing nearly always applies to the General Public License. This is in part due to the terms of the GPL
and also partly due to the position statements made by the authors of the GPL.
The GPL contains "constraints against constraints." For example, section two of the GPL allows for modifications and distribution of a GPL-licensed work if the licensee causes any work to be licensed as a whole at no charge to all third parties under the terms of the GPL. This is often problematic for companies that need to distribute their products using a license that is not consistent with the GPL. Such a company might worry that GPL license terms would spread from GPL software to its developed software and prevent the company from licensing under a proprietary license or other license inconsistent with the GPL.
The downstream constraint against restraints is intentional. The authors of the GPL -- the Free Software Foundation, or FSF -- think of it as freeing the software. The FSF position is that all software should be "free software." It should be licensed such that it is freed for all who might encounter it without constraints. The only exception is a necessary constraint against downstream recipients adding their own constraints to the license terms. The FSF refers to this as "copyleft." Those same authors also argue that all software should be licensed under such free software licenses because it is morally wrong to do otherwise.
It is worth noting that any license-propagation capability of the GPL is also a capability of any other software copyright license -- and any copyright license, for that matter.
The copyright laws give an author exclusive rights to make derivative works. Creating a derivative work is a copyright infringement absent some license from the author -- or current copyright holder -- of the original work. For example, suppose I wrote a screenplay from a book, and then a movie made from my screenplay was shown in a theater. The screenplay is a derivative work of the book, and the movie is a derivative work of the screenplay. Each of those derivative works and the public display of the movie in the theater must be licensed -- else they would be copyright infringements of the rights of each upstream contributor. Depending on the license I obtained, distribution of my screenplay could be constrained.
For example, suppose I obtained a license from the book copyright holder requiring me to pay a certain royalty and to limit public display of the work on Sunday. The limitations would apply to me and to all downstream licensees -- the movie studio that licensed my screenplay subject to the book license and the theater that licensed the movie from the studio for public display. As should be apparent from the above example, the movie is not "infected" by the book license; that is just the way licensing works.
Software is no different. If I create software that is a derivative work of your software, I need a license from you to copy and distribute my derivative work. However, if my work is not a derivative work under copyright laws, you have no right to exclude me from copying and distributing my software, so I do not need a license.
Of course, you might have some other ways to limit my actions, such as a trade secret right or a contractual right. Contractual limitations that reach beyond copyright rights are common in software license contracts. For example, the shrink-wrap contract might include a license to use a software package but preclude reverse engineering or require other limitations that one party might impose with the other party's consent. For contractual limitations to apply to a software user, the user must have assented to the contract. Notably, the GPL and many other open-source licenses are not contracts requiring assent, but rather are licenses granted.
If the software system is not a derivative work, a copyright license is not needed unless there is some other relationship between the parties that creates other obligations. This is true regardless of the nature of the licenses obtained for the prior work. This is also true regardless of the opinions of the author of the prior work. Contrary to what some operatives might want us to think, the GPL and other open-source licenses do not have some special magic feature that allows them to infect other software. They have license limitations that apply to derivative works, just like any other copyright license.
If the license limitations are not acceptable, whether it is the GPL or a restrictive end-user license, the choice is to avoid using that software or to negotiate a different license.
![]()
Tech Ping
"The solution:
"Write your own f***ing code.
"Seriously, as long as you don't look at (and become tainted) at GPL'd code, or use already existing GPL'd code, why does it matter?"
Absolutely right. Anyone that has a problem with GPL or other similar open source licensing is free to purchase their software, libraries, and operating systems from proprietary vendors or write their own. They can leave the party anytime, and good riddance.
Har har har. That would be useful information, if only the FSF wasn't so intentionally vague about what they consider to be a "derivative" work.
What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
So what constitutes a "complex internal data structure"? Go ahead, ask them, but they won't tell you - you get to guess, and find out if you're right based on whether or not you get sued.
This is exactly analogous to the concept of "fair use." It's vague because no simple (or even complex) definition can cover all possible circumstances. The answer is to either take it to court and let the courts decide (as in any copyright dispute) or to negotiate with the licensee to come to a mutual agreement on the specifics of the question. No big deal.
"So what constitutes a "complex internal data structure"? Go ahead, ask them, but they won't tell you - you get to guess, and find out if you're right based on whether or not you get sued."
Did you email and ask, and can you post the response?
Or are you speculating?
It's not speculation. I know someone who directly asked the FSF for clarification about interaction between proprietary software and GPL software, and the non-answer from the FSF was very disappointing. I've seen the emails, but they're not mine, and they're not public, so I don't really think it's my place to post them here - sorry.
"It's not speculation. I know someone who directly asked the FSF for clarification about interaction between proprietary software and GPL software, and the non-answer from the FSF was very disappointing. I've seen the emails, but they're not mine, and they're not public, so I don't really think it's my place to post them here - sorry."
THEN WHY BOTHER EVEN MENTIONING IT?
Pretty silly response. In fact, if you look up the GPL and LGPL, on the FSF and GNU site, it's clearly explained.
Of course, you can avoid the whole issue by just not using GPL software if you don't like it.
No, it's not. It's not clearly explained, as I pointed out in my original post, nor will the FSF do a whole hell of a lot to clarify it. In a way, I understand why they do this - they're obviously not going to stake out too specific a position, lest they accidentally sign up for an interpretation that is less broad than they might otherwise get from a sympathetic judge. But they wrote the thing, and they're responsible for enforcing it, and that kind of junk smacks of people who are more interested in legalisms and lawyer's games than in actually promoting the real-world use of GPL software.
Of course, you can avoid the whole issue by just not using GPL software if you don't like it.
I don't. The stuff I do belongs to my employers, and the few bits of my own that I've set free are public domain, because public domain software is actually free. Unlike the GPL, which is not about freedom - the GPL is about controlling other people, not freeing them. A gilded cage is still a cage.
Right on. The GPL is nothing but a mouse trap setup to try to steal IP from others under its confusing and controversial terms.
What stops a company from seeking a specific exemption from the GPL from the creators of whatever work they want to use? How difficult is that?
I don't know about it being a setup, but I do know it's not as "free" as some of the alternatives.
" Right on. The GPL is nothing but a mouse trap setup to try to steal IP from others under its confusing and controversial terms."
Can you explain a chonology of how such a trap would work?
Can you point to any specific examples of it happening?
It's vague because no simple (or even complex) definition can cover all possible circumstances.
That's fine, but for me, the problem arises when someone emails the FSF with a specific set of potential circumstances, and the response in return is "sorry, we can't help you". The whole idea was that they were trying to avoid GPL issues, but the authors of the license itself won't tell them how to do that. So now what? Guess, and potentially get sued? Is that really the most efficient way to go about this?
"That's fine, but for me, the problem arises when someone emails the FSF with a specific set of potential circumstances, and the response in return is "sorry, we can't help you". The whole idea was that they were trying to avoid GPL issues, but the authors of the license itself won't tell them how to do that. So now what? Guess, and potentially get sued? Is that really the most efficient way to go about this?"
Rather than spreading FUD, why don't you email the FSF with a specific set of issues, and post the response here for us to all discuss and hash over??
No, thanks. I'm not about to violate someone's confidences in me by replicating the circumstances that generated that response, all in order to satisfy your curiosity. It's not FUD - it's real, and either you accept it or you don't. Makes no difference to me either way.
....and?
This is a small fraction of the tens and thousands of IP suits in the tech industry that happen every year.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.