The minidjvu project is essentially an independent reimplementation.
Legally the main issue are the patents on the binary arithmetic coder, the
zpcoder,. that is used pretty much everywhere.
The djvulibre copyright notice gives the necessary patent rights for derived
code that complies with the GPL. That basically means that
any GPL code can be considered derived from djvulibre (if only as a source of
inspiration) and therefore can use the zcoder.
> Otherwise you'd have to ask a license
> to Lizardtech/Celartem/Caminova
I mean another thing: is it possible to create some DjVu-handling software
which would be based neither on DjVuLibre nor Caminova? Just something really
new "from scratch" - and not under GPL.
The question is what patents prevent from developping such a software? Maybe
the arithmetic coder and the zpcoder might be replaced to something different?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What's so special in GsDjVu that makes it effective? In other words - what is
the main difference between GsDjVu and http://code.google.com/p/pdf2djvu/ ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> What's so special in GsDjVu that makes it effective?
pdf2djvu just threshold black components and calls them foreground.
gsdjvu performs a much more sophisticated analysis described in http://leon.bottou.org/papers/bottou-2001.
There isa patent that discusses this idea of a ratio between perimeters
(.6,901,169) However you could maybe do things more subtle than a ratio or
more smart than perimeters. Anyway, to work around the patent, you'll have to
invent something.
Returning to the zpcoder patent, it is certain that infringing the patent is
required for interoperability. Now I do not know how much you can buy with
this argument…
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The idea is that many commercial software manufacturers would probably not
purchase the Caminova DjVu SDK to just decode DjVu or read the DjVu metadata.
Caminova should most likely release a **freeware** hypothetical "DjVu
Decoder SDK".
Only then, I hope, DjVu files might start to be indexed with Google etc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I wonder if it is possible to create some program code to deal with DjVu-files
that would be not (the code) DjVuLibre-dependent.
I know just the only such utility:
http://www.djvu.org/files/DjVuVersion.zip
What other DjVu-functionality might be implemented independently?
What patents do prevent the DjVu-functionality independent implementation?
The most interesting would be to create a legal DjVu decoder and DjVu metadata
editor under some "commercially applicable" license.
That would greatly simplify the incorporation of DjVu into the majority of the
existent commercial programs (that probably would not buy DjVu SDK).
The minidjvu project is essentially an independent reimplementation.
Legally the main issue are the patents on the binary arithmetic coder, the
zpcoder,. that is used pretty much everywhere.
The djvulibre copyright notice gives the necessary patent rights for derived
code that complies with the GPL. That basically means that
any GPL code can be considered derived from djvulibre (if only as a source of
inspiration) and therefore can use the zcoder.
Otherwise you'd have to ask a license to Lizardtech/Celartem/Caminova
<http://www.caminova.net/en>.
- L.
**leonb**
> Otherwise you'd have to ask a license
> to Lizardtech/Celartem/Caminova
I mean another thing: is it possible to create some DjVu-handling software
which would be based neither on DjVuLibre nor Caminova? Just something really
new "from scratch" - and not under GPL.
The question is what patents prevent from developping such a software? Maybe
the arithmetic coder and the zpcoder might be replaced to something different?
I do not believe it is possible to work around the zpcoder patent and at the
same time to be able to decode the same bitstream.
Conclusion: in my opinion, you either work with Djvulibre under the GPL, or
you work with Caminova. No alternative.
- L.
And what about GsDjVu: is it possible to work around its patents to implement
its ideas in http://code.google.com/p/pdf2djvu/ ?
What's so special in GsDjVu that makes it effective? In other words - what is
the main difference between GsDjVu and http://code.google.com/p/pdf2djvu/ ?
> What's so special in GsDjVu that makes it effective?
pdf2djvu just threshold black components and calls them foreground.
gsdjvu performs a much more sophisticated analysis described in
http://leon.bottou.org/papers/bottou-2001.
There isa patent that discusses this idea of a ratio between perimeters
(.6,901,169) However you could maybe do things more subtle than a ratio or
more smart than perimeters. Anyway, to work around the patent, you'll have to
invent something.
Returning to the zpcoder patent, it is certain that infringing the patent is
required for interoperability. Now I do not know how much you can buy with
this argument…
The idea is that many commercial software manufacturers would probably not
purchase the Caminova DjVu SDK to just decode DjVu or read the DjVu metadata.
Caminova should most likely release a **freeware** hypothetical "DjVu
Decoder SDK".
Only then, I hope, DjVu files might start to be indexed with Google etc.