|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix |
[Nov 28, 2004] Linux News Best of ECT News Sticks, Stones and the GPL
No matter how good a legal document purports to be, interpretation is almost always necessary because of the limitations of language and the inability to predict all possible uses of a legal document. Don't take my word for it. Even Richard Stallman and Linus Torvalds disagree on the exact interpretation of the GPL when it comes to derivative works and dynamically loaded kernel modules.
It's nice to know someone is reading my column. According to some of your letters, it seems my recent column on the GPL [Phil Albert, "A Consumer's Review of the General Public License, LinuxInsider, July 20, 2004] touched a nerve. To my critics who referred to me by names other than Phil, I can only respond with an equally mature "Same to you!" For those who prefer a more reasoned discussion, please allow me to devote this week's column to answering some of your criticism.
For starters, this is an opinion column. It is based on my opinion as an intellectual property attorney with considerable experience. My column on the GPL 2.0 was a product review, not an attack on the GPL itself -- and anyway, it was mostly favorable. I never said that companies should not use it, and I am not opposed to the concept of copyleft. The idea of copyleft was clever and very unique at the time Richard Stallman came up with it, and he deserves credit for that.
Point, Counterpoint
I started paying attention to GPL developments as a programmer in the late 1980s. Ironically, much of my early *nix programming experience was with an operating system known as SCO Xenix. Since then I've attended Free Software Foundation (FSF) seminars and studied the GPL extensively, and I'm not the first one to raise some of the issues I covered in my column.
Some readers criticized my comment that the GPL was written without lawyers. They argued that lawyers have been involved with the GPL for about a decade. But that only takes us back to 1994. The version of the GPL I reviewed is from 1991. If GPL 2.0 is so perfect, why is GPL 3.0 on the way?
It is true that when my clients pay me to provide legal advice, they prefer that I take their side in disputes. But no one is paying me to be an advocate here. I'm a LinuxInsider columnist and I express my opinions about the industry. If you don't trust my opinion, I suggest you check out legal commentary from unbiased law professors, many of whom echo my comments about the GPL. That said, let me address some of the honest criticism of my review.
Definitions of Derivative Works
Pamela Jones, who runs the awesome Groklaw.net Web site, took issue with my statement that the GPL 2.0 provides two conflicting definitions of derivative works: the "before the colon" definition tying it to copyright law; and the "after the colon" definition defining it another way. She argued they are the same, and she provides three definitions for derivative works: the "following the colon one"; a U.S. copyright version; and the statutory version. I argue that none of these are identical to each other, which proves my point -- don't define something twice. Good programmers know it is bad practice to redefine constants.
Jones pointed out that some attorneys write articles that are thinly disguised sales pitches designed to bring in new clients. That was not my intention. When I said that the definition of "derivative work" was complex, it was because it is.
In the United States, the legal definition of a term often starts with a statutory definition. For "derivative work," the controlling law is federal law and the relevant statutory definition is provided by 17 USC §101. However, since the United States is what is known as a common law jurisdiction, case law further defines the term for instances where the statutory definition was unclear. Obviously, I do not have enough space in my column to provide all of the case law to set out the legal definition of derivative work.
As a result, I believe the best definition of derivative works for a license is this: "a derivative work is a derivative work as defined by the applicable law" and nothing more. That leads to my next point.
Choice of Law
The legal definition of a term cannot always be as simple as a declarative statement, not because lawyers want to make more work, but because the real world is complicated. I recall a dispute involving an artist's copyright. Someone bought a book containing a number of the artist's prints, unbound the pages and sold the prints individually mounted on tiles.
The dispute was whether the tiles constituted derivative works. That is not exactly covered by the words of the statute. The court ruled that the mountings constituted derivative works. Don't blame the lawyers. Definitions have different meanings in different contexts.
Licenses, contracts and other legal documents include a choice of law provision because documents can be construed differently in different places. While copyright law is federal law, state law can still be implicated in a copyright dispute. Furthermore, federal law is not identical across all federal circuits. And the GPL is used in other countries, so even U.S. federal copyright law is not always the last word.
Interpretation Matters?
Forgive me if I repeat myself. Eben Moglen's interpretation of the GPL, regardless of how good a lawyer he is, means nothing for GPLed works not owned by the FSF, Moglen or his other clients.
No matter how good a legal document purports to be, interpretation is almost always necessary because of the limitations of language and the inability to predict all possible uses of a legal document. Don't take my word for it. Even Richard Stallman and Linus Torvalds disagree on the exact interpretation of the GPL when it comes to derivative works and dynamically loaded kernel modules.
When a licensor grants a license using the exact text of the GPL, the intent of the licensor and the applicable law must be taken into account to determine the bounds of a GPL-based license.
Implied License
Critics of my position on implied license missed the point. Absent a license, one incurs liability by copying a copyrighted work. An "implied" license means that, given the circumstances, the court would deem a license of some sort to have existed where there was no explicit license. That is what would give a person the right to copy the work.
This is not just legal sophistry. In some cases, mere execution of a program legally constitutes copying, so one would need a license to run, copy, modify or redistribute a program without incurring copyright liability.
The GPL 2.0 explicitly states that running the program is outside the scope of the license, so the GPL does not explicitly grant a license to run the program. However, in stating that running the program is not restricted, there is an implied license to run the program to the extent that a license is needed.
Untested in Court Does Not Mean Steel-Plated
To the credit of the FSF and others, many potential disputes go away with a little education or pressure from a community of interests. However, that does not mean the GPL is a perfect license.
For something to be tested in court, there first needs to be some significant potential upside for the plaintiff if the case is won or some significant potential downside for the defendant if the case is lost -- otherwise it settles quickly.
Second, there needs to be a significant mismatch between how the plaintiff thinks the case will turn out and how the defendant thinks the case will turn out, or a belief on the part of one of the parties that a court ruling will result in new case law favorable to that party's position.
Those conditions are not present with most GPL disputes. Often, there is not enough interest in arguing. Interpretation of the GPL is an issue we can expect to see more often.
Keeping the Debate Out of the Mud
Here's something you should know. I have written code that I have given away and some that I have copylefted, so I have no problem with the concept.
My point is simply that licenses should be clear, to both lawyers and nonlawyers, so that unnecessary disputes over license terms are avoided. I hope that clears the air, so we can avoid any muddiness in the future.
Slashdot Mambo Users Are Free And Clear
Re:Connolly replies... (Score:5, Informative)
by rewt66 (738525) on Wednesday September 29, @07:10PM (#10389189)I read his reply. He does all right until his fourth point, where he says, "However, reverse engineering would still require the permission of the copyright holder." This is total baloney. You only need permission of the copyright holder if you are copying, or if you are creating a derivative work within the meaning of the copyright law. It's not enough to say, "It does the same thing, it's by the same guy, so it must be a derivative." Reverse engineering is almost certainly not going to create a derivative work in copyright terms.
Now, reverse engineering could get you in trouble with patents. And if the same person did the work, there could be trade secret issues. But Connolly didn't argue those points; he yelled about copyrights. Sorry, it doesn't work that way. Copyright only applies if someone copies something. If I understand correctly, Salik says he didn't copy anything; he re-wrote it.
In point 5, Connolly claims, "The code committed to Mambo was done under contract and paid for by the Literati Group." If this is true, that's a big no-no. But if the code committed to Mambo does the same thing as the code written for Literati, but is in fact different code, re-written from scratch (it's only a few lines), then Connolly has nothing contractually to lean on.
Moving on to point 9: Connolly claims that the GPL doesn't require you to redistribute. This is true. What the GPL requires is that, if you distribute the program in any form, you must also distribute the source under the GPL. If you leave the program in-house running your web site, you don't have to distribute the code at all, ever, to anyone, under the GPL or under any other terms.
The questions are: First, did Salik contribute original code to Mambo, or did he contribute the code he wrote under contract for Literati or a derivative thereof? (Note well: "He wrote the one, and then he wrote the other, and they do the same things, so the second must be a derivative" is a fallacious argument.) And second, did Literati distribute the program under any terms to anybody, and does the program contain GPL'd code that is not owned by Literati? (Note that Literati can GPL a version of their code, and ship a version that contains the same code plus other code, without having to GPL all the code in the second version, as long as all the GPL'd code in the second version is owned by themselves.)
[Sep 27, 2004]
More Sparks Fly in
Open-Source Copyright Fight by Steven J. Vaughan-Nichols
Peter Lamont, CEO of Miro International Pty Ltd., has lobbed the latest volley in the ongoing cat fight over the copyrighted open-source Mambo content management system.
Lamont is now claiming that the OSSI (Open Source Software Institute) sided with Furthermore Inc. and that, therefore, Miro executives will not talk with either organization.
The fight began when Furthermore claimed that some of the code used in Miro's open-source Mambo content management system actually belongs to Furthermore. Mambo and Miro executives both deny this assertion. The OSSI had offered to act as a neutral mediator between the parties, but Miro refused to negotiate.
Now, according to Lamont, a former advertising executive, "John Weathersby of the OSSI contacted me to ask if he could be a mediator and open discussions between [Furthermore President John Connolly] and Miro. I told him I did not trust Connolly and that he must promise in writing to cease his activities for 90 days before we would discuss anything."
Weathersby said that he forwarded Miro's statements to Connolly "verbatim" and that he then provided Connolly's response directly back to Miro, "with no editorializing or input other than a request for clarification on a couple of points," he said.
Lamont, however, describes this response as coming "with an unsigned and undated document attached which demanded that Miro 'provide Furthermore Inc. a proprietary license for the complete Mambo core to use, sell and modify freely.'"
Connolly agreed that he did ask for this in his initial response to Miro but that this was simply one of the proposed negotiating points. "This was a worse-case demand," he said.
Regardless, Connolly said that OSSI was not supporting his position and was simply forwarding it to Miro.
Lamont, however, claims that Weathersby endorsed this position. According to Lamont, Weathersby seemed to find the position "quite reasonable, despite its obvious contradiction with the GPL, and suggests that his company is also given the copyright.
"Miro was not at all eager to have discussions with Connolly in the first place, as we believe he is incorrigible," said Lamont. "On the basis of the ridiculous demands of the e-mail and its attachments, we replied to Weathersby, 'We will not enter into any further communication with yourself or Connolly.'"
Weathersby disagreed with this assessment of the e-mail. "Our position was that of a mediator, not a negotiator, at least at this initial discussion phase," he said. Miro's response was a rejection of Connolly's initial proposal, Weathersby said.
"Again," Weathersby said, "OSSI did not contribute to or provide input to Connolly's proposal or comments. That was not our concern. However, the tone and direction of the exchange was enough to convince me that this was not a situation that I wanted to be involved with. Therefore, we informed both parties that, instead of being drawn into the fray, we would step away and recuse ourselves."
Miro has no desire to talk to either party.
"Miro was not at all eager to have discussions with Connolly in the first place, as we believe he is incorrigible. On the basis of the ridiculous demands of the e-mail and its attachments, we replied to Weathersby that 'we will not enter into any further communication with yourself or Connolly,'" Lamont said.
Moving on, Lamont said, "Connolly appears to be attempting to get money from or coerce the developer's client to join him in publishing a lie about Connolly's involvement in a Web site development in the Chicago Tribune, presumably to demonstrate that some of the community is supporting him."
Specifically, Lamont says that Connolly had contacted the developer's client and demanded that they either go to court, settle out of court for $10,000 or, for $1, agree to a joint article in the Chicago Tribune saying that the developer had collaborated/ co-operated with him on this site.
This, Lamont said, shows "Connolly's motivations are more sinister that just wanting 'fairness.' From his demands it seems that Connolly wants Mambo for himself to profit from and threatens legal action and/or incredible sums of money from people he thinks are using his code."
Connolly responded that "I'm trying to protect myself from thieves. The Web site was about to be launched with Mambo using our stolen code. We told the Web site owners that if they did so, we would send them a cease-and-desist order."
"What we actually gave the publisher was the chance to settle the matter [with] three basic options: One, a public announcement that we've amicably resolved that matter—consideration $1; two, nonpublic settlement—consideration $10,000; three, lawsuit and public fight. … with option number one, everybody wins. It goes away immediately and painlessly," said Connolly.
The public announcement would have read, "Open Source Software Project Mambo, Furthermore today reached its first settlement agreement with an end user of the software. Following a Cease and Desist, Furthermore and the Blank Newspaper of Blank have entered into an agreement regarding use of the 'Lead Story Block' functionality in Mambo. The amount of the monetary settlement was not disclosed."
This shows, Connolly asserts, that "We're not extorting anyone. We're simply looking to keep people from violating our copyright. A dollar consideration shows that we're about the principle."
At this point, no talks are scheduled between the feuding companies.
Check out eWEEK.com's Linux & Open Source Center for the latest open-source news, reviews and analysis.
International PHP Magazine - Cutting-Edge Technologies for Web Professionals - Online Articles The Top Seven MySQL Licensing Questions by J.A. (Zak) Greant, MySQL AB Community Advocate And Seven Simple, Direct Answers.
This article aims to clearly answer seven of the most common questions asked by PHP users about MySQL's licensing. For each question, this article attempts to provide a simple and direct answer that focuses on the intent of the question, rather than its literal meaning. Additionally, for each question and answer, there is also a more detailed and technical supporting discussion.
Introduction
This article endeavors to provide advice that is responsible, practical, conservative, and true. However, please keep in mind that it is not a substitute for professional legal advice. In matters of software licensing, it is prudent to seek the advice of a lawyer who specializes in software licensing and intellectual property law, and who understands the issues as they pertain to Free Software and Open Source.Audience
This article is written for the professional PHP programmer, but should also be of benefit to any reader with an interest in the topics discussed. The answers given tend to focus most strongly on the needs of the independent software vendor who develops and distributes software made with PHP and MySQL.
Q #0: How does MySQL AB make money?
A: MySQL AB sells licenses and various services (like certification, support and training) for our software.Discussion
This is the most common question that I am asked about MySQL at PHP conferences. MySQL AB makes money in much the same way that many other software companies make money: we sell licenses to, and services for, our software. At the same time, we also license our software free of charge under the terms of a license that allows others to do almost anything that they want with the software. They may study, disassemble, sell, re-engineer, or even re-engineer and sell the software, as long as they always share it (and works based on it) under the terms that we licensed it to them.
The combination of the two different licenses is called dual licensing.
Q #1: What is dual licensing?
A: Dual licensing allows the user of a program to choose between two different sets of terms and conditions for their use of the software.Discussion
When software is dual licensed, it means that one of two different sets of licensing terms may be chosen for each particular copy of the product.
MySQL AB allows users to choose between the GNU General Public License (GPL) and a standard proprietary license.
The proprietary license is fairly standard for the proprietary software industry and is similar to what is commonly used by other commercial software vendors like Hewlett-Packard or Novell. It can briefly be summed up by stating that, in exchange for a fee, MySQL AB allows you to run a copy of the licensed MySQL software and provides some additional assurances of importance to business users such as certain indemnities related to intellectual property. As with most proprietary licenses, few other rights are granted.
The GPL is a Free/Libre and Open Source Software (FLOSS) license that grants licensees many rights to the software under the condition that, if they choose to share the software, or software built with GPL-licensed software, they share it under the same liberal terms.
At MySQL AB, we often say this very simply as: If you are free, we are free. If you are proprietary, we are commercial.
Q #2: When should I use MySQL under the GPL?
A: Whenever you want to study, extend, and freely share MySQL and software based on MySQL.Discussion
The GPL grants licensees a broad set of rights, including the right to copy the software, freedom to create modified copies, and permission to distribute original and modified copies of the software to others. The rights are granted under the following condition: copies of GPL licensed software (or software that is based on the GPL-licensed software) can only be distributed under the terms and conditions of the GPL. Additionally, the GPL requires that the source code of the program is included with any executables or that it be made freely available for only the cost of distribution.
Some examples of legal use of GPL-licensed software include:
- Studying the source code of the software in a software engineering class.
- Using the software as a component of other GPL (or certain other FLOSS licensed) programs.
- Extending the software and distributing the extended version under the terms of the GPL. You can even sell your extended version for a fee. See http://www.fsf.org/philosophy/selling.html for details.
- Proprietary software vendors can use the GPL-licensed version of MySQL to provide their developers with no-cost copies of MySQL for use in the development process. Of course, when the software is distributed, they should use the proprietary version of MySQL.
- Reviewing the source code to understand the implementation of a feature within MySQL and then reimplementing the feature without copying the code reviewed. The GPL allows software developers to learn from the work of others and freely borrow the ideas used, but not the actual code.
- Offering services provided via GPL-licensed software, without offering the software under the terms and conditions of the GPL. This is acceptable because the GPL places no restrictions on the use of GPL-licensed software, only on the distribution of GPL-licensed software or software based on GPL-licensed software. Of course, as stated above, MySQL AB always recommends that any proprietary use of MySQL be done under a proprietary license.
Some examples of incorrect use of GPL-licensed software include:
- Giving GPL-licensed code to others under another license.
- Copying copyrightable portions of GPL-licensed code into a non-GPL product.
- Creating software based on GPL-licensed software and then selling this software under a license other than the GPL.
Note 1:
Note that not all code is copyrightable. If there is only one obvious way to do something or if the use of the code falls under fair use, then copyright may not apply. See a lawyer for more details.
Visit http://www.fsf.org/licenses/licenses.html#GPL for comprehensive and accurate information on the GPL.
Q #3: When should I buy a proprietary license for MySQL?
A: Whenever you distribute proprietary software that uses, includes or requires MySQL.Discussion
Proprietary software, for the purposes of this discussion, is software that is not licensed under a Free Software or Open Source license. Commercial software is simply software that is sold - regardless if it is proprietary or not.
In some cases, proprietary software and GPL licensed software are not incompatible. The crux of the issue revolves around a key concept of copyright law known as derivative work. If a derivative work is created with GPL licensed software, that work can only be distributed under a GPL license.
The U.S. Copyright Act, at 17 U.S.C. §101, defines a derivative work as:
... a work based upon one or more pre-existing works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation or any other form in which a work may be recast, transformed or adapted. A work consisting of editorial revisions, annotations, elaborations or other modifications which, as a whole, represent an original work of authorship, is a derivative work
Authoritatively determining when a work is or is not a derivative of another work can only be done by a court of law. Of course, legal experts with experience in these matters and an understanding of national copyright laws can make educated guesses about when a work is or is not a derivative work.
MySQL AB always recommends that proprietary software use the proprietary version of MySQL. With this strategy of always pairing valid proprietary licensing with valid proprietary licensing, the obligations and rights of the licensor and the licensee are quite clear.
If you wish to use MySQL as a part of your software, but do not wish to distribute the software under the GPL (or one of another set of FLOSS licenses - see Q #4 for details) or purchase a proprietary license from MySQL, then we invite you to discuss further with us and/or to consult a lawyer who is an expert in proprietary and FLOSS software licensing.
Q #4: When do I need to purchase a proprietary license for PHP programs built with MySQL?
A: Whenever you distribute proprietary software that uses, includes or requires MySQL.Discussion
As in every other case, if your software is not FLOSS licensed, MySQL AB recommends the use of the proprietary version of MySQL.
However, it would be unethical to not disclose the facts. It is not clear that the combination of a proprietary PHP script, GPL-licensed MySQL software and PHP would violate the GPL.
When the PHP engine executes a PHP script, the license of the PHP script is irrelevant. Nothing in the licensing of the PHP engine makes any requirements on the licensing of the PHP scripts that it runs. Even if the PHP engine were licensed under the GPL, this fact would still be true.
When a PHP script uses MySQL, it only does so via PHP's interface to MySQL. A developer can create a script that uses MySQL, but never have to distribute any MySQL source code. Asserting that this is a derivative work might be difficult.
While MySQL AB recommends that proprietary software use the proprietarily licensed version of MySQL, the licensing fees may make this difficult for less expansive proprietary applications. If you wish to purchase licensing, but find the licensing fees prohibitive, please write to [email protected]. We may be able to help arrange terms that are more suited to your needs.
Note: Readers learned in the ways of FLOSS licensing know that the distribution of derivative works formed from GPL-licensed software and non-GPL-licensed software is not legal in most cases. To avoid this problem and to allow for greater compatibility between GPL-licensed software and non-GPL FLOSS software, MySQL AB has issued a special exception to the terms and conditions of the GPL licensing for the MySQL client libraries. The full details of the exception can be found at http://www.mysql.com/products/licensing/foss-exception.html.
Q #5: Is MySQL support included in PHP 5?
A: Yes. There are two extensions for supporting MySQL in PHP 5.Discussion
In PHP 5, there are two MySQL extensions available: the old MySQL extension for MySQL versions up to 4.1 and the new, improved MySQL extension that supports all versions of MySQL (including MySQL 4.1 and greater).
There is a difference in how MySQL support is included with PHP 5 compared to PHP4. In the past, a public domain MySQL client library was bundled with PHP. This was done to make it easier for less experienced users to use MySQL with PHP.
However, a combination of problems surrounding how the MySQL client was included with PHP led to the unbundling of the MySQL client library. The major factors were:
- The client library was not kept up-to-date and did not work with all versions of MySQL
- Use of the bundled client library prevented some other programs that were used with PHP and dependent on MySQL from working
Also, while the change of license for the MySQL client library did not force the removal of the separately licensed public domain MySQL client from PHP, it is very likely that the license change is what made the PHP group examine the problems with embedding the client library in PHP.
Currently, to use MySQL with PHP, both PHP and MySQL must be installed and support for MySQL must be enabled when building PHP.
Q #6: Why did MySQL AB change the license of the MySQL client libraries to the GPL from the LGPL?
A: To better support our dual-licensing model.
Discussion
MySQL AB's guiding business principle is that of fair exchange or Quid Pro Quo (something for something). We reflect this principle in our business model by giving our software away for FLOSS use and by selling it for proprietary use.
The LGPL licensing for the MySQL client made it easy for organizations to distribute proprietary software without contributing to the FLOSS community or paying money to MySQL AB to fund further development. In short, they were not participating in a fair exchange.
MySQL AB relies on having a healthy and fair exchange with the community of MySQL users. When it comes to software licensing, we interact with the community in the same way that they choose to interact with others. When dealing with proprietary software, we sell licenses for MySQL. When dealing with FLOSS software, we give away GPL licenses for MySQL.
This simple approach lets us have a viable business model that meets the needs of many different types of users.
For more information on this model, read MySQL AB CEO M?en Mickos's excellent article on dual-licensing, fair exchange and Quid Pro Quo at the rather unwieldy URL of: http://mysql.com/newsletter/2003-11/a0000000220.html.Closing Notes
Thanks for reading! I hope that this article has made the MySQL licensing easier to understand and has helped to clear up a few related issues.
If you want to discuss the article or issues in more detail, please hit our forums and submit your article request (link at end of article).Glossary
- PHP Magazine Forums: http://forum.php-mag.net/
- FLOSS: An acronym for Free/Libre and Open Source Software.
- Free/Libre and Open Source Software: A term generally used to refer to software that qualifies as Free Software (under the Free Software Foundation's Free Software Guidelines) and Open Source (by the Open Source Initiative's Open Source Definition). For a more complete definition and discussion, please visit the Wikipedia entry on FLOSS: http://en.wikipedia.org/wiki/FLOSS.
- Free Software: Free software is software than can be freely studied, modified and shared. For a more complete definition, see the Free Software Definition: http://www.gnu.org/philosophy/free-sw.html.
- GNU General Public License: A FLOSS license designed to help encourage the spread of Free Software and ensure that Free Software remains Free Software. See http://www.gnu.org/licenses/licenses.html - GPL.
- GNU Lesser General Public License: A FLOSS license designed to help ensure that Free Software remains Free Software while still being compatible with proprietary software. See http://www.gnu.org/licenses/licenses.html - LGPL.
- GPL: An acronym for the GNU General Public License.
- LGPL: An acronym for the GNU Lesser General Public License.
- Licensee: The party who is given a license.
- Licensor: The party who grants a license.
- MySQL AB: The Swedish company that develops and markets a family of high performance, affordable database servers and tools, including MySQL, MaxDB and MySQL Cluster. MySQL AB owns all of the MySQL core product source code. This fact allows us to license the MySQL software under multiple licenses. The AB at the end of the name stands for Aktiebolag, the Swedish term for an incorporated company.
- Open Source: Code that is licensed under a license that complies with the Open Source Initiative's (http://opensource.org/) Open Source Definition: http://www.opensource.org/docs/definition.php.
- Proprietary: For purposes of this discussion, software that is not Free Software or Open Source software.
Re Use of GPL'd code with proprietary programs
From: Alexander Terekhov Subject: Re: Use of GPL'd code with proprietary programs Date: Tue, 06 Jul 2004 21:01:19 +0200
Rui Miguel Seabra wrote: > A copyright law violation is as severely pursued be it > Free Software as proprietary software "The church of GNU denounce copyright as an evil plot... unless this is connected with the direct attacks of the legality of GPL. ;-)" -- Bezroukov regards, alexander.
Google Groups gnu.misc.discuss
Lee Hollaar Jun 18 2004, 10:45 am show options
Newsgroups: gnu.misc.discuss, misc.int-property From: holl...@faith.cs.utah.edu (Lee Hollaar) - Find messages by this author Date: Fri, 18 Jun 2004 14:45:54 +0000 (UTC) Local: Fri, Jun 18 2004 10:45 am Subject: Re: The worst that can happen to GPLed code In article <x5k6y5otfo....@lola.goethe.zz> David Kastrup <d...@gnu.org> writes:
>holl...@faith.cs.utah.edu (Lee Hollaar) writes:
>> In article <x5wu25ouhr....@lola.goethe.zz> David Kastrup <d...@gnu.org> writes:
>> >First sale applies if there is a sale. It doesn't if there isn't.
>> >Copyright defines the minimum set of rights that can be _sold_ to you.
>> >It does not apply to items to which you have no right in the first
>> >place, but to which you are unilaterally granted a conditional license
>> >to use and redistribute, without any exchange of consideration from
>> >your side.
>> Wrong, wrong, wrong, at least under United States copyright law.
>> "First sale" is just a shorthand for the judicially-created doctrine
>> that is now codified in 17 USC 109. It does not require a "sale"
>> but applies to anyone who is "the owner of a particular copy or
>> phonorecord lawfully made under this title".
>What about "made under this title" don't you understand?
I seem to understand it a bit more than you do, it appears.
The phrase essentially means that the copy is not infringing, either
>> I can become the lawful owner of a copy by gift or similar things
because it was made with the permission of the copyright owner or
it falls within one of the exceptions to the copyright owner's
reproduction rights.
>> that are not a sale.
>Which then is not obtained "under this title".
More nonsense. If the owner of the copyright gives me a copy, then
I am the owner of a copy "made" (not "obtained") "under this title."
Re Use of GPL'd code with proprietary programs
Rui Miguel Seabra wrote:
[...]
> Go eat my dust 'lex.
You go first.
http://digital-law-online.info/lpdi1.0/treatise27.html
<quote>
Some have claimed that an application program that needs a library
for its operation is a derivative work of that library. They take
that position because the application program is ?based on? the
library because it was written to use the subroutines and other
aspects of the library.
Such a position is misplaced.
[... explanation ...]
It could be argued that the component program really does include
portions of the library that it uses ? data structures that are
passed as parameters, or even the parameter lists themselves. But
elements dictated by external considerations are filtered out when
trying to determine whether there is copyright infringement.
No other conclusion makes sense. If it were not the case, then
any program using the applications program interfaces (APIs) of an
operating system could be considered a derivative work of that
operating system. And, under the exclusive right to prepare
derivative works, the copyright owner of an operating system such
as Microsoft Windows could control who was allowed to write
programs for that operating system.
</quote>
regards,
alexander.
Re Use of GPL'd code with proprietary programs
From: Alexander Terekhov Subject: Re: Use of GPL'd code with proprietary programs Date: Wed, 07 Jul 2004 00:41:35 +0200
Rui Miguel Seabra wrote: > > On Wed, 2004-07-07 at 00:15 +0200, Alexander Terekhov wrote: > > No other conclusion makes sense. If it were not the case, then > > any program using the applications program interfaces (APIs) of an > > operating system could be considered a derivative work of that > > operating system. > > Yes, that's right. That's why the glibc is LGPL and not GPL. http://groups.google.de/groups?selm=40239163.78134B8B%40web.de http://groups.google.de/groups?selm=x5d68stcln.fsf%40lola.goethe.zz http://groups.google.de/groups?selm=4023C5D4.522B4B7F%40web.de > > > And, under the exclusive right to prepare > > derivative works, the copyright owner of an operating system such > > as Microsoft Windows could control who was allowed to write > > programs for that operating system. > > More and more. Right now Microsoft is trying to prevent creation of > GPL'ed software on Windows toolkits... http://groups.google.com/groups?selm=40D7E7C0.64F74067%40web.de regards, alexander.Re Use of GPL'd code with proprietary programs
From: Alexander Terekhov Subject: Re: Use of GPL'd code with proprietary programs Date: Wed, 07 Jul 2004 01:27:12 +0200
Rui Miguel Seabra wrote: [...] > Of course, what Kastrup meant was collective work (but used a confusing > choice of words). > > Of course, the technical term is not derivative. But it's easy to get > confused trying to put it in ways 3 year olds would understand and you > still don't. Impeccable logic. I have no words. > > As to usage of Linux, Linus himself adds an explicit permission to link, > just before the GPL v2: > > NOTE! This copyright does *not* cover user programs that use kernel > services by normal system calls - this is merely considered normal use > of the kernel, and does *not* fall under the heading of "derived work". > > So it was _his_ call to declare it outside the scope. Don't confuse an > explicit permission from the author with the default. Ok. This thing goes in circles. I'm tired. You won. regards, alexander. P.S. http://creativecommons.org/licenses/by-sa/2.0/legalcode
Re Use of GPL'd code with proprietary programs
From: Arnoud Engelfriet Subject: Re: Use of GPL'd code with proprietary programs Date: Wed, 7 Jul 2004 17:32:20 +0200 User-agent: Mutt/1.5.6i
Alexander Terekhov wrote: > Arnoud Engelfriet wrote: > > I'm not sure that the Linux license status is comparable to other > > GPL-licensed works. But in any case, without binding case law > > a prudent lawyer must prepare for the worst. It may be unlikely, > > but if the unlikely interpretation hurts your client, your > > client should prepare for it. > > Yes. The only problem is that such "prudence" means tremendous loss > of world-wide productivity, it puts a barrier for many would-be- > contributors, etc. Yes. If you have a better suggestion, please let me know. If the consequence is that my client may get sued successfully, I unfortunately can't accept it. It would be a lot better for everyone if there was some definite ruling one way or the other. So we need someone to be the test case. Unfortunately, you'll have a hard time finding someone. Arnoud -- Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/
Re Use of GPL'd code with proprietary programs
From: Alexander Terekhov Subject: Re: Use of GPL'd code with proprietary programs Date: Wed, 07 Jul 2004 18:44:45 +0200
Arnoud Engelfriet wrote: [...] > It would be a lot better for everyone if ther was some definite > ruling one way or the other. So we need someone to be the > test case. Unfortunately, you'll have a hard time finding someone. Would this insurance (I'm just paying and paying and no one sues me ;-) ) http://www.wgv-online.de/__pdf/9000-1001-arb.pdf cover it? regards, alexander.
Google Groups gnu.misc.discuss
Lee Hollaar Jun 18 2004, 10:50 am show options
Newsgroups: gnu.misc.discuss, misc.int-property From: holl...@faith.cs.utah.edu (Lee Hollaar) - Find messages by this author Date: Fri, 18 Jun 2004 14:50:28 +0000 (UTC) Local: Fri, Jun 18 2004 10:50 am Subject: Re: The worst that can happen to GPLed code Reply to Author | Forward | Print | View Thread | Show original | Report Abuse In article <x5oenhotjw....@lola.goethe.zz> David Kastrup <d...@gnu.org> writes:
>holl...@faith.cs.utah.edu (Lee Hollaar) writes:
>> I can become the lawful owner of a copyrighted work without any
>> exchange of consideration. It's called a gift.
>But then copyright does not apply. If I write a letter with a poem in
>it to you, you are not allowed to pass it on to somebody else without
>my permission. If I _sell_ a letter with a poem in it to you, you
>are.
Wrong, again.
Copyright always applies in the United States for works that have been
fixed in a tangible medium of expression. It has NOTHING to do with
sale. A work is still protected by copyright, even if I find it in
the street.
If I am the lawful owner of a copy of a letter, perhaps because it
was sent to me, then I can tranfer my ownership to another without
the permission of the writer. That's what 17 USC 109 says.
From: Arnoud Engelfriet Subject: Re: Use of GPL'd code with proprietary programs Date: Wed, 7 Jul 2004 19:54:19 +0200 User-agent: Mutt/1.5.6i
Alexander Terekhov wrote: > Arnoud Engelfriet wrote: > [...] > > It would be a lot better for everyone if ther was some definite > > ruling one way or the other. So we need someone to be the > > test case. Unfortunately, you'll have a hard time finding someone. > > Would this insurance (I'm just paying and paying and no one sues me ;-) ) > > http://www.wgv-online.de/__pdf/9000-1001-arb.pdf > > cover it? You'll need to speak with your insurance people to determine if you're covered. My reading of section 3(2)(d) is that copyright infringement lawsuits are excluded from this policy. I have yet to see a legal insurance policy that covers intellectual property related lawsuits. Arnoud -- Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/Re Use of GPL'd code with proprietary programs
From: Per Abrahamsen Subject: Re: Use of GPL'd code with proprietary programs Date: Tue, 06 Jul 2004 15:36:59 +0200 User-agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux)
Haakon Riiser <[email protected]> writes: > I can't even believe why they > would do such a thing -- are they afraid of getting infected by > the GPL license in some way? Do they mention the GPL specifically? The Visual C++ runtime library license does not mention the GPL specifically, but does mention "copyleft" licenses in general. As far as I can see, it hits both GPL, LGPL, QPL, and perhaps even MPL (which is a very weak copyleft). I believe the GPL is the main target, because GPL'ed software are the main competition to Microsoft in some markets. Most notoriously, the Samba server. > Here's what our lawyer said (more or less): As another poster said, listening to your lawyer is a lot smarter than listening to what I, or any other in this group, may say. > All restrictions on distribution of the GPL'd program appears under > GPL section 2, which specifically targets modified copies only: Please note that the GPL does not *restrict* distribution. It *allows* distribution. By default (i.e. copyright law), distribution is not allowed. So you should search for those clauses that explicitly allows distribution, not a lack of clauses that disallows distribution. > 2. You may MODIFY your copy or copies of the Program or any > portion of it, THUS FORMING A WORK BASED ON THE PROGRAM, Logically, this sentence (fragment) does not say that modifying the program is the only way to form a work based on the program. It implies that *if* you modify the program, you create a work based on it. Nowhere does it states what happen if you do not modify the program.
Re Use of GPL'd code with proprietary programs
From: Haakon Riiser Subject: Re: Use of GPL'd code with proprietary programs Date: 6 Jul 2004 16:12:37 +0200 User-agent: slrn/0.9.8.0 (Linux)
[Arnoud Engelfriet] > [...] > Therefore the only question is whether a work linked to the > GPL-licensed program qualifies as a "work based on the Program". See > my comments above. Again, thanks for your comments. Apparently, there isn't yet a definitive answer to the legalities of GPL/non-GPL linking, so I'll leave it at that. But there is one question I'd like to have answered: Would it be OK for a BSD licensed server to have both proprietary and GPL'd clients connected via shared memory? (Disregard the fact that some proprietary licenses may forbid even aggregation with GPL.) The BSD-style license is compatible with the GPL, but is not viral, so hopefully this should be legal. -- HaakonRe Use of GPL'd code with proprietary programs
From: Arnoud Engelfriet Subject: Re: Use of GPL'd code with proprietary programs Date: Wed, 7 Jul 2004 17:29:38 +0200 User-agent: Mutt/1.5.6i
Haakon Riiser wrote: > [Arnoud Engelfriet] > > [...] > > Therefore the only question is whether a work linked to the > > GPL-licensed program qualifies as a "work based on the Program". See > > my comments above. > > Again, thanks for your comments. Apparently, there isn't yet > a definitive answer to the legalities of GPL/non-GPL linking, > so I'll leave it at that. But there is one question I'd like to > have answered: Would it be OK for a BSD licensed server to have > both proprietary and GPL'd clients connected via shared memory? The Apache webserver (which was until recently under a BSD-like license) allows connections from Internet Explorer (proprietary) and Konqueror (GPL). Not sure if that's what you mean, but that is definitely OK. Problems begin when you use this kind of technique purely to avoid the consequences of the GPL. Courts have in other situations ruled that doing something explicitly to get around a copyright is an infringement. So, again, a legal risk you have to assess and perhaps make a reservation for. > (Disregard the fact that some proprietary licenses may forbid > even aggregation with GPL.) The BSD-style license is compatible > with the GPL, but is not viral, so hopefully this should be legal. The GPL states that if you create a derivative work, you can only distribute that derivative work under GPL terms. It is allowed to mix GPL and BSD code, since the BSD license is GPL-compatible. That is, you are allowed to distribute the result, since by obeying the GPL you also obey the BSD terms. Arnoud -- Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/ Re Use of GPL'd code with proprietary programs
From: Alexander Terekhov Subject: Re: Use of GPL'd code with proprietary programs Date: Wed, 07 Jul 2004 18:09:09 +0200
Arnoud Engelfriet wrote: [...] > The GPL states that if you create a derivative work, you can > only distribute that derivative work under GPL terms. It is > allowed to mix GPL and BSD code, since the BSD license is > GPL-compatible. That is, you are allowed to distribute the > result, since by obeying the GPL you also obey the BSD terms. The GPL terms do NOT require to reproduce the BSD list of conditions and the BSD disclaimer in the documentation and/or other materials provided with the binary distribution. That's additional requirement not present in the GPL that one must comply with. You just can't have a derivative work (and I mean REAL derivative work, not GNU absurdity) under many licenses unless each original work was "multi-licensed" under all other licenses. Practically, you never need and do things like that because "natural" ways of abstraction, design, and coding lead to separation. regards, alexander.Re Use of GPL'd code with proprietary programs
From: Alexander Terekhov Subject: Re: Use of GPL'd code with proprietary programs Date: Fri, 09 Jul 2004 10:05:22 +0200
Martin Dickopp wrote: > > Alexander Terekhov <[email protected]> writes: > > > Now, do you seriously believe that they will be able to convince > > a non-drunken district judge (appellate and supreme folk aside > > for a moment) that "works that use the library" are in fact > > derivative works under copyright law? > > Yes. On the basis of what? Assume that a district judge doesn't belong to the GNU church and doesn't live in the GNU Republic (where all works come into existence as derivatives [because the GNU law says so] of other GPL'ed works and hence also fall under the GPL). How are they/ you going to convince him? Make an argument, please. regards, alexander.
Re Use of GPL'd code with proprietary programs
From: Alexander Terekhov Subject: Re: Use of GPL'd code with proprietary programs Date: Thu, 08 Jul 2004 12:47:44 +0200
Arnoud Engelfriet wrote: > > Alexander Terekhov wrote: > > Arnoud Engelfriet wrote: > > > The GPL states that if you create a derivative work, you can > > > only distribute that derivative work under GPL terms. It is > > > allowed to mix GPL and BSD code, since the BSD license is > > > GPL-compatible. That is, you are allowed to distribute the > > > result, since by obeying the GPL you also obey the BSD terms. > > > > The GPL terms do NOT require to reproduce the BSD list of conditions > > and the BSD disclaimer in the documentation and/or other materials > > provided with the binary distribution. > > GPL section 1: "provided that you conspicuously and appropriately > publish on each copy an appropriate copyright notice and disclaimer > of warranty". For the BSD-licensed code, the appropriate notice > is the BSD text. That's a stretch, but OK. What about BSD's list of conditions? BSD conditions are clearly not the same as the GPL terms and the GPL just can't override them. "Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution." What you'll have is a set of conflicting terms. In reality, the GPL terms cover only protected elements in the GPL'ed portions (verbatim copies and derivatives) and the BSD terms cover only protected elements in the BSD'ed portions (verbatim copies and derivatives). The GPL terms do NOT apply to the BSD'ed portions and the BSD terms do NOT apply to the GPL'ed portions. regards, alexander.Re Use of GPL'd code with proprietary programs
From: Alexander Terekhov Subject: Re: Use of GPL'd code with proprietary programs Date: Thu, 08 Jul 2004 22:36:17 +0200
Arnoud Engelfriet wrote: [...] > As I understand it, the interpretation of the FSF is that linking > creates a "work based on the Program". Yeah. Let's see. http://www.fsf.org/licenses/200104_seminar.html <quote> The LGPL is a "scaled back" version of GPL, designed specifically to allow creation of a very well-defined class of proprietary derivative works. [...] We introduce the two classes of derivative works covered by LGPL, "works that use the library" and "works based on the library", and give some concrete examples of what proprietary derivative works are prohibited and permitted when basing the software on an LGPL'd work. </quote> So the non-"scaled back" version purports to disallow creation (they actually mean distribution) of proprietary "works that use the library" without making distiction between "works that use" and "works based on" (in the LGPL sense) -- they're simply treated as being the same using "based on" umbrella. The only 'problem' is that unless you happen to believe that you live in the {virtual} GNU Republic, "works that use the library" are NOT derivative works under copyright law. http://slashdot.org/article.pl?sid=00/05/01/1052216&mode=nocomment <quote> RMS: We have no say in what is considered a derivative work. That is a matter of copyright law, decided by courts. When copyright law holds that a certain thing is not a derivative of our work, then our license for that work does not apply to it. Whatever our licenses say, they are operative only for works that are derivative of our code. A license can say that we will treat a certain kind of work as if it were not derivative, even if the courts think it is. The Lesser GPL does this in certain cases, in effect declining to use some of the power that the courts would give us. But we cannot tell the courts to treat a certain kind of work as if it were derivative, if the courts think it is not. </quote> Now, do you seriously believe that they will be able to convince a non-drunken district judge (appellate and supreme folk aside for a moment) that "works that use the library" are in fact derivative works under copyright law? regards, alexander.Re Use of GPL'd code with proprietary programs
From: Alexander Terekhov Subject: Re: Use of GPL'd code with proprietary programs Date: Fri, 09 Jul 2004 11:37:19 +0200
Martin Dickopp wrote: [...] > Okay, here's an argument: The fact that you apparently have to resort to > a funny, but factually incorrect kind of rhetoric ("GNU church", "GNU > Republic", "GNU law") indicates strongly that you are wrong. Take this. http://www.gnu.org/philosophy/copyright-versus-community.html <quote> RMS: ... Meanwhile for software, I suspect that a three year copyright would be enough. you see if each version of the programme remains copyrighted for three years after its release well, unless the company is in real bad trouble they should have a new version before those three years are up and there will be a lot of people who will want to use the newer version, so if older versions are all becoming free software automatically, the company would still have a business with the newer version. Now this is a compromise as I see it, because it is a system in which not all software is free, but it might be an acceptable compromise, after all, if we had to wait three years in some cases for programs to become free... well, that's no disaster. To be using three years old software is not a disaster. [...] AM4: The problem with this change in the copyright laws for three would be that you wouldn't get the sources. RMS: Right. There would have also to be a condition, a law that to sell copies of the software to the public the source code must be deposited somewhere so that three years later it can be released. So it could be deposited say, with the library of congress in the US, and I think other countries have similar institutions where copies of published books get placed, and they could also received the source code and after three years, publish it. And of course, if the source code didn't correspond to the executable that would be fraud, and in fact if it really corresponds then they ought to be able to check that very easily when the work is published initially so you're publishing the source code and somebody there says alright "dot slash configure dot slash make" and sees if produces the same executables and uh. So you're right, just eliminating copyright would not make software free. AM5: Um libre RMS: Right. </quote> http://www.tlug.jp/docs/rms.html <quote> HY: Hmmm. Then tell me what you think about pirated software. RMS: I don't call this copying "piracy", because that is a propaganda word. I don't think it is wrong to copy and share information. Governments can pass laws against it, but that does not make it wrong, just illegal. An unauthorized copy of a proprietary program has the same drawbacks as an authorized copy. If you want to make more copies and share them, you have to do it in secret; and you cannot get the source code. So I think that unauthorized copies are not much better than authorized copies. The only good thing about the unauthorized copy is that you avoid giving money to the owner. This is good, because the owner does not deserve a reward for making software proprietary. </quote> These are all potential "exhibits", you know. ;-) regards,alexander.
Re Use of GPL'd code with proprietary programs
From: Alexander Terekhov Subject: Re: Use of GPL'd code with proprietary programs Date: Fri, 09 Jul 2004 12:32:59 +0200
Martin Dickopp wrote: [... "exhibits" ...] In my view, The FSF's conduct clearly constitutes misuse of copyright (quoting Stacy: "It seems more likely that they knew exactly what they were doing, and that from the outset they were hoping to establish new case law by changing the legal meaning of "derivative work", thereby simultaneously expanding the scope of their rights."). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Their idiotic claims are barred by the doctrine of copyright misuse and the doctrine of first sale (if you agree with the Libraries Association view of first sale in the digital age... teleportation*** aside for a moment). regards, alexander. ***) http://www.research.ibm.com/quantuminfo/teleportationRe Use of GPL'd code with proprietary programs
From: Alexander Terekhov Subject: Re: Use of GPL'd code with proprietary programs Date: Fri, 09 Jul 2004 14:17:32 +0200
Martin Dickopp wrote: [... misuse of copyright/quoting Stacy ...] > Arguing with what you read on Usenet is also something which would > likely weaken your position in a court case. AFAIK, that idea was first invented (so to say) by "Christian H. Nadan, Director and Associate General Counsel, Sun Microsystems, Inc., and Adjunct Professor, University of California Berkeley Boalt Hall School of Law. This Article represents the views and analysis of the author alone, and not of Sun Microsystems, Inc. The author would like to thank Bill Lard, Mark Lemley, Sean Hogle and Michele Milnes Nadan for their generous assistance and thoughtful comments and suggestions." http://www.xfree86.org/pipermail/forum/2004-March/004248.html BTW, curiously, neither Stallman nor Moglen replied to http://lists.debian.org/debian-legal/2004/05/msg00390.html regards, alexander.Re Use of GPL'd code with proprietary programs
From: Alexander Terekhov Subject: Re: Use of GPL'd code with proprietary programs Date: Sat, 10 Jul 2004 18:29:22 +0200
Rainer Weikusat wrote: [...] > very simple: You have a work that consists of two separately > copyrighted works, one of them GPL and one them not. So you can either > put the combined work under GPL or leave the GPL parts out, because > you have no right to use them in this way if you don't GPL the > whole. The separate copyright is not affected by this, ie you are free > to use that in other contexts, when not combined with GPLed works, as > you please. Grantback doesn't need to be exclusive to trigger misuse. The scope of the "grantback provision" is what determines misuse. <quote> the Copyright Act's grant of rights does not extend to unrelated works or preexisting (and therefore necessarily nonderivative) works, and using the copyright license to extract such rights exceeds the scope of the copyright grant. </quote> regards, alexander.Re Use of GPL'd code with proprietary programs
From: Alexander Terekhov Subject: Re: Use of GPL'd code with proprietary programs Date: Mon, 12 Jul 2004 09:48:48 +0200
Rainer Weikusat wrote: [... copyright misuse ...] > The GPL does not contain a grantback provision, Sure it does. It triggers when I want to distribute derivative works (which is okay). The only 'problem' is that the FSF makes totally idiotic claims. But those claims can only help someone to put all the FSF's copyrights in quasi "public domain" (I mean the penalty for copyright misuse) or, perhaps, help the FSF in establishing insanity defense. I mean their claims like http://www.gnu.org/licenses/gpl-faq.html#OOPLang <quote> In an object-oriented language such as Java, if I use a class that is GPL'ed without modifying, and subclass it, in what way does the GPL affect the larger program? Subclassing is creating a derivative work. Therefore, the terms of the GPL affect the whole program where you create a subclass of a GPL'ed class. </quote> Hey dak, that's why "the legal effect of the FAQ (which are not part of the license itself) is uncertain." ;-) http://groups.google.com/groups?selm=40D6DACA.5681F1DB%40web.de (Subject: Re: The worst that can happen to GPLed code) regards, alexander.
InfoWorld Open source lock-in January 16, 2004 By Jon Udell APPLICATION_DEVELOPMENT PLATFORMS
With the release of MySQL 4.0, the licensing policy of the wildly popular open source database underwent a subtle change. The code libraries that client programs use to access the native MySQL API, formerly licensed under the LGPL (Lesser General Public License), were converted to the GPL. The LGPL was designed to exempt “nonfree” programs that link against open source libraries from the GPL’s strong requirement to release source code. The purpose of the LGPL, according to the Free Software Foundation, is “to encourage the widest possible use of a certain library, so that it becomes a de-facto standard.” And indeed, MySQL has become the database pillar of the so-called LAMP platform, whose acronym expands to Linux, Apache, MySQL, and the trio of Perl, Python, and PHP.
Ongoing controversy has dogged the switch from LGPL to GPL. Last week, OpenLink Software CEO Kingsley Idehen posted angry note on his Weblog in which he denounced the move, saying in part: “Nice way to treat a community that has built itself around MySQL’s LGPL client libraries.” And he offered a workaround: an open source gateway that maps the MySQL-specific API to the database-neutral ODBC API.
Two different issues are tangled up in this complex web of circumstances. First, of course, is licensing. MySQL AB and a handful of other open source companies -- including Sleepycat Software and Trolltech -- use what’s called a dual license. “Our philosophy is simple,” says MySQL AB’s Vice President of Marketing Zack Urlocker. “If you’re open source, we’re free. If you’re closed source, we have a commercial license.” Translation: If you profit from MySQL, then MySQL AB should profit, too. Fair enough. And yet, as Yahoo developer and MySQL expert Jeremy Zawodny points out, MySQL AB is only in a position to sell enterprise licenses thanks to the huge mindshare created, in part, by the open source developers who wrapped MySQL’s C-based library for use from a variety of programming languages. “If you now put restrictions on how they can do that,” he says, “you’re slapping the community that pushed you this far.”
Urlocker says the move targets people who were “misusing the GPL by distributing the MySQL server tightly coupled with their applications.” He adds that the company has begun a public process of license review. But the open source community should also consider a related issue: its fondness for database-specific APIs rather than generic ones. As Idehen writes, “the very essence of the ODBC value proposition has been somewhat lost.” He also cites a 1999 article of mine, "Why Isn't ODBC a Standard Feature of Linux," which I could have written today.
Linux Today - Chris Allegretta When Non-Free is Free Enough By Chris Allegretta
The University of Washington's Pine mailer. A popular piece of software, indeed, as is its editor component, Pico. So much so that most people turn a blind eye to its license: a license, I feel, that is as bad as anything that has ever come out of Redmond.
Virtually every major GNU/Linux distribution ships binaries of Pine and Pico with the notable exception of Debian. After all these programs are veritable mainstays of the Unix world. Ironically, according to the legal terms of the program, Debian may be the only distribution legally allowed to distribute the program!
From the Pine Legal Notice:
Redistribution of this release is permitted as follows, or by mutual agreement:
(a) In free-of-charge or at-cost distributions by non-profit concerns;
(b) In free-of-charge distributions by for-profit concerns;
(c) Inclusion in a CD-ROM collection of free-of-charge, shareware, or
non-proprietary software for which a fee may be charged for the packaged
distribution.Let's say producer PhatHat makes a "Super Ultimate PowerPack 10 CD Edition" distribution and sells it for $40 with support. That would appear to satisfy section (c) of the notice, correct? But what if they also include on those CDs binary only, "proprietary" drivers for oh, say, the latest Ovidian video card. Now are they in violation of the Pine license? I'd say yes. There is the "written permission" clause, but that's a highly outdated means of licensing software in the wonderful electronic age in which we live.
However, because of Debian's stance on not shipping non-free software in their standard distribution, they could pass this portion of the licensing terms for distributing Pine. But Debian doesn't put Pine into their main archive. In fact they wont even ship binaries of Pine or Pico! The source code, along with various patch files, can be found in Debian's non-free section. The distribution terms violate the Debian Free Software Guidelines:
The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be free software.
Suppose tomorrow the Pine license changes to something more restrictive, say, completely closed source, binary only redistribution. Are all those distributors who were already in violation of the license going to simply drop the package from their distribution? I doubt it.
Why, you ask? Simple, because they can't stop distributing the program, users have come to rely upon it to read their email and edit their documents! Read the debian-user mailing list sometime and see how many times users of other distributions scream "Ahh! where's Pine and Pico, my life will end without them!" The users are not at fault, their old "Open Source" operating system included Pine and Pico, so why shouldn't Debian? The programs are "Open Source" after all, aren't they?
The thing is, they aren't. The Pine license is not a Free Software license, nor does it meet the Open Source Definition. Why is it included in the distribution, then? Well, because it's "free enough."
So back to our new license scenario. I hear you saying "I highly doubt Pine will go proprietary, it's published by a university". Fair enough. Suppose instead that Pine's maintainers get new jobs more demanding of their time, or something else stops them from maintaining the program full time. Now a security issue arises that requires patches to the source code. What can our distributors do then?
Well, what is normally done in situations like this is that programmers from outside the project will go back to the last release of the program, and fork a new version of the program from there with their own patches. This is what the OpenSSH developers did when the original ssh program went commercial and there was no support of the older, more open version.
So they can just fork a new copy of the program, right? Wrong. You can't fork Pine and produce modified binaries, this is forbidden by UW, it's specifically addressed in the Pine FAQ. In fact, later on the FAQ brazenly states, In particular, the earliest Pine licenses included the words: "Permission to use, copy, modify, and distribute this software... is hereby granted," but some people tried to pervert the meaning of that sentence to define "this software" to include derivative works of "this software". The intent has always been that you can re-distribute the UW distribution, but if you modify it, you have created a derivative work and must ask permission to redistribute it.
So, people who support Open Source and Free Software are perverts for thinking you should be able to ship modified binaries of a program! The wording could have been "change" or "twist", but the word chosen was "pervert". I feel this is an intentional slander of proponents of the GPL and other Free Software licenses.
Why do I feel this is licenses is as bad as Microsoft's licenses? I don't, I think it's worse. With any commercial license, you do not ever expect to see or have rights over the source code to the software. In the case of Pine, users are lulled into thinking they have rights to do what they want with the software, but really they don't. And if UW makes the license more proprietary or simply stops updating it, there's nothing they can do about it.
So, what can we do? For one thing, stop referring to Pine and Pico as Open Source! And if you can't handle that (and you know who you are), at least don't nominate them for awards specifically for Open Source programs! Also do not lump Pine and Pico in with other GPL covered programs on web pages or when discussing Free Software, as this may confuse people into thinking that Pine and Pico are in fact also Free Software programs, which they are not.
Another thing you can do it educate your peers, when they say Pine is "Free" or "Open Source", mention that the license restricts modified redistribution, and have them read it over for themselves.
You can also use free alternatives to these programs. The mutt mailer is very similar program to Pine, once you get used to the slight difference of starting up at your messages and not at a menu. There are keymaps you can download to make mutt behave like Pine. You can also use (weren't you waiting for the plug?) GNU nano instead of Pico to edit your files.
Yes, I am the author of GNU nano. I am biased in this regard. But nano is itself evidence that Pine may indeed be "free enough" for people, when perhaps it shouldn't be. Pine and Pico have been around for ten years, and nano is the first project I'm aware of that attempts to remedy the licensing problem by making a complete clone of the software starting from scratch. The question comes down to: do you want full rights over the software you use, or is Pine "free enough" for you?
BW Online August 13, 2004 A Big Fly in the Open-Source Soup
Linux is burdened with too much intellectual-property uncertainty for many companies to embrace and develop it further The open-source movement has had a remarkable run of success that has seen software such as the Linux operating system and the Apache Web server emerge as major challenges to Microsoft (MSFT ). However, the movement is now facing a crisis. At its heart is a question that has been around from the very beginning: How does software owned by everyone and by no one survive in a world where copyrights and patents shape the legal landscape? The question is being forced on a number of fronts, and if open source is to play an important role in software's future, the issue will have to be dealt with decisively.
Linux, the most important piece of free, open-source software, began as the effort by a Finnish college student, Linus Torvalds, to create the functional equivalent of the Unix operating system, developed and then owned by AT&T. Intellectual-property questions about Linux came to the forefront after the SCO Group (SCOX ), which acquired the Unix trademarks, launched a series of lawsuits against alleged infringers of its rights.
POTENTIAL INFRINGEMENTS. The central case, a 2003 suit against IBM (IBM ), an important corporate promoter of Linux, has degenerated into a messy contract dispute with no intellectual-property issues left on the table. SCO's threats to sue companies that use Linux have almost entirely evaporated.
But now another problem has surfaced. Open Source Risk Management, a new outfit that indemnifies its customers against infringement claims, found in a review of Linux code that the operating system potentially infringes on 283 patents. Although IBM declared it would make no effort to enforce its 60 patents involved, some are held by Linux foes, including 27 by Microsoft.
The potential patent infringements pose no immediate threat to Linux. Such disputes typically take years to resolve, and courts rarely issue injunctions against alleged infringers. But the uncertainty is taking a toll. In the most significant response to date, the city government in Munich, Germany, has suspended a massive transition of desktop computers from Microsoft Windows to Linux, pending clarification of the patent situation (see BW Online, 8/9/04, "Will Legal Fears Freeze the Penguin?").
"ETHICAL POLLUTION"? Most patent disputes are settled with licensing agreements, but this is a tough course for Linux to follow. With no single owner, the closest thing it has to a central authority is the Open Source Development Lab -- but the organization has no way to pass any licensing fees on to users. Perhaps the best approach would be if major Linux distributors, such as Red Hat (RHAT ) and Novell (NOVL ), and companies for whom Linux is strategically important, such as IBM and Hewlett-Packard (HPQ ), could set up a fund to deal with potential patent issues.
But open-source proponents also have to get their own intellectual-property house in order. The development of open-source software is increasingly dominated by corporate interests that, one way or another, want to use Linux, Apache, and other open-source products to make money.
But a slew of backers see open-source software as part of a social and political movement that's frankly anti-corporate. Richard M. Stallman, founder of the Free Software Foundation and a man who commands enormous respect among software developers, argues in the essay Why Software Should Not Have Owners: "The system of owners of software encourages software owners to produce something -- but not what society really needs. And it causes intangible ethical pollution that affects us all."
MURKY MODEL. That view doesn't get a very sympathetic hearing at, say, IBM headquarters. But Stallman's thinking suffuses the GNU General Public License (GPL), a document that governs the distribution of Linux and many other open-source programs. The GPL not only requires that any programs licensed under it be freely distributed but also that any modifications made to the software, or any other software derived from it, are themselves automatically covered by the GPL.
Unfortunately, the GPL is hardly a model of clarity, and few disputes involving it have gotten to court, so case law has done little to clarify its meaning. This is causing reservations as more and more companies consider using GPL-covered software to develop either commercial programs or software for their own use. Apple (AAPL ), for example, rejected Linux as the basis of Mac OS X in favor of another open-source, Unix-like operating system called FreeBSD, largely because the licensing terms were less restrictive.
What exactly constitutes a "derivative work" automatically covered by the GPL? "The truth is we don't really know, and there are reasonable arguments on both sides," Jay Michaelson, co-founder of software company Wasabi Systems and a lawyer and a programmer, wrote in the May issue of the Association for Computing Machinery's journal Queue. "Some people argue that the GPL as a whole isn't even enforceable.... At the end of the day, the unfortunate reality is that developers should check with the companies' legal departments before proceeding with any GPL-related development because the requirements may vary on a case-by-case basis."
RELIGIOUS FERVOR. Bright as it is, the future of commercial open source might be considerably brighter if Linux and other programs went to a more commerce-friendly license with fewer complexities and ambiguities than the GPL. There's plenty of precedent. The BSD license, the Mozilla Foundation license used for browsers, and the Apache license all provide for free distribution of code and source code with fewer restrictions than the GPL.
That would be tremendously controversial in the open-source community, where the GPL sometimes seems more like an object of religious veneration than a legal document, but it would be good for all concerned.
[Aug 24, 2004]
NewsForge Advice to Linux Dump the GPLBy: Joe Barr
BusinessWeek columnist Stephen Wildstrom recently wrote a piece called A Big Fly in the Open-Source Soup that concluded, "The future of commercial open source might be considerably brighter if Linux and other programs went to a more commerce-friendly license with fewer complexities and ambiguities than the GPL." At the risk of offending a great many NewsForge readers, I am going to say that I don't disagree with him. Not because of the alleged complexity or ambiguities of the GPL -- it's a piece of cake compared to a typical proprietary EULA -- but because I don't understand what he means by the term "commercial open source." If he had simply said "open source" -- or used the more definitive phrase "free software" -- I would reject his position outright. Updated:
But even allowing for the escape clause provided by an undefined, rogue-hybrid term like "commercial open source," Wildstrom provides much to quibble about. His conclusion is based upon a series of weak or simply erroneous facts and observations.
In raising the specter of IP attacks on Linux, Wildstrom fails to acknowledge that such attacks are simply a fact of life these days for all software development. Whether that development work is proprietary or free makes not a whit of difference.
Then too, Wildstrom chose an unfortunate example with which to demonstrate the threat: the recent delay of Munich's migration from Windows to Linux. He cited that delay as the "most significant" example of the toll patent fears are taking on open source projects. Unfortunately for the case he was trying to build, the delay ended after only a week. Munich is now back at work on their massive transition from proprietary to free/open source desktops.
But the timing of that unfortunate choice of an example is the least of the problems with the foundation for Wildstrom's conclusion. His point is really nothing more than the observation that it would be easier for business to profit from the work of free software developers if it weren't protected by the GPL. No, duh, Mister Wildstrom? Who's to argue with that? Certainly not me.
Wildstrom at least enough good sense to cite Stallman, writing:
But a slew of backers see open-source software as part of a social and political movement that's frankly anti-corporate. Richard M. Stallman, founder of the Free Software Foundation and a man who commands enormous respect among software developers, argues in the essay Why Software Should Not Have Owners: "The system of owners of software encourages software owners to produce something -- but not what society really needs. And it causes intangible ethical pollution that affects us all."
Once again that's a rather unfortunate choice, since Stallman's words are unerringly accurate and predictive of the patent-based IP terrorism mentioned earlier. Perhaps Wildstrom meant to show Stallman in the most flattering way possible -- as a visionary and prophet -- rather than to whip the proprietary/IP terrorists into a howling frenzy. But somehow I doubt that was his motivation.
Wildstrom takes his third and final swing at the target he has been sneaking up on all along: that pesky GPL. He begins with a low moan about the GPL's alleged "lack of clarity," then cites Apple's choice of FreeBSD instead of Linux as a meaningful example of the GPL costing Linux business opportunities. Never mind that Steve Jobs offered Torvalds the job of marrying the Apple GUI on a Unix kernel, and never mind what reasons Torvalds and thousands of other free software developers may have had for choosing the GPL to license their code in the first place, Wildstrom thinks Linux should have a different license, and that's that.
Speaking of Torvalds, Linus took a couple of minutes out of his busy schedule to answer a few questions by email. The first thing I asked him about was the claim that Apple chose FreeBSD instead of Linux because of the licensing. Torvalds said:
I'm sure many companies prefer the BSD license over the GPL, since it allows them to take code without giving anything back.
That said, I think the reason Apple went with BSD was not so much the license - they've kept things open anyway - as the fact that they had a history with Mach and BSD from the NeXT guys and Tevanian.
I also asked if a licensing change for Linux would provide greater protection against patent-based IP threats. Linus replied:
There are some open source licenses that take a more direct stance on patents (OSL etc), and maybe they might matter. And maybe they wouldn't.
To my mind, the problem with patents has little or nothing to do with licenses: we've certainly seen that patents are equally troublesome for totally proprietary commercial projects too.
And so is Linus considering a change in licensing for the kernel?
No. I think the BSD license is a great license, but it absolutely doesn't do _at_all_ what I believe in. I'm a big believer in people giving back to the community, and I'm also a big believer in the fact that sometimes they need some encouragement in the form of rules to do so - just to keep them honest. The GPL keeps everybody honest.
Wildstrom then turns to religious zealotry to bolster his position and asserts that if the "open-source (sic)community" stopped using the GPL, business could make more money. In his words, "the GPL sometimes seems more like an object of religious veneration than a legal document, but it would be good for all concerned."
Obviously, Wildstrom has no qualms about sacrificing the work of thousands of others at the altar of the almighty dollar. But his worship doesn't seem to include ethics. Nor does it consider the common good. He is a poster-boy for unenlightened capitalism: Nothing matters to him except the bottom line. People like him are the reason we need licenses like the GPL.
I have no problem whatsover with Wildstrom licensing every line of the "commercial open source" he can write with whatever license he chooses. I just wish he would show the free software/open source communities the same respect.
Update: This response was received too late to be included in the original version of the story, but we think it is important enough to warrant an update to include.
Wildstrom calls upon Jay Michaelson to further shroud the GPL in the fog of FUD. Quoting from his commentary, he writes:
What exactly constitutes a "derivative work" automatically covered by the GPL? "The truth is we don't really know, and there are reasonable arguments on both sides," Jay Michaelson, co-founder of software company Wasabi Systems and a lawyer and a programmer, wrote in the May issue of the Association for Computing Machinery's journal Queue. "Some people argue that the GPL as a whole isn't even enforceable.... At the end of the day, the unfortunate reality is that developers should check with the companies' legal departments before proceeding with any GPL-related development because the requirements may vary on a case-by-case basis."
Silly me. I wondered what Columbia law professor Eben Moglen -- also General Counsel for the Free Software Foundation -- might think of Michaelson's claims. The good professor wrote back, saying:
After many years of securing compliance with copyright law as it applies to GPL'd work, and in view of recent court decisions in Germany, to say nothing of SCO, I think there should be no remaining doubt in any well-informed mind about the legal soundness of GPL. As to the definition of "derivative work," the uncertainty is experienced by those who would like to make proprietary uses of GPL'd code, and are unsure whether a particular way of making a proprietary enhancement to a free work will certainly or only arguably infringe the free developer's copyright. The correct answer, of course, is that those who want to take advantage of the enormous quantity of freely distributable "best of breed" software now available should do so in a fashion that respects the principle of freedom in which it was created. All doubt can be eliminated, for Mr. Michaelson and all other seekers after wisdom, if they remember what they learned in kindergarten: share and share alike. IBM, HP, Novell, and other very large and very profit-minded businesses have no problem with this, nor should Mr. Michaelson's readers.
Slashdot/SCO Attorney Declares GPL Invalid
Re:Hold up a second... (Score:5, Interesting)
by watchful.babbler (621535) on Thursday August 14, @03:26PM (#6698975)
(http://www.doxagora.com/ | Last Journal: Friday February 28, @05:39PM)When the FSF refers to the GPL license as being a "copyleft" they're making a joke, because they're using COPYRIGHT law to ensure that the code remains freely available. Copyleft is not a principle the law recognizes. Absolutely correct, and that's why invoking preemption isn't so crazy as many seem to think. The federal courts, in Vault Corp. v. Quaid Software [harvard.edu], held that Title 17 Sec. 117 [gpo.gov] of the U.S. Code preempted terms in Vault's shrink-wrap licensing, so there's precedent for applying the preemption doctrine to private contracts in copyright litigation.
Without knowing more about SCO's argument, we certainly can't argue on the merits of it, but there's always the possibility that some enterprising copyright lawyer has found a potential incompatibility between the GPL and copyright law. (Offhand, though, any argument based on Title 17 Sec. 117(a) seems specious to me, since I don't see how it could possibly affect the right to authorize copies and derivative works in Sec. 106 -- but IANA(IP)L.)
And, actually, *I* say
:x!, but who's keeping track?
Re:Hold up a second... (Score:2)
by sg_oneill (159032) on Friday August 15, @08:45AM (#6704991)
(http://guild.murdoch.edu.au/)Dude chill. Stallman comes from an anarchist tradition that includes both syndicalists and libertarians.
Either traditions are 100% non communist america friendly freedom headed. The syndicalists believe that complete freedom will naturaly lead to a socialist situation, and the libertarians believe it will lead to a capitalist situation.
Eitherway, neither will step on your rights, and the truth of the two traditions is 100% up to history.
Stallman clls it a copyleft, only cos hes transposing it against a copyRIGHT. Its just a wordplay. Chill.Re:Hold up a second... (Score:5, Insightful)
by echo (735) <echo@[ ]bucket.org ['the' in gap]> on Thursday August 14, @01:49PM (#6697715)
(http://slashdot.org/ | Last Journal: Wednesday August 22, @11:10AM)Because Copyleft isn't a Law, it's just an idea. Copyright is a law.
However, that being said, Copyleft is BASED on Copyright. What they are saying is.. no matter what the license says, you can only make one copy. Of ANYTHING.
So the Book Publishers and Authors need to start suing the printing press companies, since they give them the "right" to make copies so they can sell them.
Re:Hold up a second... (Score:5, Informative)
by SmackCrackandPot (641205) on Thursday August 14, @03:10PM (#6698815)From the Legal Law Institute [cornell.edu]
A copyright gives the owner the exclusive right to reproduce, distribute, perform, display, or license his work. See 106 of the act. The owner also receives the exclusive right to produce or license derivatives of his or her work. See 201(d) of the act. Limited exceptions to this exclusivity exist for types of "fair use", such as book reviews. See 107 of the act. To be covered by copyright a work must be original and in a concrete "medium of expression." See 102 of the act. Under current law, works are covered whether or not a copyright notice is attached and whether or not the work is registered.
Most countries have also accepted the Berne Convention for the protection of literary and artistic works [cornell.edu].
Article 9 specifically states:
(1) Authors of literary and artistic works protected by this Convention shall have the exclusive right of authorizing the reproduction of these works, in any manner or form.
(2) It shall be a matter for legislation in the countries of the Union to permit the reproduction of such works in certain special cases, provided that such reproduction does not conflict with a normal exploitation of the work and does not unreasonably prejudice the legitimate interests of the author.
(3) Any sound or visual recording shall be considered as a reproduction for the purposes of this Convention.
Article 12
Authors of literary or artistic works shall enjoy the exclusive right of authorizing adaptations, arrangements and other alterations of their works.
Practical examples: The copyright owner can set the price of the object being protected. Many university research projects release their source code on condition that the authors names remain on the files or that a credit is given somewhere within a derivative application.
Re:Hmm (Score:1, Flamebait)
by dasmegabyte (267018) on Thursday August 14, @02:25PM (#6698201)
(http://www.dasmegabyte.org/ | Last Journal: Tuesday August 20, @11:23AM)Acutally, I'm kind of hoping that the end result of this is exactly what you're saying: you can either copyright something, or you can release it into the public domain. That you can't release something into the public domain with restrictions, even well meaning ones like community licenses.
Yes this invalidates the GPL. Good. I hate that viral piece of shit. The lack of "copyleft" has not hurt things licensed under Apache or BSD. In fact, all the GPL has done, really, is restrict the commercial viability of open source.
Think about it, man. Software companies need to make money, but software is very complicated. If you can grab the framework for your product for free without being restricted in how you release said product, you win. And free software wins, too, because it's DEVELOPERS and not LICENSES that make OSS great. We actually had a standing order here NOT to use OSS because of licensing questions, until I got the rule whittled down to exclude BSD, Apache and a few other licenses. The managers here thought that the money spent on exploring the legality of products based on top of GPL'd code was not worth the time they saved developers.
And it's not like non-GPL OSS is faltering. Postgresql is easily on par with (i'd say better than) the GPL'd MySQL. The BSD OS is easily on par with (and many say better than) Linux itself. Apache makes some of the best software on the PLANET. Lack of a GPL is not preventing people from using software and it's not preventing them from extending it. Fear of this was the reason the GPL was emitted from beneath RMS' tinfoil sombrero...making the GPL illegitimate would put a stop to all this stupid OSS license squabbling, and let us get back to what's important: making software.
Well fuck (Score:4, Insightful)
by autopr0n (534291) on Thursday August 14, @02:50PM (#6698552)
(http://autopr0n.com/ | Last Journal: Saturday June 28, @06:57PM)The GPL is the only OSS license I would ever release my work under. Why the hell should I let anyone profit off of my work without giving anything back. Especialy fuckheads like you?
I should be able to release my code how I want. If you don't like it, then don't fucking use it.
If the only choice was All rights reserved or public domain, then I would choose rights-reserved over PD any day.Re:Well fuck (Score:1)
by IM6100 (692796) <[email protected]> on Thursday August 14, @05:01PM (#6700346)It's always about you and your code, huh? That's kind of a mine, mine, mine! attitude, there. I bet it sucked to play on a baseball team with you when you were a kid...
Re:Well fuck (Score:1)
by screenrc (670781) on Thursday August 14, @11:26PM (#6703173)Nicely said. The GPL is an agreement " I will
share, if you share." Corporations looking
for handouts should look into non-GPL software.
Donate? (Score:5, Funny)
by autopr0n (534291) on Thursday August 14, @03:07PM (#6698774)
(http://autopr0n.com/ | Last Journal: Saturday June 28, @06:57PM)Who said anything about 'donate'? Why would I want to 'donate' code to anyone for any reason? Why on earth would I want to 'donate' my code to you? You're a dick. If I want to GPL something, that's my choice. I don't give up 'ownership' of the code in the way I would if I put it in the public domain.
Not How I Expected the GPL to be Challenged (Score:5, Insightful)
by Carnage4Life (106069) on Thursday August 14, @01:52PM (#6697745)
(http://www.25hoursaday.com/ | Last Journal: Saturday May 11, @11:36PM)This current ploy by SCO sounds like it doesn't hold any water. On the other hand, there is one part of the GPL [gnu.org] that I am unsure how well would stand up to quick witted lawyerisms in a court of law. The section You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program
seems too open to interpretation from my layman's perspective. I'm actually quite surprised that no one's ever gone to court over exactly what it means to say their application is based on another application with regards to what the GPL has to say. If a project with 1000 source files, totalling a million lines of code uses some GPL code in one of the routines that performs some utility function, is the application based on the GPL program? According to armchair lawyers on Slashdot the answer is YES, however would a judge and jury see it the same way?
Re:Not How I Expected the GPL to be Challenged (Score:3, Informative)
by CoughDropAddict (40792) on Thursday August 14, @02:12PM (#6698046)The GPL doesn't need to rigorously define what it means to form a "work based on the program," because this is covered by Copyright law in its definition of "derivative work."
According to copyright law, creating derivative works is an exlusive right of the copyright holder. The law defines "derivative work" in 17 USC Section 101 [findlaw.com]. Without the GPL, creating a work that is falls under the definition of "derivative work" is illegal unless you are the copyright holder or you have permission from the copyright holder. The GPL grants you the right to create derivative works ("works based on the Program"), but only if you agree to its terms. If you do not, everything reverts back to normal copyright law and creating derivative works is illegal.
Re:Not How I Expected the GPL to be Challenged (Score:2)
by CoughDropAddict (40792) on Thursday August 14, @02:36PM (#6698336)The problem with this definition is that it leads to the idea that the concepts themselves which are illustrated by GPL'd code are protected by copyright, and they are not.
Indeed. This is all spelled out in the law. From 17 USC Section 102(b) [findlaw.com]
In no case does copyright protection for an original work of
authorship extend to any idea, procedure, process, system, method
of operation, concept, principle, or discovery, regardless of the
form in which it is described, explained, illustrated, or embodied
in such work.
The limitation of "derivative work", in the case of the GPL, can only work so long as the code still contains *SOME* number of lines of code that were originally GPL'd by some other author.
I am not familiar with the intracacies of this, but I doubt that your interpretation is valid. I surely wouldn't depend on this conclusion without strong assurances from a lawyer.
Re:Not How I Expected the GPL to be Challenged (Score:4, Informative)
by Frobnicator (565869) on Thursday August 14, @03:38PM (#6699109)
(http://www.xmission.com/~bryanw | Last Journal: Thursday August 28, @07:56PM)Actually, the SCO case is quite strong, and in a way, that's what makes it so weak. I consult with lawyers and have discussed this issue in depth. I have read the applicable laws, and the definitions. And I am worried. But not about what you would think. I am worried about the refined definition of "derivative works" that will come out of the case, and if I will be able to reuse source code from books, personal projects, and from online sources. I am NOT worried about SCO, or Linux failing, or the GPL not being enforcable.
I'm actually quite surprised that no one's ever gone to court over exactly what it means to say their application is based on another application with regards to what the GPL has to say.
.... According to armchair lawyers on Slashdot the answer is YES, however would a judge and jury see it the same way? On the first point, There was one major case that went to court about derivative works, the issue of AT&T and Berkeley's Unix implementations. If/When this goes to court, the settlement documents will have to be opened, and we'll all get to see some interesting things, including the likely posibility that SCO does not have the rights that it is asserting. There have been a few other cases that were clearly deriviatvies (according to the wording of the law), but there have been no relavent cases other than the earlier one about Unix where the border of derivative works in software has been established.
On the second question, that's exactly what is at stake in the case. That's what the lawyers see, but many geeks try to ignore. It's the reason that so many geeks and laywers were mad when software was declared to be subject to copyright and trademark laws, rather than exempt as science. I argue it is more like science because it must be an iterative improvement, and less like art. But I digress. See 17 USC 101 [bitlaw.com] for the actual legal definition of derivative works and related terms. Or, if you don't want to bother following the link...
Excerpt from 17 USC 101: A "derivative work" is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a "derivative work".
Remember that This has not been decided in any legal case yet. So let's not say that it is decided, but look at the extremes. We know that whatever is decided must lie within the extremes, so if we examine the extremes we'll know what to expect.
In a very strict reading of the definition, ANY unix-style OS could be claimed to be a recast, transformed, or adapted verion of some earlier unix OS. The Posix standard also could be considered a derivative work. If your software interfaces with that OS, it must use OS-provided interfaces and data structures. While your application may be an original work of authorship, it could easily be argued that it is a derivative work of the OS. (It contains content that was developed by another author.)
Rinse, Lather, Repeat. Include in your rinse-lather-repeat cycle that new systems, including embedded devices, also use the same concepts that are contained in other OS's. They have to be programmed in some language, probably C, and that language was derived from the Bell Lab's work.
So from this extreme, we can see that SCO owns everything. That is a strict reading of the law.
Lets take the other extreme. In a very lax reading of the definition, it moves us back to common-law. We can then say that any copying for inter-operation and communication purposes is not a derivative work, just like using words found in the dictionary doesn't compromise ownership. Extensions made to a product are not really a derivative work, since the provide something novel, but just attach to the earlier system and use the data structures as their language, or a neutral carrier.
In this case, porting a technology between platforms does not corrupt the ownership. So when company X invents a product that runs on platform Y, it isn't derivative of Y at all. But once the product has been ported enough to become common, another bit of the copyright law comes into play...
The exception in 17 USC 1302 paragraph 2 ("Protection
... shall not be available for a design that is ... staple or commonplace, such as a standard geometric figure, a familiar symbol, an emblem, or a motif, or another shape, pattern, or configuration which has become standard, common, prevalent, or ordinary;") This could easily be interpreted to say as all the things SCO has said it owns are actually common technologies that their implementation and interfaces also become exempt from the law!
That's the lax reading: the only technologies SCO owns are those that it either developed or purchaced directly, *AND* it has lost the rights to technologies that have become common. Because these technologies have become common in the industry, even if SCO had a legal right to them they would lose them when it became common. Therefore, it either is not a derivative work, or it is derivative but excempt.
With this lax interpretation, not only would SCO have a difficult time with their case, but a good deal of current copyright infringement cases would die as well. That's not a bad thing, in my view.
So the only thing to worry about is the strict reading and the harsh judge. Most likely we'll have a reasonable judge and a fairly balanced reading (meaning we get a new definition of "derivative works" but SCO doesn't win).
Even in the worst case, there are several redeeming features left in the law, and IBM has states the two that are easiest to grasp. The clean hands doctrine and the court's ability to decide based on what is reasonable rather than a strict reading of the law.
According to the unclean hands theory, and if you accept the strict definitions, since all of our software has to interact we have all been stealing from each other. Since we have been engaged in some degree of theft, we are all guilty. The court will not assist in recovering damages from the same crimes that you committed. It is like you stealing a car, then suing because somebody stole that stolen car from you. If a judge takes this route, they will be strict about it's implementation, so the statue of limitations would be evaluated. Because the earliest cases are beyond the statue of limitations, the whole industry could become immune to the strictest reading of the law (everything is derived from Bell Labs) but not from a common-law understanding (direct theft). In either case, IBM may have violated their contract, but they would not have to recall AIX. Depending on the exact details, the Linux kernel would probably have to remove any direct theft. In any event the GPL would have to remain entact, except the definition of derived works would have been refined.
The second issue is the judge being able to discard, and even invalidate, the applicable laws because their application is not logical. While the absolute, strictest reading of that law would mean that every modern program is owned by SCO (except those that licenced it earlier) that ruling would be so damaging that a judge could not rationally make it. He could rule that SCO has a valid case, that the law is clear, and that "all your bases are belonging to SCO". He would immediately be forced to state that such a law violates the Constitution (the purpose as set out in the preamble), violates many trade laws, and makes no sense, and therefore the law is invalid.
SO wrapping this up...
In all of these extremes, SCO does not come out very well. In the biggest win for them, they can claim ownership of a handful of pieces of technology (which they will quickly lose in future lawsuits), force the removal of some Linux code, and claim royalties on products that are distributed in the future that don't remove 'derivative code'. The judge will have to decide just what, if any, derivative code there is. SCO cannot go against the other customers, because of various trade laws. They MIGHT be able to go against some hardware manufacturers (EEs beware), but those companies can easily cite enough academic literature to ignore SCO.
At least, that's came out of our discussion. Talk to your own lawyers.
frob.
Re:Not How I Expected the GPL to be Challenged (Score:2)
by TekPolitik (147802) on Thursday August 14, @09:32PM (#6702623)
.... or any other form in which a work may be recast, transformed, or adapted.... In a very strict reading of the definition, ANY unix-style OS could be claimed to be a recast, transformed, or adapted verion of some earlier unix OS.
Not true. That general phrase follows a bunch of more specific ones in a list. When reading a statute, a general phrase following a list of more specific ones is given a scope as indicated by the specific ones. All the items in the list involve some modification or transformation of a literal copy of the original work. This is the scope of the more general term.
The cases are quite clear on where the boundaries of "derivative work" are, and what is protected by copyright. Just because Linux does "the same thing" as Unix "in the same way", does not make it a derivative work. The things that are the same are what in copyright terms are called the "ideas". These are not protected by copyright law. The thing that is protected is the expression of the idea - in the case of software, the expression is the code itself. Unless the code itself has been copied, there's no risk to Linux of a copyright issue (and in some cases not even then).
Re:Not How I Expected the GPL to be Challenged (Score:2)
by CoughDropAddict (40792) on Friday August 15, @12:45PM (#6706619)The cases are quite clear on where the boundaries of "derivative work" are, and what is protected by copyright.
Has this ever been tested for software? If so, can you provide a reference?
The prevailing legal climate in the software industry seems to subscribe to a much more expansive notion of "derivative works" than you describe. "Clean room" reimplementations are attempted only under extreme caution. There seems to be a belief that a person who has ever seen copyright-encumbered code becomes "contaminated" and can never reimplement the same functionality without it being a derivative work. No one would dream of making a similar argument for music, art, or literature.Re:Not How I Expected the GPL to be Challenged (Score:2)
by TekPolitik (147802) on Sunday August 17, @05:03PM (#6718890)Has this ever been tested for software? If so, can you provide a reference Altai vs Computer Associates is a good starting point. Anything else that decides something related to software specific copyrights is likely to cite that, so if you search Lexis for that you should find everything you'll ever need.
Re:Not How I Expected the GPL to be Challenged (Score:2)
by Frobnicator (565869) on Tuesday August 19, @10:27AM (#6733299)
(http://www.xmission.com/~bryanw | Last Journal: Thursday August 28, @07:56PM)Um, no. That's not what I meant at all. You might want to read my other post [slashdot.org] about my view. As another person replied to you, the stricter reading and the lack of significant legal cases are the reason to fear. According to my lawyer friends, the definition of derivative works for software is not well defined. As another person pointed out to you, legal issues come into play when one developer of a 'clean room' environment has even reviewed the original software. In this particular case of operating systems, additional rules and laws come into play about what is common practice, common knowledge, and what is a solution that any competent software engineer could create.
If this make it all the way through court, the judge will probably have something to say about derivative works. If that happens, the ruling will very likely alter the way software is developed (from a legal view, anyway) -- we may become more free to rely on external sources, or become more restricted. Regardless, if the judge gets to make a ruling, the line of what is legal and what is not will become more clearly defined.
frob
Re:Not How I Expected the GPL to be Challenged (Score:2)
by TekPolitik (147802) on Tuesday August 19, @07:17PM (#6739516)According to my lawyer friends, the definition of derivative works for software is not well defined You know how there's incompetent techs (actually a good proportion of SlashDot readers would find most techs incompetent)? Well the situation is no different in law. It scares the living shit out of me that some of my classmates who manage to just pass their subjects then go on to become practicing lawyers. Then again perhaps my perspective is influenced by the fact that my most common result in law subjects is top of the year with most of the balance being in the top two or three, but I don't want to be a leach, hence I have no intention of ever practicing. I do think that it should be a condition of practicing law that you publish the grades you receive in law school since most people can't tell the difference between a good lawyer and a bad one.
Now, the software industry likes to claim that "derivative work" means something different in to software industry, but it doesn't. That's one of the things the Altai case was about - the same rules that apply to other works also apply to software.
The real difference with software is that software companies tend to keep the primary work in which copyright substists (source code) secret. That doesn't make the law any different at all - in fact this secrecy is quite irrelevant to the issue of whether there is infringement of copyright.
Because of this penchant for secrecy, software companies like to claim they have certain rights they don't, and other people might be misled into believing that they have them, but that doesn't make them any more real.
Re:Not How I Expected the GPL to be Challenged (Score:2)
by Kjella (173770) on Thursday August 14, @03:58PM (#6699345)
(http://slashdot.org/)The section "You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program" seems too open to interpretation from my layman's perspective. I'm actually quite surprised that no one's ever gone to court over exactly what it means to say their application is based on another application with regards to what the GPL has to say. If a project with 1000 source files, totalling a million lines of code uses some GPL code in one of the routines that performs some utility function, is the application based on the GPL program?
Under all the normal disclaimers, the point is that if you argue this is not a work based on the program, you do not have a valid licence at all and can not use it at all without committing felony copyright violations. How SCO manages to make the "GPL invalid -> code public domain" is beyond any and all sense. If that held true, freeware, shareware, demos, everything given away without a monetary compensation would be public domain too...
KjellaRe:Not How I Expected the GPL to be Challenged (Score:2)
by HoldmyCauls (239328) on Thursday August 14, @10:24PM (#6702875)
(Last Journal: Friday October 03, @05:21PM)You may modify your copy or copies of the Program *or any portion of it*, thus forming a work based on the Program
The armchair lawyers to which you refer are reading the license as emphasized above. This implies that, yes, even that one simple function does constitute a basis for a "work based on the Program".
However, the judge and jury would most likely see the license as:
You may modify your copy or copies of the Program or any portion of it, thus forming a work *based on the Program*
which implies rather that the new work would have to provide similar functionality, or that the portion of that work for which that code is used would have to provide similar funcionality when compared to the original Program from whence it came. That is, a math library used in a tax program, if it used similar code to some GNU library libmath.so, would fall under the category so long as the judge and jury understood the KISS concept of small programs and libraries working together, as in the UNIX philosophy, as opposed to complex, (mostly) self-contained software systems, as in Office or even Blender, which appear to the user as such. However, a function from libmoz.so that returned, say, an HTTP packet, when used in a library designed with tax forms in mind, would probably not fit into that category, though the FSF might be able, through good lawyering, to persuade judge and jury, and RMS would simply have a heart attack and croak all at once.
Re:Not How I Expected the GPL to be Challenged (Score:1)
by GreyWizard (567129) on Friday August 15, @04:19PM (#6708092)
(http://google.com/ | Last Journal: Thursday September 26, @10:21PM)If a project with 1000 source files, totalling a million lines of code uses some GPL code in one of the routines that performs some utility function, is the application based on the GPL program? According to armchair lawyers on Slashdot the answer is YES, however would a judge and jury see it the same way? You expect to get a better answer than the one an armchair lawyer on Slashdot would give by... asking on Slashdot? Ingenious.
Re:Not How I Expected the GPL to be Challenged (Score:1)
by atomm1024 (570507) on Saturday August 16, @09:47AM (#6712235)But if using a few functions is not a "derivitive work," and the license can be ignored, then using SCO's UNIX code in Linux is perfectly OK, and this whole thing is moot! And if using a few functions is a "derivative work" then, duh, the GPL will hold up.
What the GPL is. Why this won't work. (Score:1, Insightful)
by Anonymous Coward on Thursday August 14, @01:58PM (#6697838)Every author of original works retains the copyright on those works, unless they choose to pass the copyright on.
A copyright is a governmental monopoly given to the author to allow them to control the production of copies of their work, to allow them to extract maximum profit from their activity (for a limited period... not so limited anymore, mind).
The GPL does not limit a person's copyright holding as the author. Such a license would be an illegal contract.
An author with copyright is able to offer a license to produce copies to publishing organisations. In the case of books, a publishing company. The author still holds the copyright, but they allow someone else to exercise it, based on conditions (either a set fee, or a more detailed contract). In fact, without these enabling contracts, copyright is merely a prison of ideas. They must be copied somehow and more authors are unable to do so themselves.
An author might write a book and then draw up a contract with a publisher to allow them exclusive rights to print hard copies for a limited time, with a set percentage of the profits going to the author. In the book business, it is common for publishers to borrow the copyright from the author for a given time, so that the author can't allow someone else to publish too. In the book business, three publishers producing the same new book is bad for the business of each publisher.
The GPL is a contract like the ones authors sign, that sits above copyright law. It extends it and makes it useful.
The GPL is a reasonable contract, by and large. It does not break the fundamental rights granted by law to the publishing parties, so it is a legal contract. Moreover, it does not damage copyright law, nor does it take the copyright away from the author illegally. If you don't like it, don't copy it and don't take advantage of the copyright monopolist giving you the ability to produce copies.
It is worth understanding, though, that each of us are publishers and have legal requirements to act in a responsible way.
But the GPL is quite, quite valid.
The Mac Observer - SCO's Attorney Explains Position On Linux, GPL, IBM In Interview
C|Net's Lisa Bowman has posted an interview with Mark Heise, a lawyer from the law firm that is representing SCO in its lawsuit against IBM, in which SCO's position concerning the disputed code, GPL, and IBM. From the article SCO's big legal gun takes aim:
This case has been characterized as an attack on the GPL.
We never raised the GPL in this litigation. We are somewhat surprised that IBM, which has this tremendous copyright and patent portfolio, is advocating the use of the GPL since it could have an impact on them.If, for example, their copyrighted materials are finding their way into the GPL, does that suddenly strip them of their rights? We don't think the GPL applies. We believe it is preempted by the federal copyright law.
The Free Software Foundation apparently disagrees. If you look at the terms of the GPL and the terms of copyright law, copyright law governs. It is the exclusive authority regarding the use, distribution, etc., of copyrighted material. In the GPL, (there is a section that) specifically says it applies only to the use and distribution. In other words, the exact same topics that are covered exclusively by the Copyright Act are covered by the GPL. Section 301 of the Copyright Act says the Copyright Act preempts any claims that are governed regarding use, distribution and copying. We believe that although the GPL is being tossed into the fray, it is preempted by federal copyright law.
If SCO were to prevail, do you think it would poke holes in the GPL?
The difference between SCO and other companies that have put their copyrighted material into the GPL is SCO didn't do it. SCO is not the one that put in these derivative works, which, as SCO has maintained, these companies were not allowed to do pursuant to their license. SCO is not the one that put its copyrighted System 5 source code into the GPL. It was another Unix licensee that violated the terms of their licensing agreement. So the difference is that SCO didn't say, "Here is my copyrighted material, and I'm knowingly and willingly giving it to you under the GPL. Here's my copyrighted work."You're not going to see that when you go into Linux. You're not going to see "copyright, The SCO Group." You'll see copyright IBM; you'll see copyright any other UNIX licensee, but it's not coming from us. The difference is that other companies have donated their copyrighted material, and they did so knowingly, and they're free to do that. But you're not free to take somebody else's copyrighted or otherwise protected material and put it into the GPL and suddenly it's for everybody.
What if, during the course of discovery or another time, you find that the code was originally under the GPL?
Using that hypothetical, if Caldera (International) put something into the GPL, with copyright attribution, the whole nine yards, they can't make the claim about what that thing is that they put in there. But that doesn't mean that--well, let's use an example. Let's say you have a hundred files, and you put one of your hundred files under the GPL. That doesn't mean you've lost the rights to your other 99 files. So I don't think it's going to have an impact.Mr. Heise addresses other aspects of the SCO controversy and the interview is a very interesting read, so stop by C|Net News and read the full article. For more information on this oingoing story, check out TMO's extensive coverage.
[July 16, 2004] NewsForge Toward true open source By: Tom Walker
In the GNU General Public License (GPL), Richard Stallman was working toward a noble purpose. Software should be free-as-in-freedom, and every user should be able to obtain the source code for the software they use. Unfortunately, that isn't the way things have turned out. The GPL has come to resemble digital rights management (DRM) more than it resembles freedom. Does that sound a little extreme? I'll explain.
When I buy music protected by DRM, the seller intends is to stop me from making copies of songs. When I use software that is licensed under the GPL, the developer intends to stop me from making the software "closed," or non-free. The intentions obviously aren't even slightly similar, but the consequences are. Both the GPL and DRM want to restrict my use, and re-use, of the music or source code that I obtain. Neither does what it was designed to do. Both have unintentional harmful effects.
The GPL has unintentional harmful effects
I have been discussing the effects of preventing people from copying, changing, and building on a program. I have not specified how this obstruction is carried out, because that doesn't affect the conclusion. Whether it is done by copy protection, or copyright, or licenses, or encryption, or ROM cards, or hardware serial numbers, if it succeeds in preventing use, it does harm. -- Richard Stallman
In trying to stop you from copying, DRM introduces many unintentional harmful effects. CDs with copy-protection typically won't play on PCs, and may even refuse to play on some modern car stereo systems. Whenever you introduce restrictions, there are side effects -- and so it is with the GPL.
The first side effect of the GPL comes from its legal complexity. The GPL scares business users and their legal departments, to the extent that many have a policy that boils down to "no GPLed software may be used anywhere in this company." They are unsure of the conditions under which they might be obligated to re-license their own proprietary source code under the GPL, and for the sake of competition they want to stay as far away from those conditions as they can.
The main harmful effect of the GPL is the "gated community" it creates. When you release your source code under the GPL, the only people who can re-use it are those who also license their software under the GPL. GPL users are quick to complain when other licenses are "incompatible" with the GPL, but the GPL itself is incompatible with just about everything.
If I'm part of the GPL community, I can re-use code from any other piece of GPLed software, no matter how small and insignificant that piece of code might be. It might not be a large part of my program: I might, for example, be taking a compression routine to add to my new open source Web browser. Then I just add credit to the documentation.
The Readline library implements input editing and history for interactive programs, and that's a facility not generally available elsewhere. Releasing it under the GPL and limiting its use to free programs gives our community a real boost. At least one application program is free software today specifically because that was necessary for using Readline. -- Richard Stallman
What if my Web browser is proprietary? I'll have to write my own compression routine (or hack around the restriction in some odd way, like making the compression routine into a stand-alone GPLed program and then calling it from my proprietary program), or make my program free software. "Well, that's good," you say, pointing at the Stallman quote above. Ah, but what if I want to release my program under the BSD license, or some other alternative open source license? Then I'm screwed. I can't use your GPLed compression routine, unless I try behave in the same way as the proprietary software maker might -- but that would be frowned upon.
The rest of the open source community is standing at the gates of free software, denied access to the masses of GPLed source code within. Is this free-as-in-freedom?
The GPL doesn't do what it was designed to do
In the GNU project, our aim is to give all users the freedom to redistribute and change GNU software. If middlemen could strip off the freedom, we might have many users, but those users would not have freedom. So instead of putting GNU software in the public domain, we 'copyleft' it. Copyleft says that anyone who redistributes the software, with or without changes, must pass along the freedom to further copy and change it. Copyleft guarantees that every user has freedom. -- Richard Stallman
DRM doesn't really stop me from making copies of my music: as long as people want to share their music, they will find ways to circumvent DRM measures. Likewise with the GPL. You can't force some people to keep their software free: they want it to be proprietary, and they will circumvent the license.
Earlier, I alluded to "hacking" the GPL's restrictions. Here's an example. Say someone has produced a program under the GPL that takes a document from any version of Microsoft Word as input, formats it as HTML, and spits it out again. I want this functionality in my proprietary word processor, Wordwalker 2004. I have two choices: write my own version, or release Wordwalker as free software under the GPL. Right? Wrong. I can just include the GPLed converter program (with its source code) on the distribution media with my proprietary software (the GPL specifically allows this). I can run it silently as a subprocess (this is a grey area, but is generally believed to be allowed by the language of the GPL), sending it the Word document files and using its output in my proprietary program.
This is not what Stallman intended. I would have made use of advances made by free software, and yet my users would not ever get to see my own source code. If they want support, they've still got to come to me -- I could even stop them from hiring someone else to make changes to the source of the document conversion component, by making my proprietary routines reject any version of it that has the wrong checksum.
Want more? Let's look at the KDE/QT situation. KDE source code is released under the GPL, but it is linked to Trolltech's cross-platform QT library. GPLed versions of QT are available for X11, Macintosh, and embedded platforms -- but if you want a Windows version, that'll be $1,550, please. It's another GPL exploit: GPLed code links to software that is proprietary on one platform, and suddenly that code isn't looking so free any more.
There is no way the GPL can stop this sort of thing from happening, any more than it can stop me from writing a free software program that relies on the proprietary Windows API. But the worst is yet to come.
More and more often, the applications we use aren't on our desktop -- they're on someone else's server. Say I'm running a Web site called Tell Your Fortune. All my site does when you visit it is run a GPLed version of the fortune program that I modified to listen on port 80 and respond to HTTP requests. Can you get the source to my modified fortune? No. I haven't redistributed it in binary form, so you have no rights to the source.
This could be happening all over the Web. You could be relying on heavily modified versions of GPLed software every day: at Google, at Amazon, at eBay -- you have no real way of knowing. You are a user of the software, but you have no access to the source code.
You can't stop undesired usage, so leave it open
If you can't stop people from sharing your copy-protected CD, then why inconvenience your normal customers? We have seen how crafty proprietary users can make use of GPLed code without distributing their changes, and we've seen how the GPL stops others in the open source community from re-using your code. Why restrict your friends for the sake of non-working measures against your enemies?
This is where BSD and MIT-style licenses come in. These are licenses that, basically, say you are completely free to re-use the source code anywhere you like, even in proprietary software, as long as you give credit to the original authors.
Just imagine not having to worry about licenses any more. If I want to take a compression routine from BSD-licensed code, I can just use it, and add credit to my documentation.
You might notice the parallel with how people in the GPL community can re-use GPLed code: put simply, BSD-style licenses knock down the community's gates and let everyone use open source code for whatever they like. Here's the ultimate test of freedom: can I use GPLed code in my BSD-licensed program? Can I use BSD-licensed code in my GPLed program? (No I can't, and yes I can).
If you really want to share your code instead of jealously guarding it, use BSD-style licensing. If you care about receiving credit in other people's documentation, then you could even put your source code in the public domain! Imagine an open source community where software can be re-used like SQLite's public domain database code:
Anyone is free to copy, modify, publish, use, compile, sell, or distribute the original... code, either in source code form or as a compiled binary, for any purpose, commercial or non-commercial, and by any means. -- SQLite copyright
That's true freedom, and that's true open source.
SSRN-Viral Contracts or Unenforceable Documents Contractual Validity of Copyleft Licenses
by
ANDRES
GUADAMUZ University of Edinburgh
European Intellectual Property Review, Vol. 26, No. 8, pp. 331-339, 2004
Abstract:
This paper asks the question of whether copyleft free software licences constitute valid legal contracts, in particular with regards to the fact that it may create obligations through a distribution chain. There is increasing interest about the non-proprietary licence model expressed in popular documents such as the General Public Licence (GPL), but not enough work has been done in asking perhaps the most important question of all: are these contracts enforceable? Is there really a viral transmission of obligations? To do this the GPL licence will be analysed to try to determine whether or not the terms included are contractually valid. Keywords: Copyleft, licences, copyright, GPL, validity, unfair terms, competitionJEL Classifications: K12, K19
[Aug 19, 2004] Between the Lines » GPL could get its day in court. Finally. - ZDNet.com
The Free Software Foundation’s GNU General Public License (GPL), which is the Open Source Intiative approved license under which Linux is distributed, and which has served as a significant backdrop to SCO’s various lawsuits, may finally get its day in court. In a motion for partial summary judgment filed Wednesday, IBM has asked the court to rule in favor of its counterclaim alleging SCO has violated the terms of the GPL.
In a world where copyright law rules, just the validity of the GPL as a license under which technology can be distributed has yet to be really tested in court. In particular, IBM is claiming that, since SCO has through its lawsuits and public statements effectively renounced the GPL, it shouldn’t be permitted to distribute IBM’s copyrighted code (code that IBM contributed to Linux) in its own versions of Linux. Though some community licenses have a provision that terminates a licensee’s rights should that licensee sue other members of the community on the basis of their usage or distribution of the technology in question, the GPL doesn’t have such a provision. But, in an memorandum that’s associated with IBM’s counterclaim, IBM claims that, by threatening and suing Linux users such as AutoZone, it has triggered the forfeiture of its rights under the GPL since those threats and suits amount to the demand of fees considered excessive under the terms of the GPL and the Lesser GPL (LGPL). Considering that IBM’s counterclaim looks to invoke IBM’s rights under the GPL/LGPL while revoking those of SCO’s, the court’s treatment of the counterclaim could very well end up being a test of open source licensing. The plot thickens.
SCO to attack validity of Linux licence - ZDNet UK News SCO's strategy for its lawsuit against IBM could destroy the legal foundation of Linux and related software
SCO Group is planning to argue in its court battle against IBM that the General Public License (GPL) covering Linux and other open-source software is invalid, according to a report.
SCO, owner of several key copyrights related to the Unix operating system, has been aggressively defending its intellectual property holdings connected to Unix System V, and filed a $3bn (Ł1.87bn) lawsuit against IBM earlier this year. The suit claims that IBM has committed trade-secret theft and breach of contract for allegedly copying proprietary Unix source code into its Linux-based products.
IBM's defence will partly rest on the argument that SCO distributed its own version of Linux for many years, containing the allegedly infringing code, and that by this action effectively placed the code in question under the GPL.
SCO is planning to respond that the GPL itself is invalid, SCO's lead attorney, Mark Heise of Boies Schiller & Flexner, told the Wall Street Journal in a report on Thursday.
If SCO is successful, its lawsuit would undermine the legal basis for Linux and much other open-source software, although the open-source community has prepared an alternative licence that could be used by Linux if the GPL is invalidated.
SCO will argue that the GPL's provisions allowing unlimited copying and modification are not compatible with US copyright law, which allows software buyers to make only a single copy, says the Journal. Heise said the GPL "is pre-empted by copyright law", according to the report.
Broadly speaking, the GPL allows anyone to modify and redistribute a piece of software covered by the licence, as long as the modified code is returned to the developer community. The licence also requires that software which incorporates GPL-covered code must itself be placed under the GPL, a provision that led a Microsoft executive to compare the GPL to an "un-American cancer".
Heise's remarks echo the comments of SCO chief executive Darl McBride during a recent teleconference, in which he announced a set of licence fees that companies using Linux could pay if they wanted to avoid legal action by SCO.
McBride was unusually blunt in attacking open-source software, saying the GPL is fundamentally flawed from a business and legal perspective. "At issue here is more than just SCO and Red Hat," McBride said. "What is at issue here is whether intellectual property rights will have any value in the age of the Internet."
Red Hat, one of the largest distributors of Linux and related applications, filed a suit against SCO earlier this month in the US District Court in Delaware. The suit in part seeks a court ruling affirming that the company has not violated SCO's trade secrets or intellectual property rights. It claims that SCO's actions are intended to hurt Red Hat and other Linux backers by creating "an atmosphere of fear, uncertainty and doubt about Linux", according to the suit.
CNET News.com's Matt Hines contributed to this report.
LinuxPlanet - Reports - .comment Judgment Day for the GPL - Determining the Legality of the GPL
|
|
SCO Still Contends GPL Is Unconstitutional
Stowell said the company's U.S. District Court filing this week, called SCO's Answer to IBM's Second Amended Counterclaims, here in PDF form, no longer explicitly states that the GPL is unconstitutional, but he said the Lindon, Utah-based company does maintain the following positions:
- That "the GPL is unenforceable, void and/or voidable, and IBM's claims based thereon, or related thereto, are barred."
- That "the GPL is selectively enforced by the Free Software Foundation such that enforcement of the GPL by IBM or others is waived, stopped or otherwise barred as a matter of equity."
- And finally, that "IBM's claims are barred or pre-empted, in whole or in part, by the laws of the United States."
Putting all of these together, Stowell said, adds up to SCO still claiming that the GPL is unconstitutional. This explicit claim, however, has been removed from SCO's legal filings.
Tom Carey, a partner and chairman of the business practice group at Bromberg & Sunstein LLP, a Boston intellectual property law firm, said he doesn't see this adding up to SCO continuing to argue that the GPL is unconstitutional.
"I think they're backing off on the constitutional issue, but what I see is that they're not backing off the argument that the GPL is pre-empted by the copyright act."
Carey added, "I hardly know where to begin with SCO's second argument. It is based on factual and legal assertions that are incorrect. The Free Software Foundation [FSF] does everything within their resources to enforce the GPL.
"I'm unaware of the FSF turning a blind eye to violations of the GPL. In any case, though, the licensor is not under any obligation to enforce every license."
As for SCO's point that IBM's claims are barred by U.S. law, Carey said he sees this "as SCO restating the argument that the GPL is pre-empted by the copyright act."
In any case, Carey said, "Attacks on the GPL are far-fetched and a little bit desperate."
Stacey Quandt, principal analyst at Quandt Analytics, remarked, "SCO's prior claim that the GPL was unconstitutional was equivalent to Microsoft's claims about open source being un-American—totally ridiculous."
Thus, while the GPL's legality clearly remains a focus for SCO's attempts to win its legal war with IBM over Linux, it is not clear to outside observers that the constitutionality of the GPL is really still on the table, despite SCO's claims to the contrary.
BW Online August 13, 2004 A Big Fly in the Open-Source Soup
Linux, the most important piece of free, open-source software, began as the effort by a Finnish college student, Linus Torvalds, to create the functional equivalent of the Unix operating system, developed and then owned by AT&T. Intellectual-property questions about Linux came to the forefront after the SCO Group (SCOX ), which acquired the Unix trademarks, launched a series of lawsuits against alleged infringers of its rights.
POTENTIAL INFRINGEMENTS. The central case, a 2003 suit against IBM (IBM ), an important corporate promoter of Linux, has degenerated into a messy contract dispute with no intellectual-property issues left on the table. SCO's threats to sue companies that use Linux have almost entirely evaporated.
But now another problem has surfaced. Open Source Risk Management, a new outfit that indemnifies its customers against infringement claims, found in a review of Linux code that the operating system potentially infringes on 283 patents. Although IBM declared it would make no effort to enforce its 60 patents involved, some are held by Linux foes, including 27 by Microsoft.
The potential patent infringements pose no immediate threat to Linux. Such disputes typically take years to resolve, and courts rarely issue injunctions against alleged infringers. But the uncertainty is taking a toll. In the most significant response to date, the city government in Munich, Germany, has suspended a massive transition of desktop computers from Microsoft Windows to Linux, pending clarification of the patent situation (see BW Online, 8/9/04, "Will Legal Fears Freeze the Penguin?").
"ETHICAL POLLUTION"? Most patent disputes are settled with licensing agreements, but this is a tough course for Linux to follow. With no single owner, the closest thing it has to a central authority is the Open Source Development Lab -- but the organization has no way to pass any licensing fees on to users. Perhaps the best approach would be if major Linux distributors, such as Red Hat (RHAT ) and Novell (NOVL ), and companies for whom Linux is strategically important, such as IBM and Hewlett-Packard (HPQ ), could set up a fund to deal with potential patent issues.
But open-source proponents also have to get their own intellectual-property house in order. The development of open-source software is increasingly dominated by corporate interests that, one way or another, want to use Linux, Apache, and other open-source products to make money.
But a slew of backers see open-source software as part of a social and political movement that's frankly anti-corporate. Richard M. Stallman, founder of the Free Software Foundation and a man who commands enormous respect among software developers, argues in the essay Why Software Should Not Have Owners: "The system of owners of software encourages software owners to produce something -- but not what society really needs. And it causes intangible ethical pollution that affects us all."
MURKY MODEL. That view doesn't get a very sympathetic hearing at, say, IBM headquarters. But Stallman's thinking suffuses the GNU General Public License (GPL), a document that governs the distribution of Linux and many other open-source programs. The GPL not only requires that any programs licensed under it be freely distributed but also that any modifications made to the software, or any other software derived from it, are themselves automatically covered by the GPL.
Unfortunately, the GPL is hardly a model of clarity, and few disputes involving it have gotten to court, so case law has done little to clarify its meaning. This is causing reservations as more and more companies consider using GPL-covered software to develop either commercial programs or software for their own use. Apple (AAPL ), for example, rejected Linux as the basis of Mac OS X in favor of another open-source, Unix-like operating system called FreeBSD, largely because the licensing terms were less restrictive.
What exactly constitutes a "derivative work" automatically covered by the GPL? "The truth is we don't really know, and there are reasonable arguments on both sides," Jay Michaelson, co-founder of software company Wasabi Systems and a lawyer and a programmer, wrote in the May issue of the Association for Computing Machinery's journal Queue. "Some people argue that the GPL as a whole isn't even enforceable.... At the end of the day, the unfortunate reality is that developers should check with the companies' legal departments before proceeding with any GPL-related development because the requirements may vary on a case-by-case basis."
RELIGIOUS FERVOR. Bright as it is, the future of commercial open source might be considerably brighter if Linux and other programs went to a more commerce-friendly license with fewer complexities and ambiguities than the GPL. There's plenty of precedent. The BSD license, the Mozilla Foundation license used for browsers, and the Apache license all provide for free distribution of code and source code with fewer restrictions than the GPL.
That would be tremendously controversial in the open-source community, where the GPL sometimes seems more like an object of religious veneration than a legal document, but it would be good for all concerned.
Linux Today - Editor's Note LinuxWorld, The Summer of Suits
Regardless, I have begun to wonder if LinuxWorld, as a community event, has just been marginalized to death. It is now the home of the vendors and the customers,and much of the flavor of the Linux community has been dulled. I found myself wishing that I'd gone to OSCON this week instead.
da - Subject: Money grubing jerks ( Jul 29, 2004, 00:12:49 ) |
Well said Brian, and thank you for your contribution to the community.
Now that Linux/OSS is as good as it is and getting better every day, the
money grubing jerks of the world are out to exploit it for every penny
they can. No doubt, as they do this, there won't be as much as a simple
thank you to all the people that made it all possible for them. I find it
funny that they all had no interest in pushing Linux up the hill, but now
that it's at the top, they're all for riding it down the other side. The longer you live, the more of it you see. Human beings are indeed, funny animals. Thanks again Brian, da |
:57:24 ) |
Well cry me a river.....after all you guys keep pushing Linux in the
corporate market so now you should welcome the money grubbing jerks with
open arms. Sheesh, what is wit you guys, you want Linux to be your private play ground yet you want world domination....can't have both. |
[Aug 13, 2004] OfB.biz Open for Business - The MySQL License Question
The MySQL License Question
Date: August 13, 2004, 11:15:53 EDT
Topic: Free Software
MySQL AB's namesake database is a package that many would list among the crown jewels of Free Software. The Swedish company's database has been deployed over five million times by the company's own count. Yet, some, quite legitimately wondered if certain wording on the MySQL site might indicate the company is backing away from Free Software, and, more specifically, the GNU General Public License. We wanted to know if this was an actual concern or simply a misunderstanding, so
OfB contacted MySQL AB to find out more information.
The whole question arose from the text MySQL AB publishes on its web site concerning why one would need to purchase a commercial license for its software. "When your application is not licensed under either the GPL-compatible Free Software License as defined by the Free Software Foundation or approved by OSI, and you intend to distribute MySQL software (be that externally to customers or internally within your organization), you must first obtain a commercial license to the MySQL product," the site explains. At press time, the remark concerning internal distribution had been removed after the commercial licensing page was revised based on user feedback, MySQL AB told OfB.
At first glance, this might not catch anyone's attention, but after considering it, it becomes apparent that this sounds like stricter requirements than those laid down by the General Public License. For example, the Free Software Foundation's documentation on the General Public License, which they wrote, explains that "[y]ou are free to make modifications and use them privately, without ever releasing them." The document then continues, "This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization." If this is the case, a company desiring to keep its code private would not need to purchase a commercial license as the MySQL site indicates.
The information on MySQL's commercial license page also seems to be a bit far reaching when it suggests that one's program must be licensed under the GPL or another Free Software license if MySQL is distributed with the product. A good analogy here is that it is legal for a proprietary web browser to communicate with a GPL licensed web server, and vise versa -- the programs are communicating to each other, but not actually combining code together. In the same way, it is theoretically possible to communicate with the MySQL server either using a third party Free Software tool that allows linking to proprietary packages, such as one licensed under the LGPL or BSD licenses or by developing a proprietary program that can communicate with MySQL through networking protocols. In plain English, this means there are ways that one could have a proprietary program communicate with a GPL licensed program without violating the GNU General Public License. Furthermore, simply distributing a proprietary product and GPL licensed product together is called "mere aggregation," something explicitly permitted by the GPL.
One developer from a small consulting firm who requested anonymity explained his concerns about the issue and how it had led the company he works for to have all of its clients purchase MySQL licenses out of fear of litigation. "MySQL AB has bent the intentions of the gpl to say that any proprietary application I write that causes my customer to have to install a copy of MySQL, whether or not it uses the MySQL client libraries, must be licensed under [the GPL]."
We wanted to know if this assertion was correct or if MySQL's site was simply a bit confusing on the point of when licensing is required, so we contacted them. Zack Urlocker, MySQL's vice president of marketing, agreed to answer our questions on the matter.
The big question we wanted to know was if MySQL was adding restrictions to the GPL or if the terms on the site were simply a broad overview that represents suggestions that in no way alter the permissions given by the license. Urlocker confirmed to us that MySQL did not consider the page to be an addition to the GPL, but rather information for those attempting to understand -- in simple terms -- why they might need a MySQL commercial license. He noted that it doesn't even begin to attempt to cover all possible scenarios, just the ones the company believed to be the most common. Does that mean that MySQL accepts the Free Software Foundation's positions on what the GPL permits? Urlocker said this was the case, telling OfB that "we tell people to talk to the guys at the FSF," if they have questions about the terms of the license.
On the other hand, while Urlocker said the company is not adding restrictions on to the GPL, he felt that attempting to, as he put it, "circumvent" the GPL by communicating with the database using a third-party tool and TCP/IP or another protocol was a gray area and while perhaps following the letter, it was not following the spirit of the General Public License. He remarked that it ignores the "spirit of [MySQL's] 'Quid Pro Quo' philosophy," and that developers should "abide by the GPL license, not seek loopholes to exploit it."
The documentation on the General Public License from the Free Software Foundation, the creator of the license, is silent on the issue of whether software communicating with a GPL licensed program via standard protocols must be under a compatible license. Bradley Kuhn, executive director of the FSF, told us that "[the] FSF maintains that deciding what types of activity are prohibited by the GPL is extremely context-dependent." He continued by asserting "since GPL relies completely on copyright law, whether or not something is a derivative work depends on what is said in the copyright law and surrounding case law, not any particular thing the GPL tself says."
Kuhn declined to comment on the case of MySQL and its licensing. "We have no specific comment on how MySQL AB structures their marketing literature."
Some sources we talked to suggested that unixODBC could be used to connect a proprietary program with the GPL licensed MySQL, since unixODBC is licensed under the LGPL. Nick Gorham, of the unixODBC project, responded, "Its certainly my intention that commercial apps can use unixODBC, that's why the driver manager and support libs are released under the LGPL." On the other hand, he also noted, "I would say that if the [MySQL] driver is used for a commercial purpose, then the presence of other code [unixODBC] won't change the fact the driver is being used commercially," he told us.
Urlocker pointed out that "it is never wrong to buy a commercial license," noting that "we like being able to continue releasing new versions" of MySQL, and that the commercial licenses are what generates the revenue that MySQL AB uses to pay its development team to continue developing the MySQL database.
Emphasizing the company's commitment to the GPL, he stressed that MySQL thinks "the GPL is the best license there is" and that MySQL AB works "closely with the Free Software Foundation." On the flip side, Urlocker said the company would consider a different license in the future, if a better one became available. "The GPL is not a perfect license ... but it is the best that is available."
Concerning the fear of litigation suggested by the consultant mentioned earlier, Urlocker said, "We are never going to be the license police." While the company has no desire to legitimize uses it sees as going against the philosophy of the license, he emphatically denied that MySQL had any interest in spending time suing users over what it sees as gray areas.
"[MySQL] is always open to feedback from our users on ways to better serve them whether it's a licensing issue or a product feature, documentation, support, etc.," Urlocker told us.
The main point he made to us is that his company believes "strongly in Open Source." The company has actually tried to increase the freedoms provided by the GPL, Urlocker asserted, with the "MySQL FOSS exception" that allows some Open Source Initiative approved licenses, that are incompatible with the GPL, to still make use of the GPL licensed version of MySQL.
New Offerings on the Horizon
Speaking of the new releases made possible by MySQL's dual licensing business model, Urlocker pointed out that MySQL 4.1 is presently in beta and "should be released for production" within four to five weeks. According to information provided by the company, the new release will feature OpenGIS geographical data support and the ability to send multiple SQL statements via a C language MySQL API call and receive the results back at once, among other additions and enhancements.
MySQL 5.0, the first major update to the product since the MySQL 4.0 "production" release was announced in early 2003, is presently in the alpha stage of development. "New stored procedures and views" are among the features that this upcoming release will include. Some other interesting features may also make it into the code before the release, but Urlocker said that his company prefers to "under promise and over deliver."
Urlocker also pointed out with excitement the changes he sees in the Free Software and Open Source sector. "You use to have to be a pioneer [to use Open Source]," he told us, but he believes that is no longer true. He noted, for example, that there are now over a hundred different products that come with MySQL, and third party support is growing, with such notable additions as Quest Software's preview release of the TOAD for MySQL development environment and upcoming support in Embarcadero Technologies' cross-platform and cross-database administration tool, DBArtisan.
He also pointed to the introduction of premier support by MySQL. Urlocker said that this was intended to provide services such as a technical onsite account manager, for organizations requiring advanced, commercial level support from MySQL AB. "As Open Source becomes more popular, corporate managers are looking for these types of things," he told OfB.
Due to the company's quick expansion and the growth of the Free Software sector, Urlocker also told us his company is presently seeking to fill quite a few job positions in the United States and abroad. Those interested in available positions can find out more on the MySQL web site.
Timothy R. Butler is Editor-in-Chief of Open for Business. You can reach him at [email protected].
[May 24, 2004] Latest MySQL Fails to Quiet Licensing Critics By Sean Michael Kerner
Open Source database vendor MySQL AB released its latest incremental release last week (version 4.0.20), but according to some in the community, it still doesn't address what some say serious licensing concerns.
The licensing issue prevents it from being included in some Linux distributions and working together, from a licensing perspective, with PHP. Last week, Red Hat's community Fedora Project released Fedora Core 2 and for all of its updated and improved packages, it had one notable omission: the 4.x version of MySQL.
"Currently, MySQL is not included in Fedora Core 2 due to conflicts with the MySQL licensing scheme," Fedora Project volunteer Jack Aboutboul told internetnews.com. "The change in licensing from LGPL to GPL now prohibits inclusion of MySQL code in any software that is not explicitly licensed under the GPL, such as PHP."
MySQL AB changed the license on some of its included software libraries from the less restrictive LGPL
to GPL last year. One of the fundamental differences between the two licenses is that with the LGPL, non-GPL or proprietary software may be tightly linked with it, which is not the case with GPL licensed software. MySQL came up with something called the FOSS licensing exception in March, which was supposed to alleviate the problem. One of the programs that was most strongly affected by MySQL's licensing shift is the PHP open source programming language, and part of the LAMP (Linux, Apache, MySQL, PHP) acronym that dominates much of open source development.
In an e-mail interview with PHP and Zend co-founders Andi Gutmans and Zeev Suraski said they still have concerns with MySQL's licensing. "From a strict legal standpoint, the MySQL FOSS still does not solve all of the problems with the new MySQL licensing," Gutmans said.
The PHP founders acknowledged that MySQL's FOSS exception lists most of the open source licenses in use today. However, they claim, it still poses a significant issue for certain applications.
"Effectively, the FOSS prevents people from using closed-source software in conjunction with the MySQL client library, without purchasing a license," Gutmans explained. "While it might sound reasonable at first, effectively, this is a very odd clause that, if taken seriously by MySQL (the company), poses a serious limitation on the ability of users to develop and distribute MySQL based applications."
The two cited numerous examples where an environment has MySQL and and PHP that may be linked to other third party closed libraries like Java VM or an Oracle Server.
According to Gutmans, "PHP's tolerance to closed-source software is, at least theoretically, impaired by the complete lack of tolerance for closed-source software of the MySQL client library, even when one has nothing to do with the other."
They do not believe that the MySQL licensing shift was an intentional ruse to collect money from true open source users of the software.
"Our understanding is that they're trying to make sure that the ones who are really selling MySQL-based applications have to pay," Gutmans said. "However, the way the FOSS is phrased right now, even common people that don't want to sell MySQL or anything similar can be hurt."
Suraski and Gutmans said they had discussed the issue with the MySQL team and they are aware of the issue and are continuing to try and fix the problem. In their view, MySQL AB wants to fix the problem, "but they still haven't managed to reach a consensus with their lawyers on how to fix it without taking a risk."
Developers need not shy away from MySQL in light of this situation according to the PHP founders, especially since in their view the issues are unintentional.
"But developers who don't feel comfortable with the FOSS the way it is now definitely have the option of using another solution, be it PostgreSQL or something else," Gutmans said.
PostgreSQL may, in fact, be a beneficiary of MySQL's licensing issues, at least if you believe the PostgreSQL people. According to Josh Berkus, a member of the PostgreSQL core team, based on 'anecdotal evidence' there has been an increase in PostgreSQL downloads since the licensing issue emerged. However, Berkus admits that he can't prove it with hard numbers.
"Since our downloads are heavily mirrored, and our last new version coincided with the MySQL licensing problems, it's a little hard to prove it empirically," Berkus said. "I will say, officially, that PostgreSQL is BSD-licensed, we have always been BSD-licensed, and nobody has ever been compelled to pay a single penny for a 'commercial license' from us. Many people and companies turn to PostgreSQL in order to achieve complete freedom from licensing hassles."
Fedora Project community spokesperson Jack Aboutboul won't be switching to PostgresSQL. "At this time, migration to Postgres is unnecessary," he said. "Users can continue to use MySQL 3.x, and hopefully by FC3, this issue will be resolved. In a sentence, it's not that we don't want to include MySQL, it's just that nothing was released using the license exception that's usable to us."
Not all Linux distributions have the same opinion on the issue. The latest release of Novell SUSE, version 9.1, includes MySQL 4.x.
The Swedish-based MySQL is usually touted as being an open source success story with it dual licensing scheme that allows it be open source as well as a commercial product. At a recent users conference in Orlando (), MySQL AB unveiled its latest technological innovation: a clustering version intended to significantly improve database availability and performance.
[Mar 12, 2004] MySQL addresses open-source license problem CNET News.com MySQL, an open-source database company, has taken a step to mend a rift in the open-source world by updating a controversial licensing provision that had broken a close tie between the MySQL database and another software package. By Stephen Shankland
The rift divided MySQL and PHP, software that lets computers construct customized Web pages on the fly. The two packages are found side by side so often--along with the Linux operating system and the Apache Web server--that there's an acronym, LAMP, to label the software combination.
On Thursday night, MySQL published a license exception that, the company said, permits PHP to resume its previous practice of bundling MySQL components called libraries, said Zack Urlocker, MySQL's vice president of marketing.
MySQL's exception is "a step in the right direction," said Andi Gutmans, a PHP creator and vice president of technology for Zend, a company that sells PHP programming tools. Gutmans also expressed confidence that other remaining issues will be resolved.
MySQL's move illustrates the growing pains in the open-source software movement as it becomes a mainstream part of the computing industry.
Much attention is devoted to cases such as the SCO Group's attack on Linux, where there's friction between the open-source community's philosophy of sharing and the proprietary software world's love of secrecy. But the MySQL issue shows that there are challenges that must be addressed even between stalwart allies in the open-source movement.
And there are plenty more complexities. Some of them will surface next week at the Open Source Business Conference in San Francisco, at which MySQL will tout the benefits of the licensing strategy that lay at the root of the PHP issue.
MySQL, fellow open-source database company Sleepycat and programming component maker Trolltech employ a strategy under which they make their software available both under an open-source license for use in open-source software and under a commercial license for inclusion in proprietary software.
The dual license approach--which only works in the case where a single entity owns the copyright to all the source code in a software package--will be the crux of boasts expected from companies at the conference that they've all doubled revenue.
In MySQL's case, the Swedish company uses the General Public License (GPL) to cover its database software and the supporting libraries that other programs use to interface with the database. Previously, though, the libraries were covered by the Lesser General Public License (LGPL).
An essential difference between the two licenses is that proprietary or other non-GPL software may be tightly linked to LGPL software.
Until June, the PHP package had included MySQL's libraries, ensuring that PHP programmers could easily take advantage of the database when building a Web site. But the license change by MySQL led PHP creators to remove the MySQL components.
The library change didn't mean that PHP and MySQL couldn't be used together, only that MySQL "was downgraded from its unique status to the level of most other PHP extensions," where other databases such as Oracle and PostgreSQL are, Gutmans said.
In a later beta version of PHP, the programming team bundled different database software, a package called SQLite.
MySQL made the library change because some with proprietary software were inappropriately using the MySQL software, arguing that the LGPL libraries were an acceptable interface for their proprietary software, Urlocker said.
"There were people misusing the GPL, using our server tightly coupled with their applications, claiming the GPL didn't apply because the client libraries weren't under the GPL, they were under the LGPL," Urlocker said. The change meant that commercial software companies no longer could claim they didn't need to purchase a commercial license from MySQL.
The change affected open-source allies, though--not just PHP and Zend but also Red Hat, the leading seller of the Linux OS.
"Red Hat logged the issue with MySQL maintainers that MySQL could no longer work with PHP packages because of these licensing changes; hence Red Hat (wasn't) able to upgrade to this newer version of MySQL because of this licensing conflict with other packages that are shipped" in Red Hat's distribution of Linux, Karen Bennett, vice president of tools and application development, said in a statement. "We had to pull the upgraded package from our beta of RHEL 3"--Red Hat Enterprise Linux, the company's premium product.
Red Hat doesn't plan on including MySQL in the future, spokeswoman Leigh Day said, although not because of the license issue. Rather, it was a business decision: "Our core competency is not to service and support a database," Day said, likening the situation to the company's termination in 2002 of the Red Hat Database project it began in 2001.
These issues should now be resolved, Urlocker said. Because MySQL owns copyright to all the MySQL code, it can include additional license provisions to its software. The new provision, called the Free and Open Source Software License Exception, "enables people to use MySQL client libraries with other open-source projects under other open-source licenses other than the GPL," Urlocker said.
The exception is "very encouraging," Gutmans said in an e-mail interview. "However, we are still working with MySQL on other problematic aspects," he added.
The next issue to be addressed is a provision that will enable proprietary software libraries to run side by side with MySQL's libraries, Gutmans said. He said he expects that issue to be worked out "in coming weeks."
PHP once stood for Personal Homepage and now stands for PHP: Hypertext Preprocessor.
Related News
... ... ...
... .... ...
LGPL reciprocity terms still unclear OSL and AFL licences offer closure
By N. Alex Rupp: Sunday 20 July 2003, 07:08
IN A RECENT post to the POI developers list, Andrew Oliver interpreted a statement made by Dave Turner of the Free Software Foundation regarding the reciprocity provisions of the LGPL license when applied to Java.
Oliver's conclusion was that linking through import statements would indeed be covered under the "reciprocity provisions" in the LGPL. This news has reawakened debates in the software community regarding the risks of the LGPL and the failure of the FSF to clarify the matter.
Oliver has now released the entirety of Turner's emailed response, which begins:
"> Dear Mr. Turner: > > Brett Smith referred me to you regarding a question regarding the Lesser Gnu > Public License (LGPL) in regards to Java. It is the interpretation of most > of the open/free software communities that the use of a "jar" file by a > piece of software linked via a Java "import" statement does not bind the > linking work under the terms of the LGPL. The Apache Software Foundation, > presently takes a more conservative view and thus projects of the ASF are > not allowed to link/distribute LGPL programs into Java projects of the > foundation. This sort of linking falls under section 6 of the LGPL."
In his first response, Dave Turner refers Oliver to the license. He does not confirm Oliver's assertion and to assume so is dangerous. Presumably, Oliver asked Turner the question in the first place because the license was unclear. The second part of the letter continues:
"> Roy Fielding offered the following description of the issue: > > > " > > No. What the FSF needs to say is that inclusion of the > > external interface names (methods, filenames, imports, etc.) > > defined by an LGPL jar file, so that a non-LGPL jar can make > > calls to the LGPL jar's implementation, does not cause the > > including work to be derived from the LGPL work even though > > java uses late-binding by name (requiring that names be > > copied into the derived executable), and thus does not (in > > and of itself) cause the package as a whole to be restricted > > to distribution as (L)GPL or as open source per section 6 of > > the LGPL. " > > Is this statement true with regards to the use of LGPL Java libraries by > non-LGPL Java libraries? I appreciate your assistance in this matter. If I understand the statement correctly, yes -- that's exactly what section 6 is for."
Again, Turner has managed to evade the question. Far from making a simple, clear-cut definitive answer, he has wrapped his answer with two clauses. The first, "If I understand the statement correctly" shows either that he does not fully comprehend the question, is unwilling to admit that he understands the question, or that he is unwilling to write a simple and authoritative answer. The second, "that's exactly what section 6 is for", again refers the questioner to the license. He might be confirming Roy Fielding's assertion, or he might be confirming that section 6 covers it. Either way, his answer is wrapped in the "If I understand the statement" clause.
The LGPL license is unclear on its reciprocity requirements for software written in Java. Because the FSF has obfuscated the matter (if not deliberately then consistently), the issue remains a risk for software developers.
Which is why, to date, the Apache Software Foundation has yet to lift its prohibition on linking to LGPL libraries, binaries or including LGPL source code in its products.
Clear alternative from the OSI
Larry Rosen, the well known general counsel and secretary for the Open Source Initiative has definitively stated that with regards to its reciprocity provisions, "The Open Software License (OSL) can be used for the same purposes as the LGPL and the GPL".Rosen further clarifies the matter by offering the Academic Free License, which
"addresses issues of patent, trademark, warranty, jurisdiction and venue, contributor recognition, etc., in ways entirely consistent with the "BSD" philosophy of open source. AFL-licensed software can be used in combination with any other software, open source *or* proprietary, for any purpose whatsoever, including to create derivative works. This new version of the AFL also helps eliminate possible confusion between academic-style licenses and reciprocal licenses [see, for example, the GPL, www.fsf.org/licenses/gpl.html, and the Open Software License (OSL), www.rosenlaw.com/osl2.0.html. Reciprocity requires that any Derivative Works be licensed under the same license as the Original Work. Reciprocal and non-reciprocal open source licenses ought to be the same -- except with respect to provisions dealing with reciprocity. Therefore, the new AFL is identical to the OSL except that the AFL does not contain a reciprocity provision. A redlined comparison of AFL2.0 and OSL2.0 is at http://rosenlaw.com/afl2.0-redline.pdf."
The inconsistencies surrounding the LGPL and GPL are a continued risk to the software community at large. The OSL and AFL resolve the matter quite thoroughly.
L'INQ
Oliver's original thread on the topic
The entirety of Turner's response
More on the OSL and AFL can be found in the license-discuss lists at OSI.
Digital Law Online New Software from Old
Most computer programs are based to some degree on other computer programs. They could be new implementations of existing programs (for instance, Linux reimplementing Unix) or new programs influenced by an existing program (the first spreadsheet program, VisiCalc, influenced Lotus 1-2-3, which influenced Microsoft Excel), or they could use a preexisting library as part of the final computer program.
Obviously, there are a number of copyright considerations when creating a new computer program based on an existing one.
VI.D.1. Using a Clean Room
It is not necessary to be looking at an existing program while writing a new program for the new program to infringe the reproduction right in the existing program. The copying could be unconscious. In ABKCO Music v. Harrisongs Music, {FN105: 722 F.2d 988, 221 USPQ 490 (2d Cir. 1983)} George Harrison was found to have infringed the copyright of “He’s So Fine,’” a song that he had heard years before, when he wrote “My Sweet Lord.” If you have had access to the source of a computer program, you need to be particularly concerned that you aren’t unconsciously copying the original program when you write a similar program.
One way to avoid infringement when writing a program that is similar to another program is through the use of a “clean room” procedure. This is what was done when companies cloned the BIOS of the IBM personal computer to produce compatible systems. In a clean room procedure, there are two separate teams working on the development of the new program.
The first team determines how the original program works, by examining its source code if it is available (IBM published the source code for its BIOS in a technical manual), by reverse engineering the program (by converting its object code back to source code and attempting to understand it or by testing it to see how it behaves), or by studying available user manuals and other descriptions of the program’s function. This first team puts together a complete technical specification that describes the functioning of the original program. Such a specification is not an infringement, since the copyright in the original program doesn’t protect its functionality, only the expression in the program that creates that functionality. Generally, an intellectual property attorney will review the functional specification to assure that it does not contain any protected expression from the original program.
Given the functional specification, a second team of programmers, metaphorically in a “clean room” uncontaminated by the original program, implements the new program. These programmers have not seen the source code of the original program. In fact, it is best if they have never seen any aspect of the original program, getting all their knowledge of it from the functional specification. Because they haven’t seen the original program, they cannot be copying it, even unconsciously.
A limited clean room was used by programmers at Altai when they discovered that one of their employees had written a program that included portions of a program he had worked on at a competitor. Although Computer Associates v. Altai {FN106: 982 F.2d 693, 23 USPQ2d 1241 (2d Cir. 1992)} does not spend much time on the clean room aspects of Altai’s new implementation, it does suggest that such a procedure results in a program that does not infringe as long as the portions that are similar are dictated by function.
VI.D.2. Piecewise Reimplementation
Many people have reimplemented computer programs by rewriting them to replace the source code with code of their own writing. There is no reason to believe that this would not be a copyright infringement, particularly if the reimplementer had access to the source code of the original program, even if none of the original source code remains.
When the first segment of code is rewritten, the new code will be an infringing work if it is substantially similar to the original code, or may be an infringing derivative work if it is a reimplementation in a different programming language. That reimplemented first segment is combined with the remaining parts of the original program to form an intermediate version. Subsequent modifications produce another work. So when you have completed the piecewise reimplementation, you have a set of works, each of whose creation infringes the exclusive rights of the owner of the copyright of the original program.
As an analogy, consider the translation of a novel to a different language, something that would clearly be a derivative work. It makes little difference that none of the original words remain, or that the translation was done a little at a time. The resulting translation is still an infringing derivative work.
Even if you completely replace the program with new code, nonliteral elements also protected by the original program’s copyright are likely to remain and infringe – elements like the overall program structure or architecture and data structures that are not dictated by external or efficiency considerations. Although there is no case law on this point, it would seem that the only way to break the chain of infringing works is by some extraordinary act, such as a clean room implementation.
VI.D.3. Section 117 Adaptations
Most computer programs are covered by a series of copyrights, each coming into being when a portion of the program is written or modified. The copyright on each nontrivial modification is as a derivative work of some preexistent program. One of the exclusive rights of a copyright owner is the right to control the preparation of any derivative works, so generally only somebody with the permission of the copyright owner can modify a computer program.
There is a special exception in Section 117 that permits the owner of a copy of a computer program “to make or authorize the making of another copy or adaptation of that computer program provided that such a new copy or adaptation is created as an essential step in the utilization of the computer program in conjunction with a machine and that it is used in no other manner.” {FN107: 17 U.S.C. §117} This exception recognizes that it is sometimes necessary to configure or otherwise modify a computer program as part of its installation or to run it. While in theory this adaptation exception would allow somebody to redo Microsoft Access to run on a Macintosh, in reality such an adaptation even with access to the source code would be impractical for an individual user.
Note that Section 117 also requires the permission of the computer program’s copyright owner to transfer the adaptations you have made. So Section 117’s adaptation right is personal to each owner of a copy of a computer program and does not allow the sharing of such adaptations.
VI.D.4. Derivative Works and Compilations
Until now, we have been discussing computer programs as if they were a single work, or an original program and a series of derivative works comprising each modification to that program. While that was the case for early computer programs, now it is more common for a program to include preexisting libraries, themselves copyrighted computer programs, and similar components.
When two or more preexisting works are combined to form a new work, in copyright law that work is called a “compilation” – “a work formed by the collection and assembling of preexisting materials or of data that are selected, coordinated, or arranged in such a way that the resulting work as a whole constitutes an original work of authorship.” The copyright in the resulting overall computer program comprises the copyrights in the preexisting component computer programs and a new copyright in the compilation. But that compilation copyright is very limited.
The copyright in a compilation or derivative work extends only to the material contributed by the author of such work, as distinguished from the preexisting material employed in the work, and does not imply any exclusive right in the preexisting material. The copyright in such work is independent of, and does not affect or enlarge the scope, duration, ownership, or subsistence of, any copyright protection in the preexisting material. {FN108: 17 U.S.C. §103(b)}
This means that to distribute the overall computer program, there must be permission from the copyright owners of all the component computer programs. It is important before distributing a program using a library that the license that accompanied that library allow the redistribution of the library in the way intended, or else the distribution right for that library will be infringed.
An interesting situation arises when an application program is distributed without the libraries it needs, and those libraries are supplied at a later time by the user of the application program. While this may initially seem like a strange procedure, it actually is common for today’s software. Most programs do not run stand-alone on a machine but use the services of an operating system – a special type of preexisting library. Most operating systems also provide dynamic linking to a library, so that the library can be shared by all the programs that are using it.
In this discussion, “library” indicates a preexisting program used by a new “applications program,” because that is one of the most common instances of what is being discussed. However, the discussion is just as applicable to libraries that work with a preexisting operating system, or plug-ins that work with a preexisting browser.
With dynamically-linked libraries, the application program being distributed is no longer a compilation that includes the library. Because the library is not being distributed with the application program, no permission is needed from the copyright owner of the library for the distribution to users. Users must, of course, be authorized to use the library, but if they are owners of a copy of the library, under Section 117 they can make any adaptations of the library necessary to use it with the application program.
Some have claimed that an application program that needs a library for its operation is a derivative work of that library. They take that position because the application program is “based on” the library because it was written to use the subroutines and other aspects of the library.
Such a position is misplaced. Even though the definition of a derivative work contained in Section 101 seems to support such a reading when it talks about a derivative work’s being “based upon one or more preexisting works,” the examples all illustrate derivative works where the original work is somehow incorporated or recast in the derivative work:
A “derivative work” is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a “derivative work”. {FN109: 17 U.S.C. §101}
This need to use a portion of the original work in the derivative work is stated in the legislative history of the Copyright Act of 1976, where the drafters discussed when the derivative work exclusive right is infringed:
To be an infringement the “derivative work” must be “based upon the copyrighted work,” and the definition in section 101 refers to “a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted.” Thus, to constitute a violation of section 106(2), the infringing work must incorporate a portion of the copyrighted work in some form; for example, a detailed commentary on a work or a programmatic musical composition inspired by a novel would not normally constitute infringements under this clause. {FN110: H.R. Rep. No. 94-1476 at 62}
It could be argued that the component program really does include portions of the library that it uses – data structures that are passed as parameters, or even the parameter lists themselves. But elements dictated by external considerations are filtered out when trying to determine whether there is copyright infringement.
No other conclusion makes sense. If it were not the case, then any program using the applications program interfaces (APIs) of an operating system could be considered a derivative work of that operating system. And, under the exclusive right to prepare derivative works, the copyright owner of an operating system such as Microsoft Windows could control who was allowed to write programs for that operating system.
Re: Question to Terekhov by: terekhov |
10/28/03 04:07 am Msg: 56003 of 166806 |
> I don't think Alex has ever said the GPL is > not enforceable. I said that I don't believe that the GPL's VIRUS is enforceable due to "mere aggregation" clause to begin with. That leaves pretty much the same share-alike provisions as defined by OSL, CPL, creativecommons.org's sa1.0, and etc., etc. -- derivatives works ONLY with no infection of the entire collective works. GCC libstd++ folks added "exception" to the GPL with the effect of complete neutralization of the GPV (General Public Virus) because Lesser General Public Virus doesn't really work in the world of modern programming -- C++ (in the case of libstd++). This is telling. [L]GPL has no future (and the same applies to all other forms of "software anarchism" viral licensing under the umbrella of "open source" and "free software"). regards, alexander. |
Re: FAQ: Derivative works? by: terekhov |
10/29/03 09:16 am Msg: 56451 of 166806 |
> But they do have the right to force you to > remove the 100 lines And on what legal ground do they have that right? A mere use of the GPL'd code doesn't make the rest of the program (which is nothing but a collection of modules/subroutines) a DERIVATIVE of those 100 lines of GPL'd code if that portion can be replaced by a "clean room" implementation. I say that all you need to do is to state the availability of the GPL'd source code for THAT PORTION of the program to comply with the unclear and ambiguous terms of the GPL for the entire program, CD-ROM, "image", "executable", and whatnot. regards, alexander. |
Re: FAQ: Derivative works? by: terekhov |
10/29/03 11:13 am Msg: 56495 of 166806 |
> So you agree then that the license doesn't > permit you to use a portion of code within > your own program without paying the cost of > the license. i.e. use this code and you > have to release the combination of work > under the GPL? If making the combination of work (on source code level) involves "borrowing" a copy of GPL'd code without any modifications in the GPL'd code, then the entire stuff that was merely added to it (keeping original code intact), won't be "a derivative" of the GPL'd code, and, for that reason, it can be released under any non-GPL license or not released at all (stay closed source). The problem is that the FSF doesn't agree with that interpretation. regards, alexander. |
RE Derivative Work for Software Defined
- From: Lawrence E. Rosen
- Subject: RE: "Derivative Work" for Software Defined
- Date: Wed, 15 Jan 2003 12:53:13 -0800
Scott, > You keep returning to contract obligations. But, I'm not > relying on any contract obligations. Any distribution that > includes copyrightable material from B needs the permission > of B's copyright owner. The hypothetical that I've presented > includes distribution of B. Thus, B's permission is needed. > I'm trying to understand the conditions the copyright owner > has attached to the copyright owner's offer of permission to > distribute B (the conditions in the GPL). So, the conditions > specified in the GPL are relevant to what someone needs to do > in order to legally distribute A+B, without regard to whether > A+B is has some special status as a protected copyrightable > work (B's protectable status is enough). I keep returning to contract obligations because under copyright law there are only a limited set of exclusive rights that may be licensed, namely to make copies, prepare derivative works, distribute copies, perform and display. Where in the statute is there any reference to an exclusive right to make a "work based on the Program" or a "Larger Work"? How is a court to interpret those phrases? Why should the court even try to do so? Are those things more than a derivative work or less? Why is the licensor's interpretation of those phrases in any way binding upon licensees? The GPL grants an unlimited right to make copies but a conditional right to make derivative works (with some other words in the license about a limited right to make a "work based on the Program"). The only way a judge can interpret that license is to determine whether what is being made -- your A+B, for example, where A is the GPL-licensed work -- involves making a copy of A or creating a derivative work of A. If the former, then the license is clear that there are no reciprocal obligations. If the latter, then the license is also clear that the author of A+B must disclose his source code. That's the question we've all been struggling with. Does linking require merely the making of a copy or is it the creation of a derivative work? We're now back at square one. How does the language you quoted from section 2 help the judge perform that analysis? Why should the judge care at all that those other words are in the license, given that there is no proof whatsoever that the licensee either read or assented to that extra language? If the GPL is just a copyright license then none of that extra language matters. The only question is, has a license been granted to make a copy or to create a derivative work? But if you've got a contract to which the licensee assented, then the licensee is bound by the entire contract. The court is required to interpret a contract in light of the entire document, attempting to find a consistent interpretation that most nearly satisfies the agreed objectives of the parties. The definitions in the contract will guide its interpretation. I am perplexed by the apparent reluctance of the authors of the GPL and by you to allow the GPL to *also* be treated as a contract. If one does that, all the problems you're pointing out disappear. There will no longer be any ambiguity because the *contract* would have to be interpreted as a whole, not merely as a copyright license. What would the GPL lose by also being treated as a contract? The GPL would have much to gain by being treated as a contract. Most importantly, it would become enforceable by any licensor and not just by a copyright holder. Your invitation to "sit back in the comfort of some overstuffed chairs, possibly with a beverage in hand, and have a relaxing interactive discussion" is gratefully accepted. Depending upon the beverage I might even be convinced of the correctness of your analysis, but that will take more than one drink. :-) I think we're both going to be in Seattle soon at the same meeting, so perhaps then???? /Larry -- license-discuss
When I wrote my original blog on this case, SCO had just sued IBM, but its legal strategy was puzzling: it started out with its weakest claims and sued its strongest adversary.
Since that time, it has hired David Boies (defender of Napster and Al Gore) as its lawyer, yet its legal strategy continues to misfire: SCO recently decided not to send out "invoices" to alleged violators of its rights (since it had yet to prove infringement, such invoices are rather premature) and its lawyers just had to apologize to the Utah court for not reading all of IBM's filings: "The drafters of the first Motion for Enlargement worked largely from faxed documents that were incomplete and did not contain the Addendum to IBM's Motion to Compel . . . The Addendum does provide the requisite notice as to IBM's objections to SCO's responses. SCO apologizes to this Court for filing a motion deficient in that manner." This response is the legal equivalent of forgetting to tie your shoes and then falling down in court. And SCO has yet to show the code that it claims is infringed (except for several slides at a meeting).
Moreover, IBM has filed a very strong answer with a counterclaim that uses IBM's vast patent portfolio to target SCO's existing products. So SCO had better be successful in this suit, because IBM clearly intends to shut down SCO revenues from its existing products. Yet the most surprising part of IBM's response is the revelation that Novell can waive all alleged violations of the UNIX licenses. For reasons I don't understand, this "silver bullet" defense has not been widely reported in the press. In a very unusual provision, Novell, as part of its sale of the UNIX licenses to SCO, retained the right to require SCO to "amend, supplement, modify or waive any right" under the license agreements (and if SCO did not comply, Novell could exercise those rights itself on SCO's behalf). At IBM's request, Novell employed this right and demanded that SCO waive IBM's purported violations. When SCO did not do so, Novell exercised its right to waive the violations on SCO's behalf. Basically, this defense destroys the core of the SCO case: IBM's violation of its UNIX license with SCO.
IBM has also asserted that SCO has violated IBM's copyrights in the code contributed to Linux by providing it under terms inconsistent with the GPL (GNU General Public License). Yet the GPL remains a dangerous defense for defenders of open source: the GPL is the basis for the open-source software industry, yet no court has ever ruled on the enforceability or interpretation of the agreement (one case relating to MySQL generated an opinion, but the court deferred interpretation of the GPL and the case settled). The language of the GPL is opaque and it has many ambiguities: it does not establish a governing law, the scope of "derivative works" that are governed by the GPL is unclear and the legal effect of the FAQ (which are not part of the license itself) is uncertain. The open-source industry has more at stake than just a possible infringement of SCO?s rights by certain parts of Linux: the court?s ruling on the enforceability and terms of the GPL will determine the viability of the open-source model.
Mark Radcliffe is a senior partner at Gray Cary Ware & Freidenrich in its Silicon Valley office. He assists companies in developing and implementing their intellectual property and financing strategies.
[Jul 22, 2004] Open and Shut Does Sveasoft (Or Anyone Else) Have the Right to Make a Living From Open Source Software?By Robert X. Cringely
Last week's WiFi-in-the-sky column generated a lot of reader interest that we'll get back to next week, but first I have to write about an issue I'm tangentially involved in -- how people can and can't make money from Open Source software distributed under the Free Software Foundation's General Public License (GPL). Sveasoft, the little router firmware company on an island off the coast of Sweden that I have written about before, switched this week to requiring paid subscription access to its support forums and to download beta versions of its firmware releases for running Linux on various WiFi routers. This change in policy has created a minor firestorm of nerd indignation that I think is not only unwarranted, but stems from essential ignorance of both the GPL and the way businesses are run. It is time for some people to grow up.
A Sveasoft subscription costs $20 per year, which gives you access to the support forums, e-mail support, and the right to download the latest beta versions including source. If you don't want to pay any money you get no support or forum access, but you can download previous release versions of the software, including source. Fw), you can get a CD containing the beta source, ut no support. What brought this $50 deal into existence was the action of a small group of techies who felt that $20 per year was too much to pay, so THEYArial">Then there is the nature of Open Source development, which is typically forgotten in this argument. Think of this in terms of inpyou urge me to take the current source and fork-off.
Now back to Sveasoft, where you can get the released software for free because it is no longer being developed. Or you can buy a support subscription, which is perfectly allowed by the GPL, and buys you access to the development group and its beta code. If you source with you and start your own development group. But that will cost $50 as a reasonable price for sending a CD from Sweden to anywhere in the world. It will also cost you your membership in the Sveasoft development group and access to its support services because you have decided to fork.
What people don't like is the $50 charge, which seems to them excessive, and the restriction that you can't continue to use your $20 subscription rights once you have either bought the $50 source code CD or violated the development group rules by giving away beta code to those who aren't qualified to receive it by way of subscription. This latter bit is a support forum terms of service issue, not a GPL issue.
Fifty probably is a little steep, but this is a guy living on an island in Sweden serving a global user base. The method he has chosen for forking source distribution is physical media, the most expensive method short of having you type-in the code from a printed listing, but it is within his rights to do that. If you don't like it you can always drop back one version, take the freely downloadable code, and fork from there.
The question that is being neither asked nor answered here is how can one make an acceptable living from Open Source? Most of the people complaining about Sveasoft can easily afford the $20 subscription or the $50 forking fee but they are just annoyed that any money is involved. Some of them simply like to argue.
For Open Source to remain viable and vibrant, there has to be room for all types. Many Open Source developers are also paid programmers in their day jobs, but having that paycheck doesn't necessarily make them more understanding of Sveasoft's situation. What we have here is a confluence of forces -- entrepreneurism, technical development, and personal freedom -- with the GPL as a battlefield that is continually cited while being generally ignored.
In my experience very few programmers are entrepreneurial. They'd like to get rich but if it happens it is usually because of someone else's dream and drive, not their own. These people, even though they accept that paycheck, prefer to think of their Open Source work on weekends as being somehow pure. And the rest of us are lucky they think that way because it is through their labor that so much Open Source progress is made. But there is room, too, for the entrepreneurs. Even the Free Software Foundation goes out from time to time looking for money, you know. A lot of Open Source progress has been driven by startups doing Open Source products with the goal of making a great living from them. And a lot has been driven by profitable companies like IBM using Open Source to drive hardware sales and to generally lower the cost of development software from which they make profits. We all benefit from these groups.
There is room for all types and there has to be room for all types for Open Source to work well.
Those who are upset with James Ewing and Sveasoft don't generally begrudge him the right to make a living, they just wish he wasn't doing it this way. At the same time, they don't want the progress that his work has created to end. You can't have it both ways. There are other Open Source projects like Sveasoft's, so vote with your feet if you don't like the new policy by getting your firmware someplace else. But don't blame him for violating the GPL because he isn't.
Linux News Commentary Munich's Migration to Linux Raises Issues GPL Enforceable in Germany?
Spindler is a professor of law at the Gerog-August University in Gottingen, Germany, and as vice chairman of the German Society of Law and Information Science, he is a highly regarded German legal authority. When he was asked by a German software association to study the legal implications of open-source software, he came up with a 123-page report that reached several interesting conclusions.
One of those conclusions may give pause to some people running or considering running open-source software on their computers. He suggested that the GPL has no legal validity in Germany.
Spindler's report objected to the "no warranty" provision under the GPL. His view was that a clause where developers and distributors of open-source software are not liable for any problems with their products "is simply unenforceable under German, or even European law for that matter."
Although the software association admittedly lobbies on behalf of proprietary software vendors who tend to be critical of the open-source movement, Spindler says he is not employed by the group and that they did not influence his conclusions.
Relevancy Question
Whether German law is relevant is a good question, and the answer is probably yes, based on conflict-of-law principles. Unlike proprietary software contracts, the GPL is silent on the issue of governing law, merely referring to "applicable law."
Some legal commentators (Axel Metzger and Till Jaeger) have argued that, under international copyright and conflict-of-law principles, if the open-source software is downloaded in Germany from the Internet or acquired from a data carrier and the user modifies the software, then German law applies. In this case, one must interpret the validity of the GPL in accordance with Germany copyright law.
There are possible objections to the GPL under German Law:
Moral Rights Objections. In Europe, especially in Germany, the concept of "moral rights" has great importance. Under the Berne Convention, "independently of the author's economic rights, and even after the transfer of said rights, the author shall have the right to claim authorship of the work and to object to any distortion, mutilation, or other modification of, or other derogatory action in relation to, the said work, which shall be prejudicial to his honor or reputation." Under Section 2 of the GPL, anyone can modify your code in any way as long as they pass on the source code and meet the other restrictions. It has been argued that the "moral rights" of the author to protect the integrity of their works under German law is not prohibited by the GPL. If so, then there may be a problem if the author wishes to prohibit any modification on the ground that it violates his "moral rights."
On the other hand, the GPL is quite clever in requiring that those who redistribute modifications have to provide notice of the changes. This could diminish or eliminate any concerns of the original author over their moral rights, since the modifications would not be associated with the original author and therefore not prejudicial to their honor or reputation.
Exclusion of Warranty and Liability. It has been pointed out that Section 11 and 12 of the GPL regarding the exclusion of warranty and liability may be unenforceable under the Standard Business Conditions Act of Germany, since an exclusion of liability for damage resulting from gross negligence is invalid. What about the fact that Section 11 of the GPL provides that "there is no warranty for the program, to the extent allowed by law?" Legal experts have argued that under German law, even the use of such language does not help make it less objectionable under German law. I don't think GPL users have much to worry about, unless they are so sloppy that they include viruses in their code (and the reader of the source code doesn't notice) or they out and out copied someone else's proprietary code. In either case, the original author is liable for something, whether such code is distributed using the GPL or any other license.
Preliminary Injunction
The question of whether all of the terms of the GPL would be held up under German law is certainly open for debate. As recently as April 2004, the Munich district court granted a preliminary injunction against Sitecom Germany to enforce the GPL. Sitecom's product is a wireless access router based on software licensed under the GNU-GPL.
It was developed by Netfilter, a company providing security software for Linux firewalls. The court order reportedly stated that Sitecom did not fulfill the obligations imposed by the GNU-GPL, including not making any source code offering or including any GPL terms with their products.
After Sitecom refused to cease and desist despite warning notices, NetFilter applied for a preliminary injunction, banning Sitecom from distributing its product unless Sitecom applies all obligations of the GPL.
So What Now?
While Linux supporters are hailing this case as "the first case in which a judicial decision has been decreed on the applicability and validity of the GNU-GPL," I suggest that they wait before popping the champagne. This judgment is, after all, only a preliminary injunction that is meant to preserve the status quo until final judgment is made.
As Spindler points out, the legal debate is just beginning. The idea of the open-source license is still a relatively new concept in the German legal system. Sorting out these conflicting legal positions is risky business, and the arguments made by legal commentators that the GPL is unenforceable should not be ignored.
If they are right, Spindler suggests that one solution may be to produce a German language version of the GPL that takes in account both EU and German law. Until then, he said he believes that governments, businesses and even individual users may find themselves more liable than they expected.
Joining the Parade
With an estimated 500 German government agencies already using open source, there is no question that Linux will continue to grow in popularity in Europe. As it does, I expect to see many more legal issues that need resolution concerning how the individual copyright laws of each country may or may not apply to the GPL.
In the meantime, perhaps Linux users should start their own parade, dancing up a storm until all the legal issues converge on some consensus on both sides
Date: Jul 23, 2004 By David Gulbransen.Disclaimer: The content of this article is provided for informational purposes only. The author of this article is not a lawyer, and nothing here should be construed as legal advice. For all questions regarding legal matters, you should consult an attorney, not the World Wide Web.Birds Do It, Bees Do It: Software Licensing
You don't own your software. That's right—the operating system on your computer, the word processor you use, the image editing program you use to take the red-eye out of birthday photos—none of it belongs to you.
"But I have a box. And a CD. And manuals. And I paid a lot of money for that software. Of course I own it!"
No, in all likelihood, you don't.
Do you remember when you bought the software package, took it home, and ripped open that envelope containing the CD-ROM for installation? The envelope probably had a lot of writing on it, in small type, and you probably didn't read it. No one ever really reads that stuff. But that writing was a critical piece of finely crafted legalese called an end user license agreement (EULA), which dictates how you're allowed to use the software. Chances are that the EULA was shown to you again during the installation process, and you had to click a button stating that you agreed to the terms.
Surely you read it in its entirety then, right?
TIP
If you're using a computer with Windows installed, your EULA is contained in a text file called eula.txt. Depending on your configuration, try going to c:\windows\system32\eula.txt, or you could just try searching your hard drive for eula.txt.
Eula-gy
The EULA is just what it sounds like: an agreement—between you, the end user, and the company that "sold" you the software you are about to install. It contains a number of restrictions about how you can use the software. For example, the Microsoft EULA on your machine restricts you from using this copy of the operating system on more than one machine. If you have two computers, you can't legally buy one copy of Windows and install it on both machines. The license specifically says that you can't do that. It also contains a number of other provisions. For example:
- The license may limit the number of backup copies you're allowed to make.
- The license may restrict how many CPUs you can have in the machine on which you're running the software.
- The license may allow you to move the software from one machine to another, provided that you completely delete it from the first machine after you install it on the second.
The EULA probably also contains a lot of items that limit the liability of the software company; for example, stating that there is no warranty for the software's performance, or that you're not allowed to export or resell the software.
And then there's usually a termination clause. For example, here's what the Microsoft EULA states: "TERMINATION. Without prejudice to any other rights, Microsoft may cancel this EULA if you do not abide by the terms and conditions of this EULA, in which case you must destroy all copies of the Product and all of its component parts."
Which means that Microsoft has the option of basically taking back their software. If you don't abide by the terms of the EULA, they have the right to make you stop using their software. And if you don't stop using it, Microsoft could take you to court and possibly be awarded damages for your illegal use.
That's why it's not really accurate to say that you "buy" or "own" software. If you buy a lawn sprinkler and only use it to let the neighborhood kids run through the water in the summertime, the lawn care products manufacturer can't come to you and say, "Hey, your license agreement states that only one individual may use the product at a time, so you're in violation of your Sprinkler License and are hereby ordered to either purchase additional licenses or stop using the product immediately."
A software company can do exactly that.
Keep in mind here that we're not trying to pick on Microsoft. Far from it. Microsoft didn't invent the EULA, and they're certainly not the only software company that licenses products this way. Virtually every piece of software you use is governed by one of these license agreements—even the shareware and "free" products you might download online.
Licenses Versus Contracts
What's the difference between a license and a contract? And why does it matter? Without getting too bogged down into legalese, there are some very critical differences between licenses and contracts, especially when we're framing the two concepts as related to software usage.
First, a license is just a grant of rights to do something. You can get a fishing license from the Department of Natural Resources, which gives you the right to go fishing someplace. You can get a marriage license from the state, which gives you the right to marry your fiancé(e). Or you can get a software license, which grants you the right to use the designated software. A license can have restrictions; a fishing license can limit the number of fish you can catch, just as a software license can limit the number of users you can have using that software.
A contract, on the other hand, is a binding agreement between two parties. There are a number of things that a contract must have in order to be legally binding. For example, a contract usually consists of the following items, and in many cases is required to include these items:
- Offer
- Acceptance of the offer
- Promise to perform
- Valuable consideration
- Terms and conditions for performance
- Performance
For example, suppose you're selling a car. You set a price (offer); a potential buyer may accept the price, or may make a counteroffer. When you agree on a price (acceptance), you have the makings of a contract. The agreement is that the two of you will exchange money (consideration) and the car in good working order. As long as the buyer pays, you have to deliver the car (promise to perform). You might also have agreed that the car is in good working order, or even that it is sold "as is," with no guarantee of working at all (a car sold for parts, for example). If you take the buyer's money, but don't give him the car, you have failed to perform, and are in breach of contract. Similarly, if he takes the car and his check bounces, he is in breach of contract.
So why all the hullabaloo over whether the agreement with your software vendor is a license or a contract? Because a license deals specifically with the grant of rights, not the actual transfer of rights. Under a contract, the software company would actually be transferring certain rights to you, and then those rights (such as the right to freely resell, copy, or distribute the software, and so on) would be yours. By simply granting you certain rights to use the software in a prescribed manner, the software manufacturer retains the copyright ownership of their software, and all of the power to control how the software is used that comes with owning the copyrights.
This distinction between a license and a contract is critical trying to determine how the GPL affects your ability to use software. As you'll see shortly, it doesn't really affect end users any more than a typical EULA—in fact, often it's less restrictive than the standard EULA. The real impact of the GPL is the developer's ability to alter GPL licensed software, and to pass on those changes to other users.
Court Confirms GPL Valid in Germany |
Friday, July 23 2004 @ 03:55 PM EDT |
I'm getting positively light-headed from so much good news, and I surely hope you are sitting down if you have any inclination toward heart flutters, because a court in Germany has just confirmed the earlier preliminary injunction in the netfilter/iptables case -- the GPL is valid in Germany. Here is a reader's translation of a bit of the Heise story:
|
Linux News Commentary A Consumer's Review of the General Public License Here is an interesting opinion of Phil Albert, a LinuxInsider columnist, who is a patent attorney and partner with the San Francisco office of the intellectual property law firm Townsend and Townsend and Crew LLP.
When lawyers don't get in on the act, questions of interpretation can lead to some serious problems. Take section "0." It says, in part:
"a. 'work based on the Program' means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language."
Before the colon, a "work based on the Program" is defined as including "derivative works under copyright law." Following the colon, a "work based on the Program" is defined as "a work containing the Program or a portion of it." Unfortunately, those two definitions are not the same, because the legal definition of "derivative work" is a term that has been the subject of much case law, and it doesn't happen to mean "a work containing the [original work] or a portion of it."
If I were writing this license, I would include a definitions section that exactly defines everything I need and ensures that usage is consistent throughout.
Subtle Problems
Often, subtle problems -- such as the lack of notice requirement for downstream users -- don't show up until some unusual confluence occurs. If someone receives software and the GPL is conspicuously noted, the copyright holder could argue that the recipient had notice of the license terms.
However, if someone removed the GPL from the software, or it just dropped off for unexplainable reasons, and another party received the software without notice of the licensing terms, a court might construe that if the recipient had no notice of the actual license terms, but understood the software to be open source, they might have an implied license to use the software without the copyleft provisions of the GPL.
Lawyers might also argue that it is unclear whether the GPL is based in contract or property (that is, whether a licensee is bound because the licensee agreed to the provisions of the GPL, or a licensee is the owner of some limited property right granted to him or her by the licensor). It is also not clear if the GPL intends to bind the licensee beyond the scope of copyrights, restricting the licensee's actions even more than copyright law would. And which state or country's laws should be used to interpret the GPL if there is a dispute?
GROKLAW Comments
If derivative work doesn't happen to mean "a work containing the original work or a portion of it," someone needs to tells the US Copyright Office quick. Here is what they say in their Circular 14 - "Copyright Registration for Derivative Works":
"A 'derivative work,' that is, a work that is based on (or derived from) one or more already existing works, is copyrightable if it includes what the copyright law calls an “original work of authorship.” . . . A typical example of a derivative work received for registration in the Copyright Office is one that is primarily a new work but incorporates some previously published material. This previously published material makes the work a derivative work under the copyright law."
And here is 'Lectric Law Library's definition:
"DERIVATIVE WORK - A work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a 'derivative work'. 17 U.S.C."
response to #3 -- GPL can be removed by a third party created specifically for this purpose
Authored by: rand on Wednesday, July 21 2004 @ 12:54 PM EDT
The GPL allows anyone to receive and use (even modify) covered software with no
restriction; the only restrictions are on re-distribution. Whoever the user got
the software from would lose the right to distribute the software, and could be
sued by the by the original and any follow-on authors, but the duped user is not
at risk for just using the software.
Also, I believe that if the user paid for the software, she would be eligible
for a refund and might have standing to sue to recover, since the distributor
automatically wasn't licensed at the time of the sale.
If the licensor permits, any breach by the distributor is easily fixed: just
include the required notices with the software and make the source code
available.
response to #3 Authored by: Anonymous on Wednesday, July 21 2004 @ 03:48 PM EDT The really neat thing i'd like to mention here is where the GPL and its purpose
differs from other licenses.
other licenses impose additional restrictions and are generally meant to keep
things private and profitable. The GPL is for keeping things public and free.
what would happen if MS's license was removed and the code got into the public?
Oh my their bottom line is hurt.
what would happen if GPL'd code had its license removed and redistributed into
the public? DOH, thats what happens anyway!
The big issue left is what about people who had started selling this code and
the continued sale of the code. The author of the GPL'd code may seek damages,
probably from the person that removed the license, probably in the amount of
money made from the transfer of the code to the 3rd party that 'didn't know' as
well as profits made by the third party. The 3rd party would then logically sue
the person that gave them GPL'd code without the license, however the
circumstances around how they got the code wouldn't matter, it was never theirs
to be a trade secret, keep private, or profit from. Sucks for them to get
tricked, but they can talk to the person that removed the license about that.
flip this around and if it happenned to a closed source project, well the cats
out of the bag, and real perm damage could be done.
pretty nifty, even thou i prefer the BSD license.
What about the disclaimer of warranty? Authored by: Anonymous on Wednesday, July 21 2004 @ 01:14 PM EDT As I understand it, the argument why the GPL may require reciprocal obligations
on the part of the recipient and thus be a contract rather than a license stems
from the disclaimer of warranty. It is obvious why, in certain jurisdictions,
this could be construed to constitute "an exchange of obligations" as
Prof. Moglen puts it: in exchange for the author's obligation not to sue for
copyright infringement if the software is redistributed according to the rules
of the GPL, the recipient is obliged not to sue if the software is defective and
breaks state laws involving the fitness of merchandise.
Presumably the GPL means to address this by making clear the disclaimer of
warranty exists only "to the extent permitted by applicable law". But
it is not clear to me that this should be interpreted as "to the extent
permitted without constituting a reciprocal obligation on the part of the
recipient that would turn this into a contract." IANAL, but Phil Albert is
certainly not the only one who disagrees with Eben Moglen on this point. (For
example, read David McGowan at the University of Minnesota Law School:
http://papers.ssrn.com/sol3/papers.cfm?abstract_id=555851)
The stated intent of the GPL to remain a unilateral license and not a contract
is certainly evidence of the licensor's intent, but there's no reason that
should be dispositive if one of its provisions requires that it be construed as
a contract. While a number of legal experts--Moglen foremost among
them--clearly believe the GPL is safe from this avenue of attack, a number
disagree. (The McGowan article was approvingly cited in Larry Solum's blog,
probably the foremost legal blog on the Internet.) Nor have I seen Moglen or
any other GPL-as-license defenders address this point directly. (PJ's article
certainly does not.)
Ascribing these legitimate questions to FUD is either ignorant or evasive and
dishonest.
What about the disclaimer of warranty? Authored by: Anonymous on Thursday, July 22 2004 @ 07:21 AM EDT Maybe you think it is a fallacy, but the courts in this part of the world (The
Netherlands) think otherwise. Software is considered a product from a liability
viewpoint. Hence the waiver of all liability that the GPL contains vastly
exceeds the scope of copyright law. The GPL doesn't only give, it also takes.
The parts of the GPL that take can only be considered a contract, not just a
license. It is simply not as black and white as PJ is painting it and I think
the ad hominem attack on both Linux Insider and the author of the article are
disgusting and unfounded.
---
carpe ductum -- "Grab the tape" (IANAL and so forth and so on)
Open Source Licensing: Virus or Virtue? Volume 10 - Spring 2002 -
Number 3
Christian H. Nadan*
Abstract |
Full Text html |
Full Text pdf (144KB)
II. Open Source License Enforceability Issues
... ... ...
A. Contract Formation
Proprietary software is typically licensed under a clickwrap or shrinkwrap license. Such licenses serve as a gate through which the user is forced to pass to use the software, and require some affirmative act manifesting assent to the license—such as clicking an “accept” button before downloading the software or to complete the installation process, or tearing open the packaging displaying the shrinkwrap license.[53] There is no way to avoid the act constituting assent. Even then, there is still some doubt over the enforceability of these types of licenses.[54]
Open source licensing tries to make the license formation simpler for the licensor to implement. Rather than requiring acceptance of a clickwrap agreement for downloads from a website, acceptance of a clickwrap license that pops up during installation of the code, or acceptence of a shrinkwrap license included in the packaging, the open source licenses just require that a notice about the license be provided in or with the code. No manifestation of assent is required to prove the licensee agreed to the terms, and indeed the user can access the code without ever seeing the license, let alone agreeing to it. This greatly increases the risk that no license agreement has been formed.
Specifically, the GPL and the BSD both rely on this rudimentary “notice” form of license. The BSD License requires that redistributions of the program “must reproduce the above copyright notice, this list of conditions,” the endorsement prohibition and the warranty and limitation of liability disclaimer.[55] So the BSD license relies simply on a notice of the license terms. The BSD notices might be faithfully reproduced in the middle of the code somewhere, and never seen by the licensee. Similarly, under the GPL you may distribute copies of the program and simply provide the licensee a copy of the GPL with the program. What if the copy of the GPL is properly provided with the code, but placed in a file never opened by the user? In neither of these licenses is the user required to perform any act manifesting assent to the terms or even notice of them.[56] Thus, particularly because neither the BSD License nor the GPL specify how or where the notice is to be provided, it is possible that a user could obtain such software without notice of the terms, even though the distributor is in full compliance with the GPL or BSD License.[57]
If the user has no notice of the license, she is probably not bound by it. Consider Ticketmaster Corp. v. Tickets.Com, Inc.[58] The Ticketmaster website contained at the bottom of the webpage a “terms of use” link. The Terms of Use page provided that going beyond the home page constituted agreement to the Terms of Use. Unless the customer happened to notice and then click on the “terms of use” link, however, he would never see the actual Terms of Use page. The court ruled that this was not like a shrinkwrap license on a box of software, since a shrinkwrap is “open and obvious and in fact hard to miss.”[59] Also, the court noted that this was not like the many web sites that required the user to click on “agree” to the terms of use before proceeding. The court concluded that using a terms of use link at the bottom of the page does not necessarily create a contract. It dismissed the breach of contract claim with leave to amend to show that defendant had knowledge of the terms and at least impliedly agreed to them. Thus, simply including contract terms did not create a contract where the user was unaware of them (and thus had no idea that use of the website constituted acceptance of a contract).
Similarly, in Specht v. Netscape Communications Corp., the court held that no agreement is formed if the customer downloads the software without clicking a clickwrap and without first being informed that the downloading constitutes acceptance of the license agreement.[60] The customer could download this software from Netscape’s website without being first forced to click the clickwrap. Further, the notice about the existence of the clickwrap was not even visible on the screen when downloading the software—the user would only discover the clickwrap by browsing elsewhere on the website.[61] “The only hint that a contract is being formed is one small box of text referring to the license agreement, text that appears below the screen used for downloading and that a user need not even see before obtaining the product.”[62] Thus, the downloader was “not bound by inconspicuous contractual provisions of which he was unaware.”[63]
This is strikingly similar to open source licensing—relying on a simple notice that the user may not ever see. The user is not forced to click anything or rip open any marked packaging. This “notice” form of licensing will be effective if the user happens to notice the license, and understands that by using the software he is agreeing to be bound. But it does not guarantee that all users will see the license, or that they will understand that downloading or using the code constitutes acceptance of it.[64] Simply stated, a user is not bound by a contract of which he is not made aware.[65]
If the user is not bound by the license, can he still use the software? The GPL argues that “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. These actions are prohibited by law if you do not accept this License.”[66] This is overstated, if not incorrect. With respect to the software owned by the distributor, providing it to a user without any express (or at least enforceable) terms or conditions can create an implied license to exploit the work on reasonable terms. “[I]mplication of a license depends upon all the circumstances, including the parties’ conduct, the terms of applicable written agreements and correspondence, the reasonable expectations of the parties, the dictates of fairness and equity, and the policies underlying the intellectual property system.”[67] In the absence of an agreement, “implied licenses may arise from conduct alone. For example, when a copyright owner provides another with a copy of a copyrighted work, intending it to be used, and knowing that it will be used, for an agreed purpose, the recipient normally has an implied license to use it for that purpose, but no other.”[68]
There is no question that the open source code is provided for the express purpose of being modified, used and distributed; and if the licensee is not bound by the open source license, the licensee may have an implied license for that purpose. Indeed, fairness requires this result. If the licensor is making the code available for download and use, and through no fault of the licensee he does not receive notice of the actual open source license, it would be inequitable to find that the licensee infringed by just downloading and using the code as intended.[69] If the license agreement is not binding, then either the licensee has an implied license or is infringing. The latter result would reward a licensor for inducing the licensee to exploit the code and failing to adequately notify the licensee of the written license. A licensor should not be able to give the licensee the code without notice of the license agreement, and then sue the licensee for using the code.[70]
An implied license would not extend to those portions of the program the distributor received from others, however. The distributor cannot grant more rights than he received, and since he received the contributed portions subject to the GPL limitations, he cannot pass on those portions with fewer restrictions.[71] Moreover, many experienced programmers would be hard-pressed to claim that they did not suspect that the code was subject to the GPL, or that their failure to look for the GPL notice was reasonable. But it does not follow that every programmer who downloads the code should have known it was GPL and not public domain code, or that all open source software includes the GPL notice in a conspicuous place. All it takes is one innocent downloader: if such user is not bound by the GPL or BSD License but receives the code under an implied license, this loophole could undermine the open source nature of the program, or at least the portions contributed by the licensor.
Thus, diligently following the GPL rules may nonetheless fail to protect the code. If a recipient of that GPL code reasonably fails to receive notice of the license terms, she could have an implied right to use and distribute that code. It is unlikely a court would imply a term as unusual as copyleft without any notice of it, so the implied licensee may well be able to combine proprietary code with no tainting, or even take the GPL code private by licensing it out under a proprietary license. One initial solution is to set up the code download site so that the user is forced to click “I accept” to a clickwrap form of the GPL before downloading. Another slightly riskier approach is to provide a prominent notice on the download page that the use of the code is subject to the GPL (and provide a copy of GPL on the site or indicate where a copy can be found in the code). Commercial entities rely on clickwraps and shrinkwraps every day, and employing the same device for the GPL is the prudent approach. Indeed, most commercial software distributors already have such mechanisms in place for their proprietary code, so distributing GPL code similarly should be simple and inexpensive. Relying on a mere notice in the code, while authorized in the GPL, is not recommended.
This does not resolve the problem, however. The clickwrap GPL would bind the distributor’s licensee. Yet that licensee could still comply with the GPL and redistribute the code with only an unseen nonbinding notice of the GPL. Thus, the GPL would not bind that licensee’s licensee. An effective solution must bind the licensee’s licensee (and subsequent downstream licensees) to use an enforceable contract formation mechanism for their distributions. Ideally, the GPL should be modified to expressly require that all downstream licensees receive effective notice that the GPL binds them.[72]
B. Enforceability of Copyleft
The copyleft provision of the open source license itself creates a possible unanticipated enforceability problem. This section discusses some of the risks of enforcing or relying on copyleft provisions. To use copyleft licenses most effectively, the developer should be aware of these risks and the limits on copyleft’s effectiveness.
Even if the open source license is binding, the copyleft provision may still not be enforceable as to independent proprietary code, in light of the intellectual property misuse doctrine. The doctrine is asserted as an affirmative defense to an intellectual property infringement claim. Much like an unclean hands defense, the misuse doctrine precludes enforcement of intellectual property rights that have been extended beyond the scope of those rights. An obvious example is a contract that requires a patent licensee to continue to pay royalties beyond the statutory term of the patent.[73] A patent generally lasts for 20 years from its filing date.[74] Demanding royalties after the patent expired would exceed the scope of the rights granted in a patent. Public policy “forbids the use of the patent to secure an exclusive right or limited monopoly not granted by the Patent Office.”[75] A successful misuse defense bars the misuser from prevailing against anyone on an action for infringement of the misused intellectual property, even against defendants who have not been harmed or affected by the misuse.[76]
The misuse doctrine was judicially created, first in the patent context. Only recently has the misuse doctrine been extended to copyrights, building on the rich misuse history in the patent law.[77] Importantly, most courts have found misuse without requiring a finding of antitrust liability.[78] Thus, market power is unnecessary, as is any analysis of the competitive and anticompetitive impacts of the provision.[79]
The courts have yet to analyze a copyleft provision for misuse, but the courts have addressed an analogous provision—the grantback. A grantback provision requires that a licensee of intellectual property grant back to the licensor a license or ownership in creations made by the licensee. The typical grantback provision requires that the licensee give the licensor a nonexclusive license to any improvements or derivatives that the licensee creates based on the original licensed property. The idea is that the licensee would not have been able to make the improvement or derivative without permission of the licensor or at least access to the original; thus, the licensor should not be blocked by an improvement or derivative he and his intellectual property helped create. Giving the license back encourages licensors to license, since it mitigates the risk of becoming blocked by derivative intellectual property. Like a grantback, copyleft requires the licensee to license back its improvements. The copyleft provision is more expansive, though. The grantback clause requires the licensee to give a license back to the licensor, while the copyleft license requires the licensee to give a license to the world.
Although grantbacks have not come up in the copyright misuse arena, they have in the patent context—and as we have seen, the patent misuse cases form the underpinning for the copyright misuse doctrine. Courts have found that grantback clauses extending to improvements are not misuse, because the licensee in some sense developed the improvement with the help of the original patent. Where grantback clauses extend to preexisting or unrelated patents, however, courts have found patent misuse. Where “the scope of [licensee’s] ‘improvements’ and inventions required to be assigned to [the patent licensor] extended far beyond the scope of [the] basic patent [licensed by licensor] the effect was to extend unlawfully its monopoly and thus result in patent misuse.”[80] Plainly, the Patent Act does not give the patent owner rights to other unrelated patents, and using a patent to obtain such rights exceeds the scope of the patent.
Similarly, the Copyright Act’s grant of rights does not extend to unrelated works or preexisting (and therefore necessarily nonderivative) works, and using the copyright license to extract such rights exceeds the scope of the copyright grant. This may constitute copyright misuse. A license to a copyrighted work on condition that any work with which it is combined or shares data must be licensed back to the licensor—and the entire world—on the specific terms the licensor mandates, is beyond the scope of the copyright in the originally licensed work. Yet this is what the GPL apparently requires. The copyleft provision purports to infect independent, separate works that are not derivative of the open source code, and requires that such independent works be licensed back to the licensor and the entire world under the GPL. The Copyright Act does not give the copyright owner rights to such independent nonderivative works. Attempting to extract such rights exceeds the scope of the copyright. The fact that the GPL mandates that the license be free and open is irrelevant; as explained above, misuse doctrine does not require an analysis of market share, or a weighing of the competitive and anticompetitive effects of the provision.
If the copyleft provision constitutes misuse, then the plaintiff’s copyrights in the open source program are unenforceable until the misuse is purged.[81] As a result, at least with respect to the code contributed by any plaintiff, the defendant (and anyone else) could infringe the copyright with impunity, including taking the code private for his own commercial ends.[82] Thus, licensors using copyleft licenses need to realize that they may be unable to enforce the copyleft provision against separate works of the licensee, and that any such attempt may at least temporarily invalidate all their copyrights in the entire open source program. Copyleft licenses are still valuable, however, where they do not try to infect independent code. They should safely cover any dependent derivative works based on the original GPL code. Licensors simply need to understand the potential limitations and risks of copyleft to employ it effectively.
Yet even if fully enforceable, copyleft may still fail to prevent certain modifications from being taken private. The GPL permits modification of the code subject to the condition that the modification is distributed under the GPL. Similarly, the BSD license permits modifications provided certain conditions are met, including passing on notice of the license terms. In both cases, the license to modify is expressly conditioned upon making sure that the downstream licensees are bound by the same terms or notices. What if the user breaches the contract and fails to distribute under the open source license terms or notices? If these are truly conditions to the license to modify, then the right to create modifications is lost or never arose due to the failure of the condition (a condition subsequent, in this case). “You may modify your copy . . . provided that you also meet all of these conditions: . . . You must cause any work that you distribute . . . to be licensed . . . under the terms of this License.”[83] In other words, for any work you distribute, the right to modify is only valid if you distribute the work under the GPL.[84]
Accordingly, if you distribute the modifications under a license other than the GPL (or under no license), the modifications are thus not permitted, and are infringing derivatives. You would be a copyright infringer. The Copyright Act provides that the infringer does not own the infringing derivatives, but leaves open the question what happens to them—are they effectively owned by the underlying copyright owner whose rights are infringed, as a windfall bonus to any damages remedy (since the underlying copyright owner could claim that anyone else using these derivatives similarly infringed the underlying copyrights)? Or, do they instead fall into the public domain, free of the claims of the underlying copyright owner?[85] If the latter, then those infringing modifications that were supposed to be under the open source license are free to be taken private. Although the infringer may be enjoined from exploiting the infringing derivatives, as public domain works they are freely available to anyone else.
III. What to do about Open Source Licensing?
... ... ...
Thus, in addition to the attack on the open source community generally, Microsoft employs a specific attack on the copyleft provision. Microsoft has distributed software under a license that explicitly prohibits licensees from using the software with copyleft software.[92] Microsoft’s license calls such software “Potentially Viral Software”—defined as any software which is licensed under terms that create obligations for Microsoft or grant third parties rights in the Microsoft software.[93] Within this category the license specifically includes GPL, LGPL, Sun Industry Standards Source License (SISSL), as well as any software that is distributed as free software.[94] Microsoft fears that if GPL code is combined with or incorporated into Microsoft proprietary code, this would make Microsoft code also subject to the open license and the person creating the derivative would then be required to open source the Microsoft code with the incorporated GPL code. In fact, however, because a licensee cannot grant greater rights than he received from the licensor, a Microsoft licensee could not by combining the Microsoft code with GPL code lawfully release the Microsoft code under the GPL. Were it otherwise, anyone could simply incorporate some GPL code in Windows, and then claim Windows had become GPL code against Microsoft’s wishes. Thus, Microsoft’s anti-copyleft license restriction is not necessary, but it nevertheless precludes the licensee from using Microsoft software or distributing it “in conjunction” with any open source or free software.[95] Whether this is an attempt to hold back the open source community, or whether Microsoft ultimately succeeds, its strategy is only useful to those software companies with significant market share in the segment they wish to control.
... ... ...
Another approach to the standards problem is illustrated by the Sun Industry Standards Source License (SISSL), which is an approved OSI open source license.[103] The license is designed to encourage the industry to follow a specific standard or specification, although it does not absolutely require such conformance. Like the GPL or BSD license, it permits free modification and use of the SISSL code.[104] Like GPL, the original SISSL code may be distributed only under the SISSL.[105] This is a copyleft-like provision, to prevent the original code from being taken private. Unlike GPL, however, modified versions of SISSL code may be distributed “under a license of Your choice” provided that the modified program complies with the compatibility requirements for that SISSL code.[106] If the modified version does not comply with these requirements and thus does not conform to the standard, then the SISSL requires the licensee to publish the source code for those modifications under SISSL terms, or publish a reference implementation of those modifications together with the deviations from the standard, under SISSL terms.[107]
Thus, the SISSL’s copyleft terms apply only to the original code, and to any modified versions that fail to conform to the standard. Modified versions that do conform to the standard may be distributed under a proprietary model. This allows companies to compete on the merits of their implementations of the standard, without fragmenting the standard itself. Unlike GPL code, these companies can differentiate their products by keeping their enhancements private; they are not required to share them as long as they meet the standard. Although the community could collectively decide to change the standard, as long as the change is implemented by the community, it should be open and effective (a standard is only useful if it is uniformly followed). The SISSL prevents anyone from taking the standard itself private, no matter how much market share they might have in their proprietary implementation. Finally, safely avoiding the copyright misuse problem of the GPL, the SISSL clearly limits itself to covering derivatives, and does not infect separate programs: “You may [combine] Original Code with other code not governed by the terms of this License and distribute [the combined work] as a single product. In such a case, you must make sure the requirements of this License are fulfilled for the Original Code.”[108] This means that the separate work can still be distributed under a proprietary license, as long as the open source code with which it is combined remains under the open source license.
Open source licensing does not usually succeed as a product-oriented revenue model, however. With a copyleft license, you must share any improvements to the open source code. Thus, it becomes impossible to differentiate your products from your competitors’ products, because you have to share with them any of those potentially differentiating improvements. In theory, the developer could gain a first mover advantage, since the developer could share the modifications at the same time it shipped the binary products for sale on the market. Yet it would not take long for competitors to incorporate those improvements and release identical products. Open source licensing is best used in conjunction with a commercial business model; it does not simply substitute for a proprietary business model.
[Mar 16, 2004] Leading Open Source Software Companies MySQL AB, Sleepycat Software and Trolltech AS Prove Strength of Dual-License Model
Open source and software industry experts endorse dual-license as good for business – three companies show average of 65% revenue growth in 2003
Sleepycat Software, Trolltech AS and MySQL AB today jointly announced that 2003 software license revenues for the companies increased an average of 65 percent over the previous year, largely due to their use of the dual-license business model. This increase is 10 times the overall growth of U.S. IT industry spending in 2003, measured at only 6.4 percent, according to the U.S. Department of Commerce.
Trolltech AS, MySQL AB and Sleepycat Software are strong examples of second-generation open source companies that have established growing, sustainable businesses based on open source software. Both the business model and the open source software license are gaining increasing support in the IT industry. The companies provide dual-license software to some of the largest customers in the world, including Cisco, Google, IBM, Motorola, Sharp Electronics and Yahoo!, among hundreds more.
“Dual-license companies combine the software quality and distribution benefits of an open source model with the software licensing revenue model of a traditional commercial software vendor,” said Dan Kusnetzky, vice president for System Software Research at industry analyst firm IDC. “This appears to be a successful business model. It offers customers seeking a traditional packaged software model what they want in terms of documentation and ongoing support. For those seeking freely available software and the open source model of community development and support, they get what they want."
Second-Generation Companies
As second-generation open source vendors, MySQL AB, Sleepycat Software and Trolltech AS make the majority of their revenue from selling software licenses. This license-based business model offers higher margins than services-based businesses. Historically, most open source companies have tried to make money by selling services and support.
The guiding principle behind dual licensing is “quid pro quo,” or a fair exchange. Under this model, vendors offer their products under both an open source license and a commercial license. This allows open source projects to use the software at no cost, which contributes to widespread use and testing of the software and the fast growth of a large installed user base. Companies redistributing the software as part of commercial products can also get the benefits of the open source software by purchasing a commercial license, which releases them from requirements to publish their source code. Commercially-licensed customers generate revenue for the open source vendors, which contributes to the rapid development of high-quality software.
"Dual-license products give customers who redistribute a choice in license terms,'' said Eben Moglen, professor of law at the Columbia University Law School and recognized as one of the world’s leading experts on copyright law as applied to software. "Proprietary commercial licenses can offer customers fewer restrictions on inclusion in closed source products and enable open source software developers to grow strong businesses. This model is a win for the free software movement too, as it ensures that dual-licensed software products will be developed and supported by viable companies, and also remain available for free copying, modification and redistribution for the long-term."
CEOs Mĺrten Mickos of MySQL AB, Mike Olson of Sleepycat Software and Haavard Nord of Trolltech AS, along with Bob Bickel of JBoss, speak today at the Open Source Business Conference on a panel that covers the best practices and guiding principles of the dual license business model and investigates the benefits and risks inherent in the model. The panel runs from 3:30pm to 4:15pm at the Westin St. Francis Hotel in San Francisco, California.
The three CEOs will discuss from the benefits of dual-licensed products and how customers gain all the advantages of open source software, such as:
- An established community of open source developers sharing code;
- Faster time to market with higher software quality, reliability and stability; and
- Freedom from vendor lock-in.
In addition, customers gain all of the benefits traditionally associated with commercial software, including:
- A paid, full-time, dedicated development team, providing continuity, a roadmap of upgrades and professional documentation;
- Enterprise-level, production and developer support available 24/7/365; and
- Confidence that the vendor has full rights and/or ownership of all intellectual property in the software.
About MySQL AB
MySQL AB develops and markets a family of high performance, affordable database servers and tools. The company's flagship product is MySQL, the world's most popular open-source database, with more than 4 million active installations. Many of the world's largest organizations, including Yahoo!, Sabre Holdings, Cox Communications, The Associated Press and NASA are realizing significant cost savings by using MySQL to power Web sites, business-critical enterprise applications and packaged software. MySQL AB is a second-generation open-source company, with dual licensing that supports open-source values and methodology in a profitable, sustainable business. For more information about MySQL, please go to www.mysql.com.
About Sleepycat Software
Sleepycat Software makes Berkeley DB, the most widely used application-specific data management software in the world with more than 200 million deployments. Customers such as Amazon, AOL, British Telecom, Cisco Systems, EMC, Ericsson, Google, Hitachi, HP, Motorola, Openwave Systems, RSA Security, Sun Microsystems, TIBCO and Veritas rely on Berkeley DB for fast, scalable, reliable and cost-effective data management for their mission-critical applications. Profitable since it was founded in 1996, Sleepycat is a privately held company with offices in California and Massachusetts. More information Sleepycat Software can be found at www.sleepycat.com.
About Trolltech
Trolltech® is a software company with two product lines: Qt® and Qtopia®. Qt is a multiplatform C++ application framework developers can use to write single-source applications that run -- natively – on Windows, Linux, Unix, Mac OS X and embedded Linux. Qt has been used to build thousands of successful commercial applications worldwide, and is the basis of the open source KDE desktop environment. Qtopia is the first comprehensive application platform built for embedded Linux, and is used on numerous Linux-based PDAs and Smartphones. Trolltech is headquartered in Oslo, Norway, with offices in Brisbane, Australia, and Palo Alto, California. More about Trolltech can be found at www.trolltech.com.
FSF New Apache License not GPL-Compatible
Re:Is anyone else getting worried here? (Score:1, Flamebait)
by Tassach (137772) on Wednesday February 18, @04:46PM (#8320191)
(http://www.rapiertech.com/~tassach/)This isn't a case of "pro-opensource" vs "anti-opensource". This is a case of License Holy Wars. This is a case of RMS getting his knickers in a twist because someone has the audacity to release a useful and popular open-source program without the Holy GPL. I'm suprised he's not saying that it should be called "GNU/Apache" instead of just "Apache".
Re:Is anyone else
getting worried here? (Score:5, Insightful)
by frodo from middle ea (602941) on Wednesday February 18, @04:50PM (#8320241) (http://aol.com/) |
If I ever saw an insightful comment,
this is one.
Why does every person, who is interested to see open source succeed in business environment, making it a resposibiity of the OSS community. OSS software for most parts was never written with the objective to form a free alternative to propritory software. Most OSS projects started because of fustrations of the author at using the tools that existed at hand, and the inability to circumvent those tools, (the tools being propritory in nature). Linus never wrote the linux kernel , so that it can topple the microsoft empire, much as most of you like to belive. neither was he interested in fighting the big Unix vendors at that time. He just wanted his own version of Unix to tinker with and Minix wouldn't allow him to do just that. So to all those who say "This could have
been a break through year for OSS, but for |
|
|
Re:Is anyone else
getting worried here? (Score:2) by DrXym (126579) on Thursday February 19, @05:39AM (#8324865) |
OSS software for most parts
was never written with the objective to form a free alternative to
propritory software.
Well that argument just about falls apart when you examine Apache, Mozilla, MySQL, OpenOffice, GNOME, KDE, xmms, Xfree86 and no doubt many more complex components that are found in modern Linux and BSDs distributions. Some of these started life as commercial products and some were clearly founded in order to offer a free alternative to commercial or licence products. For example Mozilla started off as Netscape (purged of a few 3rd party licenced parts), OpenOffice as StarOffice, XFree86 as an open source implementation of X11 and the likes of GNOME / KDE were created as something analogous and better than CDE / Motif. In fact this even applies to many of the GNU base tools. They were made to replace / improve upon the original and commercial versions that shipped with the OS or sold for $$$$. e.g. gcc (for cc), tar, ls, bash (for sh / ksh), gzip (for compress) and so forth. Linus never wrote the linux kernel , so that it can topple the microsoft empire, much as most of you like to belive. neither was he interested in fighting the big Unix vendors at that time. He just wanted his own version of Unix to tinker with and Minix wouldn't allow him to do just that. And neither I suspect did he write it for philosophical OSS reasons as you imply. It seems clear it was started as a hobby to build something analogous to the (commercial) Minix. And since then it has taken off to be analogous to traditional Unix kernels. The reason Linux has been success is because it favours practicality and 'getting stuff done' over the enthusiasm dampening OSS issues that some FSF projects get bogged down in. It may be GPL but this is applied in a healthy way rather than some philosophical exercise that stamps out all of the fun. But come what may, it is a fact that large and vital chunks of the Linux kernel from 2.0.x onward were expressly written with the funding and the behest of commercial entities. Suse, Red Hat, HP, Sun, IBM, SGI, SCO and others all threw a ton of money and developers into making a kernel that runs on anything from wristwatches all the way up to mainframes. If you want to imagine what OSS would look like without commercial interests, think of GNU/Hurd running twm and emacs. That really would be the state of it. But by then the world would be running MS boxes on the MS universal subscription net and OSS community would a few beards in their basement. So hooray for providing a free alternative to proprietary software I say. |
Re:Is anyone else
getting worried here? (Score:5, Informative)
by Directrix1 (157787) on Wednesday February 18, @04:24PM (#8319940) |
Apache license has never been compatible with any GPL besides LGPL. |
GPL
(Score:4, Insightful) by Gildenstern (62439) on Wednesday February 18, @04:13PM (#8319762) |
I know this is will be Flamebait but with all these problems maybe the GPL should change. |
Re:GPL
(Score:4, Insightful) by Gildenstern (62439) on Wednesday February 18, @04:19PM (#8319884) |
Well I don't think that I'm qualified. I'm not a lawyer. I looked at the Apache license. IT seems like a good thing. If the GPL is so restrictive that it won't ever work with any other type of license then it should be changed. I believe in both types of free but with all these licenses fighting against each other it does nothing to help linux. |
Re:No.
(Score:1) by insomaniac (469016) on Wednesday February 18, @06:25PM (#8321168) |
As for your falacies regarding
freedom and the BSD and GPL licenses, those have been dealt with
thoroughly before, except to say that your attitude works well for a
small project, but for a large project (especially a large,
self-contained project like a whole OS), the GPL offers you the
developer more freedom and protection from greedy folks than the BSD
would. Well, a small nitpick but there are large [freebsd.org] self [http]-contained [netbsd.org] projects written under mainly the BSD license. The three examples are actually complete operating systems. Sure companies use the code for their own products (You wouldn't believe how many hardware appliances are BSD based) but is that actually bad? I mean would you rather have all those appliances writing their own TCP/IP stack which will have lots of bugs and therefore make for shitty firewalls/routers/whatevers which companies will use anyway because it has such a pretty windows client or whatever, this will fuck up parts of the net imho. I code under BSD myself because it makes for less stress for myself and for others. If you BSD license your code that version will allways remain open for other people to use, and thats what you want with open sourcing your app right? That people actually use it? IMHO writing under the gpl makes it less fun to code for me because then I'd have to worry about other people using my code in a way the GPL's writers didn't intend. GPL is fun to write an open source competitor to closed source in but I think standards will originate in BSD because if its in BSD, everybody can use it. This is one of the factors in how TCP/IP became the standard on the internet. |
Re:GPL
(Score:1, Insightful) by garcia (6573) * on Wednesday February 18, @04:17PM (#8319843) (http://www.lazylightning.org/) |
the FSF should change, not the GPL. The GPL is fine where it stands. The FSF is forcing this issue onto everyone else and creating drama. |
Re:No.
(Score:3, Insightful) by Walterk (124748) <[dublet] [at] [dublet.org]> on Wednesday February 18, @04:31PM (#8320033) (http://dublet.org:8083/ | Last Journal: Monday January 27, @09:52AM) |
Is it that hard for GPL fanatics to
understand that some people don't WANT protection against people using
their code in proprierty projects? I love the BSD license, exactly
because it doesn't limit my code. Everybody (except GPL users
appearently) can use my code, which I create under the BSD license,
because I enjoy coding. And no, I don't care if Sun, Apple or
Microsoft uses my code. If they do, well, I hope they choke on it. BSD style license give freedom, but no security. GPL gives limited freedom, but great security. Wasn't it one of the founding fathers of the US who said "those who are willing to give up a liberty for security deserve neither"? Really, if you ask me, GPL is the problem here, since it wants all other licenses in the world to be GPL. GPL is the OSS platform independent virus, but on IP. |
Re:Uh, dude...
(Score:2) by Walterk (124748) <[dublet] [at] [dublet.org]> on Wednesday February 18, @05:06PM (#8320374) (http://dublet.org:8083/ | Last Journal: Monday January 27, @09:52AM) |
|
Hurray for
Microsoft!!! (Score:4, Interesting) by ZuperDee (161571) <[email protected]> on Wednesday February 18, @04:37PM (#8320091) |
It seems they said long ago in their
Halloween Documents [opensource.org] that "The lack of singular,
customer-focused management has resulted in the unwillingness to
compromise between the different initiatives and is evident of the
management costs in the Linux process." In my opinion, this recent XFree86 (and now Apache) business is further proof that Microsoft was right about this. I'm not trying to bash open source as a whole--I am a big Linux fan. However, I think this problem MUST be solved if the OSS community is to move forward. We cannot go on having endless fragmentation of projects, proliferation of different (non) standards and forks and everyone-going-their-own-way. A truly usable desktop OS's bread-and-butter is its ability to have truly inter-operable (dare I say this--horizontally integrated) components. Just my 2 cents worth. |
Who cares?
(Score:5, Interesting) by neurojab (15737) on Wednesday February 18, @04:47PM (#8320201) |
I, for one, use plenty of non-GPL software in my day to day life. I enjoy GPL software, but I tend to release open source software under more permissive licenses, such as MIT. I also use (and write) a lot of (gasp) closed source software as well. For the love of Pete, there are plenty of different software licenses out there. If you don't like the terms of a given license, don't use the software. If apache changes their terms because they think it makes them less likely to be sued, good for them. The GPL isn't the One True License, it's just one of the more restrictive ones that still claims to be "free". News flash: you can run software with virtually any license as long as you agree to the conditions. If some GPL-zealot distribution decides not to include Apache because of this, that's their problem. |
Re:Who cares?
(Score:2) by SuperDuG (134989) <[email protected]> on Wednesday February 18, @06:22PM (#8321130) (http://www.eclec.tk/ | Last Journal: Tuesday December 25, @03:37PM) |
You know I was going to comment almost
exactly as you had. My more popular license schemes are in fact BSD and
MIT, why?
Just as you stated, they are more permissive and free is a term that is relative. Good comment and I'm glad you were modded up and not set as a flaimbait or troll. Looks like even the moderators are starting to get a clue. |
Slashdot XFree86 4.4 List of Rejecting Distributors Grows X11 project respores advertizing clause
It's the advertising clause stupid! (Score:2, Informative)
by bsdnazz (114881) on Wednesday February 18, @09:20AM (#8315220)The xfree86 V4.4 license adds
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution, and in the same place and form as other copyright, license and disclaimer information.
3. The end-user documentation included with the redistribution, if any, must include the following acknowledgment: "This product includes software developed by The XFree86 Project, Inc (http://www.xfree86.org/) and its contributors", in the same place and form as other third-party acknowledgments. Alternately, this acknowledgment may appear in the software itself, in the same form and location as other such third-party acknowledgments.
vs.
http://www.gnu.org/philosophy/bsd.html
Text of License (Score:5, Informative)
by Bouncings (55215) <[ken] [at] [kenkinder.com]> on Wednesday February 18, @09:08AM (#8315148)
(http://kenkinder.com/)Announcement: Modification to the base XFree86(TM) license.
After a thorough re-examination of the XFree86(TM) license and reviewing
how it fits in with the Project's long-stated licensing philosophy ("You
can do what you like with the code except claim that you wrote it."),
The XFree86 Project, Inc. has made some changes to its base license.
This license review was prompted by a desire to ensure that XFree86 and
its contributors are receiving due credit for their work. The text of
the modified license can be found at
http://www.xfree86.org/legal/licenses.html.
The purpose of these changes is to strengthen the "except claim you
wrote it" clause of the Project's licensing philosophy regarding binary
distributions of XFree86. While the original license covered this
adequately for source code redistribution, it has always been lacking
where binary redistribution was concerned.
This modified license falls easily within the long-standing XFree86
licensing policy, and so there has been no change to the classes of
licenses acceptable for code contributed to XFree86. In fact, some
contributions to XFree86 were covered by a similar license already.
Contributors to XFree86 remain free to retain copyright on the code they
contribute, and can also choose the license for their code within the
long-standing XFree86 licensing policy.
The license change applies to the base XFree86 license, and to source
files that explicitly carry a copyright notice in the name of The XFree86
Project, Inc. Copyrights and licenses in the names of others will not
be affected by this change. Furthermore, only a subset of such files
with an explicit copyright notice in the Project's name will initially
carry the modified license, which is the core XFree86 components, and
the source files where there is no explicit author list. The license
in the remaining files with an XFree86 copyright will only be changed
with permission from the listed authors.
The license change will be fully effective as of the 4.4.0 release.
The initial draft of the changes will be included in 4.4.0 RC3
(4.3.99.903). A source diff showing the initial draft of the changes
is being made available for review with this announcement, and can be
found at . All XFree86
contributors are invited to review the changes, and notify us of errors
and omissions so that they can be corrected before the 4.4.0 release.
Such notifications, as well as comments about the licensing changes
should be directed to the [email protected] list. XFree86 contributors
are also encouraged to review the license change, and let us know if
they wish to make similar changes to licenses in their name.
* XFree86 is a trademark of The XFree86 Project, Inc., and is pending
registration.
[Jan 30, 2004] Mail Box SCO Wins Convert to its GPL-is-Invalid Argument (LinuxWorld)
Summary
To the Editor: Why is the Free Software Foundation given a pass on the issue of contract enforcement under state law on binding legal agreements like the GPL? The consequences are dramatic indeed for the commercial enterprise environment.To the Editor:
Why is the Free Software Foundation given a pass on the issue of contract enforcement under state law on binding legal agreements like the GPL? The consequences are dramatic indeed for the commercial enterprise environment.
When the Free Software Foundation speaks of unilateral permissions or bare license law enforcing the GPL, they are referring to a long line of case law concerning patents that was summarized by the Supreme Court in General Talking Pictures Corp v Western Electric Co, Inc., 305 US 124,125.
The principle involving a "bare license" or "unilateral permission" is that a patentee may condition his own reward of exclusive rights as he chooses. After all, the rights are his alone and he may condition them as he sees fit. The conditions he places must involve only his exclusive rights and not the exclusive "of parties involved and there is no privity requirement. The legality of this principle has never been questioned (i.d. at 125).
A derivative copyright work by the definition of sec. 103 (b) contains exclusive rights for two distinct parties, the authorizing "preexisting material" author retains his rights and the "contributed material" author gains separate, disjoint and exclusive rights to the new material he has contributed. There is no analogous "derivative patent" creation under patent law.
The "pre-existing material" author has the exclusive right to authorize and prepare derivative works of his "pre-existing" work but has no copyrights whatsoever in the "contributing" author's material.
Since the derivative work contains both the "pre-existing material" and the "contributed material" it is obvious that if both sets of "material" have exclusive disjoint rights that two separate, exclusive permissions are required to distribute the derivative work as a whole - the "pre-existing" author's permission and the "modifying" author's permission. Both authors must agree to permit distribution of the derivative work as a whole.
This is where the unilateral permission model fails. A "pre-existing" work licensor cannot place conditions on "contributing" authors' exclusive rights. It's utterly outside the scope of definition of a unilateral permission.
The "pre-existing" author has exclusive rights and no conditions can be placed on his exclusive rights without his agreement to do so. The "contributing" author has exclusive rights and no conditions can be placed on his exclusive rights without his agreement to do so. They are after all, exclusive rights. Only some form of "binding agreement" between both parties can supply both permissions required to distribute a derivative work.
The IBM legal team in their Amended Counterclaims is absolutely aware of this problem. In their Amended Counterclaims they describe the GPL as a "public agreement" cast in "a binding legal form." Ask yourself this question: If IBM describes the GPL as "a binding legal form" - what is being "bound?" The answer is "copyright permissions." That's what the GPL is about. Exclusive copyright permissions.
Unilateral license permissions do not need state enforcement. Unfortunately "binding legal forms" are enforced under state action as there is no recognized federal authority in this area.
How then, do you permit a derivative work to be distributed? This is usually done at the time the "pre-existing" author authorizes the derivative work by way of a "binding legal agreement" of some form with the "contributing" author.
When the GPL asserts:
" 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:..."
The authorizing "pre-existing" author is attempting to condition the "contributing" author's exclusive rights on the authorizing "pre-existing" author's unilateral grant of rights. This is not possible by definition. Remember "there is no mutual exchange of obligations" in a unilateral grant of permission. ([FSF attorney] Eben Moglen's words?) Only a mutual agreement of both parties in a binding form can secure the exclusive permissions of both parties so as to permit distribution.
It is the fact that copyright law recognizes two disjoint, mutually exclusive copyrights in the same derivative work that frustrates license law as promulgated in General Talking Pictures Corp v Western Electric Co mentioned above. This type of "derivative" creation was never anticipated in the evolution of patent licensing law.
There is an exclusive right for an original author to "prepare a derivative work," but there is no exclusive right to distribute a derivative work. The Copyright Act is absolutely silent concerning the "distribution of derivative works." It's left to contract law to control the distribution of derivative works.
Now things get worse. Unilateral permissions do not require privity. "Binding legal forms" do require privity. It is obvious IBM is attempting to solve the privity problem by describing the GPL as a "public covenant." "Public trusts" do not require privity.
Even if privity were granted, things get worse yet. The GPL purports to restrict the exclusive rights of the "pre-existing" owner(s) in a derivative work from authorizing a new derivative work by "bargaining for permissions" from new "contributing" authors in a continuous sequence of new derivative works (ad infinitum). Remember the phrase "You must cause any work that you distribute...to be licensed" in the GPL sec 2(b)?
The interpretation of "binding legal forms" is left to state action for enforcement. So this "binding legal form" is clearly an attempt to create a "new right against the world" concerning copyrights. The FSF calls this new right "copyleft." The attempt to create a "new right against the world" enforced under state action because of the "binding legal form" triggers preemption by sec. 301. This legal principle of preemption is clearly described in ProCD Inc v Zeidenberg, 86 F.3d 1447 (7th Cir.).
When SCO's attorney Mark Heise said copyright law "preempted" the GPL and only allowed "one copy" he was being somewhat vague. He wasn't referring to the "number of copies," he was referring to the "number of successors." SCO is indeed correct that the GPL is invalid.
Promissory estoppal will keep everyone from suing each other short-term but Linux cannot be distributed under any kind of "viral license" for future development. All those enterprise users will be stuck with the version of Linux they are now running with no way to repair or upgrade because the license is fatally flawed. "Copyleft is not possible."
A quick check by a competent attorney with the citations above will quickly confirm the accuracy of these conclusions.
Sincerely,
Daniel Wallace
Insight Communications
What is the Best Way to Handle a GPL Violation
The GPL is probably not enforceable. (Score:2)
by Brett Glass (98525) on Friday January 16, @11:57AM (#7999119)
(http://www.brettglass.com/mailbrett.html)The GPL requires you to license, at no charge, derivative works to all and sundry. Trouble is, licensing a copyrighted work is a contract. So, the GPL is a contract that requires you to make another contract. Such a "meta-contract" is invalid under the basic principles of contract law. It wouldn't stand up in court.
Re:The GPL is probably not enforceable. (Score:1)
by Random Guru 42 (687672) <[email protected]> on Friday January 16, @04:28PM (#8002350)
(http://coldacid.djfly.org/)This has been discussed elsewhere (here on Slashdot, I believe, or maybe at Groklaw), that a contract != license.
Oh, yes, here it is: The GPL is a License, Not a Contract, Which is Why the Sky Isn't Falling [groklaw.net].I stole your code too!! (Score:1, Informative)
by rabbits77 (453747) on Thursday January 15, @11:21PM (#7994878)
(http://www.rabbitfarm.com/adam.html)Yes, I , in fact, stole the following code from your very complex tab to whitespace "utility"
//sToChange is the string containing tabs to be converted to whitespace
sConverted=sToChange.replaceAll("\t"," ");
No way I could come up with something as complex as that!! And to wrap it in a class that takes command line arguments!?!? Sheer genius!!< You want to know about getting ripped off?!! (Score:0, Interesting)
by ILuvUAmiga (578974) on Thursday January 15, @11:34PM (#7994956)Check this out - we are http://www.convea.com, a very small company and I've spent years on building the sites, the docs, the apps and everything else that goes into building a company.
These f*sckers - http://www.ingenux.com/onevision wont even return calls or pull our website content, applications and service offerings. They basically ripped our site and software and renamed it, offering it as theirs.
Nice eh? Been asking them since November to take it down.
We've also been getting ripped off all over the place. It's very sad that people can do this, the biggest offenders have been operating out of barbados and other shady places, and we can do little to track them down and stop it.
Makes me sick it does, especially when its hard enough scraping a living as it is, but hearing about people landing $150,000 deals is just a bad joke.
Re:hypocrits (Score:2)
by dipipanone (570849) on Thursday January 15, @09:45PM (#7994106)Hypocrites we may be, but at least we're hypocrites who can spell.
Neither the intention of the giver (Score:1)
by Anonymous Froward (695647) on Thursday January 15, @11:19PM (#7994861)... nor the choice of the license should be questioned here. The author has chosen whatever license that pleases him/her most, and if I want to use their code I respect the license terms of THEIR choice. Or, of course, I can choose not to use their code at all. This is the principle of these license thingie, and, as such, is irrelevant of the choice of license. Please do not start "which is more suitable for this purpose" kind of frame, as it is irrelevant. Though many say that one can do whatever they want to the code released under BSD license, that's not true.
For example, if you take my BSD-licensed code, remove the "disclaimer" terms, and redistribute with or without fees, that's a clear violation of license terms (and I'm in a potential risk of being sued by somebody who doesn't know that the original work of mine has disclaimer terms) so I'll have to bite you.
I happen to prefer BSD license over the GPL when I release codes that are only personally developed by myself (for my own reason), by the way, so please understand that I'm not attacking you based on your bias towards BSD license. Let me repeat again: If someone disrespects the licensing terms (be it GPL or BSD license or proprietary), that's bad because he's violating these terms.
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Created June 1, 1998; Last modified: March 12, 2019