|
|
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 | |||||||
|
|
|
|
By STEVE LOHR Published: December 19, 2005To remove obstacles to joint research, four leading technology companies and seven American universities have agreed on principles for making software developed in collaborative projects freely available.
The legal wrangling over intellectual property rights in research projects involving universities and companies, specialists say, can take months, sometimes more than a year. This legal maneuvering, they say, is not only slowing the pace of innovation, but is also prompting some companies to seek university research partners in other countries, where negotiations over intellectual property are less time-consuming.
"This a great start to addressing the problem," said Peter A. Freeman, assistant director for computer and information science and engineering at the National Science Foundation. "It's a recognition by both sides that for precompetitive research, 'It's the science, stupid.' It's not the intellectual property."
The companies involved in the agreement, which will be announced today, are I.B.M., Hewlett-Packard, Intel and Cisco. The educational partners are the Rensselaer Polytechnic Institute, the Georgia Institute of Technology and the universities of Stanford, California at Berkeley, Carnegie Mellon, Illinois and Texas.
Concern about the issue of intellectual property restraints on collaborative research has been growing among academic and private-sector scientists. The new effort is a byproduct of a gathering of university and industry researchers in Washington last August, sponsored by I.B.M. and the Ewing Marion Kauffman Foundation in Kansas City, Mo., which studies and finances innovation and entrepreneurial activity.
The current problem, said Lesa Mitchell, a vice president at the Kauffman Foundation, was partly an "unintended consequence" of policies meant to encourage universities to make their research available for commercial uses, thus stimulating innovation and economic growth.
The tone was set, Ms. Mitchell said, by the Bayh-Dole Act of 1980, which allowed universities to hold the patents on federally funded research and to license that intellectual property to industry.
Since then, universities, like many corporations, have sought to cash in wherever possible on their intellectual property. The companies and universities have agreed to make intellectual property developed in open collaborations available free for commercial and academic use.
They have also agreed to a set of guidelines addressing the rights of the participating companies and universities, and the public.
The guidelines and framework for the agreement will posted this week at www.ibm.com/university, and at the Kauffman foundation's site, www.kauffman.org.
[Nov 18, 2005] Sony's CD rootkit infringes DVD Jon's copyright The Register By Andrew Orlowski in San Francisco Sony's rootkit-style DRM software, XCP, designed to prevent copyright infringement, looks like it's breaching the terms of a copyright agreement itself.
In fact it contains code written by the Motion Picture Ass. of America's villain of the week for several years running, 'DVD Jon' Johansen, who was dragged through the Norwegian courts by the MPAA using a very dubious extension of US law, for circumventing the DRM on DVDs. Johansen eventually prevailed in having the spurious charges against him thrown out.
The irony of a company using code from someone who circumvented DRM to develop an even nastier form of DRM - without even saying "Thanks!" - will surely feature in geek trivia quizzes for years to come.
The British company that developed the DRM software for Sony, First4Internet Ltd, has included free software code covered by the Free Software Foundation's LGPL, a cousin of the GPL, amateur sleuths have discovered.
The LGPL, or Lesser General Public License, was designed to protect author's rights for chunks of code rather than finished programs.
It's a complicated area, with subtle distinctions between rights over code that is compiled into, and distributed as part of the final binary program, or code that is only called at as the program is executed. But it is pretty clear cut that First4Internet has used code without observing the terms under which it's distributed - terms backed up by the power of copyright (one of our greatest inventions).
And we all know what happens to people who don't respect copyright.
Sebastian Porst discovered code from the LAME project, mpglib and VideoLAN in the XCP copy restriction, which has caused Sony so much grief. Jon Johansen is a contributor to the VideoLAN project.
"I just want to mention that the function that can be found at virtual offset 0x10089E00 in ECDPlayerControl.ocx is the function DoShuffle from a GPL-ed file called drms.c written by Jon Lech Johansen and Sam Hocevar (Google for it)," notes Sebastian.
A parallel, and even more exhaustive forensic examination of the XCP code was undertaken by 'Muzzy' - who published his findings here.
So why is First4Internet in such trouble? If you use LGPL code, the license requires that you acknowledge the provenance of the code you're using - with a clear notification and an assurance that you can provide your own source code on request. It's designed to deter lazy programmers such as... well... the kind employed by First4Internet Ltd.
FSF attorney Eben Moglen told us this evening he couldn't offer a statement on what the organization planned to do next.
The Chronicle of Higher Education/The 'dotCommunist'
A Columbia U. law professor fights to keep open-source software free
Eben Moglen is a "dotCommunist" rebel who has long advocated that all software should be free. So even he was surprised when his efforts recently won millions of dollars in support from IBM and other technology companies.
Mr. Moglen, a law professor at Columbia University, is head of the new Software Freedom Law Center, formed in February. The center, supported by $4.2-million in seed money from a number of companies, will provide free legal help to nonprofit makers of open-source software. Such software is free for anyone to use and modify, providing they share their modifications with others.
The dotCommunist Manifesto I doubt that Eben Moglen intended this as is humor, but it really turned out as a high quality humor piece ;-)
A Spectre is haunting multinational capitalism--the spectre of free information. All the powers of ``globalism'' have entered into an unholy alliance to exorcize this spectre: Microsoft and Disney, the World Trade Organization, the United States Congress and the European Commission.
Where are the advocates of freedom in the new digital society who have not been decried as pirates, anarchists, communists? Have we not seen that many of those hurling the epithets were merely thieves in power, whose talk of ``intellectual property'' was nothing more than an attempt to retain unjustifiable privileges in a society irrevocably changing? But it is acknowledged by all the Powers of Globalism that the movement for freedom is itself a Power, and it is high time that we should publish our views in the face of the whole world, to meet this nursery tale of the Spectre of Free Information with a Manifesto of our own.
Re Sticks, Stones and the GPL Responding to Readers
Re: Sticks, Stones and the GPL: Responding to Readers
Posted by: gumout 2004-08-10 10:39:41 In reply to: Phil Albert Section 106 of The Copyright Act says a copyright owner may "do or authorize" six different activities:Sec. 106. Exclusive rights in copyrighted works Subject to sections 107 through 121, the owner of copyright under this title has the exclusive rights to do and to authorize any of the following:
(1) to reproduce the copyrighted work in copies or phonorecords;
(2) to prepare derivative works based upon the copyrighted work;
(3) to distribute copies or phonorecords of the copyrighted work to the public by sale or other transfer of
ownership, or by rental, lease, or lending;
(4) in the case of literary, musical, dramatic, and choreographic works, pantomimes, and motion pictures and
other audiovisual works, to perform the copyrighted work publicly;
(5) in the case of literary, musical, dramatic, and choreographic works, pantomimes, and pictorial, graphic, or
sculptural works, including the individual images of a motion picture or other audiovisual work, to display the
copyrighted work publicly; and
(6) in the case of sound recordings, to perform the copyrighted work publicly by means of a digital audio
transmission.
Where in the six authorized activities does the word "authorize" appear a second time? Which of the
six activities described above gives the copyright owner the exclusive right to authorize another person
to further "authorize" [again] any activities?
The GPL is a nonexclusive license and cannot transfer any NON-TANGIBLE copyright ownership rights.
Unless we can *distribute* our code to others, open source software is a meaningless term.
A copyright owner can *distribute* copies (FIXED IN A TANGIBLE MEDIUM) by:
a) sale or transfer of ownership
b) rental
c) lease
d) lending
That's it folks. There is no exclusive right to nonexclusively sublicense your copyright in a "copyleft" scheme, where every successor is bound by the terms of the same license. The rules of statutory construction do not allow for inserting extra terms. That is an attempt at writing your own copyright law. This scheme cannot be enforced under
section 501 since it is not an "exclusive right" listed in section 106. This "copyleft scheme" *will* give rise to an implied license through promissory estoppel.With all due respect Mr. Albert, if you have "copylefted" your code, it was an invalid attempt at licensing.
See Bobbs-Merrill Co. v. Straus, 210 U.S. 339 for the statutory interpretation of the scope of the Copyright Act
with respect to the right to "distribute to the public" (vend).
Daniel WallaceRe: Sticks, Stones and the GPL: Responding to ReadersCopyleft is preempted by 17 USC 109.
Posted by: terekhov 2004-08-10 11:19:21 In reply to: gumoutYou are indeed correct.Re: Sticks, Stones and the GPL: Responding to Readers
Posted by: gumout 2004-08-10 12:49:04 In reply to: terekhov
Congress incorporated the principle announced in
the Bobbs-Merrill decision in 1908 into the
Copyright Act of 1976 as section 109.
It is informally known as the "first sale
doctrine". It limits copyright "copies" fixed in a
tangible medium to distribution to the public by
agreement in "privity".
[Aug 8, 2005] Re LGPL module linked with a GPL lib
To: [email protected]
- Subject: Re: LGPL module linked with a GPL lib
- From: "Michael K. Edwards" <[email protected]>
- Date: Thu, 4 Aug 2005 03:24:15 -0700
I wrote: > They're a sidetrack to be sure; but kind of an interesting sidetrack. > His personal history and philosophy strike me as more reminiscent of > Dominic de Guzman or Benedict of Nursia than any modern figure. In > any case, I certainly intended no slur on RMS by that, nor on any > participant in this discussion. You know, it's funny; I make a comment like that, and a few hours later I run across Nikolai Bezroukov's comment that "some of [RMS's] recent letters look like they have been written by a medieval theologian", and I feel dirty. Not because I meant a slur, because I didn't; Dominic and Benedict seem to have been decent, even saintly, men, and leaders of men and women, and comparisons to them are complimentary in a way that, say, a parallel to Francis of Assisi (nice to animals, may have composed a good prayer or two, but a certified kook) wouldn't be. But as thick as my writing style is, I'm sure it's hard to tell the difference between my cumulative critiques and a real hatchet job like Bezroukov's. And once in a while I go off half cocked (not with "economic superiority of the free software system", which was a deliberate re-framing of RMS's published philosophy, but with an apparently wrong guess about which non-programming source of income keeps his boat afloat), and I find myself wishing I'd left the whole topic alone. But dammit, this is not a game, this is people's lives and livelihoods. Using deception about the law to claim rights over other people's work is wrong, no matter who is doing it. RMS may sincerely believe that the GPL is a successful hack around contract law and the limits courts have imposed on other software copyright holders; but I don't see how a court could possibly agree with him. Where the money comes from, and where it goes, do have some bearing on whether it's proper to accept the FSF's unsubstantiated assertions on legal matters; and I want to know the truth, and to see it known and acted on by people whose influence over the free software ecosystem is greater than mine. - Michael
[Apr 06, 2005] Schwartz swipes at the GPL Builder AU Program At Work "Imagine a developing nation that elects to use free software in the construction of its intellectual property and then finds that it has a rather predatory obligation to give back all the intellectual property to the wealthiest nation in the world that happens to be the author of the GPL," Schwartz said.
Schwartz singled out the GPL provision that says source code may be mixed with other code only if the resultant code also is governed by the GPL. That provision is intended to create a body of software that must remain liberated from proprietary constraints. But Schwartz said that some people he's spoken to dislike it because it precludes them from using open source software as a foundation for proprietary projects.
"Economies and nations need intellectual property (IP) to pull themselves up by their own bootstraps. I've talked to developing nations, representatives from academia and manufacturing companies that had begun to incorporate GPL software into their products, then... found they had an obligation to deliver their IP back into the world," Schwartz said.
The GPL purports to have freedom at its core, but it imposes on its users "a rather predatory obligation to disgorge all their IP back to the wealthiest nation in the world", the United States, where the GPL originated, Schwartz said. "If you look at the difference between the licence we elected to use and GPL, there are no obligations to economies or universities or manufacturers that take the source code and embed it in [their own] code."
[Apr 06, 2005] Sun slams predatory GPL - Computeract!ve
In his most elaborate response yet to the criticism Schwartz said the GPL is unfair and "predatory". The GPL requires developers to publish all the code that they mix in with the original GPL code, where the CDDL allows them to guard their work if they want to.
"Imagine a developing nation that elects to use free software in the construction of its intellectual property and then finds that is has a rather predatory obligation to give back all the intellectual property to the wealthiest nation in the world that happens to be the author of the GPL," Schwartz noted.
The GPL is wrongly used as a way force developers to share their work because the creators have a hidden agenda of forcing a social model on the world, the Sun executive claimed.
He described the authors of the GPL as "individuals and companies that want to use intellectual property models to define social models and economic models rather than intellectual property models."
The controversy over the GLP has led to the Open Source Initiative (OSI)to reform the system for using open source code under licence. The latest version of the license, version 2, was released in 1991.
Linux Pipeline Sun's Schwartz Equates GPL With 'Colonialism'
Schwartz in particular targeted the General Public License, used by many open-source initiatives, in a talk before 700 attendees of the Open Source Business Conference in San Francisco on Tuesday. Under the GPL, developers are required to publish or "give back" their work to the general community. Such licensing practices work to the advantage of the United States, which already enjoys a technology lead over many parts of the world, Schwartz said.
"I do not believe in intellectual-property colonialism," he declared.
Sun took a sounder approach in using the Mozilla Public License as the model for its Sun Community Development and Distribution License, Schwartz said. The CDDL was created for OpenSolaris, the open-source version of Sun's Unix operating system. Sun will make Solaris 10 available as open-source code sometime in the second quarter. The CDDL allows proprietary products to be built on top of open-source code and allows a Third World developer to produce a product for sale in the United States and elsewhere.
Schwartz said he has talked to representatives from academic institutions and developing countries that want the opportunity to sell software they produce with open-source code. The GPL inflicts "a rather predatory obligation to disgorge their IP [intellectual property] back to the wealthiest nation in the world," the United States, he noted. Instead of meeting such a requirement, poorer societies need the right to use open-source code to "bootstrap" their own economic development, he said.
But not everyone agrees. On Wednesday at the same conference, a supporter of Third World development, Lawrence Lessig, law professor at Stanford University and founder of the school's Center for the Internet and Society, expressed doubt that the GPL was a future source of technological imperialism.
Lessig said he has discussed the issue with Brazilians, and they were less concerned with the terms of open-source licenses than with not having access to the technology at all. Members of the Brazilian government told him Microsoft representatives have warned them that open-source software costs more in total cost of ownership than Windows, he said. The Brazilians told him, "We'd rather invest in a free-software infrastructure. It buys commitment to Brazilian society, building up computing expertise, as opposed to sending our capital abroad," Lessig said.
Schwartz swipes at the GPL - ZDNet UK News Schwartz correctly noted that due to its anarchistic nature The GPL imposes a 'predatory obligation to disgorge IP back to the wealthiest nation in the world'
Schwartz singled out the GPL provision that says source code may be mixed with other code only if the resultant code also is governed by the GPL. That provision is intended to create a body of software that must remain liberated from proprietary constraints. But Schwartz said that some people he's spoken to dislike it because it precludes them from using open source software as a foundation for proprietary projects.
"Economies and nations need intellectual property (IP) to pull themselves up by their own bootstraps. I've talked to developing nations, representatives from academia and manufacturing companies that had begun to incorporate GPL software into their products, then... found they had an obligation to deliver their IP back into the world," Schwartz said.
The GPL purports to have freedom at its core, but it imposes on its users "a rather predatory obligation to disgorge all their IP back to the wealthiest nation in the world", the United States, where the GPL originated, Schwartz said. "If you look at the difference between the licence we elected to use and GPL, there are no obligations to economies or universities or manufacturers that take the source code and embed it in [their own] code."
[Jul 2005] Top Tech News - Software - Sun's Jonathan Schwartz Slams Open-Source Licensing Model Schwartz said the GPL "exports a form of IP colonialism to nations seeking to create their own means of production" and demand that they return their source code back to developed countries.
The GPL governs a significant number of projects in the open-source software community. But its use is tantamount to economic imperialism, Schwartz believes.
In his speech, Schwartz said that the GPL expressly limits choice by disallowing the inclusion of non-GPL code into GPL projects. He added that it "exports a form of IP colonialism to nations seeking to create their own means of production."
Those who use the GPL as a foundation for proprietary software dislike having to give their intellectual property "back into the world," Schwartz said.
Unfolding Roadmap
As an alternative to the GPL, Schwartz praised the company's Community Development and Distribution License (CDDL), a variant of the Mozilla Public License.
Sun has already started using this license strategy with the release of Solaris source code.
In addition to his GPL comments, Schwartz also addressed criticism surrounding Sun's decision not to release Java as open-source software. The refusal to go with a proprietary scheme is to prevent Java from forking, he noted.
License Department
Schwartz's comments illustrate the increasing complexity of licensing, especially in the open-source realm, said Yankee Group analyst Dana Gardner.
"Not long ago, there were only a couple of open-source licenses," he said. "Now, you've got many, and there are many more being created."
The result is that some companies will develop their own, as Sun has done, or tweak existing licenses to suit their needs. Gardner praised Sun's willingness to address the issue directly. But even with this kind of clarity, companies should be ready for more confusion, rather than less.
"We're beginning to enter
Schwartz Attacks GPL; Sun's Mention of "Stewardship" Has People Thinking of Java
At the inaugural Open Source Business Conference, which opened today in San Francisco, Jonathan Schwartz has been giving a keynote. We bring here an early on-the-spot report, written by former JDJ editor-in-chief and LinuxWorld Magazine founding editor, Alan Williamson.
... ... ..
On the subject of Java, Schwartz also addressed criticism of the alleged hypocrisy of Sun's message for not having released Java under GPL.
He answered this criticism by asserting that the licensing of Java was not the issue: Sun wants to keep Java from forking into different incompatible versions, thus depriving the many companies that rely on Java as a standard of their business opportunity.Schwartz continued to discuss GPL, issuing a cautionary warning regarding the use of this particular license noting that Sun "believes in IP" but not in "IP colonialism." He talked about how licenses imply an obligation and one must be very careful to read the small print.
Finally Schwartz tailed off, talking about how a product should be adopted because it's better and not because it's free.
Forbes.com Follow-Up To Linux's Hit Men
Follow-Up To Linux's Hit Men
Dan Lyons' Oct. 14 story, "Linux's Hit Men," generated a flood of reader e-mail. His reply follows. Please go to our discussion board to post your opinion. Dan has promised to weigh in on occasion. --Eds.
Of course the Free Software Foundation is entitled to enforce its GNU General Public License (GPL), just as other organizations are entitled to enforce their copyrights and licenses. My article simply points out that the paradoxical effect of these "enforcement actions" (FSF's term) may be to impede the adoption of Linux. By demanding that licensees publish source code for their own "derivative work" code (in addition to the Linux they're using) the FSF is, in effect, charging a royalty that approaches 100% of the value of the licensee's product.
Yes, the FSF is entitled to do this. But some people question the wisdom of this policy. They think it will scare off commercial software and hardware developers who want to use open source software but don't want to destroy the value of their product and don't want get into a hassle like the one Cisco Systems (nasdaq: CSCO - news - people ) and Broadcom (nasdaq: BRCM - news - people ) are having. Even within the open source world there is a difference of opinion on this issue.
As many readers point out, if a company doesn't like the GPL, they shouldn't use Linux. That's fair enough. No doubt many will stay away. But is that good for Linux?
Linux News Commentary/Open Source and the Legend of Linksys. An interesting variation on the theme of old 2003 of SCO complain "'The GPL is selectively enforced by the Free Software Foundation such that the enforcement of the GPL by IBM or others is waived ". Also contains an interesting fact that OpenTV ended up paying the FSF $65,000. But OpenTV also reportedly complied by making available the requested code, so the purpose of the payment is unclear. The FSF's stated mission is not to demand money damages for GPL violations.
The "Legend of Linksys" is a metonymy for this second question, in the reverse: What have people not gotten away with? The legend has at least two sides to it: the legal and the factual. First, the facts.
I have no personal knowledge of any of the facts I am about to describe; if I did, I would not be writing an article about it. But the facts here may be murky, and I welcome correction; my lack of personal knowledge is further complicated by the legendary nature of the story -- legendary, because the negotiations to resolve it were non-public. The sources I used to put this together were mainly the Forbes article "Linux Hit Men" dated October 14, 2003, an article of the same date in Linuxdevices.com quoting Bruce Perens, and several random bulletin board postings about the Linksys product.
Linksys is a very successful purveyor of WiFi routers, in particular the WRT54G 802.11g wireless home gateway. In March, 2003, Cisco Systems (Nasdaq: CSCO)
bought Linksys for US$500 million. After the acquisition, in June 2003, complaints appeared on discussion boards such as LKML and Slashdot claiming that Linksys was violating the GPL by not providing source code for certain code used in its WRT54G wireless access point. (See for instance this posting.) The Linksys product included both the Linux kernel and other GPL code.
This is the nightmare scenario for an acquiror worried about open source. In the trade this is known as "buying a lawsuit."
The FSF stepped in, stating publicly that it was spearheading enforcement for multiple copyright holders who had licensed materials under the GPL: "[W]e are leading a coalition of many copyright holders in the WRT54G, as Linux is only one part of a large body of GPL'ed software in the product. We formed this coalition because, having done enforcement cases for a product with a broad range of copyright holders before, we have found that separate enforcement actions and/or law suits from individual copyright holders make attainment of compliance more difficult."
Undoubtedly informal enforcement actions are easier with fewer parties involved. However, this statement as it relates to "law suits" is a bit disingenuous, for two reasons: first, FSF has never actually led a formal defense group to enforce the GPL in court, and second, if it did so, it would likely do so based not on convenience, but necessity, as separate suits might be impossible due to legal due process requirements.
What Can Be Learned
Linksys eventually released the source code at issue. Various Web reports place the release at three to four months after the first demand by the FSF. It is amusing to read the morally outraged postings on this subject that describe this result as glacially slow. It seemed fast to me. The only way to do it faster would have been a scorched earth TRO action or some jackbooted GPL police.
The first take-away from this case is the difficulty of doing enough diligence on software development in an age of vertical dis-integration. Cisco knew nothing about the problem, despite presumably having done intellectual property diligence on Linksys before it bought the company. But to confound matters, Linksys probably knew nothing of the problem either, because Linksys has been buying the culprit chipsets from Broadcom (Nasdaq: BRCM)
To discover the problem, Cisco would have had to do diligence through three levels of product integration, which anyone in the mergers and acquisitions trade can tell you is just about impossible. This was not sloppiness or carelessness -- it was opaqueness.
There is no way around this problem if one approaches open-source diligence from a provenance angle. Finding the ultimate source of code is too difficult. This argues for "back-end" risk management like insurance
Accepting Controversy
The second take-away is that this was a strong case for the FSF, but to understand why takes us into some of the more excruciating details of kernel development. One online complaint said:
I am unable to build a working Linux kernel based on your tree due to source code missing from arch/mips/brcm-boards/ and other directories. You also seem to have modified the kernel module loading process, as standard kernel modules built from your tree load without warnings on a running WRT54G, but apparently do not function properly. ... I believe it is a violation of the GPL to distribute versions of the Linux kernel that are missing critical, non-modular kernel code.
I quote the above not for the truth of its assertions, but to point out why Linksys got tagged. The writer was unable to build a working kernel. He characterized the undisclosed code as "critical" and "non-modular." Engineers are practical folks, and they don't tend to quibble over adhering to the letter of a license if they can reap its benefits. He could not reap. Consider also this comment (cited above) on the LKML board:
I know that traditionally, Linux has allowed binary-only modules. However, I was always under the impression that this required that the final customer be allowed to remove them at will. That is to say, you couldn't choose to implement a portion of the kernel critical to the system's operation in a module, and then not release that module under the GPL. In this particular case, I would argue that the wireless drivers are critical to this device's operation ...
This writer is making a crucial point: There is some controversy in the free software world over whether some kinds of kernel modules escape GPL terms. But Linksys was not in one of these gray areas. Linksys not only included kernel modules in their code, they included statically linked kernel modules that could not be separated from the kernel. For the FSF, this was game, set and match.
Several commentators have noted that GPL compliance issues are particularly problematic in embedded applications, as well as code developed by overseas developers. The Legend of Linksys bears out both these observations.
It's a Small Welte After All
Across the wide ocean, other enforcement of the GPL runs along a different trail. Harald Welte, a self-appointed enforcer of the GPL who operates a GPL Web site filed two actions with the District Court of Munich to enforce the license. In both cases, Welte was the author of code that had appeared in the defendant's product. The court granted Welte an injunction against Sitecom Deutschland GmbH, prohibiting Sitecom from distributing a wireless networking router until it complied with the GPL. Sitecom appealed the injunction, but lost, and Sitecom later posted the terms of the GPL on its FAQ Web page for the router. Welte also filed for an injunction against Fortinet UK Ltd. based on its firewall products, with similar results.
Though much has been made of these two cases, there are reasons why Welte has already obtained injunctions in Germany while the FSF has not yet sought one in the US. Injunctive enforcement in Germany is so simple and quick that it makes Americans suspicious about piddling legal details like legal due process. In Germany, a preliminary injunction can be obtained ex parte -- in other words, without giving the defendant the chance to defend itself. (This has the appropriately scary sounding name einstweilige Verfuegung.)
Also, in Germany, an author of a component piece of software can enjoin an infringer from distributing the entire program, not just the part he owns. In the US, any injunctive relief requires that the defendant have the ability to present a defense. Moreover, in the U.S., a plaintiff seeking a temporary restraining order must post a bond to compensate the defendant in case the TRO is wrongly issued. In Germany, there are no such niceties. So, before you start flushing your proprietary loadable kernel modules down the commode, remember that the path to an injunction here in the U.S. -- and indeed in most common law countries -- is much more treacherous. This is why injunctions in Germany are likely to happen long before -- or in lieu of -- injunctions in the U.S.
More interesting to U.S. companies are Welte's informal enforcement actions, which have included sending letters to over a dozen large commercial software and appliance products including Motorola (NYSE: MOT)
The Landscape Evolves
Anyone who decries the enforcement actions of the FSF only need read Welte's blog to appreciate the FSF's restraint. Some of Welte's targets have complied voluntarily, but one suspects that is because they were simply unaware of the problem. Welte apparently has no authority to enforce these copyrights. These actions are not really legal enforcement -- more the equivalent of picketing companies that use cheap overseas labor. It is an attempt to embarrass, not enforce.
It is also impossible to avoid observing that Welte often proceeds without the benefit of legal analysis. For instance, he targeted AOpen, which responded, that he "should have directed that letter to their Taiwanese mother company, since the products that I claim are in violation of the GPL are not sold in Germany. They don't get it. Its their problem if they don't comply with the license. Its they who are liable for copyright infringement. I don't care which particular subsidiary of a multinational corportation [sic] is responsible. It is in the best mutual interest of any subsidiary to assure that they comply with license conditions."
Actually, AOpen's point was probably that there was no action under German law because lack of an infringing product in Germany meant it was not within German jurisdiction. But, it so happened, that AOpen was actually compliant, having offered the source code on a German Web site, as Welte later noted in his blog. Nevermind.
This kind of stuff gives lawyers the willies, on the one hand. Lay commentators who post on blogs or bulletin boards about open source legal issues without the benefit of legal reasoning are a dime a dozen, but at least they don't usually sue people. On the other hand, who would you rather be sued by: Welte or the FSF? Given that most of Welte's complaints would fail in the U.S. on procedural grounds that would allow a defendant to jettison the case quickly, he is my plaintiff of choice.
Other enforcement of the GPL has been of less note. The MySQL case, which is the only lawsuit ever filed in the U.S. regarding GPL code, was disposed of on unrelated grounds. The FSF has conducted regular informal enforcement, but none has garnered quite the press of the Linksys matter. In 2002, the FSF engaged in a GPL enforcement action against OpenTV, a San Francisco company that ships a set-top box containing Linux. According to Forbes, OpenTV ended up paying the FSF $65,000. But OpenTV also reportedly complied by making available the requested code, so the purpose of the payment is unclear. The FSF's stated mission is not to demand money damages for GPL violations.
Meanwhile, we are all waiting for the other shoe to drop. And while rumors occasionally circulate that lawsuits will be filed -- as in the case of OpenTV -- there is a big difference between making threats and filing lawsuits. So, get used to standing on one foot, while legend of Linksys lives on.
Heather Meeker is a shareholder at the international law firm Greenberg Traurig, LLP, and specializes in intellectual property transactions for software and other technology clients. Ms. Meeker is the co-chair of the Open Source Committee of the Science and Technology Section of the American Bar Association. She advises clients regularly on open-source licensing issues and open-source business strategies.
[June 10, 2005] NewsFactor Network - Enterprise - Developing Code in the Open-Source Kitchen Developing Code in the Open-Source Kitchen
Many software executives break out in hives at the mere mention of the GPL. Most likely, this is due to the GPL's "restriction on downstream restrictions," a clause that sets the GPL apart from other open-source licenses that allow downstream users to license derivations restrictively.
Don't be surprised if you achieve your business goals sooner. Introducing PlanView Enterprise. You can now align IT with your business strategies, elevate your company's IT performance and increase enterprise-wide visibility. Imagine you love Italian restaurants but you are highly allergic to garlic. To ensure your meal doesn't make you sick, you could carry around a mass spectrometer to detect the particular chemical signature that gives garlic its characteristic odor and flavor. An easier way might be to watch the kitchen prepare your pasta and note what ingredients they use.Like food lovers, software developers and companies with products that depend on software can get allergies too and must watch the proverbial kitchen to make certain everything turns out just right. For example, improperly incorporating someone else's intellectual property into a development project can make a company and its customers sick.
Copying -- or the incorporation of somebody else's protectable software without a license -- is copyright infringement. It can lead to disruptions in product releases, legal liability, public humiliation and a rash of other problems.
Understandably, everyone who produces software should be concerned that any use and distribution of products that include the code of others is done within the specific license that covers the included code.
Allergic Reaction to the GPL
Many software executives break out in hives at the mere mention of the General Public License. Most likely, this is due to the section of the I call the "restriction on downstream restrictions." This clause sets the GPL apart from other open-source licenses that allow downstream users to license derivations restrictively.
Essentially, the GPL says that you can do whatever you want with the software you licensed under the GPL, except that you cannot add restrictions when you license out the software or a derivation of the software. This causes heartburn as developers want to maintain restrictions on their own code yet still benefit from the open-source code. But the combination of the two often can be considered a derivative work, which requires compliance with the license on the open-source software used.
While many open-source licenses do not have such restrictions, this restriction against downstream restrictions makes the GPL a popular choice among open-source program creators, lest they see their freely contributed code coopted into someone else's expensive program. Like hay fever, we just have to live with it.
Open Source Is No Different
The concerns over open-source inclusions are no different than concerns over incorporating any intellectual property of others into a product. Inclusion of someone else's open-source code without the necessary license is just as harmful as inclusion of someone else's trade secrets.
Granted, usually it is easier to get hold of someone else's open-source code than it is to conduct industrial espionage, and often it can be obtained without any purchasing department oversight. But, however the intellectual property of others is obtained, there has to be a moment where someone says "Hey, here's some code we should include in our code base for our new product."Training programmers, project managers and code custodians is the key to avoiding improper inclusion of the intellectual property of others. At minimum, someone should document what chunks of code came from where. Everyone involved has to understand that they cannot include code without knowing where it came from and informing the custodian of the code.
Whatever area of the organization is charged with tracking such inclusions -- whether it is the legal department or the project-management department -- someone should be able to produce a list of what was included and the license under which that inclusion was brought in.
Automated Code Detectors
Several vendors currently offer systems or services that can scan a project's code base to detect the use of open-source software. It is likely these systems do more than look for the string "Licensed under the GPL" in the comment fields.
As some of their literature describes, the systems scan for signatures of known open-source programs. This, of course, requires knowledge of most open-source programs and their probable variations. It also requires constant updating as is done with virus signatures.
Such an approach is not nearly as reliable as checking the code at the outset. Code signatures assume that the detector vendors have access to all relevant open-source code. This seems unlikely, given that many code writers who choose the GPL write software programs informally. They don't spend time ensuring that their code propagates to all the popular code repositories.
Meanwhile, back at the Italian restaurant, let's change the scenario slightly. Instead of watching food preparation in your own restaurant that you control, imagine yourself someplace you've never been -- where the unexpected is commonplace and you don't control a thing. Such is the case with licensing code from other developers for inclusion. In such cases, signature checking is probably the only way to detect potentially dangerous inclusions.
If you inherited code, or you are licensing code from a third party that you cannot entirely trust, then go ahead and run the code through a detector. Just remember to rely on it only so far as the detector vendor is willing to guarantee accuracy.
Legal Implications
Legal institutions necessarily trail business and technical developments, and open-source usage is no exception. There are not yet any hard and fast legal rules about what happens when an organization is spotted using someone else's open-source code that is not entirely in compliance with the license for that someone's code.
Even IBM v. SCO is not strictly such a case. So even if it ends up making case law, it might not apply to many situations. Most instances of code inclusion will be attributable to individuals acting without authorization of their employers, either because the employing organization really was unaware and did not authorize the inclusion or because proof is lacking of any involvement.
A sensible organization will quickly extract the improperly used code and replace it, or will seek a license that is consistent with its prior actions. In the long run, it always costs an organization more in terms of management time, hard costs and damage to its reputation than it does simply to operate a tight ship in the first place.
Maybe it's unfair to compare brilliantly creative software code with fantastic pasta, but keeping an eye on the chef is easier than post-construction analysis any day. Like scanning the menu, post-construction scanning of code is likely to lead to a false sense of security if it is overused. There is simply no good substitute for having everyone on the team trained in the proper use of tools and ingredients.
So whether you are allergic to food or the legal ramifications of life as a programmer, make sure you study the license agreement and all the ingredients carefully. Bon appetite.
[June 2, 2005] Missing GPL detail may make it harder to enforce - ZDNet UK News
The GPL may be difficult to enforce due to a lack of clarity over who owns the copyright to the software, according to a legal expert on Monday.
Lucie Guibault, an assistant professor of intellectual-property law at the Institute for Information Law in Amsterdam, said at the Holland Open Software Conference in Amsterdam, that the GPL should clarify who is the author of the software to ensure that open source software distributed under this license receives legal protection.
The copyright of the actual text of the GPL is owned by the Free Software Foundation, but the author owns the copyright to the GPL-licensed software. Authors that wish to release their software under the GPL are advised to include a line in the source code stating "Copyright © [name of author]". Guibault told ZDNet UK that it may not be enough to have the copyright statement in the code.
If the author of GPL-licensed product discovers that a company has not adhered to the terms and conditions of the license, the individual may find it difficult to argue his case in court as the defending party could argue that the copyright appears to belong to the Free Software Foundation, according to Guibault.
"The only name that appears on the license is the Free Software Foundation — they appear to be the licensor," she said.
But Richard Stallman, the founder of the Free Software Foundation and the author of the GPL, claimed that even if this is a problem in the Netherlands, it will not affect free software elsewhere.
"If free software licenses are not valid in the Netherlands, copyright law still applies, so the result could be that no one is allowed to distribute or change free software there. However, the FSF will continue to respect everyone's right to do so," said Stallman.
"Whatever happens in the Netherlands, it won't be a disaster for free software in general. If the Netherlands has put something foolish in its laws, it will just have to fix their laws to do the right thing," Stallman added.
Harald Welte, the founder of GPL-violations.org, said in an interview in March that he is able to take legal action against companies that have violated the GPL as he is the author of the GPL-licensed software that companies have misappropriated.
"Most of the violations we're seeing are happening in the embedded market," said Welte. "They are running the Linux kernel and I have copyright on parts of the Linux kernel. In the cases that went to court, it was me as an individual copyright holder [against the company in question]."
Although Welte has been successful every time he has accused a company of violating the GPL, Guibault claimed that he is primarily relying on the goodwill of companies to settle copyright violations out of court. Welte has so far negotiated about 30 out-of-court settlements, three preliminary injunctions and one court order. None of the cases has ever gone to trial, but if this happened the case could go either way, according to Guibault.
"The accused party could say — the only party I dealt with [in the license agreement] was the Free Software Foundation," said Guibault. "The author of the software could probably argue their way out of it, but it depends on the judge."
The solution to this issue would be relatively simply matter of adding the name of the software author to the license agreement, said Guibault. She said at the conference that the Mozilla Public License is better in this respect as it makes it clear who owns the software.
"It is technically very easy to correct this," said Guibault. "Mozilla may be one of most clearest examples [of an open source license] — you can put you own name there as a developer or contributor. Users of the software don't have to look everywhere to see who grants the license."
One UK legal expert said that Guibault's argument was effectively an issue of evidence, rather than law.
"If I write a piece of software (not as an employee) I am the copyright owner whether or not my name appears on the software or its packaging," said Joel Barry, a partner at legal firm Olswang.
"I get the right to prevent certain forms of misuse prohibited by copyright law. Evidentially if I put my name and the date on the software/packaging that creates a legal presumption under UK law that I am the owner and that the date is the date of creation. If I do not then I need to prove this as a matter of fact."
"If I release my software under a license (e.g. the GNU license) then I permit certain uses under that license. If someone misuses my software I have to prove (i) I am the owner of the copyright in the software, that (ii) the misuse is a breach of the law and (iii) that is it not permitted under the license. Strictly speaking the defendant must prove point (iii) - i.e. that he has a defense under the license," Barry explained.
[May 20, 2005] ACCA_Open_Source_Hidden_Problems_05.05
Open Source: Paper Tiger, Hidden Problems? by Daniel J. Schwartz Open source software
and code has the potential to be a real problem for any organization. From small packets of code developed by back-office
programmers to the very operating system running all of the organization's computer systems, open source presents issues
that in-house must address today and prepare for tomorrow. This article addresses several possible open source issues
and provides a brief update on the SCO Group's litigation with IBM and a recent ruling by a German court, in a case of first
impression by a tribunal in any country, upholding the validity of one of the most common open source license agreements.
Intellectual Property and Technology Law Practice Rather than spend several days writing code to develop a new feature for a proprietary software application, a programmer spends an hour on the Internet searching for previously written, and freely available, code for that feature. Having found suitable code, the programmer clicks his mouse a few times, and downloads the code for use in the proprietary system. Sounds harmless enough, right? Not necessarily, especially if the programmer downloaded open source code. In general, open source refers to any program whose source code is made available for use or modification as users or other developers see fit.1 Open source software is usually developed as a public collaboration by many unrelated programmers and the software is made freely available. One impetus behind the open source movement is that software develops faster when programmers can use, modify and re-distribute others’ source code. Developers of open source software typically make their programs available through one of the open source license agreements. Hundreds of such license agreements exist. However, several particular agreements have become the most popular, including GNU’s General Public License (“GPL”), the MIT License and the Mozilla Public License.2 While each license is different, they universally exclude any warranties regarding the licensed code. Accordingly, the agreements do not provide warranties regarding use, applicability, title or noninfringement of other’s intellectual property. This leaves the licensee relatively exposed and unprotected concerning use of the open source code. Each license agreement also differs in the restrictions it places upon a licensee’s use of code and on the licensee’s ability to create and maintain proprietary software using the licensed open source code. For example, the GPL requires that any modification of the licensed code remain as open source code and be available to others under the GPL.3 Accordingly, if a programmer simply clicks on a button to download even the smallest packet of code and thereby agrees to the GPL, then the GPL may require the entire software program, which incorporates the GPL-code, to be made available as open source under the GPL. This is true regardless of whether the programmer or employer ever intended others to be able to see, read, view and modify their software. Thus, a single click of the mouse may render otherwise proprietary software available to all. For this reason, the GPL is often referred to as the most “viral” open source license agreement – i.e., like a virus, it infects any code into which it gets inserted.4 Even this short review of open source license agreements makes clear that many risks exist regarding your company’s decision whether and how to allow the use of open source code. Complicating this decision is the lack of case law analyzing these open source license agreements. In the only case presenting an opportunity for judicial evaluation of the GPL — the most commonly used open source license agreement — the parties settled before any meaningful rulings by the court.5 In Progress Software, MySQL alleged breach of the GPL, but the court never had the opportunity to rule on this issue. No other U.S. court has addressed the GPL. Therefore, no court has ruled on its enforceability or This advisory was prepared by Jenner & Block’s Intellectual Property and Technology Law Practice for the Information Technology Law & Ecommerce Committee of the Association of Corporate Counsel. May 2005 2 May 2005 even who has the right to bring suit for an alleged breach of the GPL. Recently, however, a German court squarely addressed the GPL and affirmed its enforceability.6 In this case, a group called the “netfilter/iptables project” sought an injunction against Sitecom alleging that Sitecom did not comply with the terms of the GPL in distributing certain software created and provided by “netfilters” under the GPL. Even though the German court questioned the enforceability of certain terms of the GPL under German law, it concluded that Sitecom violated other valid terms of the GPL and issued an injunction against it. While not directly construing any open source license agreement, another much-watched open source software case is the present litigation between SCO Group and IBM relating to the UNIX and Linux operating systems.7 In general, SCO Group alleges that IBM misappropriated SCO’s UNIX intellectual property — which SCO Group asserts ownership of — in the development of IBM’s Linux operating system services business.8 The prevailing thought is that if SCO is successful in this litigation, it could assert claims against users of the Linux operating systems — which include most of the world’s largest companies and many smaller ones as well. Recently, however, the court suggested that it was skeptical SCO would succeed because it had not provided any proof to support its claims in the two years since initiating the suit: “Viewed against the backdrop of SCO’s plethora of public statements concerning IBM’s and others’ infringement of SCO’s purported copyrights to the Unix software, it is astonishing that SCO has not offered any competent evidence to create a disputed fact regarding whether IBM has infringed SCO’s alleged copyrights through IBM’s Linux activities.”9 Suggestions At this point, it is unclear whether open source licensing issues are anything more than a “paper tiger,” or whether these hidden issues will truly materialize into problems for your organizations. The SCO Group litigation illustrates one of the most serious potential problems with licensing software and operating systems (commonly Linux) that incorporate open source code. Because the licenses exclude any warranties of title or noninfringement, you may be faced with a third-party claim that it actually owns the code and that your company is infringing the third-party’s intellectual property or contractual rights. In light of this uncertainty, you need to consider company policies concerning the use of open source code. Managing the risks associated with open source demands that you discuss these issues with your programmers and arrive at known solutions in advance of someone potentially entering into a license agreement without the company knowing about it. You should also consider evaluating the various open source license agreements to ensure that you know which agreements are acceptable for your company’s purposes (which may differ for each project). Furthermore, education and training is extremely important. Making sure that everyone involved in developing software at your organization knows the policies and procedures for dealing with open source issues remains the best weapon against an otherwise uncertain background. 3 May 2005 ©Copyright 2005 Jenner & Block LLP. Jenner & Block is an Illinois Limited Liability Partnership including professional corporations. This publication is not intended to provide legal advice but to provide information on legal matters and Firm news of interest to our clients and colleagues. Readers should seek specific legal advice before taking any action with respect to matters mentioned in this publication. Under professional rules, this publication may be considered advertising material; the attorney responsible for this publication is Daniel J. Schwartz. Cover image from the Collection of the Supreme Court of the United States.For more information, please contact: Daniel J. Schwartz, Partner [email protected] Tel: 312 923-2846 Endnotes 1 See www.opensource.org/docs/definition.php. 2 The full text of these agreements can be found at http://www.gnu.org/licenses/licenses.html, http://www.opensource.org/licenses/mit-license.php, and http://www.mozilla.org/MPL/, respectively. The GNU and Mozilla sites also have particularly helpful “frequently asked questions” or “FAQ” sections at http://www.gnu.org/licenses/gpl-faq.html and http://www.mozilla.org/MPL/mpl-faq.html. The FAQ sections provide explanations of use and interpretation of the license agreement as well as examples of how the license is meant to address certain situations, including the use of licensed code in proprietary systems. 3 Section 2(b) of the GPL states: “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. . .(b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License…” 4 GNU also provides a “Lesser GPL” or “LGPL” agreement. Open source developers do not use the LPGL as frequently as the other licenses, in part because the LPGL more readily allows licensees to use the code in proprietary systems. See http://www.gnu.org/licenses/why-not-lgpl.html. 5 See Progress Software Corp. v. MySQL AB, 195 F.Supp.2d 32 8 (D.Mass. 2002). 6 See http://www.jbb.de/judgment_dc_munich_gpl.pdf. 7 SCO Group v. International Business Machines, Corp., No. 2:03-CV-00294 DAK (D.Utah) 8 SCO Group is involved in additional litigation with Novell over purported ownership rights to certain aspects of the UNIX operating systems. In that litigation, Novell asserts that it — not SCO Group — own that intellectual property. 9 SCO Group v. International Business Machines, Corp., 2005 WL 318784 *5, No. 2:03-CV-00294 DAK (D.Utah Feb. 9, 2005)
With Jeremy Boynes, CTO of Gluecode Software, which sells a suite of open source software built on top of widely used open source developer projects from the Apache Software Foundation.Question: Which features of the BSD license, or BSD-style licensing, make it more appropriate for your use? Or is it more a matter of the GPL NOT being at all appropriate?
Boynes: While there are many successful and broadly used open source projects that are licensed under GPL, BSD-style licensing is more appropriate for commercial companies such as Gluecode that are striving to build product-derived "value-add" functionality on top of open source. Most companies that are built around GPL projects, including Red Hat, tend to be professional services or consulting organizations. With BSD-style licensing, individuals and organizations can build product features on top of open source without being obligated to contribute these back to the open source project. The BSD licensing model helps individuals and organizations leverage existing open source technologies to enter new markets and to compete in those markets based on their unique technology differentiation. Gluecode has chosen to use BSD-licensed technology to add value on our own terms. Gluecode has integrated a number of Apache 2.0-licensed projects, including Apache Geronimo (application server), ActiveMQ (messaging), and Apache Derby (database) to create an integrated open source stack for the lightweight container market. Gluecode adds value to this stack with features that make application deployment easier, more manageable and more scalable. End users get the benefits of using well-known, trusted open source along with the additional features that Gluecode provides.Question: What input, if any, do you receive from clients on their licensing preferences? Do you find you do a lot of education among clients on licensing issues?
Boynes: Gluecode has two categories of customers: end-user customers and ISV customers who are looking to bundle and redistribute the open source stack with their own applications. Licensing is not a big issue for end users; they want a product that works as advertised and that has the backing of a commercial vendor for support. However, ISVs that are bundling or embedding open source have to be very aware of the open source licensing and the impact on IP and distribution. In these areas, GPL can be problematic, whereas BSD licensing tends to be more favorable for ISVs and OEMs. Licensing is a complex issue, and one that is constantly evolving. We make it easier on our customers by sticking to one licensing model. All of the core open source projects that we use are Apache 2.0-licensed.Question: Is Gluecode's license GPL-compatible?
Boynes: Can you run Gluecode on GPL-based technology like Linux? The answer is yes. We don't use any GPL-licensed components in our product, but people are certainly free to run it on Linux or alongside MySQL, both of which are GPL.
GPL Sued For Software Price Fixing @ LBN
