I've worked with the Australian AV affiliate since day one (this is a while back) and I seriously doubt that AV will release/os their source. It was quite a computer science marvel (at the time, to a fresh graduate) which DEC had invested reasonable R&D$$ into.
Back then as an affiliate, you get to access their text/HTTP-based search interface (which you can customise the results returned for your site) plus the AVSHE interface (which you don't have to use - I've managed using perl). I suspect this announcement/move is purely extending the affiliate selection (back then only large telcos are invited) so that smaller players get a chance too.
That is an interesting analogy. However I don't think it reflects some key points in the DeCSS case so I will try to refine it a bit using more "traditional" medium, hopefully represents both side of story (which I gathered from extensive reading of/. and links provided).
=========================== Manufacturers of certain $ITEM have been investigating for a new kind of $PACKAGE for their $ITEMs. They are not very happy with their existing $PACKAGE or the ones they've been using - the inherent technical nature of those $PACKAGEs allows the $ITEMs packaged to be duplicated easily, which they see is potential revenue.
However, after extensive marketing and technical researches, the manufacturers came to the conculsion that it's too hard to find a feasible $PACKAGE that disables the duplication. Knowing that $PACKAGEs requires $PACKAGE_OPENERs, they wrap special $LICENSE around the new $PACKAGE technology so that you have to register with them to make a $PACKAGE_OPENER. (which wasn't the case with the older $PACKAGEs - please correct me if I'm wrong)
You have bought a shiny new $ITEM with the latest kind of $PACKAGE from your local department store. You know, from expereince, that new $PACKAGEs requires new $PACKAGE_OPENERs. You shopped for a $PACKAGE_OPENER and there were only $PACKAGE_OPENERs for the front room, study and toilet. You bought one for the front room but you also enquired about one that can be used in the kitchen - unfortunately there isn't one.
Enter your local Norwegian kid. He'd love to make a $PACKAGE_OPENER for the kitchen as he spents most of his time in the kitchen and would prefer to enjoy the $ITEM there. However this new registration and $LICENSE deal (which original intend is to prevent duplication) requires a large sum of money. Therefore he purchased a existing $PACKAGE_OPENER (much cheaper than getting the $LICENSE), studied it, (in effect reverse engineered it) and produced his own $PACKAGE_OPENER - for the kitchen.
Now the manufacturers weren't dumb - they have asked all the $PACKAGE_OPENER manufacturer to make their $PACKAGE_OPENER secure so it can't be reverse engineered - but obviously one of them didn't. Note that the $PACKAGE_OPENER manufacturers knew they may make mistakes like this. With every $PACKAGE_OPENER they sell, they have included a $NO_REVERSE_ENGINEERING clause in it.
So with the existence of an $UNAUTHORISED $PACKAGE_OPENER, whose fault is it?
The $ITEM manufacturer went for the Norwegian kid. They claim the "$PACKAGE_OPENER for the kitchen" is a duplication tool, a pirating tool and is thieving in nature.
Slashdot Mirror
Funny hacks are good pranks.
I've worked with the Australian AV affiliate since day one (this is a while back) and I seriously doubt that AV will release/os their source. It was quite a computer science marvel (at the time, to a fresh graduate) which DEC had invested reasonable R&D$$ into.
Back then as an affiliate, you get to access their text/HTTP-based search interface (which you can customise the results returned for your site) plus the AVSHE interface (which you don't have to use - I've managed using perl). I suspect this announcement/move is purely extending the affiliate selection (back then only large telcos are invited) so that smaller players get a chance too.
Good luck to them.
That is an interesting analogy. However I don't think it reflects some key points in the DeCSS case so I will try to refine it a bit using more "traditional" medium, hopefully represents both side of story (which I gathered from extensive reading of /. and links provided).
:)
===========================
Manufacturers of certain $ITEM have been investigating for a new kind of $PACKAGE for their $ITEMs. They are not very happy with their existing $PACKAGE or the ones they've been using - the inherent technical nature of those $PACKAGEs allows the $ITEMs packaged to be duplicated easily, which they see is potential revenue.
However, after extensive marketing and technical researches, the manufacturers came to the conculsion that it's too hard to find a feasible $PACKAGE that disables the duplication. Knowing that $PACKAGEs requires $PACKAGE_OPENERs, they wrap special $LICENSE around the new $PACKAGE technology so that you have to register with them to make a $PACKAGE_OPENER. (which wasn't the case with the older $PACKAGEs - please correct me if I'm wrong)
You have bought a shiny new $ITEM with the latest kind of $PACKAGE from your local department store. You know, from expereince, that new $PACKAGEs requires new $PACKAGE_OPENERs. You shopped for a $PACKAGE_OPENER and there were only $PACKAGE_OPENERs for the front room, study and toilet. You bought one for the front room but you also enquired about one that can be used in the kitchen - unfortunately there isn't one.
Enter your local Norwegian kid. He'd love to make a $PACKAGE_OPENER for the kitchen as he spents most of his time in the kitchen and would prefer to enjoy the $ITEM there. However this new registration and $LICENSE deal (which original intend is to prevent duplication) requires a large sum of money. Therefore he purchased a existing $PACKAGE_OPENER (much cheaper than getting the $LICENSE), studied it, (in effect reverse engineered it) and produced his own $PACKAGE_OPENER - for the kitchen.
Now the manufacturers weren't dumb - they have asked all the $PACKAGE_OPENER manufacturer to make their $PACKAGE_OPENER secure so it can't be reverse engineered - but obviously one of them didn't. Note that the $PACKAGE_OPENER manufacturers knew they may make mistakes like this. With every $PACKAGE_OPENER they sell, they have included a $NO_REVERSE_ENGINEERING clause in it.
So with the existence of an $UNAUTHORISED $PACKAGE_OPENER, whose fault is it?
The $ITEM manufacturer went for the Norwegian kid. They claim the "$PACKAGE_OPENER for the kitchen" is a duplication tool, a pirating tool and is thieving in nature.
But is it?
===========================