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. -- View this message in context: http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/... Sent from the Main discussion list for the graph-tool project mailing list archive at Nabble.com.
On 01.08.2015 19:34, monkeynut wrote:
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 -- Tiago de Paula Peixoto <tiago@skewed.de>
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 On Sun, Aug 2, 2015 at 12:59 PM, Tiago Peixoto [via Main discussion list for the graph-tool project] <ml-node+s982480n4026222h79@n3.nabble.com> wrote:
On 01.08.2015 19:34, monkeynut wrote:
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
-- Tiago de Paula Peixoto <[hidden email] <http:///user/SendEmail.jtp?type=node&node=4026222&i=0>>
_______________________________________________ graph-tool mailing list [hidden email] <http:///user/SendEmail.jtp?type=node&node=4026222&i=1> http://lists.skewed.de/mailman/listinfo/graph-tool
*signature.asc* (836 bytes) Download Attachment <http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/attachment/4026222/0/signature.asc> -- Tiago de Paula Peixoto <tiago@skewed.de>
------------------------------ If you reply to this email, your message will be added to the discussion below:
http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/... To unsubscribe from Please help with my licensing headache!, click here <http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4026221&code=dGltLmFuYWx5c3RAZ21haWwuY29tfDQwMjYyMjF8MTcyNTI2MzkzNQ==> . NAML <http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
-- View this message in context: http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/... Sent from the Main discussion list for the graph-tool project mailing list archive at Nabble.com.
On 03.08.2015 18:57, monkeynut wrote:
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?
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 -- Tiago de Paula Peixoto <tiago@skewed.de>
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 On Mon, Aug 3, 2015 at 7:14 PM, Tiago Peixoto [via Main discussion list for the graph-tool project] <ml-node+s982480n4026224h41@n3.nabble.com> wrote:
On 03.08.2015 18:57, monkeynut wrote:
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? 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
-- Tiago de Paula Peixoto <[hidden email] <http:///user/SendEmail.jtp?type=node&node=4026224&i=0>>
_______________________________________________ graph-tool mailing list [hidden email] <http:///user/SendEmail.jtp?type=node&node=4026224&i=1> http://lists.skewed.de/mailman/listinfo/graph-tool
*signature.asc* (836 bytes) Download Attachment <http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/attachment/4026224/0/signature.asc> -- Tiago de Paula Peixoto <tiago@skewed.de>
------------------------------ If you reply to this email, your message will be added to the discussion below:
http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/... To unsubscribe from Please help with my licensing headache!, click here <http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4026221&code=dGltLmFuYWx5c3RAZ21haWwuY29tfDQwMjYyMjF8MTcyNTI2MzkzNQ==> . NAML <http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
-- View this message in context: http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/... Sent from the Main discussion list for the graph-tool project mailing list archive at Nabble.com.
On 03.08.2015 20:20, monkeynut wrote:
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: https://github.com/erwinvaneijk/bgl-python ) Best, Tiago -- Tiago de Paula Peixoto <tiago@skewed.de>
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 On Mon, Aug 3, 2015 at 9:07 PM, Tiago Peixoto [via Main discussion list for the graph-tool project] <ml-node+s982480n4026226h3@n3.nabble.com> wrote:
On 03.08.2015 20:20, monkeynut wrote:
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: https://github.com/erwinvaneijk/bgl-python )
Best, Tiago
-- Tiago de Paula Peixoto <[hidden email] <http:///user/SendEmail.jtp?type=node&node=4026226&i=0>>
_______________________________________________ graph-tool mailing list [hidden email] <http:///user/SendEmail.jtp?type=node&node=4026226&i=1> http://lists.skewed.de/mailman/listinfo/graph-tool
*signature.asc* (836 bytes) Download Attachment <http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/attachment/4026226/0/signature.asc> -- Tiago de Paula Peixoto <tiago@skewed.de>
------------------------------ If you reply to this email, your message will be added to the discussion below:
http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/... To unsubscribe from Please help with my licensing headache!, click here <http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4026221&code=dGltLmFuYWx5c3RAZ21haWwuY29tfDQwMjYyMjF8MTcyNTI2MzkzNQ==> . NAML <http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
-- View this message in context: http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/... Sent from the Main discussion list for the graph-tool project mailing list archive at Nabble.com.
participants (2)
-
monkeynut -
Tiago de Paula Peixoto