

Tuffy is an open-source Markov Logic Network inference engine - adulau
http://research.cs.wisc.edu/hazy/tuffy/

======
jwr
This is exactly what we need in our startup. We use Clojure, so Java is a
perfect fit. We would be able to contribute quite a bit, we have already done
some work in those areas. So — I was very happy while reading the description…

…until the "GPLv3" part.

People need to understand that a library project which is under GPLv2 or GPLv3
gets immediately rejected in most commercial settings. Note that I'm not
judging here — just stating a fact. We reject a lot of interesting options
because of licenses.

Of course, the authors of the library are free to choose whichever license
they like. But choosing invasive licenses such as the GPL means that they will
not benefit from our contributions and they will restrict the user base for
their libraries to experimenters and academics. Less users, less
contributions, less development, less popularity. Again, I'm not being
judgmental — I'm not saying it's necessarily a bad thing, I just want the
authors to be aware of this.

EDIT: I actually realized I need to write an article/blogpost about this, as
many people are unaware of how software gets rejected upfront in a commercial
setting because of the license. Will explain.

~~~
rbanffy
Let's just be clear that GPL software is commercial software. Even if it's
provided for free, it's still "commercial" in a sense that the author expects
something in exchange - fixes, improvements, bug reports, feature requests. In
order to be commercial, it's not required to involve financial transactions,
as barter is a form of commerce.

I also hate when people do the open-source/commercial dichotomy. Unlike
Canonical, Red Hat, Oracle, and others your business model may not be
compatible with charging for a product that's open-source, but that does not
preclude other businesses from using it. Companies like Amazon, Google,
Facebook, Twitter and Rackspace use GPLv3 software routinely in their
"commercial" settings.

I agree LGPL could be preferred for libraries, because it makes it easier to
use the software someone generously gave you in a closed product you can
profit without giving anything back to the generous souls that offered it to
you in the first place.

> Less users, less contributions, less development, less popularity.

I see how the *BSD vs Linux thing is going.

And, BTW, all you can't do is link to the library directly from less-free-
than-GPLv3 code. You would be perfectly fine writing a GPLv3 wrapper around
the library and call it via RPC from inside your closed-source product. You
then provide the source to your wrapper along with the product and you'll be
perfectly compliant.

~~~
jwr
> Companies like Amazon, Google, Facebook, Twitter and Rackspace use GPLv3
> software routinely in their "commercial" settings.

True. But they don't use GPL libraries as part of their strategic code base,
especially if that code base is then "distributed" to their clients.

I also use GPL software and I'm happy with it. Linux is a good example. But I
can't put my main software application under the GPL.

Don't box me as a "GPL-hater", because I'm not. I'm just providing a viewpoint
that library authors might not have considered.

~~~
rbanffy
Won't box you, jwr, but we have to agree that the only business model where
using GPL'ed libraries is the one where you link the GPL library as part of
your code and sell (or give away) the resulting program as closed source.
Google, Facebook, Oracle, even Microsoft are free to base their web properties
on GPL-ed code without any fear whatsoever someone will obtain their prized
source.

In this case, the simplest way to dodge the GPL would be to write a service
around the library and call it through an IPC mechanism. This way you can
distribute your private code along the GPL library, as long as you provide
code for your service layer. This is hardly an unsolvable problem.

