Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Google   

Softpanorama Copyleft Problems Bulletin, 2004

[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:

Some examples of incorrect use of GPL-licensed software include:

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 community@mysql.com. 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:

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

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
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.

>> I can become the lawful owner of a copy by gift or similar things
>> 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 <address@bogus.example.com> 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.

-- 
 Haakon

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: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 <address@bogus.example.com> 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/teleportation

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 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,