Hi Contributors, I'd like to open a discussion about a licence change. I've been thinking for a while to open up the licence more. Currently the code is GPL which allows end-users (including commercial companies using XWiki internally or for their web sites) to use XWiki without being required to contribute code back, but requires software distributors to contribute all modifications using the GPL. Until version 0.9.543 there was only code from myself in it which allowed me to double licence code, which has been done with one company in the US who has embedded XWiki in a proprietary product. Starting with release 0.9.793, XWiki has significant contributions from other users which if we want to be able to allow this company or others in the future to use XWiki in compliance with the open-source licence we need to: 1/ Either get the right from ALL contributors to allow XPertNet to double-licence the contributions for proprietary usage and charge for it as well as support. 2/ Open up the licence to a licence which would allow them to do it without a double licence. This licence could be LGPL or ASL. Customers could still take a support contract with XPertNet. I'd like to hear the opinions of everybody and of course especially of contributors who have commited code to XWiki. Which route should be go from your point of view and are you willing to relicence your code to any of the licence proposed (giving the right to double licence, changing licence to LGPL or changing licence to ASL). This question is also true for Jens who has contributed the Lucene plugin and the email notification plugin but to a lesser extent as these are plugins and could keep a separate licence. It would just restrict specific usage of these specific plugins. Whatever we decide, we will need to create some documents that contributors would sign to specifically accept the conditions under with the contributions are made to the code base. Ludovic -- Ludovic Dubost XPertNet: http://www.xpertnet.fr/ Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost AIM: nvludo Yahoo: ludovic
I am interested to hear other people's thoughts about this. I have been considering embedding xwiki in an app, however I was a little concerned about the GPL license - I would prefer an ASL (presuming that this means apache software license). I'd then also be happy to help contribute on this project. It seems to have a great feature set and it uses technologies that I am familiar with. Cameron
-----Original Message----- From: Ludovic Dubost [mailto:[email protected]] Sent: Thursday, 2 June 2005 7:12 AM To: [email protected] Subject: [xwiki-dev] Considering a licence change
Hi Contributors,
I'd like to open a discussion about a licence change. I've been thinking for a while to open up the licence more.
Currently the code is GPL which allows end-users (including commercial companies using XWiki internally or for their web sites) to use XWiki without being required to contribute code back, but requires software distributors to contribute all modifications using the GPL.
Until version 0.9.543 there was only code from myself in it which allowed me to double licence code, which has been done with one company in the US who has embedded XWiki in a proprietary product.
Starting with release 0.9.793, XWiki has significant contributions from other users which if we want to be able to allow this company or others in the future to use XWiki in compliance with the open-source licence we need to:
1/ Either get the right from ALL contributors to allow XPertNet to double-licence the contributions for proprietary usage and charge for it as well as support. 2/ Open up the licence to a licence which would allow them to do it without a double licence. This licence could be LGPL or ASL. Customers could still take a support contract with XPertNet.
I'd like to hear the opinions of everybody and of course especially of contributors who have commited code to XWiki. Which route should be go from your point of view and are you willing to relicence your code to any of the licence proposed (giving the right to double licence, changing licence to LGPL or changing licence to ASL).
This question is also true for Jens who has contributed the Lucene plugin and the email notification plugin but to a lesser extent as these are plugins and could keep a separate licence. It would just restrict specific usage of these specific plugins.
Whatever we decide, we will need to create some documents that contributors would sign to specifically accept the conditions under with the contributions are made to the code base.
Ludovic
-- Ludovic Dubost XPertNet: http://www.xpertnet.fr/ Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost AIM: nvludo Yahoo: ludovic
That's a difficult question. 1) As XWiki uses several library, I'm not sure that it really make sense to offer dual license. As I don't know the license used for these library (hibernate, etc) I can't have an idea about that. 2) Switching to ASL ou LGPL license would be better if you want XWiki to spread (as Cameron said), it would make it harder for XPernet to make money out of XWiki. So it's difficult balance. Whatever your decision, my contribution is so small that I'll agree with it.
This is a real issue especially from what I understand in the context of some of the complex consortiums doing European RTD projects. I have been told it commes up in every project (open v.s. closed source) so it would be interesting to have a license that facilitates choosing XWiki as a technology base. My understanding from reading some of Marc Fleury's writing is that LGPL is the license that offers the best balance between our needs as an open source business and its community, and removing barriers to adoption in a context that is sensitive to intellectual property rights. On 6/1/05, Ludovic Dubost <[email protected]> wrote:
Hi Contributors,
I'd like to open a discussion about a licence change. I've been thinking for a while to open up the licence more.
etc... -- Luis Arias http://www.xwiki.com http://www.innover-entreprendre.net +33 6 14 20 87 93 mobile
On Wed, Jun 01, 2005 at 11:12:23PM +0200, Ludovic Dubost wrote:
Hi Contributors,
I'd like to open a discussion about a licence change. I've been thinking for a while to open up the licence more.
[..]
1/ Either get the right from ALL contributors to allow XPertNet to double-licence the contributions for proprietary usage and charge for it as well as support.
This could prove as a show stopper when it comes to attracting new developers - imho nobody really wants to sign such an agreement for just submitting a patch. drastically said, this double licensing could look from a committers point of view like this: 'they make money by selling my code to closed-source producing companies which don't want to give anything back to the project'. A developer who wants his code being used in commercial software usually won't choose "GPL+giving expertnet the right to release his code under other licenses", but choose a commercial-friendly license like ASL right from the start. On the other hand, when there is a number of developers interested in the project, who like the GPL but not the dual licensing option, it could lead to a fork into a GPL-only branch and a dual licenseable branch, which imho is not desirable. Imho the better way to make money of such a project is getting paid for new features and support/hosting. Selling software licenses is what companies like the one from Redmond, USA, do, and usually is considered a bad practice ;-) Besides that, I think that XWiki is more a product than a library, and I can't imagine that many cases where a company will pay for being allowed to embed XWiki into their own product. In most cases, people will simply use XWiki for themselves, customized to fit their needs or not, which already is permitted by GPL. But maybe I underestimate the possibilities in this sector. You get the point, I'm no fan of the dual licensing option.
2/ Open up the licence to a licence which would allow them to do it without a double licence. This licence could be LGPL or ASL. Customers could still take a support contract with XPertNet.
LGPL is problematic, as there is often doubt about where the line between allowed use and license violation is drawn. In my company, if we have the choice, we always choose ASL'd libs over LGPL'd ones, just to be on the safe side. So if you really want to open up the license, I'd vote for ASL. On the other hand, there is still option 3/: Don't dual license any more and let XWiki stay GPL, which solves the problem of handling contributions, too. Not really an opening in terms of licensing, though... [..]
This question is also true for Jens who has contributed the Lucene plugin and the email notification plugin but to a lesser extent as these are plugins and could keep a separate licence. It would just restrict specific usage of these specific plugins.
right, but it would be nicer to have the whole code share the same license. In my understanding they have to stay GPL'd as long as XWiki is GPL'd, since I'm extending XWiki base classes in the plugins. Greetings from germany, Jens -- Jens Krämer [email protected]
Jens Kraemer a écrit :
1/ Either get the right from ALL contributors to allow XPertNet to double-licence the contributions for proprietary usage and charge for it as well as support.
This could prove as a show stopper when it comes to attracting new developers - imho nobody really wants to sign such an agreement for just submitting a patch.
I agree.. this is the main reason we want to change the licence..
drastically said, this double licensing could look from a committers point of view like this: 'they make money by selling my code to closed-source producing companies which don't want to give anything back
Well the real thing is a little different.. The reality is more that we want to protect the OSS project from hijacking by people making money with it and not give back to the project. But at the same time we would like these people to be able to use and contribute to XWiki. With a non dual licencable GPL, the customers just cannot do that. When they pay to get the right to do it, at least we force them to give something back if not code. At least the money can go back some way or another to the project. It's true that XPertNet does not necessarly put it back in the project but at least from the community standpoint there is a better chance that we do than that proprietary companies do.
to the project'. A developer who wants his code being used in commercial software usually won't choose "GPL+giving expertnet the right to release his code under other licenses", but choose a commercial-friendly license like ASL right from the start.
Yes..this is true.. There is a good chance they will prefer a commercial friendly licence.. Now we did sold a dual licence already ! Now there is a good possibility we could have sold a support contract too as we did some support work. We can also have a proactive approach at selling to commercial vendors.. This would allow to fund full time people in the team to manage the community and work on XWiki. With a very open licence, proactive approach to selling is quite risky as it can lead to convince the people that XWiki is good for them and lead to no actual sale since they can do it for free.. With a very open licence we would probably use the same strategy as with the non commercial users which is to wait until they have a need and want support and services.
On the other hand, when there is a number of developers interested in the project, who like the GPL but not the dual licensing option, it could lead to a fork into a GPL-only branch and a dual licenseable branch, which imho is not desirable.
Agreed and we don't want this to happen.
Imho the better way to make money of such a project is getting paid for new features and support/hosting. Selling software licenses is what companies like the one from Redmond, USA, do, and usually is considered a bad practice ;-)
We agree.. this is our main priority and is why we are considering licence change.
Besides that, I think that XWiki is more a product than a library, and I can't imagine that many cases where a company will pay for being allowed to embed XWiki into their own product. In most cases, people will simply use XWiki for themselves, customized to fit their needs or not, which already is permitted by GPL. But maybe I underestimate the possibilities in this sector.
I think you do ;-) We already have another project where XWiki is embedded to do something that's not really a wiki.. Now there is another issue with the GPL (I'll talk about it later).
You get the point, I'm no fan of the dual licensing option.
Got the point
2/ Open up the licence to a licence which would allow them to do it without a double licence. This licence could be LGPL or ASL. Customers could still take a support contract with XPertNet.
LGPL is problematic, as there is often doubt about where the line between allowed use and license violation is drawn. In my company, if we have the choice, we always choose ASL'd libs over LGPL'd ones, just to be on the safe side.
Now we could clearly state where the line is.. Embedding is allowed.. Modifications to the code inside the libraries need to be contributed.. Nothing around it needs to be contributed..
So if you really want to open up the license, I'd vote for ASL.
Now ASL has one issue with LGPL also has: people can use it and make money easily without contributing their plugins and stuff.. But ASL has one more issue.. People can steal any bit of code.. enhance it and not give back the enhancements.. For example: JotSpot could take our PDF export code, improve it.. embed it in JotSpot.. Distribute it and not give it back.. With LGPL they would have to give it back if they ship it in the JotBox (they don't for the JotSpot.com service). Proprietary vendors getting the benefit of their code, having a better product with their own R&D and not share that be us is annoying.. Even more when their our competitors for us and for our community.. JotSpot does compete with us for developers of applications.. The whole community of XWiki users benefits from having as many application developers as possible on XWiki... Another example would be true for the Lucene plugin.. Let's say a proprietary competitor like the lucene plugin implementation and takes the code, modifies it and uses it for their own wiki.. and they don't have to give anything back, even if they fix bugs on the way..
On the other hand, there is still option 3/: Don't dual license any more and let XWiki stay GPL, which solves the problem of handling contributions, too. Not really an opening in terms of licensing, though...
Now we come to the issue that the GPL has.. One issue is the dual licensing.. We could say we don't care and we don't care of proprietary vendors.. That they just can't use XWiki if they don't comply with the license.. Now the problem is that we will have this issue with users also.. We just had this issue with a customer who has taken a support contract and paid for some additional features in XWiki. This client (very big European company) has clearly asked that we guarantee that we have the rights to give them the possibility to make any usage of XWiki, including shipping it to their subsidiaries or even in a product of theirs.. The product in question could be a very big plane.. Not that they plan to embed XWiki in this plane, but they want to keep all options open just in case they think it is a good idea. Now they don't necessarly ask that it be for free.. but they ask that they can do it without having to give back the rest of the stuff they have linked to it as GPL. The interesting thing is that the person i had on the phone told me that the problem already happened with a contracted using GPL stuff in solutions this contractor built for them.. Now it looks a bit extreme, but the reality is that we could spend days discussing a support contract and just the fact that they want to keep the options open would make the deal fail.. This is way too stupid.. So for me I'm quite convinced that it's not worth getting this problems. I believe in the hyperdistribution of software as open source dans that in the end we will be able to maintain our team. I also believe our community is getting strong enough to not be hijacked by others and especially commercial companies.
This question is also true for Jens who has contributed the Lucene plugin and the email notification plugin but to a lesser extent as these are plugins and could keep a separate licence. It would just restrict specific usage of these specific plugins.
right, but it would be nicer to have the whole code share the same license. In my understanding they have to stay GPL'd as long as XWiki is GPL'd, since I'm extending XWiki base classes in the plugins.
I don't have this understanding.. For me you are not shipping any code of XWiki in your plugin.. Extending a class is not "linking".. Now I agree that it's better to share the same licence.. So would you be willing to relicence in LGPL or ASL if we change the XWiki code licence. In the end I tend to lean towards the LGPL with a clear message saying that embedding is clearly not a problem. That you can write your own proprietary plugins or extensions.. The only restriction is that if you take code from the LGPL packages then you have to contribute your modifications as LGPL too.. We could also double licence GPL/LGPL. I'd be happy to know what the community feels about potential proprietary competitors getting the benefits of some code of XWiki without giving back.. Ludovic -- Ludovic Dubost XPertNet: http://www.xpertnet.fr/ Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost AIM: nvludo Yahoo: ludovic
This question is also true for Jens who has contributed the Lucene plugin and the email notification plugin but to a lesser extent as these are plugins and could keep a separate licence. It would just restrict specific usage of these specific plugins.
right, but it would be nicer to have the whole code share the same license. In my understanding they have to stay GPL'd as long as XWiki is GPL'd, since I'm extending XWiki base classes in the plugins.
I don't have this understanding.. For me you are not shipping any code of XWiki in your plugin.. Extending a class is not "linking".. Now I agree that it's better to share the same licence.. So would you be willing to relicence in LGPL or ASL if we change the XWiki code licence.
In the end I tend to lean towards the LGPL with a clear message saying that embedding is clearly not a problem. That you can write your own proprietary plugins or extensions.. The only restriction is that if you take code from the LGPL packages then you have to contribute your modifications as LGPL too..
We could also double licence GPL/LGPL. I'd be happy to know what the community feels about potential proprietary competitors getting the benefits of some code of XWiki without giving back..
[Cameron Braid] I totally agree here. This sounds like a good option. I would be happy with a LGPL license that states that I can embed xwiki in a commercial/closed source app. I also think it is a good idea to require contribution of modifications to the code inside the libraries. Anyway, I'm just making these comments since I am considering embedding xwiki in an app (or more).
Ludovic
-- Ludovic Dubost XPertNet: http://www.xpertnet.fr/ Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost AIM: nvludo Yahoo: ludovic
participants (5)
-
Alexis KARTMANN -
Cameron Braid -
Jens Kraemer -
Ludovic Dubost -
Luis Arias