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