Softpanorama (slightly skeptical) Open Source Software Educational Society

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

Softpanorama Copyleft Problems Bulletin, 2002

Linux Today - MySQL AB and Nusphere Corporation Announce Settlement

MySQL AB and Nusphere Corporation Announce Settlement
Nov 8, 2002, 17 :30 UTC (3 Talkback[s]) (3836 reads)

MySQL AB and NuSphere Corporation have announced a settlement of the dispute between the two companies regarding use of the MySQL trademarks, copyrights, and compliance with the GNU General Public License (GPL).

The settlement resolves all outstanding issues between the two companies including ownership and use of trademarks and domain names and assignment to MySQL AB of copyrights for all NuSphere contributions to the MySQL program, and MySQL AB has issued a letter to NuSphere Corporation verifying GPL compliance.

"We are happy to resolve this dispute," said Olivier Beutels, Sales Executive, Northern Europe, MySQL AB. "These past months of discussion with NuSphere regarding trademark rights and GPL issues have confirmed for us all that open source software can flourish free under the GPL license and commercially when the situation merits it."

"We are pleased to reach this amicable settlement and resolve the issues between the two companies," said Dmitri Dmitrienko, General Manager Europe, NuSphere Corporation. "We look forward to getting back to the normal run of business and plan to continue shipping the MySQL database in the NuSphere Technology Platform, and remain focused on our flagship product."

ESR Invited To Advise USPTO

"Hundreds of Thousands of Developers" my ass (Score:5) by MaineCoon (12585) on Monday June 26, @05:57AM (#975993) (http://avp.dhs.org/)

Personally, I believe this line to be pure bull - not only in the Mac community, but also in the Linux community. I know many people who started using Linux, and couldn't write, without help, a single, simple, syntax-error-free line of C code. Now that may sound very harsh against Linux users - and it is very well meant to be. All in all, the technical competence of most Linux users IS above average. But that doesn't mean that they all have the competence of commercial quality programmers, or even mediocre programmers. I doubt the majority of them could fix a simple buffer overflow bug given adequate debugging information that points the bug out directly. The claim that there are "40,000" contributors to "Linux" is very misleading. First off, Linux is more than the kernel. It is all the programs that it takes advantage of or requires to get the job done. Linux would be NOWHERE without programs like 'make', 'gcc', 'gdb', and all those similar tools. However, those tools WOULD exist without Linux. So, that number (which is pure estimate on the part of anyone claiming it as fact anyways) most likely includes the developers of all the programs that Linux takes advantage of... and in this case, that is like saying a printing company (Which can be run by a handful of people - a manager, a couple secretaries, a couple graphic artists, and a few printing press operators) employees "hundreds of people", by counting the foresting company, the people that operate the paper-making machines, and the people who produce the ink. IF, on the other hand, said number was restricted to the heart of Linux - for TRUE "Linux" is nothing more than the KERNEL - I wouldn't be surprised if, over the course of Linux's 8+ years of evolution, 4,000 (not 40,000) people have contributed something to the source code for some program for some platform or another - but even then I'm wondering how many of those contributions were very minor ones - such as a bug fix - and how many contributions overlapped. How many people provided moderate (more than a few dozen lines of code) contributions, and how many provided SIGNIFICANT contributions (on the lines of a few hundred or thousand lines). I'd guess more along the lines of 400 and 40, respectively. And how many Linux kernel contributors are well known by any kernel hacker? I think the number falls around 4 (to 8). In the end, the true core work of a project is done by just a few people (scaled to the size of the project, of course). While they may take advantage of existing libraries (such as a PNG or JPEG library, ZLIB compression, a communications architecture, or some such), that does not truly increase the size of the development team - that actually gives them less of an excuse to have large amounts of people. You can't claim the authors of these libraries on your dev team (but giving them credit for their work and it's use in the project is something else entirely different). And finally, what if the project is commercial? The problem these days is that Free Software (Free as in Freedom of Speech/Open Source) is equated these days with Free Software (Free as in Free "Beer"/No Cost). This is a very dangerous equation that is being made, and even promoted by so-called experts such as Richard M. Stallman. Eric S. Raymond has a clearer view, but it is still distorted by the belief that everything can and should be source-available. In many cases, especially Games, this option isn't available while the product is still commercially viable. Hence why Doom and Quake were not Open Sourced until years after they were off the shelves and replaced by better products (in the cases of Doom and Quake, 2 generations of products later). - Chris Jacobson (MaineCoon)

[PDF]Virtual Organization Design-Lessons From the Open Source Movement
File Format: PDF/Adobe Acrobat - View as HTML

[PDF]Open Source Software Development and the Public Sphere: ...
File Format: PDF/Adobe Acrobat - View as HTML

Open Source Software Development Paper

2.b.i. The “Comedy of the Commons” (Raymond 2001, 154)

            Garret Hardin’s concept of the tragedy of the commons is fundamental to most economic thinking.  The idea that a free resource lacks sustainability has been proven throughout history with the example of the English commons, clean air, and fish in the open seas.  Things are different today when we are dealing with the ephemeral.  Unlike grass, air, and fish, information (in this case written code) has no inherent dissipation of value the more people that use it.  Put simply, while fishing the seas clean deprives everyone else of fish, having a copy of someone’s software does not leave her any worse off in the same sense.  In fact, in the case of Open Source, it often leaves individuals better off. 

            There are actual concrete costs in the development in software.  People generally do not work without some form of compensation and firms that employ programmers expect to get benefits from the code that their developers create.  “In a complex setting, the self-developer is hardly distinguishable from the commercial software firm—the agent’s own consumption value is now a very small part of the overall calculation.  For this reason, I do not treat self-development separately” (Bessen 2001, 20).  For all intensive purposes, in terms of the economic analysis at this point, firms and individual developers are one and the same.  In this case, the answer to how individuals and firms can benefit from letting go of their intellectual property lies in a rethinking of how the software industry works. 

            “Part of the Answer lies in the fact that people don’t merely need solutions, they need solutions on time” (Raymond 2001, 125; emphasis author’s).  What Raymond means is that people cannot necessarily wait for a vendor to provide a solution to whatever problem they may be having.  Finding a bug in a Microsoft product, such as IIS (their web serving software), is a fundamentally different experience than finding one in a comparable open source product like Apache would be.  The difference lies in that finding a bug in IIS, would require Microsoft to fix it.  This could take an indeterminable amount of time.  However, in an open source product, it can be fixed now.  It is not just important that the solution be had, but if the problem is important enough, the problem can be solved immediately.   “If the payoff from fixing a bug or adding a feature is sufficient to any potential contributor, that person will dive in and do it (at which point the fact that everyone else is a free rider is irrelevant” (ibid).  

            This explains why a developer would work on an open source project, but does not explain why these developers give their code away freely.  Why there may be little to no costs involved in giving the code away, there does not at first appear to be an impetus to do such a thing.  Developers can actually profit from giving away code freely. 

Suppose I write a fix for an irritating bug, and suppose many people realize the fix has money value; how do I collect from all those people? … It may be more to the point that this value is not merely hard to capture, in the general case it’s hard to even assign.  …  It would take a superbeing, both able to evaluate the functional worth of patches and trusted to set prices accordingly, to lubricate trade. …  Unfortunately, there’s a serious superbeing shortage, so patch author J. Random Hacker is left with two choices: sit on the code, or throw it into the pool for free.  (Raymond 2001, 126)

            The idea that firms give away intellectual property that they could not profit from is nothing new.  It has existed for many years and has been known to profit in the long term.  Harhoff, Henkel, and von Hippel give us “four incentives which could induce user-innovators to freely reveal their innovations:” (Harhoff, et. al. 2000, 1)

a) Inducing manufacturer improvements

By freely revealing an innovative product or process, a user makes it possible for manufacturers to adopt that innovation and improve upon it.  …

b) Setting a standard advantageous to the user innovator

By freely revealing an innovation, a user makes it possible for other users to adopt it as their solution as well.  This adoption as a “standard” can be beneficial to the user-innovator if his innovation contains imbedded features particularly beneficial to that user … Not that being first to reveal a given type of innovation increases a user’s chances of having his innovation widely adopted, other things being equal.

c) Reciprocity and reputation effects

By revealing an innovation, the innovator may create or discharge “generalized reciprocity” obligations … He may also reap a gain in reputation

d) Low rivalry conditions

When competition between users is low … the revealing user does not suffer as a consequence of the advantages to the other users.  This is not so much of an incentive as absence of a disincentive.  (Harhoff, et. al. 2000, 2)

            These are all important issues in the development in open source.  I will flesh out only reasons ‘a’ and ‘b’ here for the sake of brevity, but also I believe that ‘d’ is similar to that which I have discussed above and ‘c’ will be discussed later in terms of business theory. 

            Inducing of manufacturer improvements is hard to translate directly into a paradigm that often has no manufacturer in the traditional sense.  There are still many parallels that can be drawn.  Perhaps the easiest one would be with the development of the Linux kernel.  The very idea that it is constantly improving would lead one to improve it further if she found a bug.  Fixing one bug could cause others to find further bugs and a user who knows that further improvements are coming along would be more likely to contribute to such a project.  Another example could be of Fetchmail, an open source mail client for Unix machines.  Raymond describes how he started writing patches for and eventually took over an existing project and each time more patches came in and Fetchmail became a powerful and popular piece of software thanks in large part to the continuing innovations (Raymond 2001, 19-63).  This is something of a snowball effect.  In essence each time a contributor adds a new feature or fixes an existing problem; it causes more features and fixes to come down the pike. 

            Setting a standard advantageous to the user is also an important concept.  Phenomena like the network effect, which derive from having a single standard, contribute greatly to the private support of Linux.  IBM benefits from having an open standard like Linux or Apache.  Accepting and promoting these standards allows IBM to focus more on improving its hardware line while setting a software paradigm that is already gaining acceptance.  This gives a firm, such as IBM, a jump start on the competition in these fields as it innovates and standardizes. 

            There is another advantage in setting a standard.  In fixing a bug, for instance, there are inherent costs in not distributing it.  In open source, one of the fundamental philosophies is that of “release early, release often” (Raymond 2001, 28).  This leads to new versions of a user’s software to come out on a frequent basis.  Each time that the new software is released, the user would have to re-integrate the code with the new release.  This is a costly practice.  Each time, the user would have to go back through the code and is likely going to have to edit the patch in order to make sure that the program works and that the previous problems are fixed all over again each time (Ibid, 126).  This would be the equivalent of replacing a washer somewhere in the middle of all the pipe works in a building each time the water filter is replaced.  It is unnecessary, it is time consuming, and it is often difficult to do. 

            Even non-contributing users can have an effect as well.  There is the concept of evangelization and users can contribute in other ways.  Users who do not contribute to the development of open source projects contribute in their simple use.  One could argue that by not contributing money to closed source software projects, i.e. not purchasing products like Microsoft Windows, you are in essence giving the free alternatives a competitive advantage.  Users of open source are also its biggest fans.  A user of open source is likely to “spread the good word” of open source and convince others to join up.  Many of these other users may contribute donations to organizations like the FSF or could hire firms such as IBM or Red Hat to assist in using open source software at an individual or enterprise level.  While these may not be a direct benefit of a free-riding user, these externalities can outweigh the minimal costs of distributing software. 

**** Why you should use a BSD-style license  - a very interesting and unorthodox paper

This document makes a case for using a BSD-style license for software and data resulting from open research; specifically it recommends using a BSD-style license in place of the GPL. It can also be read as a BSD versus GPL Open Source License introduction and summary. I am not an expert in this area, but about the fifth time I found myself writing to explaining ramifications of current open source I decided to attempt to consolidate my efforts. My experience in ongoing arguments in the Federal civil service in the 1970's over the merits of in-house, contract, off-the-shelf, public domain, and government-developed ``open source'' software may contribute to a dreary aversion to this subject.

*** OSNews.com - Exploring the Future of Computing -- a couple of interesting comments in a usual garbage...

	Amen.
	By Solar (IP: 212.149.48.---) - Posted on 2002-05-14 07:48:57
> Most of the important innovations happened 20 years ago. Amen that, brother. Because since then, the "innovative" people have flocked around a GPLed Unix descendant, claiming it to be the end-all, be-all to all computing woes. (Yes, I know, I'm exagerating, but so is the other camp...) GPL (and to a lesser extend BSD) have their weaknesses, but instead of admitting it and trying to do something to counter the effects (inconsistent and uncomfortable user interfaces to name only one), many actually consider it a "feature"... Just to avoid (too much) flaming, the other camp doesn't fare any better: trying to squeeze the utmost in profit out of the customer, while stiff-arming the "competition" and turning a blind eye towards the s***load of legacy that has build up in the process... But when people step up trying to offer a *really* innovative, alternative approach, especially the Linux community cries rape and murder, why oh why don't you join the Linux hype... as many an "alternative" OS visionaire can testify. I could not believe the sincerity with which people approached me when I kicked lose my OS project, telling me "if your OS isn't build on Unix, it will suck - Unix is so brilliant on everything"... so much for innovation...

 

	Sorry...
	By Solar (IP: 212.149.48.---) - Posted on 2002-05-14 07:55:50
Sorry I went a little bit OT in that post... but fact is, we will have a hard time in *our* project *because* of the popularity of the GPL. If we want to get anywhere anytime soon, we will have to "canibalize" other Open Source projects. Due to the GPL, we must take utmost care so that we can export an interface that is *not* GPL, but LGPL / BSD - because, like it or not, to be a *real* success you need the companies' support, and to attract them "GPL" is the wrongest thing you could say. I think the GPL has done much to Open Source. But I also think that the GPL is a bad choice if you are working on a bigger scope than implementing yet another MP3 player. Even the LGPL has some tricky parts in it...

 

	.
	By DavidGentle (IP: 213.1.61.---) - Posted on 2002-05-14 20:53:19
Does your OS ues object orientation networking and gui's? what about threads? Those are the sort of innovations I'm talking about. The only thing I can think of that isn't 20 years old is aspect oriented progrsming and the only implementation of that I know about is an (open sourced) version of java. Everything just seems to take the same few ideas and recombine them. Which is okay. But not innovation.

 

	my my
	By JackDaddy (IP: ---.rdu.bellsouth.net) - Posted on 2002-05-15 05:13:19
... ... ... He must have covered 5000 points in the 3 articles. For what its worth, it all comes down to whether or not you or your company are going to use code written by someone else. If you are not going to use someone elses code in one of your projects then it doesn't matter whether you like BSD or GPL licenses. Same goes if you just use the software. If on the other hand you or your company plan on using someone elses code in a commercial product then you have to make some choices. For all programmers that feel they could get rich if only Linux hadn't shown up, its time to take a good hard look in the mirror. You will have to stick to stealing BSD code for your own private gain or hire programmers and make money the hard way. EARN IT. Please do not let Microsoft turn this into a battle between open source licenses. What does the open source community care what microsoft thinks about its licenses? To hell with 'em. If Microsoft feels that $4,000,000,000 is not enough for R&D then maybe they should shake loose some of that wad of cash they have stored up but please do not whine about the difficulties of using GPL code in commercial products. If you feel there are no innovations comming out of GPL code then you will not be inclined to use GPL code in a commercial product. Problem solved. If you feel that software developed using federal funding (our tax dollars) should later be sold back to the public for a profit, then maybe you would not mind sending major commercial software companies a little stipend every year to save time instead of filling out tax forms. Maybe the IRS could add a little box on our tax forms right under 'president fund' or 'plant a tree fund'. say for example the 'buy Bill Gates a new wing on his house fund' or 'Send Larry Ellison on a round the world cruise fund' The beauty of open source is that millions of people around the planet have the source code for thousands of projects in their hands. Sounds a little pie in the sky but due to this fact these projects will never die due to a bad business plan or a down economy or through obsolescence. The source code.is freely available. Even if 90% percent of the public can't do anything with the source, the other 10% will be able to carry on. Commercial software companies on the other hand seem to think that THEIR source code is worth millions ONLY if it is kept secret. As if all of its value would vanish like a puff of smoke if it was taken out of its vault and exposed to sunlight. rotfl ---- ps Everybody chip in a dollar to save poor old SOLARs liittle OS project. He just can't figure out whose code he is going to have to steal to make his project work. Oh and don't worry about the OS market. Its wide open.

 

Linux Today - O'Reilly Vanishing Features of the 2.6 Kernel is this IBM's "bait and switch" style political move or resonable technical consideration ?

Article:		Vanishing Features of the 2.6 Kernel
Subject:		Congratulations -- Linux is 6 years late
Date:		2002-12-21 00:16:20
From:		anonymous
Wow, Linux finally has kernel-mode HTTP. NT/IIS has had this for four years, and it is available to any developer (fully documented). It's not even restricted to HTTP -- you can move FTP data in k-mode, etc. Also, NT has had zero-copy TCP/IP and UDP/IP from NT 4.0 on -- welcome to 1996, guys. NT also has an extremely open, well-documented, extensible driver interface. No GPL restrictions. Why is Linux shooting itself in the foot? Why insult & restrict the people who are SUPPORTING your platform -- device driver developers! You're just killing one of the few advantages that Linux has (or, soon, "had").

Article:		Vanishing Features of the 2.6 Kernel
Subject:		Arrogance in action
Date:		2002-12-17 07:53:57
From:		anonymous
Remember when the FUD-o-matics at M$ said that the GPL is a "viral license"? Well, this is exactly the thing they were talking about. What are you all thinking? Sure, I can see that anything provided with the stock kernel should be open sourced (GPL, BSD, whatever). Why do you care about the rest? Leave my freedom be. As a driver developer I am in the situation of trying to justify the time I spend getting my company's hardware to work under Linux. The simple choice is closed source driver or no driver. The Linux kernel developers are *consistently* saying they would prefer nothing. Keep it up and that's what you will get...nothing. No driver development, no apps being ported, no support, and no one in the business world will really care. What you people are doing is just like what M$ did in the 80's and 90's. Give people a good, flexible, powerful alternative to the current offerings. Then once you have consolidated your power force everyone to do things your way. That doesn't sound "free" to me...hell, it doesn't even sound ethical.

Article:		Vanishing Features of the 2.6 Kernel
Subject:		Push the vendor, kill the independent developer
Date:		2002-12-16 23:47:49
From:		anonymous
Vendors may respond to this push towards GPL modules, but independent developers who put their own money and time into providing a driver for a certain piece of hardware for Linux who comply with the NDA set by the hardware vendor can only stop their effort and count their losses if this move continues. I run a philips webcam and this driver makes the kernel 'tainted'. Reading the comment of the author about this move makes it clear that he cannot make a GPL module (see http://www.smcc.demon.nl/webcam/tainting.html) because of the NDA. So 'more GPL kernel' means 'end of driver'.

Article:		Vanishing Features of the 2.6 Kernel
Subject:		syscall table text is bollocks
Date:		2002-12-17 03:00:22
From:		anonymous
the export was removed because it was actually impossible to use it correct and racefree. Especially the combination of 2 modules overriding the same syscall is rather explosive (the example given is a clear way to do it wrong: the syscall table is restored to what it was before, however that might be a module that's no longer loader). Binary only modules were not an argument to remove it; rather nothing using it correctly (and the impossibility thereof) was. THAT is a technical consideration, not a political.

Article:		Vanishing Features of the 2.6 Kernel
Subject:		Binary-only modules
Date:		2002-12-17 03:34:49
From:		anonymous
From what I understand, nvidia would probably be amenable to make a completely GPL'ed module, but they *can't*. There's parts of it that are covered by technologies and patents they don't own, and don't have permission to release for free. They're doing the best they can, and a pretty good job of it. Deliberately cutting them off because they're not perfectly conforming to the One True Way Which You Shall Follow Or Be Assimilated For Resistance Is Futile is a very Microsoft way of doing business. What was that saying again Nietsche had about fighting monsters?

CLU - Subject: Binary modules ( Dec 19, 2002, 09:59:27 )

It has always been the vendors supplying device drivers for the operating system. Even for Windows NT and the rest, the number one problem for instability is drivers. MS managed to partially solve the problem by certification which make sure the drivers are more or less "tested". I have seen several vendors supplied drivers crashed NT immediately upon loading. And we are talking about a micro-kernel based OS. The problem with Linux drivers is not all that different, a buggy driver can surely crash the whole system - while it is binary-only, kernel developers cannot see what was going on, the only support is left up to the vendors. The real concern for the developers is the quality control. I am not saying the vendors should open up all the source code of the driver, however, what is consequece of losing your so-called "trade secrets"? The hardware is already proprietary, take for example graphics card that use a "particular" chipset. There are *plenty* makes and models that use the reference board and the same chipset by many vendors. One driver for this chipset pretty much drives all makes and model without much problem. If you are worrying about competitors, you already have them without exposing your "trade secrets". By releasing source code to the driver, what possible "trade secrets" will you be exposing? Unless...you have hidden APIs that give you an edge that only your secret driver knows about. Then, why the heck bother making a reference board and let 20 or so vendors to copy it and sell it? Is this some kind of ploy to "enlarge" your market and eliminate competitions? Now, for other devices like webcam, cd/dvd writers etc., why do the words "open source" immediately triggered a reaction that "it will expose or IP/trade secrets"? For crying out loud, many of these cdrw drives use a technology that is similar to Burn-proof(TM) to avoid their royalty. Where are their drivers now (while Burn-proof is supported in Linux)? The bottom line is money, whoever sell the most, make the most. The way I see it: opening up the driver source encourage people to buy, the market will see the device as "more compatible with everything else", just like the Realtek ethernet chip on every mainboard nowadays. At the moment I am in the market for 50 or so machines, whenever I see wierd chipset on the mainboard, or devices that use a rare chipset, I just go forward and find another one that use a well known chipset, preferably with a Linux driver, even some of them are going to be Windows box. Things get "well-known" because their behaviour is more predictable.

O'Reilly Network Binary-only drivers use wrappers these days

The kernel source tree is GPL, so any modifications that are made to it and released must also have their source released under the GPL.

The GCC compiler is also GPL. Modifications made to the compiler itself must be released with source, as with the Linux kernel. But, a program compiled with the GCC compiler can be released under any license. There is a legal barrier between the gcc compiler and its output. This is well-understood. This legal barrier also exists between the compiled program and any preexisting C libraries on the system, even though that program may make use of those libraries at runtime.

Most third-party kernel modules are compiled outside of the kernel source tree, and are output by the GCC compiler just like other C programs. The only link to the kernel comes at runtime, similar to C libraries. Therefore, it is accepted that a kernel module has this legal barrier, and can be released under any licence.

However, what happens when the kernel module uses API's that were intended to be part of the internal workings of the kernel, and were only exported because it was technically necessary? The system call table would be an example. It becomes a gray area in this case.

The GPL's legal barrier only applies to interfaces intentionally defined by the architecture of the software, such as an application's plugin mechanism, or a compiler's runtime library and linker. When a kernel module takes advantage of an unintended API such as the system call table, does the legal barrier still apply? This is a difficult question to answer.

For this reason, many binary-only drivers use GPL wrappers these days. The GPL wrapper is a kernel module that is open source, interfacing with the kernel without requiring for the legal barrier. The binary-only driver communicates solely by using the API presented by this wrapper, and not the kernel. The GPL only covers distribution of software, not its original authorship (the original author is always free to redistribute their software under a different licence). As both wrapper and binary-only driver are written and copyrighted by the same author, there is no licence conflict.

This seems to work well, and also has the advantage of allowing the wrapper module to be upgraded along with the kernel. When the kernel API changes, the wrapper module can be kept in sync, without needing to change the binary-only driver. Linux is known for speed and robustness because it is free to throw out old obsolete functionality that is no longer needed, something that would not be possible if a binary-only driver depended on that functionality.

I support the use of open source wrappers around binary-only drivers, and find it to be a reasonable compromise. Drivers that use this technique will not be hurt by API evolution such as this in the new 2.6 kernel.

O'Reilly Network Some comments from the Author

Vanishing Features of the 2.6 Kernel
Subject:	Some comments from the Author:
Date:	2002-12-17 08:17:57
From:	coop
I think (some) people are missing some points about binary modules, the GPL (and other open source licenses, I didn't mean to restrict things to GPL), and how Linux "operates." 1) Binary modules (in fact any modules) are restricted only to use a certain API. Normally device drivers do not have to monkey with basic kernel internals -- there is no reason a mouse driver has to manipulate scheduling or memory management for instance. You can't do this in closed source OS's either, such as Microsoft variants. If a device driver requires certain changes in the core kernel, then the hardware manufacturers should argue for those changes in the open. 2) A 'tainted' kernel is just as functional as an 'untainted' one. The only thing you don't get is free tech support from kernel developers. If you don't want to pay for it (by opening your license) why should you get help for free? 3) Anybody can patch the kernel to do anything they want (and even violate the GPL) as long as they don't distribute it (for money or for free). If it is for your own use, go ahead and enjoy. There are no Linux brain police going to stomp on you. 4) The technical problems of exporting system calls are not trivial (race conditions especially) but they are solvable. However, the will to solve them is not there because of licensing problems. 5) Linux is not run like Sun, Microsoft, or any other big company. And it never will be. People keep expecting "linux" to respond to customer complaints as if it had a responsibility to shareholders. It won't happen. 6) Those big companies often do make arbitrary changes to either content or licensing, ones that cost a lot of money to customers. These customers have few options often except to pay for costly 'upgrades' and changes. The changes in Linux are not arbitrary and all the arguments are out in the open. coop

The Register

Linux Today - Foreign Affairs Who Owns Ideas The War Over Global Intellectual Property

But in recent years public-health advocates, most notably the physicians group Medicins Sans Frontieres, have argued that stringent intellectual property protections make lifesaving medicine expensive or unavailable in the poorest countries. The inability of aids patients in Africa to obtain medications has put the vast international pharmaceutical industry on the defensive.

"Mickey Mouse was funny. This failure is heart wrenching. But it reveals a fundamental misunderstanding on the part of those who oppose intellectual property rights, even as they appear to be the more human and compassionate figures in the debate. Preventing the distribution of copycat drugs because of adherence to patent laws invariably means that some desperately ill patients will not have access to medicines they need. Yet the act of ignoring patents in the name of helping sick people curbs the incentive to develop new, lifesaving drugs in the future. The critics of intellectual property protection have forgotten Abraham Lincoln's statement that the patent system 'added the fuel of interest to the fire of genius.'

"Unfortunately, the public health field is not the only one in which the argument against the ownership of ideas is gaining ground. Today, governments around the globe are being asked to use only computer software that is available under an open-source license. The General Public License (GPL) is the most common license and is used for the most popular open-source software package, the Linux computer operating system. Although many Linux and open-source software users are content to co-exist with the for-profit world, the GPL can quickly suffocate intellectual property rights. The GPL allows anyone to distribute copies of open-source software for free or use the source code to create a derivative software program. But if anyone uses some of the Linux code in creating a derivative work or complementary program, that software, too, must be distributed for free and its source code made available to all. Adherents of the GPL refer to the system as 'copyleft,' fully understanding that it forces any proprietary software maker who wants to use code licensed under the GPL to surrender its intellectual property to the commons..."

Copyright Contradictions in Scholarly Publishing

Copyright Contradictions in Scholarly Publishing by John Willinsky
This paper examines contradictions in how copyright works with the publishing of scholarly journals. These contradictions have to do with the protection of the authors' interest and have become apparent with the rise of open access publishing as an alternative to the traditional commercial model of selling journal subscriptions. Authors may well be better served, as may the public which supports research, by open access journals because of its wider readership and early indications of greater scholarly impact. This paper reviews the specifics of publishers' contracts with editors and authors, as well as the larger spirit of copyright law in seeking to help scholars to better understand the consequences the choices they make between commercial and open access publishing models for the future of academic knowledge.

Linux Today - LinuxDevices.com Two Suggested Revisions of the GPL

Linux, the GPL, and a New Model for Software Innovation

"Increasingly, software is going 'open source,' with increasingly good results. Linux, the most visible of open-source software, is rapidly gaining ground in both embedded and server software markets, and even begins to make inroads on the desktop.

"This is particularly interesting given the peculiar licensing structure that governs it: the GNU General Public License (GPL). This license 'promises' cannibalization of intellectual property, but does not quite deliver on this promise, and so has attracted the affection of mammoth electronics companies (normally IP-protective) who see Linux as their key to the future. In turn, this most 'anti-IP' of licenses is arguably doing more to foster innovation than patents or copyrights ever have.

"In this whitepaper, Matt Asay (former Linux naysayer-turned-disciple) analyzes the GPL, picking apart what it means (and does not mean) for users, and whether it is enforceable. Asay also details how its terms inhibit and foster innovation, and why we should care. In this next generation of software, those who understand 'copyleft' licenses like the GPL will have the upper-hand, and will be best positioned to take on closed-source shops like Microsoft..."

Complete Story

Proposal Suggests Revision of GNU General Public License

"Matthew R. Harris, CEO of Embedix, Inc. (Lineo), has written a suggested revision of the GNU General Public License. Note that it is not an official version of the GNU General Public License, and is published at this time for informational purposes only. Harris, a stong proponent of the GPL, believes that in its current form it is difficult to understand and contains a number of ambiguities..."

Complete Story

Download xpdf (For both stories)

Related Stories:
NewsForge: Draft Version of RealNetworks' New Public Source License(Aug 02, 2002)
The Register: MS to Eradicate GPL, Hence Linux(Jun 26, 2002)
Distributed Computing Foundry: The Affero GPL: Closing the Distribution Loophole(May 22, 2002)
The Register: Gates: GPL Will Eat Your Economy, But BSD's Cool(Apr 23, 2002)
LinuxDevices: RTAI goes (Partly) GPL(Mar 26, 2002)
FSF Announces Support of the Affero GPL, First Copyleft License for Web(Mar 19, 2002)
Builder.com: The General Public License: It's not just about open source(Mar 11, 2002)

wine-license mailing list By Thread

• Webpage discussing GPL x BSD licensing... Roland (Tue May 14 2002 - 18:02:49 CDT)
  • Re: Webpage discussing GPL x BSD licensing... Guido Draheim (Wed May 15 2002 - 03:35:30 CDT)
    • Re: Webpage discussing GPL x BSD licensing... Roland (Wed May 15 2002 - 14:36:15 CDT)

• Re- WineX and the AFPL

• Re- wine-license digest, Vol 1 #100 - 7 msgs

• Dangerous back door in the LGPL

Linux Today - Australian IT Open Source Legal Warning

wine-license mailing list Re GPL vs. sweatshops (was Re Bias)

From: Deven T. Corzine (deven@ties.org)
Date: Mon Jul 15 2002 - 09:26:44 CDT

Next message: Deven T. Corzine: "Re: Economics and the GPL"

• Previous message: Deven T. Corzine: "Re: Economics and the GPL"
• Next in thread: Roland: "Re: GPL vs. sweatshops (was Re: Bias)"
• Reply: Roland: "Re: GPL vs. sweatshops (was Re: Bias)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

---

On Tue, 18 Jun 2002, Tony Lambregts wrote:

> GPL is accused of being "viral" because the designers of it did not want 
> GPL'd code used in proprietory products period. This aspect of the GPL 
> was designed as a posion pill (as a deterent) and it does the job it was 
> meant to do.  This license has the most protection for the community of 
> volunteers.

It's not the most protection for the community of volunteers who make their 
code freely available -- it's the most protection for the GPL community, 
which isn't the same thing.

The GPL's approach is basically "play the game by my rules or I'm going to 
take my ball and go home!"  This may be legitimate, but ultimatums like 
this are often viewed as immature and antisocial.  If such behavior is 
disdained on the playground, why should it be revered among professionals?

The GPL does a very good job of keeping GPL code from being incorporated 
into closed proprietary products.  It also limits the ability to integrate 
into other open projects, such as MPL-licensed ones.  This is undesirable
collateral damage, and detracts from the nominal goal of the GPL: the free 
and open sharing of code.  However, there's a good argument to be made that 
the nominal goal is secondary, and that the primary goal is actually to 
utterly destroy ALL closed proprietary software...

> X11/BSD has the least restrictions as far as business go but has the 
> least amount of protection for ensureing the community is compensated.

This is true -- it's clearly easy for a closed proprietary vendor to take 
unfair advantage of BSD/X11 code.  On the other hand, this vulnerability is 
exactly the reason why such vendors will be attracted to using the code, 
and if they depend on the sale value of their software, they certainly will 
never use GPL code.  At least if they use the BSD/X11 code, they might give 
back some non-strategic code, though surely not strategic code.  Does the 
competition of a closed product derived from open code outweigh the value 
of these possible non-strategic contributions?  It probably depends on the 
particular situation.

> Mozilla uses MPL and while there was some inital complaints about it not 
> being GPL it seems that things are working out ok for both netscape and 
> the open source community around Mozilla.

The major complaints about the MPL were from GPL zealots who believe that 
everything must be GPL to be "free", and Stallman, who demanded that the 
MPL change to become GPL-compatible -- despite the obvious solution that 
the GPL should be changed to be compatible with licenses (like the MPL) 
which are in the same spirit as the GPL...  (Stallman refuses because it 
would be too difficult to define and he's afraid of opening a loophole.)

> Each of these company's have found a business reason for supporting 
> these projects and the open source communities seem to be satisfied with 
> them.  These are win-win situations because both sides feel they are 
> getting what they want.  Even in the case of Apache it worked because 
> both sides are ok with the situation.

Keep in mind that Mozilla and OpenOffice were commercial products (Netscape 
and StarOffice) that were released freely as a calculated business risk to 
take down Microsoft.  AOL/Netscape and Sun aren't getting a direct return 
proportional to their costs involved, but instead they're betting that if 
they can weaken Microsoft's hold on the market, it will be worth the huge 
loss they've incurred by releasing that commercial code.

Apache is one of the few open projects contributed to by companies for its 
own sake -- and that's because it grew as a grassroots community effort 
among webmasters before management become cognizant of what was happening.  
By the time management realized what value was being added, it was already 
becoming clear that proprietizing their Apache version would be likely to 
cost them a lot because of the very active open project -- so unless their 
additions are extremely valuable, it makes business sense to keep the new 
code as free as the old, so it remains integrated.  (The only case I can 
think of, offhand, where it was compelling to make a proprietary fork was 
for SSL-enabled Apache, which is no longer a strategic advantage...)

> As far as I am concerned Wine could have chosen MPL/SISSL/LGLP/WineOrg 
> and I would have been OK with the result.  

I think any license choice is valid, but it's best to understand all the 
ramifications of the choice, as much as possible...

Deven

Re: Economics and the GPL

From: Deven T. Corzine (deven@ties.org)
Date: Mon Jul 15 2002 - 09:39:55 CDT

Next message: Roland: "Re: GPL vs. sweatshops (was Re: Bias)"

• Previous message: Deven T. Corzine: "Re: GPL vs. sweatshops (was Re: Bias)"
• Maybe in reply to: Deven T. Corzine: "Re: Economics and the GPL"
• Next in thread: Deven T. Corzine: "Re: Economics and the GPL"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

---

On Wed, 19 Jun 2002, Roland wrote:

> At 05:30 PM 6/19/02 -0400, Deven T. Corzine wrote:
> >On Wed, 19 Jun 2002, Roland wrote:
> >
> > > At 02:45 PM 6/19/02 -0400, Deven T. Corzine wrote:
> > > > > That's one way of looking at it.  Another is that it is using the 
> > > > > tools of oppression against the oppressor.
> > > >
> > > >But are you on a higher moral ground if you act like those you despise?
> > >
> > > He is not acting like those who he despises, he is merely using their
> > > tools. Sounds fair to me.
> >
> >He's not?  Hmm...  Software hoarding?  Check.  Embrace and extend?  Check.
> 
> Unlike proprietary software, GPLed software is free for everyone to use for 
> no charge. Plus you have the source to adapt/modify/improve.

Yes, it's free to use unmodified.  It's not free for everyone to adapt, 
modify or imprive the code -- only for the GPL community to do so.  (Well, 
technically there's a niche case of closed modifications which are used but 
never distributed, but that's a very special and limited case.)

Just because anyone can participate in the GPL community doesn't mean that 
the code is free to everyone.  If Microsoft can't incorporate GPL code into 
Windows, how can you say it's free to everyone?  Microsoft can distribute 
GPL code, sure, but they're not free to use it any way they choose.  Please 
don't claim the GPL is more free than it really is.  BSD/X11 licenses are 
much more free, because anyone can use them with very little limitation.

Now, I'm not saying that the GPL should allow Microsoft to use GPL code in 
Windows -- that's exactly what it's trying to prevent.  And whether or not 
it's the best means to accomplish the goal (and it's debatable), there's no 
reason why the GPL shouldn't be allowed to take this approach.  However, 
GPL advocates should be honest and admit that it's not really free for 
everyone to use, but only for the GPL community to use...

> Usually open source software will use open/official standards(for 
> file-formats etc...) so it enables everyone to participate...

This is a good thing, of course.  This happens because it's better to use 
an existing standard than to invent a proprietary format.  Since most open 
source programmers aren't looking to lock out others, there's very little 
incentive to invent proprietary formats.  (Unless it's for simplicity, in 
which case the format will probably still be documented and open.)

> So I see a lot of differences between proprietary and GPL.

Then you've got blinders on.  The GPL is just as proprietary as Microsoft.  
It's open proprietary software, but nonetheless proprietary.  Certainly, 
there is a big difference from closed proprietary software, but "closed" is 
the word to be demonized, if any -- not "proprietary".  Rail against closed 
software all you like, but it's hypocritical to rant about "proprietary" 
software without distinguishing open from closed while supporting the GPL.

> >I thought Microsoft and others were supposedly bad *because* they did these
> >things, not only because they don't distribute source?
> >
> >I guess the question is, do the ends justify the means?
> 
> Hmm, I think this question is really a bit off topic now :) (Due to its 
> generality)

Perhaps.  What else is new? :-)

Deven

LawMeme Legal Bricolage for a Technological Age - Open Season on Open Source in Australia Posted by Kim Weatherall on Tuesday, October 29 @ 19:31:32 EST

It seems that, periodically, someone in Australia raises the question: is the GPL enforceable?

One of Oz's newspapers, The Australian, have a new story, where they quote a lawyer from one of Australia's bigger firms, Minter Ellison, suggesting that there are doubts about GPL enforceability, and consequences of non-enforceability (Minters' (very) slightly more extended analysis is also online: here. There's some trickly little issues in here - and while some of the claims aired in The Australian article are just silly, there may be something to it, though I still doubt the world will fall apart...

First things first: - the Australian's article is about as general as it comes. - Minters' analysis is also aimed at (generating new) clients - so is also very general in its terms.

The other interesting thing about this story is that, in many cases, the issues it raises are common to all software - not just open source. Blaming it all on the GPL and open source is just plain wrong.

The summary of my views is this: legal issues for people involved in the open source community, building their own software for their own purposes and putting it out there to contribute to the public domain will continue to be - well, not that huge. The reason we're getting these concerns now is that businesses are in on the act. Either they want to make money through open source (distributing it, with warranties or without); or they want to use it - to save money. For these people, there are issues. Because they generally need more certainty - in reliability (who'd want to be in charge of a bank's computer system - esp if it went haywire?), and in having someone to blame if it does all go wrong (who'd want to be their supplier, if you couldn't limit liability). So, for these people, there certainly are legal issues. But we knew that, right?

So what of the claims?

1. "From a copyright point of view, developers are most at risk because they lose the ability to assert ownership."

Not correct. The statement is carefully worded but misleading, because it suggests that the writers of the software lose their copyright (indeed, that is how readers seem to be interpreting it - look at the 'Your Say' comments page on the article). Which, of course, they do not. Note the word "assert" though - I think the lawyer (committing the usual sin of "lawyer-speak") means that you can't "assert" copyright rights like the right to make copies, to make adaptations etc etc. Even then it's still misleading, because the GPL doesn't ever stop you distributing your own independent work as a separate work.

2. "The lack of a liability regime also meant the distributor was not liable for defects in the product, which may cause data loss or systems to crash"

Hardly news, and misleadingly suggests that this is not true of other software. 99.99999% of all software end user licenses have disclaimers. Further, the GPL specifically allows people to offer warranties, including offering warranties for a fee. Would be an issue for businesses wanting to install all open source, though.

3. "This could be a problem with employees, who could, for example, be using a piece of open-source software that they download from somewhere. Not understanding the implications of what they are doing, they could incorporate it into a program for their employer, which may then be distributed for a price and they could be in breach of the GPL"

Any employer who does not warn their employees against taking code from elsewhere and then incorporating it into software that the employer sells is laying themselves open not just to breaches of the GPL. It also means that if the employee uses material from proprietary software they'll be in trouble for copyright infringement.

4. Legal uncertainties surrounding open-source software were complicated in Australia because of the Trade Practices Act and state Fair Trading legislation"

Ah, here is where it gets all vague and wishy-washy. Unfortunately, it seems that they don't want to tell us just how things get complicated here.

The Trade Practices Act is the legislation in Australia that seeks to protect consumers (Part V of the Act). It contains things like warranties of merchantability/fitness for purpose that cannot be excluded by contract. These provisions, and the warranties they create, apply to all goods and services. They are not specific to software. There is caselaw in Australia on whether software is a "good" or a "service" but the summary is - it's not 100% clear. The basic warranty is that a good is of "merchantable quality" (s71). This basically means - fit for the purpose for which goods of that kind are commonly bought as is reasonable to expect having regard to any description applied to them, the price, and other relevant circumstances. With services, the warranty is that they are "reasonable fit for the prupose for which they are supplied" (s74).

Now, there are questions about how much the legislation applies to things that are given away, like open source software. I also think a court would hesitate to find that any particular "purpose" had been warranted in the case of software which is there for the taking and modification. The court would likely take into account the "description" of open source software, and the understanding that people have that it is a "work in progress". It is probably one area where courts are going to say - you act at your own risk.

Of course, if a party wants to provide open source software on a large scale in business, their customers are going to want some more certainty than that, possibly. But if they want to back it up with a warranty, that's allowed under the GPL.

5. "There is generally no warranty that the software does not infringe any third parties' intellectual property rights. This could expose the end user of the software to liability for intellectual property infringement"

This is a harder issue to dismiss. If programmer X puts some proprietary software into their work and distributes it under the GPL, then subsequent users might be liable for the infringement as well. But a couple of qualifications are worth noting. First, you have to find the infringer. Good luck there. Second, there would have to be a reproduction of a substantial part of the proprietary software in the distributed program. Substantial part, in Australia, is assessed according to the originality of the work as well as the quantity taken. So the bit incorporated would have to be significant. Third, Australian law also offers a defence of innocent infringement (s115(3)) where "defendant was not aware, and had no reasonable grounds for suspecting, that the act constituting the infringement was an infringement of the copyright". The result of such a finding is that the plaintiff is "not entitled under this section to any damages".

other issues

Enforceability of online contracts is an ongoing drama (at least for legal academics) - in the states and here. For a recent analysis, see the Australian copyright Law Review Committee Report on Copyright and Contract (Chapter 5) (a report which, by the way, doesn't seem to have looked at viral contracts in any depth).

moral rights might be another issue - Australia has legislation (Copyright Act, Part IX) that prohibits, in essence, denigrating use of a work, or alterations that attack the integrity of a copyright work - meaning acts that consist of the material distortion of, or material alteration of a work, or anything else, which is "prejudicial to the author's honour or reputation" (s195AJ). But there are defences where the action is reasonable (s195AS).

So, in short - the article is a bit misleading, and a lot scare-mongering. There are definitely issues for the GPL in Australian law, but my reaction (without going through truly detailed legal analysis) is that at least many would be overcome in practice. The biggest issue is, of course, for companies wanting either (a) to make a lot of money out of distributing the stuff, or (b) save a lot of money by using it instead of Microsoft. For the former - they are in a position to price their product, right? And the people in category (b) can pay for the extra security - get someone else to provide warranties. If I were them, yes, I'd be getting some pretty good legal advice. and being careful where I got the software from. But isn't that always true? So it's complicated in law, that's right. But it ain't the end of the world for most programmers, methinks.

Who says paranoia doesn't pay off - Tech News - CNET.com

ZDNet Tech Update Platforms-OS - Assessing the risks of open source

"However, IT leaders are increasingly concerned with liability and security surrounding the use of open source. IT organizations must develop policies and procedures to aid in assessing the risk associated with all code utilized in the organization...

"Several risks are associated with using application software developed by others, such as copyrights and patents, liability, security, and quality. Commercial software brings a certain sense of safety by assigning specific rights, defining legal limits, and providing a named commercial entity that theoretically stands behind the code. When it comes to open source, the picture becomes murky. IT organizations (ITOs) must define rules of use based on where software is obtained and utilize software tools to evaluate third-party software.

Organizations must understand what rights have been assigned. When software is acquired, legal review of contracts and licenses is part of the normal process. This is an expense that must also be incurred with open source. However, accepting specific types of sources (for example, all software distributed under the Apache license) can limit the recurring cost for each new package from a site.

Linux Today - Politech CEI Blasts Linux as Unsuitable for Government, Business Use

"The NYT view has some gold. Competition is always good. And the Linux backers have hold of an important truth, which is that persuading a lot of smart people each to devote a small part of their time to an effort can produce impressive results. They are also right to think that opening up computer code to the eyes of the whole programming community can be extremely productive. Microsoft itself sees increasing virtue in this idea, and is developing shared source to open up code to scrutiny while the company keeps firm hold of the pen.

"But the NYT misses in some ways. First, none of this is free. Software is a complicated industrial product requiring continuing re-creation and support, and money to support it must come from somewhere. Linux programmers are not street people who sleep on steam grates so as to indulge their passion. They are supported, often handsomely, by universities and IT companies. Even this support is not sufficient to keep Linux going, and hardware companies, notably IBM, are now pouring billions into it. There is nothing wrong with this; IBM has good competitive reasons in that it wants to dish Sun and Microsoft. But the movement is not the folk song army depicted in the NYT..."

politechbot.com Competitive Enterprise Institute blasts open-source software

The most sacred example of open-source's success -- the popular Linux operating system now regarded as at least a credible threat to Windows -- remains difficult for anyone but specialists to use. So far, few critical major applications - word processors, spreadsheets, 3D games - run on Linux. Boasts of Linux's crashing less often than alternative operating systems matter little if few applications people can use run on it.

Use of Linux will probably expand dramatically - but the numberless open versions tweaked and Web-posted by hackers and hobbyists aren't the ultimate reason. Driving Linux's mass-market embrace today is the offering of a proprietary version called Red Hat -- and investment in Red Hat Linux by Intel and Netscape.

A dilemma for the open-source model is that its programmers aren't fundamentally answerable to anyone. Squishy product support won't cut it in the marketplace. Someone must be available to chew out and to sue when systems fail catastrophically, as happens occasionally.

The point here isn't to declare the open-source model "wrong." In free markets, we needn't embrace the open-source advocates' view indiscriminately, nor must we regard Microsoft's particular proprietary model as final. Free markets allow numerous experiments proceed in parallel. Some mix between the two approaches -- just like we enjoy today -- probably will remain ideal.

Like free love, open-source code is fun, but it's probably not a way to run the world. Somebody's got to step forward and take care of the babies.
Microsoft, for its part, accepts that responsibility, and that's one reason
why granting free access Microsoft's code isn't a rational or honest
response to the company's alleged abuses. Like most pop-critiques of the
profit motive, the open source doctrine is blind to its hypocrisy: for every
non-profit hacker, somebody must collect a paycheck to feed him and pay for
the computer.

Why I Reject the GPL

Scripting News

... ... ...

Brett Glass keeps bringing the discussion back to the evils of Richard Stallman and the GPL. I think it's more complicated. I couldn't support the GPL for MacBird because it's a poison pill for a person such as myself who makes a mixture of commercial and open source software. When I give away code, I want to give it away with no strings attached, for me or for anyone else. And when I put a price on software that's because I want to be paid for it. I've always done both open source and commercial software. To me it's an honor to get paid for something I create. I'm like a musical artist that way.

Then the subject swung around to why the open source "movement" gained traction. For some reason this discussion happened off the DG in email. I'd like to give my thoughts some public air.

Stallman's popularity is a result of what Microsoft did when the Web became a juggernaut. They attacked. Everything was a threat to Microsoft. They attacked relentlessly. They forced a choice. Become a captive Microsoft developer, or.. or what?

Developers legitimately wanted WORA. Microsoft thwarted them. This was their mistake, focusing on Sun, and blowing off the developers. I expected Gates to get this, but he didn't. They call him a "developer's developer." Bullshit. Now MS is left with developers who are such pussies they could overlook MS's "company town" attitude about developers. The ones with balls went to Java, or open source, or are drifting around aimlessly waiting for the industry to restart.

So don't say Stallman created this mess. No one would have cared if Microsoft hadn't forced a decision. If they had been more relaxed about the Web, let Netscape drift, and stay on the side of developers, Microsoft would have cleaned up and we wouldn't be talking about Stallman or open source now. My opinion of course. (And this isn't just good hindsight, it's what I begged Microsoft to do, publicly, starting in 1995.)

Talking with Paul Everitt yesterday, the Zope guy, I said "We've acknowledged open source, now it's time to have balance." Let's have the open source developers acknowledge that it's a multi-colored world, that there are Macs and Windows and Linux, and open source and commercial software, and all levels of quality therein.

Now, a lot of open source developers wonder what the big deal is. "We already acknowledge you," they say. They are our friends, and they tell us that most open source developers agree. That's cool! But the PR noise about open source is not in agreement with this message, and the users, press, and investors hear the PR message, and you wouldn't believe the kind of pressure it puts on us. When the initial rush of hype about open source came a couple of years ago, while all the PR leaders were basking in the glory, we were getting decimated. For us it was esp bitter, it came just as we were turning Frontier into a commercial product after having given it away for years, we were trying to get onto solid ground. Had we not been able to do this, there would be no Manila, no XML-RPC, probably no SOAP or RSS either. Or Radio UserLand, or the World Outline, or whatever else we come up with next. The open source hype made it much harder than it had to be.

BTW, to the open source developers, all our innovations are without patents. We've been blazing new trails on a regular basis for the last few years, esp in the last few weeks, and documenting our work. Anyone who files patents in these areas, and you can be sure that's happening now, will find a trail of prior art blocking their greed.

During the heat of the open source hype, every day our users would tell us Eric Raymond's bullshit about our intentions. They would demand that we release our source code, as if that had anything to do with getting them what they wanted. We were undermined. At the same time Bill Gates was fueling the fire by picking on Java developers, undermining them as we were being undermined by the open source PR. The opportunists on the open source side continued to hurl bricks at all commercial developers, as if we were all self-centered bastards like Gates. I'm sure they knew better, but it worked for them. Meanwhile open source developers, people much like ourselves, ignored the hype, but we couldn't. It was so in our face it couldn't be ignored.

Now, I've tried to be an official open source developer. I gave away a beautiful program that would help the Linux guys compete with the Mac. It's gone nowhere. The leaders want to take the shortcut, instead of linking up with the Mac, they want to erase it. These are not our friends. They do unfriendly Bill Gates-like things. Well fuck that shit. Let's create a programmer's club, and let's help each other.

And to Bill Gates, I'm totally happy to meet to talk with you too. Let's get the software industry going again. It'll be good for all of us. I'm willing to do my part, but you have to do yours. You hurt all of us by attacking the Web so viciously. The right thing to do is to repair the damage you caused.

End of rant, for now.

On O'Reilly 

I've been very hard on O'Reilly. I didn't realize how hard.

Re-reading my message to Brian Behlendorf, I see it differently from how I saw it then.

A statement of friendship must not have any bitterness in it.

I also understand that O'Reilly is a high-quality company. And they have their own point of view, which is certainly a valid one.

I had similar trouble with Apple, and eventually came to understand their point of view. (They hated the Web because it undermined everything they stood for. I didn't understand this, while I was saying publicly that they didn't get the Web, they did get the Web, they just didn't like it!)

Apple also controlled the Macintosh developer community. This was a choice of Apple's and the Macintosh developer community. So when I say O'Reilly is running a captive developer community, the same applies. You have to be a friend of O'Reilly's to speak at their developer conference. I am not a friend of O'Reilly's. And the developers who attend the conference must know that, even if not at a conscious level. Their conference works, and will continue to work, whether or not dissenting views are embraced.

I have wanted to be a friend of O'Reilly's, because we stand for many of the same things. First and foremost is technical excellence. That's also, by the way, the bond we have with Microsoft. Even though they play a piggish game with the rest of the industry, underneath it, there's a twinkle in the eye of Microsoft's technical culture. O'Reilly has that twinkle too.

Tim has also personally come out against software patents, but the follow-through has been unsatisfying, given the urgent and escalating threat to intellectual freedom for software developers. Open source does not trump patents. The freeze in MP3-related technology is not just coming from music industry, it's also coming from a patent held by a German company who is ruthlessly enforcing it.
 

nettime The case for lagom copyright

Tim O'Reilly tried to press the issue in a couple of articles and seemed convinced that Stallman and his colleague Kuhn was for GNU GPL legislation. O'Reilly suggested a sys