I have heard similar things from others about the RE laws in Europe. And I think you are right that it is intended and used for file format compatibility and that kind of thing. As such I dont' see how REing the CSS mechanisms in a DVD player would be considered legal. You are not maintaining any kind of compatibility. The only way I can seeit being able to be legal under that law is to claim you did it for maintaining compatibility with other DVD authoring software. Even then, one could only legally RE the encryption algorithm used and perhaps where on the disc one has to place the disc and title keys.
Current DVDs (the large majority of them) use a Bridge format. MicroUDF and ISO9660. This allows current ISO9660 file systems to use them without any problems (assuming they have a large enough address space built into them) but will maintain compatibility once full UDF based ones start coming out and players start using that filesystem to access the discs.
This has absolutly nothing to do with the data layout of DVD-Video data, though. That requires that all the data that is going to be written to disc be known before the files start to get written. The original question asked about a mkdvdfs, which implies they want something like being able to simply put an MPEG-1 or MPEG-2 encoded video stream onto the disc and expect it to be played with standard DVD software as a DVD, this is not a real possibility. That is what I was pointing out.
From what I've learned through speaking with people at Sigma Designs (Hollywood+ and the DXR3 chipset makers) linux drivers are not going to be coming out for current or past generation decoders because of CSS and AC-3 decoding being done in software. Under linux their is a hieghtened fear of someone reverse engineering the code (which appears to be founded) and their appear to be significant differences between how Windows and Linux handle libraries/DLLs. These differences have thus forced them to not release linux drivers for linux. There is also a problem with in-house development experience with Linux (at Sigma Designs).
Companies seemingly do not want to put out any DVD decoder based product on Linux that has software decoder/decryption involved.
There are alternative DVD decoder vendors (this LiViD project aims with Matrox addon and standalone cards) which don't have this problem of software decoding and are in fact releasing programming information.
A note, the Creative Labs Dxr2 does not have any software based decoding/decryption so it is possible that they could release binary drivers for that product if they chose to. But they keep citing a NDA problem with C-Cube (the chipset makers of that card). If someone can get licensing from C-Cube, Creative labs would probably work with them to get Linux drivers for the DXR2 out.
What are the laws regarding reverse engineering, specifically reverse engineering a piece of software that has a specific clause in it's usage license not to reverse engineer or dissasemble the code? Are there any ways around a reverse engineering clause of a software product? Could someone, for instance, dissasemble a DLL or EXE in windows and figure out how it works. Then take their knowledge (not in electronic code form but written english/spanish/swahili(sp)/etc or through speaking) and pass it on to someone else who could then make a software product from that information. Would that constitute breaking the reverse engineering clause?
It was my understanding that the Wine approach hadn't worked yet because of the mechanisms built into the DLLs and dvd player programs to help prohibit debugging and dissasembly. It is not clear that this code would allow anything to be made that would now allow the Wine approach to work. In order for it to work some kind of middle man process would need to be stuck in between the DVD drive and the player software (software would establish a conneciton with the middle man as would the drive). Even then, it may be that the DLL that the win32 app is using for this simply can't be run properly under wine, so even this middle man approach wouldn't work.
DVD-RAM is not compatible with current players and most DVD drives. And a mkdvdfs isn't likely to be coming around in the form you are thinking about. Even DVD-RAM uses standard DVD Spec format for disc layout. As such a disc has to be imaged and then burned (the format has a lot of pointers to disc areas that need to be static before anything is put to disc). As such, authoring software will be needed and will most likely not be free unless someone figures out the DVD Spec on their own. Otherwise the specs need to be bought at US$5000 (US$500 each additional copy).
The Linuxtv.org project is ongoing. Final arrangments are being made for manufacturing. Dirvers are in the works. And the coders for the project are keeping people informed of their status through the LinuxDVD mailing list. To see the archives or join the list go to:
This needs to be established as of yet. This code was released before anyone checked into the legal end of things. I'm sure Mathew P. and the source codes "creator" will be contacted to cease and desist distribution of this code. The anonymous source (who isn't entirely anonymous, as far as I know, as he made himself known on other forums) will be at the most risk here for legal problems. Best idea now is to download the code. Get it spread around as widely as possible. It may not be able to be used legally when all is said and done, but at least it will be out there for others to work with.
Chances are it will not happen, ever. There are legal issues that bind them from doing it. As I've said in the past, however, the next set of decoder cards to be coming out will most likely have linux drivers from the vendors (but most likely not open source).
I agree with your last statement, that open source is one of the only (if not the only) development model that would allow the project/application to survive a political/ego induced problem as was detailed above. And that is a good thing... a testament to the power and utility of open source development. I also agree that removes limits on creativity that is found under closed source models.
But you also seem to indicate that in order to really be considered operating under an open source development model, the project can't have any authority mechanism in place for how the code develops. As if chaos in the cvs tree with little or no direction is the only viable path to follow to be considered open source. This, I think it's important to say, is not true.
Any successful open source developed application I've seen has followed an implementation of having at least one person at the top of the project who brought it all together. At least one person to filter the chaos and make it into something cohesive. Open source is just what you said - a model - not an implementation. Make sure you don't miss the point.
This is the notion that Winnow and Chaffing (sorry is the spelling is wrong) operates. It isn't a new idea, but application to today's network systems was recently (within the last year?) brought up by the R and S in RSA (Rivest and the other name I forget... Shamir?). The idea is simply to flood any given packetized connection with false signatured/authenticated garbage. The packets that are good are also signed/authenticated but they actually will check out correctly when the signature is checked. Depending on how small the packets are different methods of creating the "chaff" packets can be effectively utilized in this scheme. In this method corrent information can travel somewhat securely in the clear among "noise."
Future DIVX Only releases
on
DIVX is dead
·
· Score: 1
Does anyone know what will happen concerning the titles that were to be coming out in the next few months that were going to be DIVX Only, an example being The Thin Read Line from Disney. What message will the studios get from this, especially those that were supporting DIVX? Will they say, "DIVX was going no where anyway, time to seriously invest in DVD" or will they take it like, "Well, DIVX is done. Maybe this means theres not enough stability here and we should back off of DVD as well." How's the industry likley to react to this?
Yes, there is CSS implemented on the hardware. But from my understanding it only takes care of the MPEG/Video stream and Sub-Picture Streams. It does not (in most products) take care of the AC-3/Audio streams. This is the case on the Hollywood+ and (since the same chipsets are used as far as I know) the Dxr3. Also, AC-3 to PCM/Stereo downmixing does not happen in hardware. I was told by Sigma Designs representatives that this was handled in software since their chipset didn't deal with the AC-3 streams.
This all makes sense with the "rules" that once a CSS encrypted data stream is decrypted, it can not be passed to anything but an output source. So, a hardware implementation of CSS couldn't pass unencrypted data back out the card to the computer or the card's data bus. The fact that I have yet to see a decoder board without a VGA and s-Video/RCAvideo connector for output supports this. This also means that if the aC-3 is indeed not handled in the hardware on the boards I mentioned (and I suspect at least a few others) that there would need to be a CSS implementation in software.
I'm willing to admit I may have the wrong idea of how things work. But I got a good portion of my information straight from Sigma Designs and my reading of the DVD-Video Specs.
As for why they arent' releasing information on the decoder boards. It is mostly a legal issue. They have to protect their agreements to keep CSS implementation tightly gaurded. This seems to agree with a statement made in a previous posting regarding Creative or C-Cube not releasing info until you have a DVD-Video consortium license and a CSS license. Everyone is tryign to cover their ass and not get sued.
As I said previously the next geenration chipset coming out of Sigma Designs will take care of this Ac-3/CSS software decoding/downmixing issue and allow for a binary linux driver release. You will not see a open source release until restrictions on CSS are loosened or the algorithm and handshaking is publiic knowledge.
This is much less likely to happen under the way they actually license. They do not license to the company persay. They actually license the CSS specs to individuals. For instance there are two people at Sigma Designs that actually know what the CSS specs are, same at IBM, and every other company involved. These two people are most directly responsible (the company that they work for is also held responsible on a financial basis). So these two people have a great incentive to keep those specs either on their persons at all times or in a very secure place.:)
Protect wasn't necessarily the best word I could have used there. Unfortunately a better one isn't coming to mind. I've spoken to Sigma Designs on this at great length and the reasons I was given that there wasn't linux support for their current products were:
1) They didn't have anyone inhouse that had done linux driver development previously. They were rectifying that problem, however.
2) Their CSS license would not allow for a linux OS software release. While they didn't go into detail on their licensing terms, it does make some sense that it would be much more likely to be hacked or reverse engineered by the linux community than the Windows community. Not necessarily out of malicious pretenses, but higher "knowledge bar" in the linux OS and the people that use it than the windows community.
3) They were developing a new chipset that would handle all this in hardware, and it's expected to be out in the second quarter of 1999. This being the case it made little sense from a business standpoint to go back and write drivers and application software for the older products (hollywood+ and related chipsets) when they had something new coming out that would be much easier to work with (from both a legal/licensing standpoint and a development standpoint).
Current generation hardware DVD decoding products and their related software do not have industry support in linux for at least one major reason. Most products out today perform the AC-3 decoding in software. This means that there is an associated CSS decryption happening in software. Because of this, companies are not jumping at the chance to do linux support. It would require software CSS handling routines and in the linux OS these routines are not as "protected" as they are in the windows or other supported OSes, from reverse engineering and hacking.
There will be linux support in the next generation of hardware decoding devices (expect something out of Sigma Designs in the next 6 months if not sooner) since this issue will be overcome. New decoding chipsets will do all decoding and decryption on chip, meaning there will be little in the way of software driver requirements and writing applications to support the newer hardware will be much easier than in the current generation of products.
For those companies that put out products now that don't do any CSS or ac-3 stuff in software, then their only reason for nopt supporting linux is that they don't have the manpower to do it themselves or they don't see the market yet.
The difficulty of the encoding methods and syncronization and whatnot are not the tough issues with this, which is precluding any open source development regarding DVD on Linux. It is the legal and licensing issues.
The DVD specs cost $5000 and an NDA signing to get a hold of. This is for one copy of the library (a few books totalling maybe 1500-2000 pages). This information could not be shared with anyone for development purposes. Point 1 against open source DVD products.
CSS encryption is very tightly controlled (the knowledge of what the algorithms involved are, that is). In order to get them one must sign very stringent NDAs and contracts with Matsushita. This licensing is free, however. Contrary to some statements made previously in other replies. But gaining access to these routines would be possible for an individual, not a whole group of people. Point 2 against open source dvd products.
Point three is that even though the AC-3 and Mpeg-2 specs are freely available (and we'll assume you have access to the required DVD specs to know how the mpeg and ac-3 data is stored) each has royalties and licensing associated with it. Well, I know Ac-3 does, I'm not sure about Mpeg2. This being the case, even if the products was developed open source (which points 1 and 2 preclude) there would be a per distributed copy charge for the ac-3 handling code. Not free software. While this doesn't mean open source development has a point against it in this case, it is a big deterrent.
I'm not sure why you basically called my entire post FUD. I'm not a newbie. I'm not a windows advocate. I love Linux, as well as OS/2 and can't wait to give BeOS a try. I wasn't posting FUD. I was posting fact. For instance, on the XF86Config tweaking which you declare as being FUD. I just recently installed RH 5.2 on my system (first time for RH, I ran slackware several times over the last three years or so) and my card was not autodected or on the list of cards under the xf86config script. I had to go out and find a server not included in the distro (slightly daunting and an annoyance), put it in the right directory (granted not a hard thing to do in and of itself, but to the novice who doesn't know where everything goes I think this would be more difficult), and manually alter the XF86Config file to get it to work correctly with the card and monitor combo I have. None of this is performance tweaking, mind you, this was just to get X up and running with better than 256 colors and 640x480 resolution.
All the other point I made were similar in that they were problems encountered in the recent install I did. Again, I'm not a newbie, I've been installing Linux for better than 4 years now and have been into computers for more than 14 now.
My simple point is this. Linux is at least an annoyance to setup right now (based on my experience with Slackware and RH, I'm guessing the other distro's are also). At most it is daunting and very difficult to setup. Things are getting better, and they will continue to. But it seems clear to me that if people are going to have to put up with installing an OS in the first place, they are going to pick something that has current wide range support and is the least likely to piss them off (Windows installation is generally quite easy, done in 30 minutes as compared to an hour or more for a linux installation).
Just because my statements presented here are somewhat "anti-linux" doesn't mean I'm some Windows drone or that they are FUD statements.
All this analysis is not worthless. The key reason is because the market can be easily manipulated. The major manipulation tool is media, which is exactly what I'm betting this article goes into (if I could read it, I wouldn't have to bet).
The media has created a major buzz about this OS and the "Open Source Movement". As a result the market is giving Linux and OSS a much harder look than it probbaly would have at this time. The last phrase is the most important: at this time. Sure, Linux might have caught on a few years down the road without the push the media has given it lately, but at least then it would have been ready.
All this media attention is forcing things. In short, Linux is not ready for the mainstream commercial world. It'll continue to be used on some web servers and inter-company file servers and whatnot, but it is not ready to make the populace at large happy. While basic installation is getting easy (as long as you have all supported hardware), that is about where the ride will end for the large majority of people trying this out. X can still be a major pain in the ass to setup (no average joe is going to pour through the XF86Config file and tweak it manually or have much luck in finding the right server for his card). Getting email working can be trying, unless one used Netscape's mail abilities. And there isn't too much idiot proofing in the OS as a whole, and we all know that with media hyping comes a whole bunch of people who don't think for themselves and aren't really all that interested in learning how to (both central requirements for a successful Linux installation, I'd say).
The market isn't ready yet. More specifically, Linux isn't ready to go to market (we have to cater to them, they aren't going to be forgiving of us).
Some of us border folks were considering stocking up on shloads of CD-Rs at $1 US apiece and smuggling them across the border - making a bit o' profit and saving you guys the bad evilness of paying a tax to the RIAA...
MS has market share out the wazooo... They can afford to lose some to get a better standing with the DOJ, who is only concerned with MS OSes and Web Browsers right now. By porting Office, they create a lessening of their Win OS market share for the near term and gain market share in a fast growing segment. they look like they want other OSes but in reality they only get to control an entire app segment on a new OS in the near term, allowing them to control it's use later on down the road when the DOJ smoke clears...
I say we let him do it though. It helps us in the long run because MS will end up getting bitten by trying to steer Linux. Bill is a smart man, but he simply can't outwit the entire OSS and Linux community.
In the short term it will help Linux gain some much needed market share, especially on the desktop/workstation. Long term though, and this is the direction that we really need to think when considering Linux, it will probably stiffle the development of better Office like suites on Linux if:
1) A MS release of Office on Linux is GPL'd or source is released. (people will more than likely try to "fix" Office instead of work on better/cleaner suites) 2) Microsoft actually keeps up development and releases under Linux. Remember that Office under MacOs is somewhat worse than Office under Win.
Both are not likely to happen. This,if it turns out to be true, is probably just MS trying to look like is it "with the community" and as a ploy to fend off DOJ monopoly assertions. So, if MS releases a version or two for Linux and then lets it die I think that it will, in the end, help out Linux. If they keep it going though it could pose as a roadblock to acceptance of better office like suites for linux in the future. Release of any office source code brings a wild card into things that I really don't have any clear thoughts on (midnight here, I should be in bed sleeping:)
Slashdot Mirror
I have heard similar things from others about the RE laws in Europe. And I think you are right that it is intended and used for file format compatibility and that kind of thing. As such I dont' see how REing the CSS mechanisms in a DVD player would be considered legal. You are not maintaining any kind of compatibility. The only way I can seeit being able to be legal under that law is to claim you did it for maintaining compatibility with other DVD authoring software. Even then, one could only legally RE the encryption algorithm used and perhaps where on the disc one has to place the disc and title keys.
It is a royal pain to boot to Windows simply to watch a DVD movie.
Current DVDs (the large majority of them) use a Bridge format. MicroUDF and ISO9660. This allows current ISO9660 file systems to use them without any problems (assuming they have a large enough address space built into them) but will maintain compatibility once full UDF based ones start coming out and players start using that filesystem to access the discs.
This has absolutly nothing to do with the data layout of DVD-Video data, though. That requires that all the data that is going to be written to disc be known before the files start to get written. The original question asked about a mkdvdfs, which implies they want something like being able to simply put an MPEG-1 or MPEG-2 encoded video stream onto the disc and expect it to be played with standard DVD software as a DVD, this is not a real possibility. That is what I was pointing out.
From what I've learned through speaking with people at Sigma Designs (Hollywood+ and the DXR3 chipset makers) linux drivers are not going to be coming out for current or past generation decoders because of CSS and AC-3 decoding being done in software. Under linux their is a hieghtened fear of someone reverse engineering the code (which appears to be founded) and their appear to be significant differences between how Windows and Linux handle libraries/DLLs. These differences have thus forced them to not release linux drivers for linux. There is also a problem with in-house development experience with Linux (at Sigma Designs).
Companies seemingly do not want to put out any DVD decoder based product on Linux that has software decoder/decryption involved.
There are alternative DVD decoder vendors (this LiViD project aims with Matrox addon and standalone cards) which don't have this problem of software decoding and are in fact releasing programming information.
A note, the Creative Labs Dxr2 does not have any software based decoding/decryption so it is possible that they could release binary drivers for that product if they chose to. But they keep citing a NDA problem with C-Cube (the chipset makers of that card). If someone can get licensing from C-Cube, Creative labs would probably work with them to get Linux drivers for the DXR2 out.
What are the laws regarding reverse engineering, specifically reverse engineering a piece of software that has a specific clause in it's usage license not to reverse engineer or dissasemble the code? Are there any ways around a reverse engineering clause of a software product? Could someone, for instance, dissasemble a DLL or EXE in windows and figure out how it works. Then take their knowledge (not in electronic code form but written english/spanish/swahili(sp)/etc or through speaking) and pass it on to someone else who could then make a software product from that information. Would that constitute breaking the reverse engineering clause?
It was my understanding that the Wine approach hadn't worked yet because of the mechanisms built into the DLLs and dvd player programs to help prohibit debugging and dissasembly. It is not clear that this code would allow anything to be made that would now allow the Wine approach to work. In order for it to work some kind of middle man process would need to be stuck in between the DVD drive and the player software (software would establish a conneciton with the middle man as would the drive). Even then, it may be that the DLL that the win32 app is using for this simply can't be run properly under wine, so even this middle man approach wouldn't work.
DVD under linux is still a while off.
DVD-RAM is not compatible with current players and most DVD drives. And a mkdvdfs isn't likely to be coming around in the form you are thinking about. Even DVD-RAM uses standard DVD Spec format for disc layout. As such a disc has to be imaged and then burned (the format has a lot of pointers to disc areas that need to be static before anything is put to disc). As such, authoring software will be needed and will most likely not be free unless someone figures out the DVD Spec on their own. Otherwise the specs need to be bought at US$5000 (US$500 each additional copy).
The Linuxtv.org project is ongoing. Final arrangments are being made for manufacturing. Dirvers are in the works. And the coders for the project are keeping people informed of their status through the LinuxDVD mailing list. To see the archives or join the list go to:
http://linuxdvd.corepower.com
This needs to be established as of yet. This code was released before anyone checked into the legal end of things. I'm sure Mathew P. and the source codes "creator" will be contacted to cease and desist distribution of this code. The anonymous source (who isn't entirely anonymous, as far as I know, as he made himself known on other forums) will be at the most risk here for legal problems. Best idea now is to download the code. Get it spread around as widely as possible. It may not be able to be used legally when all is said and done, but at least it will be out there for others to work with.
Chances are it will not happen, ever. There are legal issues that bind them from doing it. As I've said in the past, however, the next set of decoder cards to be coming out will most likely have linux drivers from the vendors (but most likely not open source).
I agree with your last statement, that open source is one of the only (if not the only) development model that would allow the project/application to survive a political/ego induced problem as was detailed above. And that is a good thing... a testament to the power and utility of open source development. I also agree that removes limits on creativity that is found under closed source models.
But you also seem to indicate that in order to really be considered operating under an open source development model, the project can't have any authority mechanism in place for how the code develops. As if chaos in the cvs tree with little or no direction is the only viable path to follow to be considered open source. This, I think it's important to say, is not true.
Any successful open source developed application I've seen has followed an implementation of having at least one person at the top of the project who brought it all together. At least one person to filter the chaos and make it into something cohesive. Open source is just what you said - a model - not an implementation. Make sure you don't miss the point.
This is the notion that Winnow and Chaffing (sorry is the spelling is wrong) operates. It isn't a new idea, but application to today's network systems was recently (within the last year?) brought up by the R and S in RSA (Rivest and the other name I forget... Shamir?). The idea is simply to flood any given packetized connection with false signatured/authenticated garbage. The packets that are good are also signed/authenticated but they actually will check out correctly when the signature is checked. Depending on how small the packets are different methods of creating the "chaff" packets can be effectively utilized in this scheme. In this method corrent information can travel somewhat securely in the clear among "noise."
Does anyone know what will happen concerning the titles that were to be coming out in the next few months that were going to be DIVX Only, an example being The Thin Read Line from Disney. What message will the studios get from this, especially those that were supporting DIVX? Will they say, "DIVX was going no where anyway, time to seriously invest in DVD" or will they take it like, "Well, DIVX is done. Maybe this means theres not enough stability here and we should back off of DVD as well." How's the industry likley to react to this?
Yes, there is CSS implemented on the hardware. But from my understanding it only takes care of the MPEG/Video stream and Sub-Picture Streams. It does not (in most products) take care of the AC-3/Audio streams. This is the case on the Hollywood+ and (since the same chipsets are used as far as I know) the Dxr3. Also, AC-3 to PCM/Stereo downmixing does not happen in hardware. I was told by Sigma Designs representatives that this was handled in software since their chipset didn't deal with the AC-3 streams.
This all makes sense with the "rules" that once a CSS encrypted data stream is decrypted, it can not be passed to anything but an output source. So, a hardware implementation of CSS couldn't pass unencrypted data back out the card to the computer or the card's data bus. The fact that I have yet to see a decoder board without a VGA and s-Video/RCAvideo connector for output supports this. This also means that if the aC-3 is indeed not handled in the hardware on the boards I mentioned (and I suspect at least a few others) that there would need to be a CSS implementation in software.
I'm willing to admit I may have the wrong idea of how things work. But I got a good portion of my information straight from Sigma Designs and my reading of the DVD-Video Specs.
As for why they arent' releasing information on the decoder boards. It is mostly a legal issue. They have to protect their agreements to keep CSS implementation tightly gaurded. This seems to agree with a statement made in a previous posting regarding Creative or C-Cube not releasing info until you have a DVD-Video consortium license and a CSS license. Everyone is tryign to cover their ass and not get sued.
As I said previously the next geenration chipset coming out of Sigma Designs will take care of this Ac-3/CSS software decoding/downmixing issue and allow for a binary linux driver release. You will not see a open source release until restrictions on CSS are loosened or the algorithm and handshaking is publiic knowledge.
This is much less likely to happen under the way they actually license. They do not license to the company persay. They actually license the CSS specs to individuals. For instance there are two people at Sigma Designs that actually know what the CSS specs are, same at IBM, and every other company involved. These two people are most directly responsible (the company that they work for is also held responsible on a financial basis). So these two people have a great incentive to keep those specs either on their persons at all times or in a very secure place. :)
Protect wasn't necessarily the best word I could have used there. Unfortunately a better one isn't coming to mind. I've spoken to Sigma Designs on this at great length and the reasons I was given that there wasn't linux support for their current products were:
1) They didn't have anyone inhouse that had done linux driver development previously. They were rectifying that problem, however.
2) Their CSS license would not allow for a linux OS software release. While they didn't go into detail on their licensing terms, it does make some sense that it would be much more likely to be hacked or reverse engineered by the linux community than the Windows community. Not necessarily out of malicious pretenses, but higher "knowledge bar" in the linux OS and the people that use it than the windows community.
3) They were developing a new chipset that would handle all this in hardware, and it's expected to be out in the second quarter of 1999. This being the case it made little sense from a business standpoint to go back and write drivers and application software for the older products (hollywood+ and related chipsets) when they had something new coming out that would be much easier to work with (from both a legal/licensing standpoint and a development standpoint).
Current generation hardware DVD decoding products and their related software do not have industry support in linux for at least one major reason. Most products out today perform the AC-3 decoding in software. This means that there is an associated CSS decryption happening in software. Because of this, companies are not jumping at the chance to do linux support. It would require software CSS handling routines and in the linux OS these routines are not as "protected" as they are in the windows or other supported OSes, from reverse engineering and hacking.
There will be linux support in the next generation of hardware decoding devices (expect something out of Sigma Designs in the next 6 months if not sooner) since this issue will be overcome. New decoding chipsets will do all decoding and decryption on chip, meaning there will be little in the way of software driver requirements and writing applications to support the newer hardware will be much easier than in the current generation of products.
For those companies that put out products now that don't do any CSS or ac-3 stuff in software, then their only reason for nopt supporting linux is that they don't have the manpower to do it themselves or they don't see the market yet.
The difficulty of the encoding methods and syncronization and whatnot are not the tough issues with this, which is precluding any open source development regarding DVD on Linux. It is the legal and licensing issues.
The DVD specs cost $5000 and an NDA signing to get a hold of. This is for one copy of the library (a few books totalling maybe 1500-2000 pages). This information could not be shared with anyone for development purposes. Point 1 against open source DVD products.
CSS encryption is very tightly controlled (the knowledge of what the algorithms involved are, that is). In order to get them one must sign very stringent NDAs and contracts with Matsushita. This licensing is free, however. Contrary to some statements made previously in other replies. But gaining access to these routines would be possible for an individual, not a whole group of people. Point 2 against open source dvd products.
Point three is that even though the AC-3 and Mpeg-2 specs are freely available (and we'll assume you have access to the required DVD specs to know how the mpeg and ac-3 data is stored) each has royalties and licensing associated with it. Well, I know Ac-3 does, I'm not sure about Mpeg2. This being the case, even if the products was developed open source (which points 1 and 2 preclude) there would be a per distributed copy charge for the ac-3 handling code. Not free software. While this doesn't mean open source development has a point against it in this case, it is a big deterrent.
I'm not sure why you basically called my entire post FUD. I'm not a newbie. I'm not a windows advocate. I love Linux, as well as OS/2 and can't wait to give BeOS a try. I wasn't posting FUD. I was posting fact. For instance, on the XF86Config tweaking which you declare as being FUD. I just recently installed RH 5.2 on my system (first time for RH, I ran slackware several times over the last three years or so) and my card was not autodected or on the list of cards under the xf86config script. I had to go out and find a server not included in the distro (slightly daunting and an annoyance), put it in the right directory (granted not a hard thing to do in and of itself, but to the novice who doesn't know where everything goes I think this would be more difficult), and manually alter the XF86Config file to get it to work correctly with the card and monitor combo I have. None of this is performance tweaking, mind you, this was just to get X up and running with better than 256 colors and 640x480 resolution.
All the other point I made were similar in that they were problems encountered in the recent install I did. Again, I'm not a newbie, I've been installing Linux for better than 4 years now and have been into computers for more than 14 now.
My simple point is this. Linux is at least an annoyance to setup right now (based on my experience with Slackware and RH, I'm guessing the other distro's are also). At most it is daunting and very difficult to setup. Things are getting better, and they will continue to. But it seems clear to me that if people are going to have to put up with installing an OS in the first place, they are going to pick something that has current wide range support and is the least likely to piss them off (Windows installation is generally quite easy, done in 30 minutes as compared to an hour or more for a linux installation).
Just because my statements presented here are somewhat "anti-linux" doesn't mean I'm some Windows drone or that they are FUD statements.
All this analysis is not worthless. The key reason is because the market can be easily manipulated. The major manipulation tool is media, which is exactly what I'm betting this article goes into (if I could read it, I wouldn't have to bet).
The media has created a major buzz about this OS and the "Open Source Movement". As a result the market is giving Linux and OSS a much harder look than it probbaly would have at this time. The last phrase is the most important: at this time. Sure, Linux might have caught on a few years down the road without the push the media has given it lately, but at least then it would have been ready.
All this media attention is forcing things. In short, Linux is not ready for the mainstream commercial world. It'll continue to be used on some web servers and inter-company file servers and whatnot, but it is not ready to make the populace at large happy. While basic installation is getting easy (as long as you have all supported hardware), that is about where the ride will end for the large majority of people trying this out. X can still be a major pain in the ass to setup (no average joe is going to pour through the XF86Config file and tweak it manually or have much luck in finding the right server for his card). Getting email working can be trying, unless one used Netscape's mail abilities. And there isn't too much idiot proofing in the OS as a whole, and we all know that with media hyping comes a whole bunch of people who don't think for themselves and aren't really all that interested in learning how to (both central requirements for a successful Linux installation, I'd say).
The market isn't ready yet. More specifically, Linux isn't ready to go to market (we have to cater to them, they aren't going to be forgiving of us).
Some of us border folks were considering stocking up on shloads of CD-Rs at $1 US apiece and smuggling them across the border - making a bit o' profit and saving you guys the bad evilness of paying a tax to the RIAA...
MS has market share out the wazooo... They can afford to lose some to get a better standing with the DOJ, who is only concerned with MS OSes and Web Browsers right now. By porting Office, they create a lessening of their Win OS market share for the near term and gain market share in a fast growing segment. they look like they want other OSes but in reality they only get to control an entire app segment on a new OS in the near term, allowing them to control it's use later on down the road when the DOJ smoke clears...
I say we let him do it though. It helps us in the long run because MS will end up getting bitten by trying to steer Linux. Bill is a smart man, but he simply can't outwit the entire OSS and Linux community.
In the short term it will help Linux gain some much needed market share, especially on the desktop/workstation. Long term though, and this is the direction that we really need to think when considering Linux, it will probably stiffle the development of better Office like suites on Linux if:
:)
1) A MS release of Office on Linux is GPL'd or source is released. (people will more than likely try to "fix" Office instead of work on better/cleaner suites)
2) Microsoft actually keeps up development and releases under Linux. Remember that Office under MacOs is somewhat worse than Office under Win.
Both are not likely to happen. This,if it turns out to be true, is probably just MS trying to look like is it "with the community" and as a ploy to fend off DOJ monopoly assertions. So, if MS releases a version or two for Linux and then lets it die I think that it will, in the end, help out Linux. If they keep it going though it could pose as a roadblock to acceptance of better office like suites for linux in the future. Release of any office source code brings a wild card into things that I really don't have any clear thoughts on (midnight here, I should be in bed sleeping