Many thanks for the comment on the two posts. As you say, in many ways there is nothing new here. The revenue dilemma isn’t news to me, but I wrote about it to draw attention to what I see as a common misunder5standing about the Affero GPL: that is prevents the use of code in cloud environments.

I agree there is much more to this than I covered in either of these two posts and I have received some very interesting feedback from very knowledgeable people (both here and via email) which will will include in a more formal analysis of the situation in 2010.

Thanks
Matt

The AGPL plugs the GPL loophole that allows companies to provide services to third parties using *proprietary unpublished modifications to open source software*.

I agree with Matt that the AGPL (or even OSL 3.0 that I wrote and prefer to the AGPL) doesn’t solve all the problems he identified in his first post. His second headline calls the main problem “the Revenue Dilemma”, which is as fair as you can be in identifying any commercial company’s problems using copyright and contract law alone to protect a revenue stream. Age old problem you’re talking about, Matt. It may be news to Matt, but it isn’t news to those of us who have been helping open source and proprietary companies deliver profitable solutions for over a decade now. The revenue dilemma can only be solved with excellent products and services delivered with expertise.

I believe that the AGPL and OSL 3.0 both offer a solution to a type of free-rider problem, such as Google’s use of improved open source GPL and other code that is never shared with its competitors and customers. I have no problem in principle with that model, except that I believe that Google (and its ilk) ought to pay for that privilege to use free software for profit. The AGPL and OSL 3.0 plug that loophole. Even that is not necessarily enforceable strictly, because software can be run in lots of functional ways without invoking copyright infringement at all. And big companies like Google will continue to refuse AGPL and OSL 3.0 software altogether because their business choice is NOT to share.

Isn’t the notion of “privilege of subscribing for a fee” a fundamental basis for any open source company’s success? So if some customers (such as Google) refuse software under a strict license like the AGPL or OSL 3.0, then your company should offer them a commercial license for a fee. That goes a long way toward solving the revenue dilemma. Your customers will understand.

/Larry

DISCLOSUR: I wrote this comment originally as a member of the Jaspwersoft Advisory Board and am publishing it here with their permission.

Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com)
3001 King Ranch Road, Ukiah, CA 95482
Office: 707-485-1242 Cell: 707-478-8932
Apache Software Foundation, member and counsel (www.apache.org)
Open Web Foundation, board member (www.openwebfoundation.org)
Stanford University, Instructor in Law
Author, Open Source Licensing: Software Freedom and Intellectual Property Law (Prentice Hall 2004)

If I need to include a component in an area where there are no standards, then the implementations are not interchangeable. I will probably have to choose the one with the feature set I want to expose via my cloud based application, and live with its license.

Suppose my first choice is using the Affero GPL? I have three choices: 1) Live with it, and contribute my changes back to the project. 2) Choose a different project with a different license. 3) Write my own from scratch. I’ll argue that 2) isn’t really a choice – by definition I’m going with my second (or third or fourth) choice, and I’ll need to spend resources enhancing it to get the functionality I want that I would get automatically via 1). In this case, I can either re-apply my changes each time the project gets updated, or contribute my changes back so they are incorporated in the main code-base. Since contributing back is what I want to avoid, that leaves me with the choice of either re-appling my patches, will be a HUGE maintenance headache, or forking the code (if the license allows it.) Forking isn’t all that different from choice 3)

I think few if any companies can afford to either fork and advance an existing project or create their own from scratch. Even a company the size of Google will have to decide how much it wants to spend re-inventing a wheel to avoid licensing restrictions.

RE: So what? I agree, I wasn’t criticizing the AGPL but some people evidently think that licensing under the AGPL prevents Gooogle or AWS or whoever from running the code. I was just pointing out a misunderstanding.

RE: dual licensing. Perhaps, although only if the company owns all the copyright.

Regarding point 2, surely those modifications are
a) Generally uninteresting to other people so who cares if the changes to run on Azure are not released
b) “The Affero GPL doesn’t prevent the deployment of open source software in networked environments, it just requires contribution of modifications”. So what? AGPL is not about stopping people deploy in network environments. All it wants is the code back. This is no different to the intentions of the GPL regarding traditional applications.

Regarding point 3, could the code not be dual licenced for a fee to the ISV’s if they are partners? If it wasn’t for the AGPL they would not be tempted to do this?

This post was mentioned on Identica by caostheory: New post: The Affero GPL does not solve the open source/cloud revenue dilemma. http://bit.ly/6helNt...