MIT Licensed code in LD_PRELOAD?

2021-06-21 Thread Marc Haber
Hi, I am planning to package a small bit of code that is MIT licensed and is intended to be used via LD_PRELOAD to overload and inflience the bind() syscall regarding source address selection. Is the MIT License sufficiently compatible to the (L)GPL to allow this use? The code interfaces both wit

Re: MIT Licensed code in LD_PRELOAD?

2021-06-21 Thread Sam Hartman
> "Marc" == Marc Haber writes: Marc> Is the MIT License sufficiently compatible to the (L)GPL to Marc> allow this use? The code interfaces both with the (arbitrary) Marc> application issueing the bind() call and the glibc. Is that a Marc> linking issue? I believe MIT should b

Re: MIT Licensed code in LD_PRELOAD?

2021-06-21 Thread Francesco Poli
On Mon, 21 Jun 2021 10:10:57 +0200 Marc Haber wrote: [...] > Is the MIT License sufficiently compatible to the (L)GPL to allow this > use? I assume that, by MIT, you mean the [Expat] license. [Expat]: As far as I can tell, the [Expat] license is basically

Re: Declaring license for autogenerated file (W3C)

2021-06-21 Thread Diego M. Rodriguez
Hi Paul and Michael, On 6/19/21 3:45 AM, Paul Wise wrote: > The upstream source (from GitHub in your case) should always be > preferred over the downstream packaging (on PyPI in your case). > Missing files, generated files, extra cruft and other things are > common problems with the downstream red

Re: MIT Licensed code in LD_PRELOAD?

2021-06-21 Thread Ole Streicher
Marc Haber writes: > I am planning to package a small bit of code that is MIT licensed and is > intended to be used via LD_PRELOAD to overload and inflience the bind() > syscall regarding source address selection. > > Is the MIT License sufficiently compatible to the (L)GPL to allow this > use? Th