While your cynicism is partially understandable, it is also somewhat misdirected. Pressure to encrypt comes from the publishing/e-publishing crowd, not from the DAISY Consortium itself. We would rather not have to do it! Dave David Andrews Chief Technology Officer Minnesota State Services for the Blind (651) 642-0513 >>> mlang@teleweb.at 11/05/02 02:16AM >>> Janina Sajka <janina@afb.net> writes: [...] > There was a meeting regarding this very issue following CSUN last year. > At this meeting I was tasked to chair a committee report to the DAISY > Board recommending that DAISY's next generation of user agents and > authoring tools use GPL/LGPL licensing, meaning that they would be open > source. The DAISY Board niether adopted nor rejected this > recommendation, and I believe the issue continues unresolved within the > DAISY Consortium. Regretfully, I am not attending their meeting later > this month in Korea. Excuse my pessimism, but this is quite what I expected. Or do you seriously believe this comitee would "take away" the valueable income source of all those poor AT-companies? No, they will not I fear, and most probably sell DAISY readers with decrypt-features for a fortune... oh well. > However, nothing prevents any one of us, or any group of us, from > initiating a project to create open source tools for DAISY. I would > expect that creating user agents would be comparatively simpler, and > provide the tool most needed. One would need to control audio file > playback of .wav and .mpg, while displaying text at the same time. There > are more issues, of course, but this ese are the basics in simplest > terms. Synchronization is achieved through SMIL 1.0 in the case of DAISY > 2.02 and SMIL 2.0 in the case of DAISY 3.0 > > Regretably, RFB&D has adopted a copyright scheme based on "security > through obscurity," so the unpacking agent would most likely need to be > binary only. ANd here is where I stop thinking about the whole issue. Play this silly game without people like me... see, text-files are nice, ogg files are nice too, I dont need to play with things which crypt the content of a book. It's like crypted .pdfs, they are too only trouble. > Good authoring tools are another subject altogether, though there are > certainly component applications that could be incorporated, such as > docbook. WRiting authoring tools which *dont* support encryption sounds interesting. Could be used to produce content which is actually useable. > I am happy to assist anyone wanting to look at taking this up to the > extent I can. One thing I can do is to send out several DAISY 2.02 > titles that are not encrypted and which provide both text and audio. I > expect to have such content for DAISY 3.0 in a few months. How about lobbying for not crypting stuff? Or demonstrating that the algo can be broken? Both would be a kind of solution. I still don't believe that serious people can believe they achieve anything but problems with "security through obscurity". -- CYa, Mario _______________________________________________ Blinux-list@redhat.com https://listman.redhat.com/mailman/listinfo/blinux-list _______________________________________________ Blinux-list@redhat.com https://listman.redhat.com/mailman/listinfo/blinux-list