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