search

hillu / linux-audit-parser-rs

Parser for Linux Audit logs
GNU Lesser General Public License v3.0
1 stars 0 forks source link

Issues with the chosen license (LGPL3+) #1

Open hillu opened 2 weeks ago

hillu commented 2 weeks ago

In https://github.com/threathunters-io/laurel/issues/224#issuecomment-2313150363, @jszwedko stated:

My understanding is that users using Vector or VRL in their own projects that they distribute would need to either open source their code with an acceptable license or distribute the resulting artifacts in a way that the LGPL code could be modified and reincluded.

While we seem to agree in principle on the restriction, I think that this restriction only concerns authors of combined works who do not want to provide source for their work. And even then, it's merely a technical issue that can be overcome by offering some clever linker script to end-users. This issue will get even easier to overcome as soon as Rust grows a stable ABI.

I chose the LGPL because I find it important that bug fixes and enhancements (however insignificant they may seem) are made available under the same terms as the original code. To my knowledge, Apache-2.0 cannot be used to enforce this. MIT and BSD licenses certainly can't.

Of course, I'm open to other suggestions.

jszwedko commented 2 weeks ago

Thanks for opening this new issue and adding your thoughts @hillu

While we seem to agree in principle on the restriction, I think that this restriction only concerns authors of combined works who do not want to provide source for their work. And even then, it's merely a technical issue that can be overcome by offering some clever linker script to end-users. This issue will get even easier to overcome as soon as Rust grows a stable ABI.

This is the restriction I was thinking of too, which is not currently enforced for Vector or VRL via their MPL-2.0 license. It does seem like it may be possible to overcome with some clever linking, but I'm actually not sure what that would look like in practice for a Rust program. I don't suppose you've seen this done somewhere already that could be used as an reference?

cc/ @jorgehermo9 just for the notification

jorgehermo9 commented 2 weeks ago

I think that in practice, if someone wants to build Vector with another version of this crate, that could be easily done editing its Cargo.toml, though it cannot be easily done on runtime (dynamic linking).

In the case of VRL, they could use patched dependencies https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html if this linux-audit-parser-rs crates happens to be a transitive dependency of their program (which would happend for all programs depending on the VRL crate)

I think that that complies with the LGPL requirements and therefore there is not additional work in order to enforce that for Vector/VRL? I'm not an expert in licensing so I may be wrong though...

jszwedko commented 2 weeks ago

Ah, yes, to clarify I mean it would place additional restrictions on projects that depend on Vector or VRL rather than Vector or VRL itself (which, as you note, people could easily recompile with the modified version of the dependency).

Projects depending on Vector or VRL would either need to be distributed as open source with a compatible license so people could rebuild with a modified version of linux-audit-parser-rs or, as @hillu is suggesting, recipients of the "Combined Work" sans source code would need to be able to modify the included linux-audit-parser-rs dependency somehow. This is the part I'm not entirely sure what would look like in practice.

jorgehermo9 commented 2 weeks ago

I chose the LGPL because I find it important that bug fixes and enhancements (however insignificant they may seem) are made available under the same terms as the original code. To my knowledge, Apache-2.0 cannot be used to enforce this. MIT and BSD licenses certainly can't.

I think the MPL-2.0 complies with this. Modifications to the MPL-2.0 code should be made available as you require https://www.mozilla.org/en-US/MPL/2.0/FAQ/ (see Question 1)

jszwedko commented 2 weeks ago

I chose the LGPL because I find it important that bug fixes and enhancements (however insignificant they may seem) are made available under the same terms as the original code. To my knowledge, Apache-2.0 cannot be used to enforce this. MIT and BSD licenses certainly can't.

I think the MPL-2.0 complies with this. Modifications to the MPL-2.0 code should be made available as you require https://www.mozilla.org/en-US/MPL/2.0/FAQ/ (see Question 1)

Indeed, I think MPL-2.0 would still achieve this particular goal. Any changes to MPL-2.0 licensed code would need to be made available.