undefined | Better HN

0 pointskbumsik5y ago0 comments

In this case I interpret LGPL as "Please don't maintain your own fork (with bugfixs) in your company internally, contribute to my repo directly", which make sense.

0 comments

DTolm5y ago

This was indeed what I was thinking in the first place, when I made VkFFT - your project doesn't have to be open-source, but please share your modifications to VkFFT. I think about switching it to MPL 2.0, is this one better for everybody?

Reelin5y ago

Yes, I believe the MPL fits the usecase you describe.

As far as I understand it, proprietary code using an LGPL licensed library is more or less incompatible with templates in header files (!!!) since there's no way (AFAIK?) to relink against a modified version without providing your full source code. Supposedly the LGPLv3 provides an exception for header files but personally I wouldn't go anywhere near it because it seems quite vague - "small" macros, templates that are less than 10 lines (what constitutes a line?) etc.

So as currently licensed (LGPL), I don't think your library is usable as part of a proprietary project.

The MPL, in contrast, places no relinking requirements on the developer. You only have to share any changes you happen to make to the MPL licensed code.

ncmncm5y ago

Your code, your license. Nobody else has earned a say.

Ask anybody who actually contributes, usefully, what they think. Their opinion might mean something.

j / k navigate · click thread line to collapse