Fix faulty package name in requirements

[qkaiser]

The lzo dependency in install_requires is invalid. The actual dependency is named python-lzo.

Merging this upstream would help us with onekey-sec/unblob#501

[jrspruitt]

Hi QKaiser,

Thanks for pointing this out, I would have assumed an error would show up, not being able to find the package.

I read your link there. Is there a license that would better suite your needs? It looks like perhaps the LPGL would fix the issue. I have to admit I didn't put much thought into which one, when I picked it, GPLv3 seemed popular.

My biggest things are that it would be nice if someone fixes a core bug or issue to contribute it back upstream and also so I'm not being held liable for anything. My intent of ubi_reader was to be something you could easily include in your own projects, or make something beyond the included scripts. From the sounds of it, this what you want to do, and the license is holding you back.

The other patch, about the extract path, I don't want to include as this actually serves a purpose for me. But I don't want trivial UI decisions to cause a bunch of hassle. It'd be nice if you could just copy paste one of the scripts, make your changes then use ubi_reader as a module. But from what I understand, you can't because of the license. Which there is a major UI infrastructure update coming that could make this easier, so the license thing is a problem.

Let me know what would help you do what you want, but not be dependent on my UI decisions, as that shouldn't be a factor in it.

-Jason

[kissgyorgy]

I read your link there. Is there a license that would better suite your needs?

MIT would be the best fit, anything else is kind of problematic.

I have to admit I didn't put much thought into which one, when I picked it, GPLv3 seemed popular.

If doesn't really matter for you and you want to your project used by others, usually the best choice is MIT or Apache 2 as those are the most permissive. GPL licenses are very strict, companies are avoiding any kind of GPL licensed projects, because it restrict how you can use them.

My biggest things are that it would be nice if someone fixes a core bug or issue to contribute it back upstream

GPL doesn't actually enforce this, companies can take your project, use it internally and not contribute back. You best bet is a permissive license like MIT for this case too.

so I'm not being held liable for anything.

I think all of the Open Source Licenses include this non-liability clause 😃

[jrspruitt]

Okay this turned into quite the rabbit hole. Apparently I can not change the license with out approval by all the contributors. At least ones that have contributed more than just obvious bug fixes.

[qkaiser]

@jrspruitt we will switch to the PyPi package based on the upstream ubi-reader with unblob I think, rather than our fork. We can live with #67 not being merged. This won't pose any licensing issue since it will be a dependency rather than included in the code/vendored.

I really hope we can contribute more to ubi-reader over time (probably related to journaling as indicated in #44 and #46). Let us know if there's anything you would like us to look into 💻

[jrspruitt]

Hi @qkaiser
Okay glad to hear it'll work for you. This was eye opening in regards to having contributors and the license control.

You're welcome to contribute what ever. Honestly I haven't used this program for my own use since I first wrote it, 10 years ago. So I'm not always the most motivated or informed on what could be done or is needed for day to day use.

There are a few things on my wish list of functionality though.

The journalling functionality would be great, or any functionality that would make reading the images more UBI/UBIFS drivers complete. This would be the most useful.

Some higher end functionality, would be handling OOB removal on the fly, and dealing with ECC on NAND dumps. Both require significant knowledge on the end users part though. OOB would need a datasheet at least, ECC would take knowledge of some magic. Making this a rather advanced feature, but should be easy to work in, with some CLI args and math in the right place. I imagine for forensic work this would be very handy, for when the data has been pulled straight off a NAND chip. So there is no chance to deal with errors or keep the OOB out of the dump.

The thing I do use this for mostly, is figuring out why an image won't extract. Either bug in ubi_reader, bad dump, or manufacturer shenanigans. This usually ends up in me messing with the ubi_reader source. Any sort of ideas on adding functionality to handle this, beyond just very verbose logging is welcome too. The testing branch, very out of date now, does have some of this. Basically the ability to override parameters that would normally be figured out from the image contained info. I may be the only person in the world that needs this, so not a priority :)

Thanks for what you have contributed, any bit is appreciated. And any feedback on how ubi_reader is being used is good too. Like I said my perspective is fixing bugs and why an image won't extract, so not the best.

-Jason

[nightlark]

This won't pose any licensing issue since it will be a dependency rather than included in the code/vendored.

Depending on the company lawyers you ask, this can also be an issue (which I recently came across with another PyPI library that is also GPLv3 licensed). While the code that calls the library can be under any license, the end result (that links to the GPL'd library) as a whole may still need to be released under a GPLv3 license (which is the "issue" the LGPL resolves, though some would argue the virality of the GPL being applied to users of a library is a feature).

Okay this turned into quite the rabbit hole. Apparently I can not change the license with out approval by all the contributors. At least ones that have contributed more than just obvious bug fixes.

Probably the most realistic way to make the switch would be having new contributions going forward be under both licenses, while waiting for either approval from all past contributors (or until the code they contributed has been rewritten) to use the new license. LLVM and ZeroMQ are two cases of relicensing efforts on a large scale.

I would be happy to open a separate issue/discussion if this is something that you want to look into more; this is the kind of thing that the legal folks at work would have flagged if I sent something through the open source release process, and listed unblob as a dependency and then they decided to look into licenses for unblob dependencies.

[jrspruitt]

I have a question for all of you, would you be interesting in taking over this project? To be honest, I haven't used it for my own needs, since I first wrote it. You all seem like you have a lot more interest in it and need for it and would probably be better at navigating these kind of issues in the future.

-Jason

[qkaiser]

@jrspruitt We're discussing the subject internally, I'll get back to you by email if we reach an agreement :)

[kissgyorgy]

In a couple of weeks, I will be available to help for the initial refactoring, dependency management, CI setup and whatnot.

[qkaiser]

Hi everyone ! I recommend we continue the discussion here: #74

[vlaci]

This won't pose any licensing issue since it will be a dependency rather than included in the code/vendored.

Depending on the company lawyers you ask, this can also be an issue (which I recently came across with another PyPI library that is also GPLv3 licensed). While the code that calls the library can be under any license, the end result (that links to the GPL'd library) as a whole may still need to be released under a GPLv3 license (which is the "issue" the LGPL resolves, though some would argue the virality of the GPL being applied to users of a library is a feature).

I don't want to let this issue hanging without clarifications. From Unblob's perspective this tool was and will continue to be used as a CLI, so linking aspect is not present. You are quiet right, that Unblob mustn't import from GPL/AGPL libraries. I don't see anything pressing us to pursue re-licensing.