The EBookDroid become a closed source application.
All 3d-party GPL code are deleted or moved to separate programs.
Only Android 3.1+ devices supported.
Legacy fonts are added back in package and selected by default. "
I'm not aware of any other free DjVu implementation, so I assume they used this one.
They claim that
"This software is an aggregation in terms of GNU.
It contains other standalone binary programs, that executes as separate processes
and communicates with this software only through OS mechanisms (files).
Some of that programs are GPL based, some are not.
Sources of GPL programs can be found on our site."
I'm not a lawyer, this isn't legal advice, and all that, but somehow I doubt the claim that their app is "aggregation".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This has come up before with other GPL libraries. My understanding of the matter is that the GPL was intended to disallow this, but what counts as a "computer program" and what counts as a "release" is now more complicated than it was when the GPL was written. For instance, if a program calls a GPL library, and the program and that GPL library are both available for download on the same server, and the user interface to that server allows a user to easily download and install both at the same time, how do you distinguish an ftp user interface that is "bundling" from one that is "aggregating"? What if the end-user's OS or package manager sees the dependency and installs the GPL library on its own?
My own strong opinion is that the DjVuLibre team shouldn't be worrying about this, because DjVuLibre shouldn't be GPL. When you're trying to get people to use a standard file format, you should never GPL the code needed to deal with that file format.
People use PDF because there are hundreds of powerful pieces of commercial software to create, edit, transform, convert, and classify PDFs. No commercial software that I know of handles djvu, and it's because they can't use djvulibre. When I worked for the NIH, NASA, and other federal agencies, I couldn't use any GPL code in anything I wrote, even though most of that software was open-source, because many of our users refused to use anything GPLed--even though many of THEM were also making open-source code--because GPL on a piece of code poisons all the code downstream of it, reducing adoption.
TL;DR: GPL is killing djvu.
Last edit: Phil Goetz 2018-04-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In my personal view, the DjVuLibre team need not be concerned about this issue, as DjVuLibre should not be licensed under the GPL site. When promoting the use of a standard file format, it is unwise to apply the GPL to the code necessary for handling that format.
Last edit: John Harry 2023-07-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
https://code.google.com/p/ebookdroid/
"Since version 2
I'm not aware of any other free DjVu implementation, so I assume they used this one.
They claim that
"This software is an aggregation in terms of GNU.
It contains other standalone binary programs, that executes as separate processes
and communicates with this software only through OS mechanisms (files).
Some of that programs are GPL based, some are not.
Sources of GPL programs can be found on our site."
I'm not a lawyer, this isn't legal advice, and all that, but somehow I doubt the claim that their app is "aggregation".
This has come up before with other GPL libraries. My understanding of the matter is that the GPL was intended to disallow this, but what counts as a "computer program" and what counts as a "release" is now more complicated than it was when the GPL was written. For instance, if a program calls a GPL library, and the program and that GPL library are both available for download on the same server, and the user interface to that server allows a user to easily download and install both at the same time, how do you distinguish an ftp user interface that is "bundling" from one that is "aggregating"? What if the end-user's OS or package manager sees the dependency and installs the GPL library on its own?
My own strong opinion is that the DjVuLibre team shouldn't be worrying about this, because DjVuLibre shouldn't be GPL. When you're trying to get people to use a standard file format, you should never GPL the code needed to deal with that file format.
People use PDF because there are hundreds of powerful pieces of commercial software to create, edit, transform, convert, and classify PDFs. No commercial software that I know of handles djvu, and it's because they can't use djvulibre. When I worked for the NIH, NASA, and other federal agencies, I couldn't use any GPL code in anything I wrote, even though most of that software was open-source, because many of our users refused to use anything GPLed--even though many of THEM were also making open-source code--because GPL on a piece of code poisons all the code downstream of it, reducing adoption.
TL;DR: GPL is killing djvu.
Last edit: Phil Goetz 2018-04-11
In my personal view, the DjVuLibre team need not be concerned about this issue, as DjVuLibre should not be licensed under the GPL site. When promoting the use of a standard file format, it is unwise to apply the GPL to the code necessary for handling that format.
Last edit: John Harry 2023-07-19