Is this a blunder, or just too subtle for me?
Is this a blunder, or just too subtle for me?
Posted Jul 26, 2007 4:18 UTC (Thu) by rickmoen (subscriber, #6943)Parent article: SugarCRM goes to GPLv3
I may be missing something, here, so I'm phrasing this in the form of a question or two, and it's not rhetorical: Didn't FSF bow to pressure from sundry interest groups and remove the "ASP loophole" language that had been present in some GPLv3 drafts? Therefore, what in Sam Hill is a Software as a Service (Saas) / ASP / Web 2.0 firm doing adopting a copyleft language whose copyleft language gets finessed by hosted deployment?
FYI, there are a number of genuinely open source licences, a couple of them OSI certified, that do apply copyleft obligations to the ASP industry. One of the best is Larry Rosen's OSL, and there is also Apple's ASPL, both of those being OSI-certified. Non-certified options include Affero GPL (newly reissued as a patch to GPLv3, by the way) and Honest Public License.
On the basis of recent history, it's possible that SugarCRM not only lacks any clever, non-obvious reason why it picked a non-ASP copyleft licence for ASP code, but also doesn't really have any idea what it's doing in this area, and picked GPLv3 just because it has had good press (good press that it generally deserved, IMVAO). Remember, this is the firm that created the first MPL-based ASP licence, and then acted shocked and indignant when it belatedly discovered that its licence permitted forking (when TigerCRM of Chennai forked the codebase), and overreacted by writing what became the prototype MPL + Exhibit B "badgeware" licence that impairs third-party usage through mandated logo advertising without a trademark licence.
It'd be more reassuring if I thought this firm had a master plan, but I now rather strongly suspect it's just a bunch of sales people in an office in Cupertino, staggering from one inadvertant move to the next.
Rick Moen
rick@linuxmafia.com
Posted Jul 26, 2007 7:23 UTC (Thu)
by BrucePerens (guest, #2510)
[Link]
Similarly, lots of folks tell us that BSD licensing has protected them adequately (although the failures are more obvious in this case). Whatever the reason, it is good to see that folks like Ross Mayfield and Matt Asay have become convinced that badgeware isn't the way to go. Bruce
Posted Jul 26, 2007 16:00 UTC (Thu)
by khim (subscriber, #9252)
[Link] (3 responses)
FYI, there are a number of genuinely open source licences, a couple of them OSI certified, that do apply copyleft obligations to the ASP industry. Yup. And they are mostly unsuccessful ones. It's quite hard to distinguish two cases: Licenses like AGPL/APSL punish equally - that's why I'll probably never use AGPL/APSL-licensed software. And if I'll be forced to use such software I'll do everything possible to not ever fix or change it. Even badgeware is better from practical viewpoint. If you'll think about it it's only logical. Yes, usurpation of the code by SaaS vendors is a problem but AGPL is worse medicine then disease itself...
Posted Jul 26, 2007 21:38 UTC (Thu)
by rickmoen (subscriber, #6943)
[Link] (2 responses)
Yup. And they are mostly unsuccessful ones.
Your "unsuccessful". My "underappreciated so far".
It's quite hard to distinguish two cases:
And, in my personal view, pointless. (My opinion, yours for a small fee and agreement to post my logo on your forehead. And by the way, I also deny the premise that LWN is a "private endeavour" in any sense meaningful to this context. Of course, Jon and co. happen to use their own code, IIRC.)
Rick Moen
Posted Jul 27, 2007 6:45 UTC (Fri)
by khim (subscriber, #9252)
[Link] (1 responses)
And by the way, I also deny the premise that LWN is a "private endeavour" in any sense meaningful to this context. And I deny the premise that the sky is blue. LWN is "private endeavour" as far as the code is concerned, there are nothing to accept or deny, it's just truth. Of course, Jon and co. happen to use their own code, IIRC. Nope. They use the code from different projects and their own code, too. The problem is: they can not (and will not) use "superprotected" AGPL/APSL code without hassle. And that means you have less potential contributors for AGPL/APSL projects. Most benevolent users of web-server tools pass three stages: Note that they AGPL/APSL breaks all that. If you changed something (for example added some 15-line function which includes SQL-access password) - you MUST publish it (or at least give it to anyone who asks). And this is definitely NOT something stage 2 users (like LWN) will like. This is the question of balance. BSD makes it easy to use stuff but encourages private forks. GPL makes it harder to use stuff but discourages private forks and so wins in long run. AGPL/APSL makes it even harder to use stuff and makes all changes public (so private forks are even less likely). My opinion is that it makes use so hard that 90% of people will just not bother, but I can be wrong. To just deny this problem is to delude himself (or herself).
Posted Jul 27, 2007 9:31 UTC (Fri)
by rickmoen (subscriber, #6943)
[Link]
LWN is "private endeavour" as far as the code is concerned, there are nothing to accept or deny, it's just truth.
My usual response to tiresome definitional games is to descend down the abstraction ladder and talk about something more specific, so let's do that here.
I had thought that LWN is build on homebuilt Web-app code, which you say is not entirely the case. OK, but then my concern applies more rather than less:
The only sense of "private endeavour" that struck me as meaningful in this context is "entirely internal project". Obviously, LWN is not (other than in the form-over-substance sense that I believe you're advocating): Although its foundational code does not get distributed, all the functionality that in pre-ASP days required distribution is deployed and used by public users. That is "private" only in a deliberately blinkered sense of the term (and your polemically labelling such things "private forks" should fool very few, this late in the game).
If, on the one hand, some portion of LWN's third-party code is under simple permissive licences, then none of the above matters at all, as to that code, since the authors intended all manner of usage including proprietary forks, anyway. If, on the other hand, some code is copylefted, then odds are that those codebases' authors intended for public exploitation of their code to trigger copyleft reciprocity obligations, and merely made an (obsolete) assumption that such exploitation would entail distribution. I know from damned sure that the licences' authors intended that, because I asked.
Frankly, it's abundantly obvious that you know all that, and merely dislike it, presumably finding it inconvenient. Sorry to hear about your personal problem, but kindly just step out of the way while other people update their assumptions, and their licensing practices to match.
Rick Moen
SugarCRM and its ilk have to balance pressure between what their customers will accept in a license and what their own company wants in a license. While there is an FSF-approved version of GPL 3 that addresses the ASP loophole, the Affero GPL3, they aren't using that one. Nor is MySQL using a license that closes a similar loophole. It's clear that you can use MySQL with proprietary software and without buying a commercial license, as long as you use a properly-licensed client library rather than the one that comes with MySQL. In MySQL's case, the company offers enough desirable services that people buy the commercial license anyway. Perhaps SugarCRM is expecting that customers will pay to get out of some of GPL3's provisions regardless of whether it addresses the ASP loophole or not, or perhaps they think that they can win the commercial licenses as MySQL does, with services.The end of Badgeware
Is this a blunder, or just too subtle for me?
1) where your package is used for SaaS (like Google)
2) where your package is used for some private endeavour (like LWN)
"khim" wrote:
Is this a blunder, or just too subtle for me?
rick@linuxmafia.com
Is this a blunder, or just too subtle for me?
1. First they use the code without any modifications
2. Then they change some small pieces "to fix this or that"
3. Finally if they fill that the change is big and good enough - they submit it upstream.
a. Never send the code to end-users, only to upstream.
b. Want to have the ability to tinker with system in peace if they feel that changes are just "not worth it"
khim wrote:
Is this a blunder, or just too subtle for me?
rick@linuxmafia.com