Readium: Difference between revisions

Line 11:

<blockquote>"The Readium project was started by the IDPF in 2012 because the EPUB 3.0 specification had been released late in 2011, but no implementation yet existed (or, at least, had been publicly released). So IDPF provided some funding and encouragement and two firms, Evident Point and Bluefire, took the lead in developing a JavaScript implementation of a significant part of the EPUB 3 spec."</blockquote> The JavaScript implementation lacked features and was written as a [[Google Chrome]] extension. It also didn't provide native implementations for devices and "it couldn’t support DRM securely." After additional development, they released the open source Readium SDK Core.<blockquote>"The SDK was designed from the beginning to support DRM ( Digital Rights Management ), a mandatory feature for digital library lending, and also required by many publisher for anti-piracy matters. It was moreover designed to be DRM-agnostic, able to support multiple DRM implementations. However, while that capability existed in the SDK, there was also an increasing perception over time that the existing DRM implementations (Adobe, Kobo, Sony) were too heavyweight and proprietary and there existed a need for a new open-source DRM specification and implementation. The result was the Readium LCP (Licensed Content Protection) specification and implementation, which is rolling out in 2017."</blockquote><ref>{{Cite web |title=A Bit of History |website=readium.org |url=https://readium.org/about/history.html/ |url-status=live |archive-url=https://web.archive.org/web/20260623141903/https://readium.org/about/history.html/ |archive-date=23 Jun 2026}}</ref>

==Consumer-impact summary==

While it is commendable that Readium and its partners (like EDRLab) promote open source code and wished to design a DRM system that aimed to avoid vendor lock-in (which could have caused a lack of innovation, diversity, features and would have handed one vendor total control), aimed to be more interoperable, simpler and ~~secure~~, it can be argued that [[Digital rights management |DRM]] in itself is negatively affecting consumers.

While it is commendable that Readium and its partners (like EDRLab) promote open source code and wished to design a DRM system that aimed to avoid vendor lock-in (which could have caused a lack of innovation, diversity, features and would have handed one vendor total control), aimed to be more interoperable, simpler, secure and ensuring that: <blockquote>"The solution is designed to be minimally intrusive for end-users, who don’t need to create a third-party account. User can share their ebooks with their family or close friends"</blockquote><ref>{{Cite web |title=Readium LCP |website=edrlab.org |url=https://www.edrlab.org/readium-lcp/ |url-status=live |archive-url=https://web.archive.org/web/20260617083801/https://www.edrlab.org/readium-lcp/ |archive-date=17 Jun 2026 |access-date=23 Jun 2026}}</ref> it can be argued that [[Digital rights management |DRM]] in itself is negatively affecting consumers.

Moreover, the Readium SDK was reportedly developed so that it would support multiple DRM technologies, allowing other DRM vendors to easily integrate their systems with Readium. This in effect lowers the barrier to entry, because companies with existing DRM implementations can more easily migrate to Readium and keep using their DRM. The variety also allows for companies that would otherwise be hesitant to pick and choose and implement DRM in a way that might be cheaper or more for them.<ref>{{Cite web |title=Overview of the DRM ecoystem |url=https://www.edrlab.org/readium-lcp/overview/ |url-status=live |website=edrlab.org |archive-url=https://web.archive.org/web/20260623144934/https://www.edrlab.org/readium-lcp/overview/ |archive-date=23 Jun 2026}}</ref>

@@ Line 11: / Line 11: @@
 <blockquote>"The Readium project was started by the IDPF in 2012 because the EPUB 3.0 specification had been released late in 2011, but no implementation yet existed (or, at least, had been publicly released). So IDPF provided some funding and encouragement and two firms, Evident Point and Bluefire, took the lead in developing a JavaScript implementation of a significant part of the EPUB 3 spec."</blockquote> The JavaScript implementation lacked features and was written as a [[Google Chrome]] extension. It also didn't provide native implementations for devices and "it couldn’t support DRM securely." After additional development, they released the open source Readium SDK Core.<blockquote>"The SDK was designed from the beginning to support DRM ( Digital Rights Management ), a mandatory feature for digital library lending, and also required by many publisher for anti-piracy matters. It was moreover designed to be DRM-agnostic, able to support multiple DRM implementations. However, while that capability existed in the SDK, there was also an increasing perception over time that the existing DRM implementations (Adobe, Kobo, Sony) were too heavyweight and proprietary and there existed a need for a new open-source DRM specification and implementation. The result was the Readium LCP (Licensed Content Protection) specification and implementation, which is rolling out in 2017."</blockquote><ref>{{Cite web |title=A Bit of History |website=readium.org |url=https://readium.org/about/history.html/ |url-status=live |archive-url=https://web.archive.org/web/20260623141903/https://readium.org/about/history.html/ |archive-date=23 Jun 2026}}</ref>
 ==Consumer-impact summary==
-While it is commendable that Readium and its partners (like EDRLab) promote open source code and wished to design a DRM system that aimed to avoid vendor lock-in (which could have caused a lack of innovation, diversity, features and would have handed one vendor total control), aimed to be more interoperable, simpler and secure, it can be argued that [[Digital rights management |DRM]] in itself is negatively affecting consumers.
+While it is commendable that Readium and its partners (like EDRLab) promote open source code and wished to design a DRM system that aimed to avoid vendor lock-in (which could have caused a lack of innovation, diversity, features and would have handed one vendor total control), aimed to be more interoperable, simpler, secure and ensuring that: <blockquote>"The solution is designed to be minimally intrusive for end-users, who don’t need to create a third-party account. User can share their ebooks with their family or close friends"</blockquote><ref>{{Cite web |title=Readium LCP |website=edrlab.org |url=https://www.edrlab.org/readium-lcp/ |url-status=live |archive-url=https://web.archive.org/web/20260617083801/https://www.edrlab.org/readium-lcp/ |archive-date=17 Jun 2026 |access-date=23 Jun 2026}}</ref> it can be argued that [[Digital rights management |DRM]] in itself is negatively affecting consumers.
 Moreover, the Readium SDK was reportedly developed so that it would support multiple DRM technologies, allowing other DRM vendors to easily integrate their systems with Readium. This in effect lowers the barrier to entry, because companies with existing DRM implementations can more easily migrate to Readium and keep using their DRM. The variety also allows for companies that would otherwise be hesitant to pick and choose and implement DRM in a way that might be cheaper or more for them.<ref>{{Cite web |title=Overview of the DRM ecoystem |url=https://www.edrlab.org/readium-lcp/overview/ |url-status=live |website=edrlab.org |archive-url=https://web.archive.org/web/20260623144934/https://www.edrlab.org/readium-lcp/overview/ |archive-date=23 Jun 2026}}</ref>