My point of view about the OpenERP relicensing

Hello everybody,

I will now tell you about the subject of the last week: The addition of an exception in the OpenERP AGPL license, potentially allowing to avoid the redistribution of source code through the purchase of an OpenERP Enterprise version.

So like everyone else in the community, instantly I was shocked:

-We create some kind of a dual license, which is our worst fear: SugarCRM, Pentaho, Magento, etc … most of the popular business free software also have in parallel an enterprise version which means that not all efforts are made to improve the free version and often even limiting the efforts of the community. This is one of the main power of OpenERP now than not falling into this trap and it’s a very, very bad news to see that begin to rears its ugly head.
Ok so we are assured that the Enterprise version has nothing to do with the other double licenses, that all the modules continue to be dismissed AGPL, don’t act I return to it later in this post. Nevertheless, the name is very scary.

-We can also read the fact we can, against some good cash, purchase the right not to redistribute the source code. No really need to be a fan of conspiracy theories to immediately imagine arrangements between OpenERP SA and large companies to make some breaches against the GPL’s garantees and thus those protecting the community and users.

This is what comes to mind when OpenERP SA presented its new offer, and that is why the debates have been particularly virulent last week about this. I myself began to fear that a significant part of the community begins to turn to Tryton.
But when we analyze in detail the offer, we realize that it is not necessarily so bad thoughts, to understand where I’m going let me go into detail *GPL license.

The first license *GPL , I will move quickly on it because it was never used by OpenERP, and also the least restrictive is the LGPL. It is used primarily when the license of software needs to be compatible with proprietary code while being able to protect by the GPL guarantees the software itself.

The GPL is the basic license approved by FSF and one of the most restrictive. Sometimes excess according to some people because you can not use GPL software with other proprietary code. You have an obligation to redistribute the source code if you make a modification to the software, but however you can create an extension as an OpenERP module without having to publish as you use it privately. OpenERP remained long in GPL V2 and then in GPL V3 when this version was released.

Still, the GPL failed to give guarantees with the SaaS. You could take for example the OpenERP code, create useful modules, and on that basis make an SaaS offer without having to publish the source code of your modules. I call that an opportunistic SaaS offer obviously wrong in light of the spirit of free software.
This is to compensate for this scenario that the FSF has created the AGPL license. The principle is simple: You can request the source code of any software you use, even if it is used across the network. Note the size difference between the GPL and the AGPL: If we place ourselves in business context, this means that even employees or partners with limited access to the ERP can request the source code of the company’s OpenERP, including modules developed specifically for it and only used privately.

OpenERP is licensed under the AGPL since last year. It was obviously necessary to avoid opportunistic SaaS offers I mentioned and that could appear very quickly. Imagine you take the code OpenERP, develop a vertical integration, for example services companies and sell all without having to redistribute your work. I can imagine how these opportunists could appear in a few years on the back of OpenERP so it was obviously a necessity.

And so now OpenERP SA receives requests from companies wishing to protect their private modules (which can often reflect a unique way of working to the company and does not want to give to the competition). On which OpenERP SA meets today with the AGPL exception.
This exception says that if the client company pays the enterprise version, it may not give the source code of its modules to private users but must make if it distributes copies (especially if he tries to sell them) returning immediately under the terms of the classic AGPL. For me it is neither more nor less than selling the right to use the GPL instead of the AGPL.

And for once I will not plant a knife in the back OpenERP SA: I agree with them. For me, both GPL and AGPL protect the interests of the community, with the exception of opportunistic SaaS offers for GPL. I see no problem in allowing the companies to use private module, it’s fully in the spirit of free software, it has been like that throughout the GPL period of OpenERP and I would even say that simply forbid it as the AGPL actually unserve the interests of OpenERP and community.

But where I find really interesting the choice of OpenERP SA is that they have managed to find an economic model (the fact to charge companies that want to protect their internal working methods), equal (not all companies will need such protection, and those who need it can pay for it) and especially with the only difference between the paying and non-paying users is … just impose even more restrictive license about the free software guarantees, via the AGPL license for non-paying users. Users who pay will have a GPL equivalent already properly protecting the interests of the community and non-paying users whose the only restriction is to be forced to publish the source code for its employees and partners … It’s brilliant, just brilliant.

Since I started on OpenERP, I feared that OpenERP SA is finally forced to adopt a dual license in order to survive, I have seen throughout the period struggle to come to find a viable business model but respectful of the community. When this exception appeared, I thought, like many others, they had mainly started throwing in the towel and move to a dual license, however, finally … it seems on the contrary they have actually managed to find the economic model they were looking for. Personally I therefore support the idea, and I think it is incredibly original.

Now consider the various scenarios:

1) The case where an unscrupulous company is developing a module and then tries to sell it without redistribute the source code. This case should in my view not be possible without violating the spirit of free software.

2) The case where a client company wants to develop a module for internal use only. The company should have the opportunity, so free or paid, to retain full intellectual property of the module without publish it to its employees and partners. This does not violate the spirit of free software.

3) The case where a client company wants access to a module. It is my opinion that is respected the spirit of free software if he has free access to the source code for all modules developed by the publisher, by an integrator which bases its services above and those used in a SaaS offering. They did not necessarily have access to a module only used internally in another company.

4) The case where an unscrupulous company develops a module for an SaaS offer based on it without having to redistribute the source code. This case should in my view not be possible without violating the spirit of free software.

OpenERP under GPL licence:

1) Case impossible without violating the license

2) Possible case without license violation

3) The client company has no access to modules of an unscrupulous SaaS offer.

4) Possible case without license violation

OpenERP under AGPL licence:

1) Case impossible without violating the license

2) Case impossible without violating the license

3) The client company has successfully access to all modules.

4) Case impossible without violating the license

OpenERP under AGPL + exception. The company which is mentioned in the case purchased the enterprise version.

1) Case impossible without violating the license

2) Possible case without license violation

3) 4) I’m not sure … I’m looking at the text of the exception, what OpenERP SA offers to the users with the Enterprise version is the right not to redistribute the source code to users over network, without any other restriction. That’s too close to the GPL to prevent opportunistic SaaS offers to appear, they would then just buy the Enterprise version … OpenERP SA needs to be much more explicit on this point, and explicitly specify that the exemption is void if access to ERP is paid in any way (I think of SaaS opportunistic offer as well as to a company that would charge an option to its clients for accessing their invoices on the ERP of the company, in this case the code must also be redistributed).

Moreover, there are two problems with the implementation of this license, I’ll just mention them quickly:

-There are still many people in the community, holding some copyright on the code of OpenERP, who refuse to allow the transition to the new license. In response OpenERP SA wants to rewrite their contribution which is obviously an insult. I find this regrettable, even if ultimately the idea seems good OpenERP SA wanted to push through and the result is climbing. OpenERP SA MUST NOT rewrite these contributions, they have tended to be too closed in on themselves which is not healthy for a free software (I have already sufficiently expressed my opinion on the fact OpenERP SA should make a much better use of the community contributions). I encourage everyone to talk responsibly about the subject, if there is a reluctance on the side of the community, suggest and ask for guarantees.

-Some community members have highlighted the fact that the modules AGPL is not compatible with AGPL + Exception. It would be obviously a huge problem, but my limited legal skills do not allow me to make more comments on the subject.

In conclusion, my opinion is that I support the new license, provided that the opportunistic SaaS offer is explicitly banned from the exception, and congratulations to OpenERP SA for finding this business model.

PS: I invite you to read this excellent post on the same subject: http://www.qmuxs.com/version2beta/2011/a-new-openerp-product-and-license/.

Mon point de vue sur le changement de licence d’OpenERP

Bonjour à tous,

Je vais aujourd’hui vous parler du sujet qui a embrasé la communauté depuis la semaine dernière : L’ajout d’une exception dans la licence AGPL d’OpenERP, permettant potentiellement d’éviter la redistribution du code source via l’achat d’une version Entreprise auprès d’OpenERP SA.

Alors comme tout le monde dans la communauté, sur le coup j’ai été scandalisé :

-On a la création d’une part d’une double licence, ce qui est notre pire frayeur : SugarCRM, Pentaho, Magento, etc… énormément de logiciels libres populaires aujourd’hui et à destination des entreprises ont également en parallèle une version entreprise ce qui implique que tous les efforts ne sont pas fait pour améliorer la version libre et souvent limiter même les efforts de la communauté. C’est l’une des principales forces d’OpenERP à l’heure actuelle que de ne pas être tombé dans ce travers et c’est une très, TRES mauvaise nouvelle que de la voir commencer à pointer le bout de son nez.
Alors ok on nous assure que cette version Entreprise n’a rien à voir avec les autres doubles licences, que l’ensemble des modules continuera à être licencié en AGPL, don’t act j’y reviens plus tard dans ce billet. Il n’empêche que le nom fait très peur.

-On nous parle également d’acheter contre espèce sonnantes et trébuchantes le droit de ne pas redistribuer le code source. Pas vraiment besoin d’être un adepte des théories du complot pour imaginer immédiatement des arrangements entre OpenERP SA et de grosses sociétés afin de faire des entorses aux garanties de la GPL et donc les garanties protégeant la communauté et les utilisateurs.

C’est ce qui nous vient immédiatement à l’esprit lorsque OpenERP SA a présenté sa nouvelle offre, et c’est pour cela que les débats ont été particulièrement virulent la semaine dernière à ce sujet. J’ai moi-même commencé à craindre qu’une partie importante de la communauté ne commence à se tourner vers Tryton.
Mais quand on analyse dans le détail l’offre, on se rend compte qu’elle n’est pas forcément si mal pensée que cela, pour comprendre où je veux en venir laissez moi rentrer dans le détail des licences *GPL.

La première licence *GPL, que je vais passer rapidement car elle n’a jamais été utilisée par OpenERP, et également la moins restrictive est la licence LGPL. Elle sert principalement quand la licence d’un logiciel a besoin d’être compatible avec du code propriétaire tout en pouvant néanmoins protéger par les garanties GPL le logiciel lui-même.

La licence GPL est la licence de base approuvée par la FSF et l’une des plus restrictive. Parfois trop au regard de certaines personnes, car vous ne pouvez utiliser un logiciel sous GPL avec du code propriétaire. Vous avez l’obligation de redistribuer le code source si vous faites une modification sur le logiciel, mais vous pouvez néanmoins créer une extension comme un module OpenERP sans avoir à le publier tant que vous l’utilisez de manière privée. OpenERP est resté longtemps en GPL V2 puis en GPL V3 quand cette version est sortie.

La licence GPL n’apportait néanmoins aucune garantie par rapport au SaaS. Vous pouviez par exemple prendre le code d’OpenERP, créer des modules utiles dont vous gardiez le code et proposer sur cette base un service SaaS payant sans avoir à publier le code source de vos modules. C’est ce que j’appelle une offre SaaS opportuniste, evidemment condamnable en regard de l’esprit du logiciel libre.
C’est pour palier à ce cas de figure que la FSF a créée la licence AGPL. Le principe est simple : vous pouvez demander le code source de tout logiciel que vous utiliser, même si celui-ci est utilisé à travers le réseau. Notez la différence de taille entre la GPL et la AGPL : Si on se place en contexte d’entreprise, cela signifie que même les employés ou les partenaires ayant un accès restreint sur l’ERP peuvent demander le code source de l’OpenERP de l’entreprise, y compris des modules développés spécifiquement pour elle et qu’elle utilise uniquement à titre privé.

OpenERP est sous licence AGPL depuis l’année dernière. C’était de toute évidence nécessaire pour éviter les offres SaaS opportunistes que j’ai évoqué et qui auraient pu apparaitre très rapidement. Imaginez vous prenez le code d’OpenERP, développez une verticalisation par exemple à destination des sociétés de services et vendiez le tout sans avoir à redistribuer votre verticalisation. J’imagine aisément comment ces opportunistes aurait pu apparaitre en quelques années sur le dos d’OpenERP donc c’était de tout évidence une nécessité.

Et donc maintenant OpenERP SA reçoit des demandes de la part d’entreprises souhaitant protéger leurs modules privés (qui peuvent souvent refléter une manière de travailler unique à l’entreprise et dont elle ne veut pas voir profiter sa concurrence). Ce sur quoi OpenERP SA répond aujourd’hui par l’exception de l’offre AGPL.
Cette exception dit que si l’entreprise cliente paye la version entreprise, elle peut ne pas donner le code source de ses modules privés à ses utilisateurs mais doit le donner si elle en distribue des copies (notamment si elle essaye de les revendre) qui reviennent alors immédiatement sous les termes classiques de la AGPL. Pour moi il ne s’agit ni plus ni moins que de vendre le droit d’utiliser la licence GPL plutôt que l’AGPL.

Et pour une fois je ne vais pas planter de couteau dans le dos à OpenERP SA : Je suis d’accord avec eux. Pour moi, les deux licences GPL et l’AGPL protègent les intérêts de la communauté, à la seule exception des offres SaaS opportunistes pour la GPL. Je ne vois aucun problème à autoriser les modules à usage privés dans les entreprises utilisatrices, c’est parfaitement dans l’esprit du logiciel libre, cela a été comme ça pendant toute la période GPL d’OpenERP et je dirait même que l’interdire purement et simplement comme le fait l’AGPL déservirait vraiment les intérêts d’OpenERP et de sa communauté.

Mais là où je trouve vraiment intéressant le choix d’OpenERP SA, c’est qu’ils ont réussi à trouver un modèle économique (le fait de faire payer les entreprises qui veulent protéger leurs méthodes de travail interne), égalitaire (c’est pas toutes les entreprises qui auront besoin d’une telle protection, et celles qui en ont besoin peuvent en payer le prix) et surtout dont la seule différence entre les utilisateurs payants et non-payants est… juste d’imposer une licence plus restrictive encore sur les garanties du logiciel libre, via l’imposition pour les utilisateurs non-payants de la licence AGPL. Des utilisateurs payants ayant un équivalent GPL protégeant déjà correctement les intérêts de la communauté et des utilisateurs non-payants dont la seule restriction est uniquement d’être obligé de publier le code source à ses employés et partenaires… C’est brillant, juste brillant.

Depuis mes débuts sur OpenERP, je craignais que OpenERP SA ne soit obligé finalement d’adopter une double licence pour arriver à survivre, je les ai vu pendant toute la période lutter pour arriver à trouver un business model viable mais respectueux de la communauté. Quand cette exception est arrivée, j’ai cru, comme beaucoup d’autres, qu’ils avaient surtout commencé à jeter l’éponge et à se diriger vers une double licence néanmoins finalement… il semble qu’au contraire ils aient bel et bien réussi à trouver le modèle économique qu’ils cherchaient! Personnellement je soutiens donc cette idée qui est selon moi incroyablement originale.

Étudions maintenant les différents cas de figure :

1)Le cas où une société peu scrupuleuse développe un module et tente ensuite de le vendre sans redistribuer librement le code source. Ce cas ne doit selon moi pas être possible sans violer l’esprit du logiciel libre.

2)Le cas où une société cliente veut développer un module à usage interne exclusivement. La société doit avoir la possibilité, de manière gratuite ou payante, de garder la pleine propriété intellectuelle du module y compris vis à vis de ses employés et partenaires. Ceci ne viole pas selon l’esprit du logiciel libre.

3)Le cas où une société cliente veut avoir accès à un module. Elle doit selon moi pour que soit respecté l’esprit du logiciel libre pouvoir accéder librement au code source de tous les modules développés par l’éditeur, par un intégrateur qui base ses services dessus et ceux utilisés dans une offre SaaS. Ils n’a pas forcément à avoir accès à un module utilisé uniquement en interne dans une autre société.

4)Le cas où une société peu scrupuleuse développe un module pour baser une offre SaaS dessus sans avoir à redistribuer librement le code source. Ce cas ne doit selon moi pas être possible sans violer l’esprit du logiciel libre.

OpenERP sous GPL :

1) Cas impossible sans violer la licence

2) Cas possible sans violation de licence

3) La société cliente n’a pas accès aux modules d’une offre SaaS peu scrupuleuse.

4) Cas possible sans violation de licence

OpenERP  sous AGPL

1) Cas impossible sans violer la licence

2) Cas impossible sans violer la licence

3) La société cliente a correctement accès à tous les modules.

4) Cas impossible sans violer la licence

OpenERP sous AGPL + exception. La société dont il est fait mention dans le cas a acheté la version entreprise.

1) Cas impossible sans violer la licence

2) Cas possible sans violation de licence

3)4) Je ne suis pas sûr… J’ai beau regarder le texte de l’exception, ce qu’OpenERP SA offre aux utilisateurs de la version Entreprise est le droit de ne pas redistribuer le code source aux utilisateurs, sans autre restriction. C’est bien trop proche de la GPL pour empêcher les offres SaaS opportunistes d’apparaitre, il leur suffirait alors juste d’acheter la version Entreprise… OpenERP SA a besoin d’être beaucoup plus explicite sur ce point, et indiquer explicitement que l’exception n’est plus valable si l’accès à l’ERP est payant d’une quelconque manière (Je pense aux offres SaaS opportuniste mais aussi à une société qui ferait payer par exemple une option à ses clients pour qu’ils accèdent à leurs factures sur l’ERP de la société, dans ce cas le code doit être également redistribué).

Qui plus est, il reste deux problèmes à la mise en place de cette licence que je vais juste évoquer rapidement :

-Il y a encore beaucoup de personnes dans la communauté, détentrice de copyright sur le code d’OpenERP, qui refusent d’autoriser le passage à la nouvelle licence. En réaction OpenERP SA veut réécrire leur contribution ce qui est évidemment une sacrée insulte. Je trouve cela infiniment regrettable, même si au final l’idée semble bonne OpenERP SA a voulu passer en force et résultat c’est l’escalade. OpenERP SA ne DOIT PAS réécrire ces contributions, ils ont déjà beaucoup trop tendance à être renfermé sur eux même ce qui n’est pas sain pour un logiciel libre (J’ai déjà suffisamment fait part de mon opinion sur le fait qu’OpenERP SA devrait faire un bien meilleur usage des contributions de la communauté). J’invite tout un chacun à discuter de manière responsable sur le sujet, si il y a des réticences du coté de la communauté, proposez et demandez des garanties.

-Certains membres de la communauté ont mis en avant le fait que les modules AGPL ne serait pas compatible avec l’AGPL+Exception. Ce serait évidement un considérable problème, mais mes compétences juridiques limitées ne me permettent pas de faire plus de commentaires sur le sujet.

En conclusion, mon avis est que je soutient la nouvelle licence, à condition que les offres SaaS opportunistes soit explicitement bannies de l’exception, et j’adresse mes félicitations à OpenERP SA pour avoir trouver ce business model.

PS : Pour les anglophones, je vous invite à lire cet excellent billet sur le même sujet : http://www.qmuxs.com/version2beta/2011/a-new-openerp-product-and-license/.

Update : Depuis l’article et suite principalement à l’insistance de la société Akretion, il semblerait que l’on commence à ce diriger vers la possibilité pour les contributeurs de vendre leur “version entreprise” de leur module : http://www.openerp.com/irc/%23openobject.2011-06-30.log.html#t2011-06-30T23:22:31 . C’est en train de devenir très interessant car du coup non seulement le modèle économique de la licence est interessant mais en plus toute la communauté pourra profiter des retombées économiques! Ceci pourrait potentiellement convaincre la communauté de changer la licence de leurs modules et donc régler ce problème d’incompatiblité.

Bravo et merci Raphael ;).