Quote:
Originally Posted by eureka
@baf, can you lead or participate in updating technical documentation of MOBI format basing on your fresh knowledge?
|
I don't think any leadership is needed here. We could just start with updating MOBI wiki.
It is my duty to contribute to the wiki and I want to do it, but at the moment libmobi development itself consumes too much of my time. I hope I will be able to document some KF8 related algorithms when I reach more stable state of my project.
Quote:
I can read Python and C, so knowledge hidden in KindleUnpack/libmobi code would be accessible to me. But undefined license of KindleUnpack and LGPL of libmobi are pretty restrictive for me, because I also have a desire to write another mobi library (someday), but with MIT license, so I'm trying to hold back from reading KindleUnpack and libmobi code.
|
Choosing a license is a personal choice. I support GPL idea. Just notice that LGPL license is pretty permissive for a shared library. You can use it in commercial, closed-source applications. It still contains the dreadful virus though. So I well understand that somebody else may want to choose another approach.
You shouldn't be afraid of reading KindleUnpack or libmobi code. Is there much difference between learning an algorithm from a source code or from a documentation made of this source code? I still believe you know how to make fair use of it.