2 ms·

It seems entirely nonsensical not to allow LGPL for library code, since it does not add any restrictions compared to BSD/MIT/etc. You should advise your users b

It seems entirely nonsensical not to allow LGPL for library code, since it does not add any restrictions compared to BSD/MIT/etc. You should advise your users better in this regard, since they seem to not understand how these licenses work.

lmeyerov 3y ago
LGPL is understood to incur stipulations in scenarios like static linking, which for a dev library, can be a concern. These concerns are not in MIT/BSD/Apache, which is why professional organizations often have rules allowing only the latter. It takes undesirable work by developers to go against their organizational guidelines. My job isn't to advise users on legal matters nor promote graph-tool, though I do try to increase awareness of options in general as a neutral technical party. The graph-tool's community's decision to use & stick to a relatively unpopular license (outside of academia), and the ensuing issues around legal, practical, and perception... are problems for the graph-tool community to address, not me. We OSS our work as MIT/BSD/Apache because that's what our users accept and pay us to do. That's all that's in our control.
- eoverride 3y ago
  Python libraries cannot be statically linked. This has nothing to do with promoting graph-tool, but not promoting disinformation, as you have been doing. This is shameful FUD against LGPL based on blatant nonsense. If organizations have rules that don't make sense, the problem is with those rules. Spreading this kind of misleading narrative is damaging to the community as a whole. Lost a lot of respect for Graphistry during this interchange.
  - lmeyerov 3y ago
    I'm confused. There was a surprise that LGPL was not seen as equiv as MIT/BSD/Apache by orgs, so I clarified with the typical example of why organizations may have default-deny rules for LGPL libraries bc the static linking restrictions, and that those default-deny rules would require devs in these orgs to get an exception. You made me curious, and this thread was enlightening to me: https://www.quora.com/Can-I-use-LGPL-in-commercial-software https://www.quora.com/Can-I-use-LGPL-in-commercial-software . Note the political & bureaucratic work that'd be involved to get a licensing exception, and then the extra SW infra work to do the above. Again, I try to keep our team technical & neutral about graph DB/lib/etc providers. We get used with a variety of tools, and I personally end up seeing areas where each invests more than others + try to keep discussions to the resulting kind of objective distinction. So I'm genuinely curious what's wrong in my summary, both wrt legal theory and what organizations do in practice. I get frustrated when projects we get pulled into (digital crime, outages, genomics, ...) get hamstrung by something like OSS licensing.

lmeyerov 3y ago

LGPL is understood to incur stipulations in scenarios like static linking, which for a dev library, can be a concern. These concerns are not in MIT/BSD/Apache, which is why professional organizations often have rules allowing only the latter. It takes undesirable work by developers to go against their organizational guidelines. My job isn't to advise users on legal matters nor promote graph-tool, though I do try to increase awareness of options in general as a neutral technical party. The graph-tool's community's decision to use & stick to a relatively unpopular license (outside of academia), and the ensuing issues around legal, practical, and perception... are problems for the graph-tool community to address, not me. We OSS our work as MIT/BSD/Apache because that's what our users accept and pay us to do. That's all that's in our control.

eoverride 3y ago
Python libraries cannot be statically linked. This has nothing to do with promoting graph-tool, but not promoting disinformation, as you have been doing. This is shameful FUD against LGPL based on blatant nonsense. If organizations have rules that don't make sense, the problem is with those rules. Spreading this kind of misleading narrative is damaging to the community as a whole. Lost a lot of respect for Graphistry during this interchange.
- lmeyerov 3y ago
  I'm confused. There was a surprise that LGPL was not seen as equiv as MIT/BSD/Apache by orgs, so I clarified with the typical example of why organizations may have default-deny rules for LGPL libraries bc the static linking restrictions, and that those default-deny rules would require devs in these orgs to get an exception. You made me curious, and this thread was enlightening to me: https://www.quora.com/Can-I-use-LGPL-in-commercial-software https://www.quora.com/Can-I-use-LGPL-in-commercial-software . Note the political & bureaucratic work that'd be involved to get a licensing exception, and then the extra SW infra work to do the above. Again, I try to keep our team technical & neutral about graph DB/lib/etc providers. We get used with a variety of tools, and I personally end up seeing areas where each invests more than others + try to keep discussions to the resulting kind of objective distinction. So I'm genuinely curious what's wrong in my summary, both wrt legal theory and what organizations do in practice. I get frustrated when projects we get pulled into (digital crime, outages, genomics, ...) get hamstrung by something like OSS licensing.