3 ms·

Another Go SAT implementation (with an MIT license for those that can't use GPL): https://github.com/mitchellh/go-sat https://github.com/mitchellh/go-sat

jzelinskie 9y ago
There's also gps[0], which has been what the community has been working to integrate with dependency management tools since 2016[1] and is what's currently used in dep[2]. I'm not sure how generically applicable it is, though. [0]: https://github.com/sdboyer/gps https://github.com/sdboyer/gps [1]: https://github.com/Masterminds/glide/tree/gps-integration https://github.com/Masterminds/glide/tree/gps-integration [2]: https://github.com/golang/dep https://github.com/golang/dep
acidtrucks 9y ago
Is it common for companies to ban LGPL?
- Newtopian 9y ago
  for many companies the fitness criterion is locked in proportionality to how much money it costs... for them LGPL is to be avoided at all costs.
- ominous_prime 9y ago
  I think it's even more common with companies using Go, because the output is often statically linked which changes the distribution requirements. The main difference between GPL and LGPL is that the the latter allows proprietary or non-free software to be linked without creating a derivative work.
  - cyphar 9y ago
    > The main difference between GPL and LGPL is that the the latter allows proprietary or non-free software to be linked without creating a derivative work. That's not strictly correct. LGPL has the requirement that it must be possible to replace the components that are under LGPL. So you could statically link them as long as you provide separate .o files. Of course that's a bit harder with Go. But the concept of derivative work comes from copyright law, your choice of license doesn't affect whether something is a derived work or not. All that changes is the set of restrictions.
- petroseskinder 9y ago
  At least at the major companies I have worked at (n=3), GPL is to be avoided, if at all possible. LGPL, to a lesser extent. The general impression I received was that it was cancerous.

jzelinskie 9y ago

There's also gps[0], which has been what the community has been working to integrate with dependency management tools since 2016[1] and is what's currently used in dep[2]. I'm not sure how generically applicable it is, though. [0]: https://github.com/sdboyer/gps https://github.com/sdboyer/gps [1]: https://github.com/Masterminds/glide/tree/gps-integration https://github.com/Masterminds/glide/tree/gps-integration [2]: https://github.com/golang/dep https://github.com/golang/dep

acidtrucks 9y ago

Is it common for companies to ban LGPL?

Newtopian 9y ago
for many companies the fitness criterion is locked in proportionality to how much money it costs... for them LGPL is to be avoided at all costs.
ominous_prime 9y ago
I think it's even more common with companies using Go, because the output is often statically linked which changes the distribution requirements. The main difference between GPL and LGPL is that the the latter allows proprietary or non-free software to be linked without creating a derivative work.
- cyphar 9y ago
  > The main difference between GPL and LGPL is that the the latter allows proprietary or non-free software to be linked without creating a derivative work. That's not strictly correct. LGPL has the requirement that it must be possible to replace the components that are under LGPL. So you could statically link them as long as you provide separate .o files. Of course that's a bit harder with Go. But the concept of derivative work comes from copyright law, your choice of license doesn't affect whether something is a derived work or not. All that changes is the set of restrictions.
petroseskinder 9y ago
At least at the major companies I have worked at (n=3), GPL is to be avoided, if at all possible. LGPL, to a lesser extent. The general impression I received was that it was cancerous.