[Mulgara-dev] License Question.
Ian Boston
ian at caret.cam.ac.uk
Mon Oct 23 22:45:52 UTC 2006
I have read with horror the history of how Mulgara came into life, and I
believe that you have made the right decision. I am working as part of
the Opensource project, www.sakaiproject.org. We have some 60
Universities world wide contributing, and a handful of commercial
affiliates also contributing. We use an Apache style license... and now
the problem.
We want to use a highly scalable triple store, we thought Kowali with
its MPL license was suitable, but having seen the behavior of a certain
corps legal department, and the distinct lack of enthusiasm since then,
I'm not so certain that we should follow Kowari.
We have great difficulty using an opensource license with GPL like
statements (eg OSL-v3 clause 1c) since it would force the few commercial
affiliates to opensource all there code. The core community, with about
2M line of code has little interest in forcing them to do this, as, in
order to get support, they tend to do it anyway. (and if they dont, we
could change the API's :) under them. )
On the other hand I absolutely understand why Mulgara would want to make
certain that all commercial or other users of Mulgara opensource all
their code.
So my question,
Would it be acceptable to use the Driver code for Mulgara and obviously,
bind to that code....
and
1. continue to use an Apache style license
2. not require others who deploy the code bundle, containing those
bindings to opensource their code.
---------------------
When we have asked this same question of LGPL licensed code, in general,
the authors have confirmed that we are Ok to use their jars in this
form. We also deploy on MySQL, but the JDBC bindings to the MySQL
drivers are loose, so we can just ask deployers to download their own
jars. Presumably a similar loose binding would resolver the issue in the
case of Mulgara.
As you might have guessed, I'm not a lawyer (thankfully) but I dont want
to commit the development time if I'm going to find that a lawyer
prevents us from using Mulgara.
Thanks
Ian Boston
More information about the Mulgara-dev
mailing list