Licensing and goal of Readium SDK

12 posts / 0 new
Last post

Continuing here a discussion started on Twitter with Micah Bowers:

As a developer who contributed to several FLOSS projects, especially making my own code available under MIT/GPL/AGPL license, the signal that Readium Foundation sends by dual-licensing Readium SDK as AGPL and as "pay-to-use-it-in-closed-source-sw" is discouraging me from contributing code to the project. It does not surprise me that the code contributions mostly come from staff of the Readium Foundation or their members, while the issue tracker sees more external activity.

Let me explain. I am not really upset by the fact that the commercially-friendly license that allows the licensee to use the Readium SDK code in closed-source applications has a street price of 30,000 USD ("base contribution") and a mandatory 3,000 US annual fee, while I could have contributed some of said code for free. After all, nobody forces me to contribute.


My main concern is about the rationale behind asking a fee for a basic library which should be given out for free even for commercial purposes, without the constraints of the AGPL. For a big publisher or a software vendor or a VC-backed startup, 30,000 USD are peanuts. For a bootstrapped startup or an independent developer that price is simply impossible. (The alternative "contribute substantial code for a discount on the fee" may be equally unfeasible in those two cases.)

If the goal of the Readium Foundation/IDPF is to promote the use of the EPUB format, then this licensing scheme does not make any sense. I do not think that most of the members of the Readium Foundation will go bankrupt by directly funding the development team behind the Readium projects while releasing the code under MIT, Apache, or any similar license...

So, my questions are:

1. What is the rationale behind the dual licensing of Readium SDK?

2. Am I mistaken in believing that the end goal of the Readium projects should be promoting EPUB adoption? If I am wrong, then what is the goal of the Readium Foundation? Building the libraries for their own sake? Sharing the development cost among the current/potential implementers? Providing a reference implementation?

Thanks in advance

First off, I'd like to be clear that my comments here will be my own personal opinions and perspectives. Meaning my comments here in no way are meant to represent the views of other participants in the project or of any organization. With that caveat out of the way:

The Readium project has a variety of participants. Some are supporters (their organization is not developing a reading system, but they support the effort in various ways for various reasons), others are active implementers of reading systems. Some of these implementers derive revenues directly from licensing reading system technologies to third parties (such as Bluefire). Other implementeres derive revenues from other sources (e.g. licensing of content) and they implement reading systems in order to facilitate their business. Others orgs such as DAISY and IDPF participate as part of the mission of their org. It is hypothetically possible that individuals could contribute for personal reasons/interests too, though I've not seen much of that so far.

In any case, the point is that there are a wide spectrum of motivations, goals, and missions in terms of the various participants in the project. So my perspective might be very different than others that are involved. I would say that all participants have a common interest in "promoting the use of the EPUB format". That said, my company's involvement in the project is driven much more by other goals. I wrote a post a while back that expressed some of these goals here

So how does this relate to the dual license for Readium SDK?

First, lets be clear that the vast majority of the Readium code libraries are totally free to use and modify under an open license. e.g. all of the code to create in-browser reading systems is under BSD. The native C++ code "Core SDK" for mobile apps is the only component that is dual licensed - more info found here:

The initial motivation (from my perspective) to go with a dual license scheme was this: when we first got together with a few other companies that were interested in collaborating on an SDK for EPUB3 native apps, one of the challenges was that several of us were competitors, that made our living developing ereader apps. So there was some concern that these early contributors to the project would invest a great amount of time and energy into the project, only to have other competitors "sit it out" and wait until it was done, grab it and then compete with the contributors, without having themselves contributed. An idea was floated that implementers that came late to the game, would need to contribute something back, either code or financial support to the organization in order to deploy a competing commercial product that leveraged the code. This was really about trying to create a scenario that helped early potential contributors to "get over the hump" of their concerns with working in an open source way more than anything else. One could argue that this worked, or it didn't or that it was misguided or brilliant. From my own perspective, I think it worked, but it is hard to know what would have happened if we took a different tack. Important to note that this conversation was occurring well before there was any formal organization. It was a handful of companies and orgs kicking around the idea of collaborating on such a project in informal conversations.

As the project evolved and changed and more people got involved, the ideas around the concept of membership, or a paid license, etc evolved as well e.g. :
One thing happened that I had not expected in that organizations got involved that were not implementers. Some of them paid membership fees and even license fees even though they had no immediate plan to create software themselves. I had largely thought of the project as being a group of implementers working together for their mutual self-benefit, but it went beyond that.

One outcome of this is that the membership fees and license fees began to be sufficient enough to pay developers to add to the work being done by implementing contributors. This was really helpful as the most active implementers/contributors were (and still are today) small, bootstrap, privately held companies like Bluefire, Mantano, and Evident Point. These small companies have limited resources, and the highly skilled developers necessary to create such technologies are expensive (at least for US developers).

That said, it is natural that people would look at the paid license and see that as counter to the "broader" mission of promoting EPUB. e.g. wouldn't it be better if it were free from that perspective? And the answer of course is yes. But before anyone can build a great reading system mobile app on top of the SDK, the SDK (and related stack) needs to be built, and it is not there yet. So the first order of business is how do we achieve that?

It may be that had it taken a different path, with no license or membership fees, that it would have attracted more code contributions. And those additional contributions would have been greater than the many hundreds of paid-developer hours the fees have since funded. Unfortunately, hindsight is not always 20-20 when trying to compare the present to the road-not-taken.

The question really is, what is the best road forward? If the dual license approach was ended, would that hole be filled with additional contributions - either financial or code?

What do you think?

Thank you for your articulate perspective and for taking time to write it down.

Yes, I was referring specifically to Readium SDK, given the importance of mobile native apps have nowadays.

(BTW, I personally think that is very unfortunate, since the Web would be a much better platform for both users and developers. But I am aware of the business needs in the short period, and this observation is little relevant to this discussion anyway.)

I am not able to answer your latter questions with 100% confidence. All I can do is reinforcing my initial statement: if Readium SDK were to be licensed under commercial-friendly terms without a fee, I would be much more comfortable contributing code to the project. Of course, I am speaking for myself only, others might disagree.

En passant, let me remind that in the past I raised a few other issues about the Readium projects, other than licensing, that the Readium Foundation might want to discuss as well to attract more contributors: 1. documentation and 2. written policies for managing contributions efficiently.

One more thing I forgot to write yesterday: knowing the resources at the Readium Foundation's disposal would help answering your questions. For example, how many SDK licenses have been sold? How many developers can the RF fund? At what seniority level? Etc.

(It seems to me there are no financial statements anywhere on the RF or IDPF Web sites. Please correct me if I am wrong.)

And, of course, publishing them would be interpreted as a great transparency signal by the potentially interested developer.

You are welcome to attends meeting to ask question and provide input. I myself do both, on a regular basis. I am not a spokesperson. I am a contributor.

You are welcome to attends meeting to ask question and provide input. I myself do both, on a regular basis. I am not a spokesperson. I am a contributor.

Potentially interested developers have other things on their mind Alberto. You are not potentially interested. You and I both know that.

That said, I agree that transparency is a good thing in community projects.

Thank you for taking time to reply.

I just note that, albeit not being an IDPF or RF member (and never was), I keep providing issue reports and spec suggestions, mostly about EPUB 3 Media Overlays. Of course, feel free to judge that as "not enough" to qualify for being a "potentially interested developer".

Readium SDK modules are publicly licensed as Open Source Software via Gnu Affero General Public License Version 3. This license contains terms incompatible with use in closed-source software including a copyleft provision.

I welcome and deeply appreciate your interest, issue reports, and other contributions. As I appreciate all contributions no matter how small. What I meant was that I recognize that the goals of the SDK project are not fully in line with your own desires, and thus I don't expect that you will devote significant time and effort to contributing code, though of course I would be delighted if you did. My views on how to best foster adoption have been shaped over ten years actively working to foster a healthy and diverse epub ecosystems worldwide, and I've learned a lot along the way. One of the things I've learned is that the ecosystem is actually quite small and fragile in many ways, and that the proper economic incentives need to be in place for the various ecosystem players in order to create a robust and healthy playing field that lays the right foundation for ongoing innovation. It is a delicate balance to achieve given the forces at play. Much of the innovation that occurs in the ebook ecosystem (outside of the mega-retail platforms closed silos) is done by very small companies, like Mantano, Feedbooks, Evident Point, DataLogics, Bluefire, Bookshout, and many other similar companies. Creating an environment that enables these small private companies to thrive is in my experience the most important and meaningful thing that can be done to help EPUB3 adoption over the long haul. If, say a govt entity or NGO were to "suck the air" out of the market by replacing these company's role in the market, we would then become dependent long term on that organization carrying the entire ecosystem forward, and I've seen commercial parallels to that in the current ecosystem, and the outcomes have been very disheartening at times. I'm 100% all for non-profits and govts playing a role in bringing ebooks and ebook technology to sectors and people that would otherwise be under-served by commercial platforms. But I do think it is important to also foster a robust commercial ecosystem that can fund this innovation, and that is my focus and my goal. And it is one of the prime reasons Bluefire co-founded the Readium SDK projects, why we provided seed funding for the organization, why we have actively participated and contributed for the last three years, and why I personally spent many hours trying my best to recruit organizations, friends, partners, customers, and our competitors in the digital publishing industry to participate in and support the effort. I do get a bit testy sometimes when criticized about the difficult decisions we've made because, well, I'm extremely passionate about the project, and because we repeatedly hear "Readium should do this, Readium should do that" and it sometimes makes me want to pull out my hair and scream, THEN HELP US! or if what you want is something different, with a different goal, well then go make that happen like we helped make this happen. It can be done, granted it takes serious commitment, sacrifice, and hard work. Which you know full well having done it. But, then, I have to remember that sometimes people have good, heartfelt, suggestions and criticism, and it is important to listen graciously, and sometimes I fail in that. I'm imperfect for sure, but trying.

One of the meta issues around this conversation relates to "mission" and "method". Here's what I mean. If, as just a random example, there is a mission to solve food shortages in a Northern Africa. One method for tackling that is to teach farmers how to increase productivity. Another might be to create economic incentives for foreign investment in farming or distribution. Or perhaps fund R&D to create hybrids stains of wheat that grow better in the regional climate, or simply to import and distribute free food, etc. Each has pros and cons. For example, a campaign to distribute free food might solve a short term crisis, but it can also undermine the economics of local farming, and ultimately exacerbate the food shortage problem (this exact thing actually happens sometimes with hunger relief programs unfortunately). It actually takes a fairly sophisticated - multi-pronged - and coordinated effort across agencies pursuing a variety of methods to solve these kinds of problems in a sustainable way. This particular issue is close to my heart as my church is very involved with hunger relief programs, and often there is great conflict between different orgs that are employing different methods. As well as much criticism of each method by folks that advocate for others. e.g. "Stop spending that money on farmer education! the people need food NOW! In reality, both are needed, among other things.

To critique any given method as not being "comprehensive" as it does not address every possible method would indeed be accurate. How helpful that criticism is of course varies by situation, but in almost every case, there is a great amount of complexity in play, and it requires a fairly deep understanding of the root causes of the problem and the unique landscape of the solution set, and the pros and cons of the various methods, and what it actually takes to employ a given method, to find the right balance.

I don't expect Readium Foundation to be a silver bullet, nor do I expect it to be able to attract sufficient resources to employ all available methods, or tackle all challenges with the adoption of open web standards in digital publishing. And I would hope that no one else assumes it can or should.

Secondary menu