Thursday, May 31, 2007
Don't be dumb, give it an A (GPL)
Today the FSF has introduced the latest draft of GPL v3 and, at the same time, of AGPL v3. I am not going to comment on the changes of the GPL v3 (although the compatibility with Apache licenses is a great step forward), but I would focus on the AGPL v3 (a.k.a. GNU Affero GPL).In a nutshell, AGPL v3 is the same exact document of GPL v3, with an additional paragraph on Section 13, which says:
Notwithstanding any other provision of this License, if you modify the Program, your modified version must give all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to copy the Corresponding Source from a network server at no charge.What this means is: if you run this software as a service (SaaS), everything else here applies. You must give back the source code. It closes the in(famous) ASP loophole.
Now, my suggestions on the last draft were:
- Do not make the provision as in the current Affero license, that forces the ASP to offer a service to download the source code while you are using the program (insane, think how you could apply this to mobile phones)
- Do not let Affero Inc. own the license but make sure it is managed by the FSF
- Make it OSI approved
- The provision stated above is just perfect. You have to give the users an opportunity to receive the source code. CVS will do it.
- They changed the name of the license, adding GNU at the beginning. It is pretty clear who owns it now ;-)
- It is exactly as GPL v3 and I bet it will be OSI approved the day after it is final
Bottom line: if GPL v3 and AGPL v3 are exactly the same document and are 100% compatible, why would an open source developer choose to allow people to run its software as a service without returning the code to its community? It does not make any sense... Zero, nada... Every single developer that will have to choose between GPL and AGPL will go for AGPL. I guarantee it.
The only risk is ignorance. Therefore, the next fight is making sure that the entire open source community knows about AGPL. Let me start here.
Do not use GPL. Don't be dumb, give it an A. That's AGPL (and yes, I might have a t-shirt for OSCON ;-)
Posted by Fabrizio at 14:14
16 Comments:
Doesn't even AGPLv3 still leave the possibility of using one's program/code/library via API so that one does not have to publish one's source code?
I'm thinking of an inhouse application using AGPLv3 stuff as part of the solution.
Comment Posted at 04:13
Andrew said...
Doesn't this potentially do more harm than good? As a site owner, this potentially strips my "freedom" to express myself uniquely. If I use AGPL software, and hack it slightly for my purposes on my site, you are legally entitled to pester me for my changes, whether I want to share them or not. Imagine Joomla! or Drupal went AGPL - 3 million sites in the world suddenly become fair game for the so-called leaches to demand the sources for the subtle changes, not for the good of the community, but purely for self-interest (or am I reading this completely wrong). If that is indeed true, then the problem you generate is far worse than the problem you are trying to fix.
While I respect some of what the AGPL clause is trying to do, I also feel that it's mutating the spirit of Free [as in freedom] Open Source to "freedom on my terms and I want any changes you make thankyou very much".
Comment Posted at 16:00
Fabrizio said...
Hi Andrew,
sorry, I totally disagree with you :-))
Sharing your changes with others is the basis of open source and copyleft.
It is exactly as today with GPL when distributing software.
Is anybody "pestering" Red Hat today when they make changes to Linux? They just provide the source code of their software, that's it. They HAVE to.
Should Red Hat decide what is a "subtle change" or not, providing source code only for not-so-subtle changes? No. They have to provide everything. Let the people decide what is important or not.
My point is: distributing open source software as a service is not different from distributing it in a floppy.
Open source is not free as in beer. You have to return your changes to the community.
If you feel that returning your changes to the community strips some of your freedom, then you should not use open source software. Buy a license from someone and they won't ask for your changes.
Cheers,
fabrizio
Comment Posted at 09:51
Andrew said...
> You have to return your changes
> to the community.
I disagree totally with the notion that Open Source is about "giving away but you must give back". For me, using an Open Source model is about ensuring that my code that I give to the community (maybe hundreds of thousands lines of codes over more than a half-dozen projects now) always remains free [as in freedom]. I don't care what people do with it, how much money they make, whatever. I've let it go, I know it will always remain free to use ... I'm happy.
The "community" has a right of usage but I'm very concerned by a growing attitude that the community has some assumed rights over the way other people use distributed code. That infringes my liberties of individual expression.
Just because nobody has gone after Red Hat is immaterial. Bottom line is under the AGPL I could ask any AGPL site owner for their changes to the site and they have to give it to me. The big guys (which I'm assuming is the target of the AGPL) are not going to be affected. They have the budget to fight things and they aren't going to go AGPL anyway. The little guy is the one who is going to be affected and potentially preyed upon.
All I'm saying is that this license model has the potential to shift the problem onto otherwise innocent site owners who have made a couple hacks.
And in my view, the greater community has no right over the way people use source code given away for free. If some people give back to a project great (I actually find the problem is there is too much help offered). If some people don't, or give back in non-source ways (which to me is far, far better) then that's fine too.
Comment Posted at 14:26
Fabrizio said...
Hi Andrew,
I believe we disagree on the importance of copyleft in open source. In my opinion, it is what made open source what it is TODAY.
And, yep, it forces you to return the code. Even if you are an innocent small developer... It affects everybody.
BTW, I really do not see an issue with providing the source code of what you changed in an OSS project. You just put it on your web site, not really an hassle.
Bottom line: I feel we agree to disagree :-)
Cheers.
fabrizio
Comment Posted at 09:23
Andrew said...
You miss my point. The problem I see is that you are introducing an un-freedom that legislates forced distribution.
Imagine a small break-even business that takes an AGPL CMS and does something simple but really cool with it. The right channel is for them to be free to inject the change back through the project. However, under the AGPL you take out the project as the middle-man and expose the implementor directly.
Imagine the feature is slash-dotted. The site owner directly gets unmaintainable requests directly for the source code - and *must* comply whether or not he/she has the resources.
It's also absurd to think that people won't expect some level of support. No, of course they shouldn't but they will and this could further swamp the innocent site owner with genuine and stupid mail. And when the masses find a security flaw in the hack, well, you know who they are going to point the finger at (a clue, not the dummy that downloaded it because they had the right to).
To me this breaks a golden rule of good software development. Don't distribute if you are not prepared to support it.
But I guess the failsafe is to put a price point on the forced distribution that keeps demand to a manageable level - and the FSF's own commentary doesn't mind how much that is (yet).
Comment Posted at 14:15
I am the author of a semi-popular PHP script. I would not like some big company to come in and offer a hosted version of my service without contributing their modifications back to the community.
However, many of my users make small modifications to the code. This license would make them have to provide a copy of that code, right? Seems like a big inconvenience to them.
And what about karim's question?
Comment Posted at 14:35
Fabrizio said...
> However, many of my users make small modifications to the code. This license would make them have to provide a copy of that code, right?
Right, but only if they offer the code as a service to the public. Not if they use it in house or for themselves.
Hey, where is the inconvenience? If they are offering a web service, they have a web site. What the license requires is that the code they changed is on the same web site for people to download. I honestly see the excuse of the "inconvenience" as a weak one. Put out the service on a web site, provide a link to download the source, that's it.
fabrizio
Comment Posted at 19:23
Because my original question did not get answered, I'll rephrase it a bit and make it more Funambol:
If I create a marvellous addition to Funambol DS Server, but only use it (Funambol code) via documented APIs, do I have to publish the source when Funambol is under AGPLv3? (I presume it is in the future.)
Even if running it SaaS or similar?
(Funambol DS Server is used as an example here.)
Comment Posted at 17:33
Fabrizio said...
Hi Karim,
sorry for not responding to your comment earlier. From my point of view, the answer is yes, you should publish your connector as AGPL (as today for HPL). However, I am not a lawyer and I have limited understanding on the details of AGLP v3 on this topic. I plan to study the issue more in the next weeks.
Cheers,
fabrizio
Comment Posted at 00:09
Chris Marino said...
Fabrizio, I completely disagree. The Affero license will keep the lawyers busy for years to come.
Comment Posted at 17:18
Fabrizio,
Thank you for all you are doing.
I understand that this is ultimately a topic for the well paid attorneys, but since their responsibility is to ultimately implement the intent of their clients and since you are very knowledgeable in this special area, I would ask for your thoughts on a standard scenario:
Say we develop a connector for the Funambol server, I understand the new work would be subject to AGPLv3 i.e. derivates of the AGPLv3 code remain AGPLv3.
Say this AGPLv3 connector communicates to a closed source system over an API. Also say that the closed source system is a pre-existing independent product, where the Funambol server is a incremental feature (not the product itself), and where this description would pass the "sniff test" i.e. the case is not being used as a loophole to add a feature to Funambol without a proper AGPLv3 provision.
A hypothetical example would be building a connector for Microsoft Dynamics CRM, or SalesForce CRM. The connector would most obviously remain AGPLv3, but what about the closed source app? Is it your intent that the entire closed source system would be subject to the AGPLv3? Or, because the AGPLv3 "code" was not modified and because the "product" is not Funambol it would not be subject to the AGPLv3 conditions?
I guess fundamentally the question is asking to clarify if there a rule-of-thumb for a sustainable open-source / closed source software stack.
Comment Posted at 18:51
Fabrizio said...
Hi Steve,
quite complicated topic. And I am no lawyer... The philosophy behind AGPL is that - if you do not offer the software over a network (i.e. you use it inside your enterprise) you do not have to return the code to the community. Instead, copyleft applies when you host the software as a service.
When you start digging into the case of interfaces, it gets beyond my ability to determine where copyleft stops. Once again, I am no lawyer (and I am not pretending to be one...).
Therefore, let me go with the boilerplate answer, which I hope clarifies our position as Funambol.
Funambol's interpretation of AGPLv3 is that it affects not just software that interfaces directly with our server (such as a connector to Funambol), but also software (and products) that interface indirectly, such as software which interacts with a connector to Funambol.
We understand that the use of APIs between a connector (e.g.) and an end product might make the distinction of what constitutes the final product to be hard to clarify. As a software company, we are not in a position to dispense legal advice, as the interpretation of AGPLv3 does not have a simple definitive answer that applies to every situation, it requires a case-by-case analysis. For this reason, we recommend that if people have questions about this, they should seek the advice of a qualified attorney.
Alternatively, many Funambol customers decide to purchase the commercial version of Funambol, Carrier Edition. It contains no copyleft requirements i.e. it can be used without the need to make any code available. Carrier Edition provides many additional benefits, such as scalability, a consumer portal, a customer support interface, phone packs, commercial support from Funambol and much more versus the open source Community Edition.
I hope it helps,
fabrizio
Comment Posted at 19:19
northrock said...
Thanks Fabrizio!
One would think that it would be unreasonable to expect that Salesforce must 'GPL their code because an integrator developed a connector for the "open source" Funambol server.
As a for-profit business what value does AGPLv3 provide you? Would it not be simpler to only license your software for under a commercial license and avoid this ambiguity thus eliminating all barriers to all markets? I do know there is a commercial license, but the question really is then, why open source?
Just trying to make sense of it in a practical situation.
Comment Posted at 21:27
Fabrizio said...
The reason for why open source is pretty clear. There are thousands of enterprises that are using our software because it is open source. And the software is improving every day because of it. In particular, open source is giving our community the ability to address 2B phones in every corner of the world. This would not be possible without an open source initiative.
The Carrier Edition is limited to those that offer the service to the public in a SaaS fashion. They are a very limited set of companies, a micro percentage compared to the enterprise users.
The model works very well and both communities are happy. Enterprise get a great product for free with the source code, service providers get a great product and commercial support, plus the benefit of having a community behind its core (and the phone broad reach).
fabrizio
Comment Posted at 08:32
northrock said...
The value proposition for the two examples you describe are clear, however the Salesforce scenario remains ambiguous. Given the trend for Enterprises and SMBs to use SaaS products and Cloud computing stacks it would seem as an important area to clarify. SaaS is a growing segment of IT, with a natural affinity to software such as Funambol - not micro and not carrier.
Thanks again for your responses; for now, I'll leave it at that. We shall follow your recommendation to analyze this internally.
Steve
