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

Something confused #7

Open
MurasameAya opened this issue Jan 24, 2024 · 6 comments
Open

Something confused #7

MurasameAya opened this issue Jan 24, 2024 · 6 comments

Comments

@MurasameAya
Copy link

Excuse me, I have my own adobe license and rmsdk. I want to build a drm version of my own Android app, would you please tell me how to deal with it or give me some suggestion?

@io7m
Copy link
Contributor

io7m commented Jan 29, 2024

Hello!

Are you trying to build the existing Palace application with Adobe DRM support, or are you trying to build your own application using the DRM API in this repository?

@MurasameAya
Copy link
Author

Sorry,I haved tried both. But still not work in my application.Could you please give me some suggestion?

@io7m
Copy link
Contributor

io7m commented Feb 6, 2024

The purpose of the code in this repository is to provide a couple of different things:

  1. It tries to provide a somewhat pleasant Java-like API over the Adobe DRM connector. The Adobe DRM connector doesn't come with any kind of API at all, so you have to write a lot of JNI code to actually use it.
  2. It provides an interface that hides the actual Adobe DRM connector behind a dynamic class lookup. This means that applications can dynamically check for Adobe DRM support instead of doing some sort of conditional compilation, and test suites can mock the availability of the DRM connector in order to test that the application does the right thing regardless of support being available.

On its own, the code in this repository doesn't really do anything: It tries to locate our closed-source component on the classpath that actually implements the various DRM operations. In order to actually use this API to have DRM support, you'd need to have access to our closed-source component, plus access to a certificate from Adobe to allow the DRM to work. To date, noone has ever asked us for access, so I'm entirely unsure as to how we'd handle giving you access to the closed-source components. I'm not saying it can't be done, but I'm not qualified or authorized to know how that kind of thing is handled legally (I can ask if you still want to try going ahead with it).

To my knowledge, the Palace Android application (and the older NYPL Library Simplified Android application) are the only two applications that use these components. We're not able to provide support on how to build your own from-scratch application using these components, but the entirely open source Palace Android application does provide useful examples as to how the DRM API is called:

Device deactivation: https://github.com/ThePalaceProject/android-core/blob/main/simplified-books-controller/src/main/java/org/nypl/simplified/books/controller/ProfileAccountLogoutTask.kt#L166
Device activation: https://github.com/ThePalaceProject/android-core/blob/main/simplified-books-controller/src/main/java/org/nypl/simplified/books/controller/ProfileAccountLoginTask.kt#L535
Fulfilling an ACSM file (downloading a book): https://github.com/ThePalaceProject/android-core/blob/main/simplified-books-borrowing/src/main/java/org/nypl/simplified/books/borrowing/internal/BorrowACSM.kt
Numerous extensions to make the API less painful: https://github.com/ThePalaceProject/android-core/tree/main/simplified-adobe-extensions

On top of all this complexity, it's then necessary to configure the reader (likely Readium 2) with a decryption provider that's only available in our closed-source component, so I can't show you that code here.

On a personal note (and this is my personal opinion, and not necessarily the opinion of Lyrasis, the Palace Project, or the NYPL), but Adobe DRM isn't something anyone who values their sanity should be working with today. I consider it to be abandonware, and it wasn't good before it was abandoned either. I highly recommend looking into alternatives such as
LCP unless you have some kind of mandated hard requirement to support Adobe DRM. Actually supporting Adobe DRM in an application is extremely difficult to even get started, and it's an ongoing serious maintenance burden.

@MurasameAya
Copy link
Author

Thanks, I'd really appreciate it if you could ask for me. I also know Adobe Drm is a disaster, but I need to deal with Overdrive books on my side to deal with DRM.I have to try going ahead with it.So I have to try build my own AdobeConnetor class to replace the code. :(

@io7m
Copy link
Contributor

io7m commented Feb 18, 2024

I'll try to get the ball rolling on Monday.

@io7m
Copy link
Contributor

io7m commented Feb 19, 2024

Hello! I'm sorry to say that it turns out we can't give you access to the closed source component. There's a complicated legal history around it, and I'll try to summarize:

  1. I wrote the DRM connector wrapper under contract to the New York Public Library (NYPL) as part of their Library Simplified project.
  2. The NYPL negotiated the limited use of the DRM connector from Adobe. Note that this is a special version of the standard RMSDK with the embedded version of Readium removed.
  3. The NYPL negotiated the use of Adobe-encrypted EPUB files from Overdrive; Overdrive do not normally allow third parties to consume their books in this way.

LYRASIS worked with the NYPL for a while on Library Simplified, but the two organizations eventually separated, and LYRASIS formed The Palace Project. In the process, LYRASIS was granted access to the NYPL's DRM connector wrapper code (the public part of which you can see in this repository you're in now). LYRASIS is permitted to modify and use it in applications, but not to redistribute it to other parties.

At some point, maintenance of the Adobe DRM connector and RMSDK was taken over by WebQEM:

https://www.webqem.com/

So, currently, at this point:

  1. The only people that can grant you access to this code is the NYPL. The NYPL are the (partial) copyright holders on the wrapper code.
  2. The NYPL are likely only going to grant you access if both WebQEM and Adobe say that they're allowed to do so. The wrapper code is effectively a derived work of the Adobe DRM connector, and so the NYPL can't even redistribute it unless Adobe say so.
  3. If you are granted access, or even if you write your own DRM connector wrapper, it still won't mean that you have access to Overdrive books, as access to those books is given at Overdrive's discretion to parties that have negotiated for it.

You'll need to somehow negotiate with WebQEM, Adobe, Overdrive, and the NYPL to actually achieve what you appear to be trying to achieve. My condolences!

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

2 participants