David is correct. In fact, there's much opposition to the encryption spec even within members of the DAISY Consortium. In fact, this spec is not formally part of the DAISY protocol. It's just there under consideration--and in use by RFB&D. Many other libraries around the world do not use it. In the U.S., however, not only publishers require such things, but the law seems to by implication. What do I mean when I say "by implication?" Since 1996, agencies such as NLS and RFB&D no longer need to ask publishers for permission to republish content, as long as they republish in a medium that's only used by blind and print disabled persons. That's easy enough when the medium is braille, and it's easy enough when it's half-speed, four-track cassette. But it doesn't apply to DAISY--except for the encryption. PS: Did you ever consider that half-speed, four-track cassettes were a kind of analog rights management? In fact, those characteristics were purposefully chosen to frustrate sighted people from using our set aside content. I guess this might be as clear as mud, but the bottom line is that the fact that agencies don't need to ask permission any longer has greatly speeded up the process of putting titles in the hands of patrons. That's a real benefit. What we need to do is to convince NLS, RFB&D, and other libraries that effective encryption, sufficient to satisfy this requirment for a set-aside medium, can be achieved with open encryption technologies. I believe PKI is up to it, and we need to show them how that's achievable economically before they launch service with DAISY 3.0. Fortunately, there's time to get that together. Meanwhile, we need open source user agents and authoring tools. David B Andrews writes: > From: "David B Andrews" <DANDREWS@ngwmail.des.state.mn.us> > > 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 -- Janina Sajka, Director Technology Research and Development Governmental Relations Group American Foundation for the Blind (AFB) Email: janina@afb.net Phone: (202) 408-8175 _______________________________________________ Blinux-list@redhat.com https://listman.redhat.com/mailman/listinfo/blinux-list