Giters

kspalaiologos / bzip3

A better and stronger spiritual successor to BZip2.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Switch to permissive license (library part only)

sorairolake opened this issue · comments

commented

At this point, when implementing the bzip3 format, I think it is necessary to look at the reference implementation code, which would pretty much force me to use LGPL (or compatible). This means that implementations of this format cannot be released under a permissive license such as the MIT License. I think this might be an obstacle in implementing this format.

So, I suggest switching to a permissive license for the library if possible. Alternatively, multi-licensing under LGPL or a permissive license is also conceivable (I don't know if this is possible).

commented

Hi,

You are free to license your derivative works under LGPLv3. And the reason for this follows:

I want all improvements and changes to bzip3 that are published to be released under LGPLv3. If you improve the algorithm, speed up the code, etc... - it would be unfair if someone took advantage of this and kept the change to themselves and merged it into a closed source product (which happens to MIT-licensed code a lot; it's also notoriously common in the field of data compression - see Oodle, PDE-based compression, a lot of programs in LTCB are closed source...). While licensing a lot of stuff under LGPLv3 usually doesn't make sense, I want to ensure that we all can benefit from the improvements made to my codec (because I am sure that there is room for plenty of them).

As for how I personally interpret LGPLv3: If you are making an open source project and want to use bzip3 in it, static linking to a LGPL library is allowed, but you must make the source (or linkable compiled version) of the library available. Linking to either type of library will not pollute the rest of your project so long as you make the source or object files available and include a copy of the LGPL. Using LGPL in non-LGPL code is fine, but it generally pushes people away due to the complexity of the license as a large majority of available libraries are licensed under MPL, Apache2, or MIT.

Hence: you have to deal with the differences between LGPLv3 and MIT only if you actually intend to modify the library itself, which in my opinion is not a problem and in fact the expected outcome.

I hope that this addresses your concerns.

commented

Do you plan to provide documentation of the bzip3 format sufficient for clean room implementations? If this is done, I think most of the concerns are resolved.

commented

Yes, this is planned. However, due to my unreasonably demanding real-life circumstances I will not be able to provide it quickly. If someone else wants to do it before me and could contribute it to the repository, I will gladly proofread and merge it.

commented

For your information.

The LGPL requires source code or unlinked object code files when "static linking".
If bzip3 explicitly wants to allow "static linking", how about adding an exception to the LICENSE file?

Also, the LGPL must allow reverse engineering, even for dynamic linking.
Therefore, further exception clauses may be needed if bzip3 allows dynamic or static linking with software that prohibits reverse engineering.

However, I am not a legal expert, so I cannot make specific suggestions for others' projects.
As a reference, here are the exception clauses for Bison, FLTK, and the FOX toolkit.

SPDX also has information on exceptions.

commented

Also, the LGPL must allow reverse engineering, even for dynamic linking.

Interesting, may I see which part of the license states that?

commented

Also, the LGPL must allow reverse engineering, even for dynamic linking.

Interesting, may I see which part of the license states that?

Sorry, my memory is wrong.
I also checked Wikipedia and that doesn't seem to be the problem.