...making Linux just a little more fun!
Rick Moen [rick at linuxmafia.com]
----- Forwarded message from rick -----
Date: Tue, 26 Jun 2007 21:21:42 -0700 To: firstname.lastname@example.org Cc: Karsten Self <karsten> Subject: Red Hat Exchange has a serious flawDear Ashlee:
I note with interest your recent articles in ElReg: "Red Hat's Exchange roars like a muted lamb" and "Red Hat RHXes out to open source partners". However, I'd like to point out one problem you haven't yet covered:
Many of Red Hat Exchange's offerings, although all are implied to be open source, are in fact nothing of the kind. For example, the offered products from Zimbra, SugarCRM, Compiere, CentricCRM, and GroundWork are very clearly under proprietary licences of various descriptions.
When I attended Red Hat's RHEL5 product launch in San Francisco on March 14, I heard RHX described for the first time, immediately noticed the problem, and quietly called it to the attention of Red Hat CTO Brian Stevens. Stevens acknowledged the point, and said (loosely paraphrased) that their Web pages should to be adjusted to make clear that not all RTX offerings are open source -- which is indeed a sensible remedy, but it hasn't yet happened.
I also attempted to call Red Hat's attention to the problem via the designated RHX feedback forum, at http://rhx.redhat.com/rhx/feedback/feedback.jspa . (You'll note my comment near the bottom.)
I'm sure it's an honest slip-up, but, accidentally or not, Red Hat has mislead its customers for the past several months on this matter, and is continuing to do so.
Best Regards, Rick Moen email@example.com
----- End forwarded message -----
----- Forwarded message from Rick Moen <firstname.lastname@example.org> -----
Date: Wed, 27 Jun 2007 11:54:04 -0700 From: Rick Moen <email@example.com> To: Ashlee Vance <firstname.lastname@example.org> Cc: Karsten Self <karsten> Subject: Re: Red Hat Exchange has a serious flawQuoting Ashlee Vance (email@example.com):
> Thanks so much for this, mate. Will investigate.
Sure. In case it will help:
Most if not all of those codebases are ASP (Web app) code, which poses a thorny problem: Suppose you are, say, Google, and wish to behave benignly towards open source with your Web apps. You deploy a Web 2.0 hosted application, and release its source code to the community under a proper, forkable licence such as BSD / MIT X11 (simple permissive type) or GPLv2 (copyleft), that fully satisfies the Open Source Definition. For the sake of illustration, let's assume GPLv2.
Google's competitor EvilCo swoops by, grabs the source tarball, modifies it extensively behind closed doors, and deploys it under a completely different name as a hosted Web app (product/service) of its own, bearing very little resemblance to Google's original application. Let's say that EvilCo nowhere mentions its borrowing from Google, and that EvilCo doesn't provide anyone outside its employees access to the modified source code.
Probably, Google would never even realise that EvilCo had deployed a derivative of its work. If it came to realise that fact, and asked EvilCo for a copy of the matching (modified) source code, EvilCo could entirely lawfully say "No."
Wait, you ask: Wouldn't that violate clause 3b of copyright owner Google's licensing terms under GPLv2, and hence constitute the tort of copyright violation? Nope: EvilCo has no copyleft obligation to make available source code unless and until it distributes the work or a derivative of it. And ASP/Web deployment doesn't require code distribution.
That's the bone of the matter: A reputable, open-source-respecting Web 2.0 firm that releases source code under (most) open source licences is at the mercy of less-scrupulous competitors creating, Web-deploying, and commercially exploiting undisclosed, proprietary forks of its creations.
So, the problem is real. The solution so far has been problematic:
Faced with this dilemma, a group of ASP firms lead by SugarCRM has started creating what Bruce Perens (and I) call "badgeware" licences. Typically, these are created by adding proprietary addenda to Mozilla Public License 1.1 -- addenda that require third-party users to retain graphical and linkback advertisements of the "original contributor" on (typically) "all user interface screens" on any derivative works. Often, the addenda also explicitly deny third-party users any rights to the "original contributor" trademarks embodied in the graphical advertisements and other mandated advertising. (This is seen by many including me as a deliberate attempt to impair use in commerce by third parties: You have to fear trademark-infringement lawsuits.)
There are about a dozen or so "badgeware" firms in the SugarCRM camp. I have written, off and on, about the problem in _Linux Gazette_: http://linuxgazette.net/134/moen.html http://linuxgazette.net/135/misc/lg/talkback_134_moen_html.html
There have been new developments, that I have not yet covered in _Linux Gazette_: After extensive discussion of the modified-MPL licences, none have yet been OSI-approved (actually, most of the firms have very scrupulously avoided submitting them for OSI scrutiny), and consensus is so far strongly against them being OSD-compliant, despite much futile arm-twisting by big-money VC interests behind some of them. Some of the firms are showing some signs of an attempt at good-faith compliance without putting themselves at the mercy of EvilCo ploys -- but things are not yet fully worked out.
Also, OSI President Michael Tiemann has finally put his foot down and deplored the practice of all such firms of promoting themselves as "open source" when their licences aren't OSI approved and in general they are plainly proprietary on their face: http://opensource.org/node/163
I intend to catch up on recent developments soon, but haven't yet done so.
I should also note that some ASP/Web firms aren't even within a country mile of OSD compliance, and offer only what are absolutely without any room for dispute proprietary programs: CentricCRM, which you'll note is featured on Red Hat Exchange, would be a classic example.
I hope this explanation helps.
----- End forwarded message -----