license may be wrong

[gyakovlev]

one of the direct dependencies is ansi_colour which is LGPL3-or-later

IANAL but afaik derivatives works (including modifications or anything statically linked to the library) can only be redistributed under LGPL, but applications that use (link dynamically to) the library don't have to be LGPL.

[sharkdp]

Thank you very much for reporting this.

ansi_colours is a dependency that is based on some (MIT-licensed) bat source code, as documented in #202 and #319. I didn't notice that @mina86 chose to make the dependency LGPL licensed.

As I don't want to change the license of bat, I see the following options:

• Kindly ask @mina86 if ansi_colour could be provided under MIT as well (maybe dual-licensed).
• Revert Use ansi_colours package for better true-colour approximation #319 and go back to the old way that colors were approximated in bat
• Use a different library that provides the same functionality. My own pastel crate has its own 8-bit approximation code, but this would be a huge dependency and pastels implementation is not optimized for speed.
• Write a new crate from scratch that re-implements the (improved) functionality that we currently have in bat. This would also be a chance to go back to a pure-Rust implementation.

[gyakovlev]

thanks for such a detailed reply!

I just happened to overview licenses of rust packages I maintain in gentoo and noticed possible issue, since we now require listing all licenses of all crates a single package uses at build.

whatever works for you, all licenses are free and it's not a super-huge deal, but it's better to comply of course, even if it's free and amazing software.

probably asking is the most reasonable, since there are only 3 contributors and 13 commits total, even dual-licensing will work, I've seen triple licensed crates.
LGPL with linking extension also exists and will allow static linking if no modifications are made.

[gyakovlev]

just for reference, link to our bug
https://bugs.gentoo.org/694438

[mina86]

IANAL but afaik derivatives works (including modifications or anything statically linked to the library) can only be redistributed under LGPL, but applications that use (link dynamically to) the library don't have to be LGPL.

This isn’t quite accurate. Per GPL FAQ, ‘if you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.’¹ Since source code of bat and all its dependencies is available, this condition is met and there is no conflict in bat being licensed under MIT or licensing issues for Gentoo which distributes all the sources.

It’s true that if someone was to take bat and turn it into closed-source program, they might be in violation of ansi_colour’s license, however, I wouldn’t consider that an issue that bat or Gentoo needs to resolve.

I’m not completely opposed to changing ansi_colour’s license if that’s required for bat to continue using the library, but I don’t believe that legally speaking such change is required.

¹ See also copyleft.org guide, which elaborates on this requirement, and §4¶(d)(0) of the license, which is the paragraph that grants the permission.

[gyakovlev]

wow, thanks. that totally works for us!
I'll leave this issue open, please go on as you wish, but it looks it's fine to distribute bat under MIT from that explanation.

[sharkdp]

@mina86 Thank you very much for the detailed explanation. In this case, I'm fine with leaving everything as is.