Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Questions for noDRM #2

Closed
j-howell opened this issue Nov 25, 2021 · 10 comments
Closed

Questions for noDRM #2

j-howell opened this issue Nov 25, 2021 · 10 comments

Comments

@j-howell
Copy link

@noDRM

Thank you for merging the pull requests that have long been pending and making other needed changes to this project. While I do not agree with everything you are doing, on the whole I think this fork is a good thing.

There are already some new pull requests since your first release. Perhaps the idea that contributed changes might make into a release has stimulated interest. I am curious about your plans for the frequency of new releases going forward. Do you plan on having another release soon?

I am also interested to learn whether you intend this to be a short term project or if you are committed to this in the longer term.

@noDRM
Copy link
Owner

noDRM commented Nov 25, 2021

Hello @j-howell,
I can imagine which of the changes are the ones that are seen as controversial - watermark removal and library block removal.

I see watermarks / social DRM as being a DRM nonetheless, even though it usually does not technically restrict the user in any way. It still "socially" restricts things that should be "Fair Use". Giving a purchased book to a close friend or a family member to read is something that's perfectly legal (with paper books, and DRM-free eBooks depending on the jurisdiction).

But if this always carries the small legal risk of getting in trouble for something other people did (getting charged because your friend illegally uploaded an eBook with your watermark to the internet), that will deter people from doing that. That's why I still consider watermarks a kind of DRM, and thus something that a DRM removal tool should remove (if requested by the user, it's not enabled by default) - it still restricts the user in what he's comfortable doing with his eBooks.

In addition to that, there's always the possibility of a malicious attacker acquiring (and sharing) your ebooks without your knowledge. Put a virus on someone's computer (or clone their harddrive, steal their laptop / eReader, ...), then dump their eBooks and throw them onto the internet, and bam, a ton of legal trouble and issues for an innocent victim to prove that they're innocent, just because there's watermarks in the books. No idea how often this happens, but it has happened in the past, and it certainly can happen again.


As for the library book restriction - I do not condone lending books from a library and then keeping them forever. But I strongly dislike Amazon eBooks being locked to the Kindle ecosystem and Adobe books being locked to the Adobe ecosystem. If the user is currently in the possession of an eBook - bought or loaned - he should be able to read that on all of his devices. Same for the formatting. If a user has an eBook, then he should be able to format that book in any way he likes, even if that book's from a library.

Sure, that's not the case with paper books either - you'd get fined if you were to "reformat" or otherwise modify paper books loaned from a library - but there's no reason to take arbitrary restrictions from the analog world and apply them to digital things just because "it's always been that way", is there?

If all or most libraries (including Amazon) would offer both Adobe and Kindle format loans, and if they'd make sure the books are all formatted properly, there would be no need for DRM removal on library books. If Amazon and Adobe would talk to another and agree on a DRM standard that's supported on ALL devices, there would also be no need for DRM removal on library books.

And if that was the case, I probably also wouldn't have removed the blocking code, and maybe even added similar code for Adobe and LCP eBooks. (The old plugin by Apprentice Harper did remove DRM from Adobe library books just fine, it was just Amazon where that was blocked). That's not the case, though, and thus I feel that there is a need for DRM removal on library books. Just because now the plugin no longer actively prevents you from removing library DRM, that's not going to be increasing piracy.

Almost all eBooks are available from illegal sources anyways, so if someone knows enough about computers (and is willing) to install Calibre and any of the DRM removal plugins to be able to keep books from a library, he would also be able to just pirate the books instead if he would be arbitrarily prevented from removing the DRM. And anyone who's "in the scene" and actively providing illegal sites with new ebooks would probably be smart enough to A) remove two lines of Python code blocking the library DRM removal or B) buying one book with two accounts to see how the watermarks work and remove them on their own.

Including DRM (= arbitrarily restricting what the user is able to do with the software) in a DRM-removal software, what stupid oxymoron is that ...


As for keeping the plugin updated in the future - I cannot promise anything, but I did not intend this to be a "publish one release and then disappear into the void" situation. I'm not sure how much code I will be able to write myself for this plugin, but I will be happy to merge new useful PRs. Not sure which ones you mean with "there are already some new PRs since the release" - right now I'm only seeing the Mac key fix, and I've just merged that into my repository. The release frequency would then also depend on the amount and the severity of the PRs. When there's multiple new PRs that got merged, no reason not to make a new release. When there's no PR that got merged since the last release - no reason to make a new one.

@j-howell
Copy link
Author

I was mistaken about the number of pull requests. I did see that Leseratte10 is working on solving an occasional problem with ADE decryption that may result in a pull request. Perhaps that stuck in my mind. In any case I am glad to learn that you plan to be timely in releasing updates.

I did not realize that the function of removing personal information is optional and not enabled by default. That is a reasonable way to approach the issue as far as I am concerned.

I provided a link to this issue in the discussion of new DeDRM releases on MobileRead in hopes that others might express their opinions and desires for the future of this plugin here.

Thanks again for you efforts! (I would like to contribute to this project but as a US citizen fear of the DMCA prevents me from doing that.)

@noDRM
Copy link
Owner

noDRM commented Nov 25, 2021

I provided a link to this issue in the discussion of new DeDRM releases on MobileRead in hopes that others might express their opinions and desires for the future of this plugin here.

That's great, but for stuff like this people should probably open a Discussion rather than just having everyone comment on this single issue.

@j-howell
Copy link
Author

Yes, using discussions makes make sense. I am used to issues and didn’t consider that possibility.

Someone on MobileRead posted about their confusion in needing to open the zip file of the release to find the zip file of the plugin. That has been a common problem for new users. Is there any good reason why the calibre plugin shouldn’t be the first file offered for a new release since that is what most users actually need?

@mizuOda
Copy link

mizuOda commented Nov 26, 2021

... the Mac key fix, and I've just merged that into my repository. The release frequency would then also depend on the amount and the severity of the PRs.

Thank you @noDRM for merging the key fix. This is a common issue for Mac users, affecting those new to Kindle for Mac or Calibre, new to the DeDRM plugin, those who had to do a clean install of Kindle for Mac or Calibre for some reason, or who get a new Mac computer. There is a workaround involving downgrading to Calibre 4.23 and DeDRM 6.8.1 to retrieve the key, then upgrading back to Calibre 5 and DeDRM 7.2.1 (or 10.0.1), but it's tedious. I'm hoping you will make a new release sooner rather than later.

ETA: Thank you for releasing this fix with v10.0.2. I have updated the Mac post on MobileRead accordingly :)

@noDRM
Copy link
Owner

noDRM commented Nov 26, 2021

Is there any good reason why the calibre plugin shouldn’t be the first file offered for a new release since that is what most users actually need?

Mainly just because "it's always been that way". Also, there's the Obok plugin which is included in the release, too. Although I could just upload two ZIP files to one release for that - maybe I should do that in the future. Although that can cause other issues - as far as I know, some browsers (particularly on MacOS) like to auto-extract (and then delete) downloaded ZIP files by default ... so maybe I better leave it as it is.

@j-howell
Copy link
Author

... so maybe I better leave it as it is.

Thanks for considering it.

@ElleKayEm has been handling support for DeDRM pretty much single handedly. The same issues come up over and over again. I was thinking that some of those questions could be avoided by changes to the plugin that make it more intuitive to set up and use, such as including common solutions along with error messages. Considering that was not possible in recent years since even essential changes were not being made to this project. Now I have hope for improvement.

Another thing that I think would help is an ability to optionally raise a dialog in the calibre user interface when errors occur. This isn't currently allowed for File Type plugins such as DeDRM. I have been thinking of a way to make it possible and will try to contribute it to the calibre project if Mr. Goyal is amenable.

@noDRM
Copy link
Owner

noDRM commented Nov 26, 2021

Another thing that I think would help is an ability to optionally raise a dialog in the calibre user interface when errors occur.

That would be a great feature. Ideally in a way that allows a plugin to both print info messages to the user (pop up a dialog box but continue importing the book) and error messages (pop up an error box and skip / stop importing the book). And/or to live-update the text in the progress window to reflect what the plugin is currently doing. I did look for features like these, too, but it doesn't look like that's possible right now. If this is possible in future Calibre versions I'll gladly implement that in the plugin.

I do know that people trying to install the container ZIP instead of the plugin itself is a somewhat common issue - I played around with adding a custom __init__.py file to the outside ZIP, hoping to be able to trigger a custom error message instead of "Invalid plugin" when people import the wrong ZIP, but I didn't find a way to implement that either.

@j-howell
Copy link
Author

Another thing that I think would help is an ability to optionally raise a dialog in the calibre user interface when errors occur. This isn't currently allowed for File Type plugins such as DeDRM. I have been thinking of a way to make it possible and will try to contribute it to the calibre project if Mr. Goyal is amenable.

The idea that I had for this didn't work out. I am abandoning this effort for now.

@j-howell
Copy link
Author

Thanks for the answers. Closing.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants