Please help with my licensing headache!

graph-tool
1

I have been working on a toolkit for network security analysis. I intended to
license it with a BSD license, but I ideally want the freedom to change the
license in future versions as I see fit.

So far all the dependencies have been BSD, MIT, or Boost license so I have
not really had any concerns. However, for performance reasons I need to
switch out of using networkx and graph-tool seems extremely attractive
(great quality, API, openmp use etc.). I originally chose Networkx over
graph-tool purely for the liberal license and not having to spend much
effort on license considerations.

The toolkit itself has (currently) 11 major components which can be
theoretically self-standing but are particularly useful together (do they
count as one, can they have seperate licenses?). Two of these components
require the use of a graph library.

I have now spent weeks reading the FSF, GPLv3, BSD, Boost etc. license pages
and guides and all sorts of stuff. Plenty of (people claiming to be) lawyers
who all disagree about what to do and where I stand (most of it involving
disagreements about derivative works). I would love to just get back to
design and development, something I'm actually good at!

The obvious solution would be just to GPL everything but given the amount of
pain the draconian and anti-liberal GPLv3 has given me, I don't want to
inflict that on anyone else in the future if possible. Additionally, there
are a number of people I would like to work with who would be unable due to
contractual contraints to risk using my project if it were GPL.

Has anybody had a similar situation and how have you resolved it? Can
anybody help? Tiago, if you could give me any advice about your intentions
behind choosing GPLv3 over e.g. LGPL and how my project relates to that (is
this something we should discuss off-line)?

Thanks in advance for any help.

2

I have now spent weeks reading the FSF, GPLv3, BSD, Boost etc. license pages
and guides and all sorts of stuff. Plenty of (people claiming to be) lawyers
who all disagree about what to do and where I stand (most of it involving
disagreements about derivative works). I would love to just get back to
design and development, something I'm actually good at!

The standard interpretation is that derivations (including software that
uses the library) must be released under the same license, or a
compatible one. In the case of graph-tool, that would be the GPLv3 or
any later version.

The obvious solution would be just to GPL everything but given the amount of
pain the draconian and anti-liberal GPLv3 has given me, I don't want to
inflict that on anyone else in the future if possible. Additionally, there
are a number of people I would like to work with who would be unable due to
contractual contraints to risk using my project if it were GPL.

It only inflicts pain if you (or others) desire or leave open the
possibility of using it as part of proprietary code. It is pretty much
the whole point of the GPL to make this impossible, or at least very
difficult.

Has anybody had a similar situation and how have you resolved it? Can
anybody help? Tiago, if you could give me any advice about your intentions
behind choosing GPLv3 over e.g. LGPL and how my project relates to that (is
this something we should discuss off-line)?

My choice for using the GPL is the same, I presume, than anyone else
that leans towards copyleft. I want don't want anyone to be restricted
to use or modify the library or any variations by any third party.

If you are free to choose your own licence, using anything else means
you don't care about further restrictions being imposed.

The LGPL makes an exception for just linking (importing) the library,
which can make strategic sense in some cases, but I judged it not to be
the case for graph-tool.

Best,
Tiago

3

Hi Tiago,

Thanks for the quick response.

I see what you are saying and why you chose the GPL. I suppose its just
frustrating to have to re-think (or even think much about!) licensing when
it hasn't been an issue for the bulk of my work.

The bits where I need the much better (and distributed) performance from
your library is a graph generation/storage and analysis service.
It holds a bunch of graphs, quantifies topology on them, and identifies
interesting groups of nodes/edges, returning the results via JSON (the
analysis component needs to be able to run on a different machine from
other bits of it - inputs are also JSON based API). Basically a generic
"graph stuff" network service which implements the bits I need for the rest
of the project.

From what I understand I can keep the original networkx version of this

service and also develop a graph-tool version, the former staying with a
BSD license and the latter having a GPL license.
However, one of my friends said that many would see that as "cheating" but
it seems to be an intentional provision of the GPLv3 as far as I
understand.

How would you view that scenario? Would you be OK with it or would you be
upset/feel violated? Would your position change if I couldn't keep up
maintaining both versions?

FYI I'm not a developer for any company, infact I'm not even a developer by
trade (ex. pentester now security architect).

Cheers,
Tim

attachment.html (7.18 KB)

4

There is nothing for me to feel violated about if you follow the terms
of the license. If you develop a piece of software that does not use
graph-tool in any way, there is absolutely no claim I can make. If you
decide to make a version that uses graph-tool, it needs to follow the
GPL. It is really very simple.

It seems like a headache to develop two versions of your platform. To
do so only in order to avoid the GPL seems really strange, in my
opinion. I know it is annoying to think about licensing, but think a bit
about this decision: You're going through the trouble of developing two
alternative versions of your code, just so that someone down the line
can avoid the terms of the GPL, i.e. turn it into proprietary code. Why
would you do that?

But it is up to you, of course.

Best,
Tiago

5

Hi Tiago,

Thanks again for the response.

I originally arrived at graph-tool because I was thinking about making a
wrapper around boost graph library for the functionality I need and found
that you already did that quite some time ago (and its mature, bug fixed,
and usable).

I wouldn't be maintaining two versions of the whole platform, only of the
graph analysis service (but yes, it still sounds like a headache!)

Since you asked "why would I do that?", I thought I'd explain myself a bit,
in-case you're curious or maybe have a different perspective you'd like to
share:

( TL;DR - As the only person I know of who has written a python wrapper for
BGL, would you be able to give me a few words about how 'hard' it is? Was
this a fairly trivial part of graph-tool or a pretty huge part of the work?
If I only need a few of the algorithms will this make much difference to
the overall effort? )

I wanted to go with a BSD license (among other reasons) because I believe
it paradoxically protects my project from being ripped off better than the
GPL would.
The system is a functional PoC for several interesting brand new ways of
analysing the security of system architectures, which I hope will live on
as a proper tool my colleagues will use and enjoy.
If my code is GPL then proprietary companies will, if use becomes
widespread, take the ideas and re-implement them (being unable and/or
unwilling to contribute back).
If my code has a BSD license then it would be more economical (and legally
feasible) for them to work off my code base and contribute improvements
back as they integrate it with their products/appliances etc.
Therefore I think if I use the GPL the ideas will flourish but my project
will become a footnote in the history of that, whereas if I use BSD license
I think it would live long and prosper. I think the Boost guys went with
BSD style license instead of GPL style license because it gave them the
best chance at being the de-facto libs for the things it covers. For
example, you certainly found it useful to be able to choose your own
license, and I suppose may not have used Boost graph libs if their license
terms forced you to use Boost's own license (as you want a GPL style
license).

Ideally my project could receive the support of proprietary vendors as well
as the public community, as I think this gives it the best chance.
* Metasploit had a BSD license and when bought by Rapid7 the source remains
open and the community very active (although there is an extra closed
source component - pro version). A pentester can still use everything they
need for free.
* Nessus had a GPL license and when bought by Tennable they closed the
whole thing and the community died, A pentester can't get any functionality
from it without a very expensive license.
* Nipper was written by one of my friends/colleagues and released under
GPLv3. Most of the security community use it to analyse firewalls but
no-one contributed code or even money for new devices so he can support
them etc. (even though a huge amount of money was being made by using it).
Because of this he had the choice of either stagnating the project or
turning it into a company, which is now very successful and all the
developments he dreamed of are being done. I believe he would have had more
code support and therefore perhaps have stayed open if he had originally
released with a BSD license, but no-one really knows what alternative
histories would have looked like.

I will have to think a bit more about this. Its quite likely that in future
I'd want to share datastructures with the graph service in future, or even
expose a direct API whereupon the GPL might start to 'infect' the rest of
the project.
Given what we have discussed I therefore have to decide between 3 options:
1. Don't worry about all the above thoughts, just go ahead and GPL the lot
so as to go back to not worrying about which components have which license
2. Do worry about the above, maintain two versions of the graph service
with different licenses, hope future architectural decisions don't land me
in the GPL trap.
3. Do worry about the above, write my own BGL wrapper and hope its not too
hard to make/maintain, but still retain ability to choose the license for
all my code (and not worry about which bits have which license).

As the only person I know of who has written a python wrapper for BGL,
would you be able to give me a few words about how 'hard' it is? Was this a
fairly trivial part of graph-tool or a pretty huge part of the work?

Thanks very much for your time,

Tim

attachment.html (9.77 KB)

6

If my code is GPL then proprietary companies will, if use becomes
widespread, take the ideas and re-implement them (being unable and/or
unwilling to contribute back). If my code has a BSD license then it
would be more economical (and legally feasible) for them to work off
my code base and contribute improvements back as they integrate it
with their products/appliances etc.

It would be economical and legally feasible for them only if they
intended to make proprietary code... I would prefer _not_ to make it
economical and legally feasible for them.

Therefore I think if I use the GPL the ideas will flourish but my
project will become a footnote in the history of that, whereas if I
use BSD license I think it would live long and prosper. I think the
Boost guys went with BSD style license instead of GPL style license
because it gave them the best chance at being the de-facto libs for
the things it covers. For example, you certainly found it useful to be
able to choose your own license, and I suppose may not have used Boost
graph libs if their license terms forced you to use Boost's own
license (as you want a GPL style license).

You are judging the success of your project solely on weather or not it
is used by other people, lives long and so on. Of course that is an
important part of it, but it is also important to consider the freedom
people have with it. There are many very "successful" scientific
programs out there, like Mathematica, that I think do a lot more harm
than good. Of course, a BSD program is not quite like that, but it can
become as soon as derivatives become proprietary.

In any case, this is the very old debate of copyleft vs noncopyleft, and
maybe it is not useful to rehash things here. I guess you and I have
simply different priorities.

As the only person I know of who has written a python wrapper for BGL,
would you be able to give me a few words about how 'hard' it is? Was
this a fairly trivial part of graph-tool or a pretty huge part of the
work?

It depends a lot. The BGL is a template library, so it is quite
versatile, and cannot be directly bound to python. Usually you have to
settle for a specific graph data structure and bind the specific
template instantiations for it. In graph-tool I wanted to keep some of
the versatility, so I compile several different instantiations that are
chosen at run time. This improves performance, but adds complexity.

(There is also an unmaintained, deprecated but "official" python
bindings for BGL: GitHub - erwinvaneijk/bgl-python: Boost Graph Library - Python interface. This is the repository with the imported repository from Douglas Gregor )

Best,
Tiago

7

Hi Tiago,

If only all license debates could be so reasonable.

Thanks so much for the advice on implementing python bindings for BGL.

I've seen the bgl-python before but I kind of wrote it off as it was last
updated 5 years ago and talks of python 2.3.
However, you raise a good point that if I'm going to do this perhaps
resurrecting or at least borrowing code from that module would probably
save me some time!

I'm quite curios about that now so I might try that route first. But if it
is too time-consuming I think I will go back to graph-tool.

Thanks again,
Tim

attachment.html (7.21 KB)