Issues with the chosen license (LGPL3+)

[hillu]

In threathunters-io/laurel#224 (comment), @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]

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]

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]

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]

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]

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.

[jorgehermo9]

Hi @hillu, any thoughts about this?

[hillu]

@jorgehermo9 Yeah, I have been thinking a bit about the license.

The issue LGPL addresses and MPL does not is that users of a combined work should still be able to change the library (i.e. the audit parser in this case), even if they cannot build the entire combined work from sources. I think that users should have this freedom.

I think I'll leave the license as-is but add a note about what can be done about alternative arrangements.

For Rust projects that depend on this library, there'd always be the option to only use it if a certain feature flag is set.

[jorgehermo9]

Understood, thank you very much for your response, I really appreciate that.

Should we wait then to the note you will add so we can procede with what you suggest?

I don't know if this fits the Vector project @jszwedko. I don't think that is feasible to ship Vector with dynamic linking (I can't think of any other alternatives to comply with LGPL). If not, we should work in a completely new parser.

[hillu]

I find that adding any vague note that boils down to contacting the author and contributors looks ethically questionable, so let's not do that. To be clear, I don't want to make this about money going to me - I'd consider that ethically questionable at best, too. (Gee, picking a different license might have meant less of a headache, who knew?)

I don't think that we should discuss license exceptions for distributing specific binary-only builds of Vector in public – but my e-mail address can be found at the bottom of the README file.

[jszwedko]

Thanks for the additional thoughts @hillu .

@jorgehermo9 I think we could still use this library in Vector so long as we put it behind a feature flag so that it can be excluded when Vector is used in a "Combined Work" where the author of the "Combined Work" isn't able to comply with LGPL (which I believe, in this case, would mean distributing the entire source of the combined work so that it could be recompiled with a modified version of this library). I'd want to validate my understanding further before we move in that direction though.

Dynamic linking of this library in Vector, somehow, would be another option but I'm still not quite sure what this would look like.

[jorgehermo9]

Oh, I understand now. In cases where the LGPL can't be complied with (for example, in closed source projects), the functionality of the linux-audit-parser crate wouldn't be available to use at all for the end-users, because Vector would be compiled without that crate, so there is no need for dynamic linking at all.

And then, open source projects could use linux-audit-parser as regular.

I have a few doubts about it... How will Vector distribution be done? Would you distribute two docker image versions @jszwedko , for example, one LGPL-compliant and other without the linux-audit-parser crate? 🤔

[hillu]

Oh, I understand now. In cases where the LGPL can't be complied with (for example, in close source projects), the functionality of the linux-audit-parser crate wouldn't be available to use at all for the end-users, because Vector would be compiled without that crate, so there is no need for dynamic linking at all.

Exactly.

How will Vector distribution be done? Would you distribute two versions, one LGPL-compliant and other without the linux-audit-parser crate? 🤔

You'll just have to ensure that you make corresponding source code available for every binary build that includes linux-audit-parser. Without having looked at your CI job definitions, it seems to me that Github is already doing that with the "Source code (zip) " and "Source code (tar.gz) " download links in the release pages.

[jszwedko]

Right, yeah, I think for Vector itself, the LGPL license is compatible as we already distribute Vector's source and so users could modify linux-audit-parser and recompile Vector with those modification and so there is no need to distribute multiple Vector versions. My concern is with consumers of Vector as a crate where they don't, themselves, distribute the source. I believe this usage would require not including the linux-audit-parser crate (or it would need to be included in a way that could be modified) which is where the Vector feature flag would come in handy: to be able to opt into the LGPL dependencies only when able to comply with the license.

[jorgehermo9]

Everything is clear then! You can close this if you want @hillu, thank you very much for your time

[jorgehermo9]

Hi @hillu. We finally decided to not include this library in Vector due to licensing issues. You can find the final decision here.

I really appreciate your work on this and I totally hope that someone else find this crate useful. Due to the licensing issue, I may end up writing my own parser (with no inspiration from yours, of course) with a MPL/Apache/MIT-compatible license.

I'm sorry for all the inconveniences and thank you very much for your work and time.