This sounds like an excellent reason to avoid H.264. But what if a system were set up whereby all the H.264 decoding was done purely in the video card? The application (such as the Firefox browser) would identify an area of its display for video location. That area would be passed on via the video display layer (X and it's video chipset driver) as translated to the full display, to the video card/chipset. Associated with that identified display location would be a data stream, with flow control, as well as an additional substream for metadata such as decryption keys where needed. Then the browser merely feeds a raw bit stream that X passes on to the video card.
Is MPEG-LA going to want to claim licensing of the browser and/or display system (X) just because they are passing along a bit stream (that may even be encoded in something else besides an MPEG/H.264 format, so the software might never even know what it is) ?
Even if they don't claim a right to license the raw bitstream transmissions just because the data might contain something encoded in a format they hold rights to, there is still an issue around licensing "per encoding". They are wanting to charges licensing at that stage based on how many viewers are actually going to decode and view it, or even potential viewers (e.g. licensing of broadcasts by market size). None of the articles gave any info on how the market size fits in per video hosted on a web site, since the potential "market" for a web page is the entire world.
I emailed that organization about 3 years ago and specifically asked for licensing information. I got no answer. Perhaps they just don't want to address licensing issues for millions of individual web sites? But they clearly aren't coming out and saying those will be free, either.
I did contact Unisys about licensing LZW, for inside GIF, many years back when that was an issue. At least to their credit they did answer, and were willing to discuss it. The problem was, the terms just didn't want to recognize a small operation that was generating GIFs on the fly (so there would have been LZW encoding going on, or else uncompressed GIFs). They wanted to license based on factors that I could not provide, such as number of subscribers (since there were no subscribers... they didn't understand the web very well back then). The only alternative was a flat rate that was around ten times my whole first years startup costs. The lady I spoke with at Unisys did personally understand the issues, and acknowledged to me that she could clearly see that the licensing structure didn't work for me, and that her management clearly "did not get it" with respect to web usage. She also acknowledged that they were unlikely to ever make any effort to straighten it out with respect to "small users" that, in total, represented less than one percent of their licensing revenue.
BTW, I would have switched to PNG for that project, but the PNG group made a serious error in not including basic animation within the standard. So don't get any idea that the open standards community does things well, either. PNG is a clear case of failing to completely address a need (they tried to replace GIF without addressing all of what GIF could do).
MPEG-LA licensing seems to be as equally messed up as Unisys was. Maybe the same clueless management is there? Or maybe it's all the owners of all the patent components they are bundling that have turned it into a camel?
Anyway, unless and until this is fixed (which I doubt will ever happen), then MPEG/H.264 is something for the open source, open standards, open access, open information, communities to stay away from. PNG, despite its omissions, did succeed to supplant a large portion of GIFs and managed to stay on as a viable image format. MNG, the motion successor to PNG, I'm not so sure of. JPEG did the rest and GIF pretty much was clobbered until the LZW patent ran out in most of the world.
PNG didn't do as well as GIF and/or JPEG in most cases. Yet it
But this is tele over the internet, right? If all you have is a computer and high speed internet, but no tele, do you, or do you not, have to pay a license fee? And what if (you Brits) are overseas and want to see the tele shows from back home?
Would it be possible to upload a program that gives the wheels and the robotic arm short command pulses in alternating directions, at a resonant frequency tuned by the extension of the arm, to rock the rover loose in one direction or the other? Is that what the "wheel wiggles" mentioned are? Was the arm being swung in sync with these wiggles?
There was no substance inside the Gatorade bottle? And there are science and technology teachers in this school (or at least there are supposed to be) that could have taken a look at this and immediately figured it out? How many Gatorade bottles are opaque? Does this school principal even have any technology and science education?
I'm just sick of stupidity being attracted to our schools. We need to educate kids, not dumb them down to the level of school administrators. We need this especially so in science and technology. And we need to have the very best quality at our technology magnet schools.
... before following any of the above advice. By all means do NOT let the client/customer write the license or you will end up being liable for everything.
Writing a separate license could get YOU into some new legal liabilities, including the expectation of support, reliability, suitability for their purposes, and possibly even financially liable for their failures.
Just tell them straight up that it appears they have made a grave error in the analysis of open source licenses and have assumed that the GPL license is universal in open source. Explain to them ONCE (and tell them this is their ONE and only chance to get this clue) that BSD is different than lots of other open source licenses.
But if you do decide to humor these idiots, you better have an experienced team of licensing lawyers review the license you have with them to be sure you didn't just stuck your neck out under their knife. They will want to pass on all liabilities to you. If they didn't make the mistake of misunderstanding BSD, then this is exactly what they are trying to do.
I'm not willing to give up on vertical alignment. And lots of code sections I've written, in addition to ascii-art comments to explain lots of code, really needs that vertical alignment. And that's not just leading alignment, it is internal alignment.
This won't break Python's indentation based syntax because one should be using consistent indentation. But many displays of proportional fonts will collapse multiple spaces into the space of one, and even Python becomes hard to read.
The solution is to have a proper display system that can do both proportional fonts AND controlled alignment at the same time, without mangling the code files themselves, for all active programming languages (and that's a LOT of them). Inserting invisible alignment into the code is not an option unless we can teach every language parse to remove such alignment elements before parsing the code for what it is coded for. Someone could do this with a new language I don't doubt. But it remains to be seen if anyone can do it in general for all existing active languages.
Oh, and if you do come up with a solution and it just can't manage to achieve it with COBOL, I won't cry. But it better work with assembly and microcode syntax.
So the next big question is, how long will it take for all the über geeks at Google to make it happen? I wonder if they can pull it off quicker than the time it takes to hire a new person.
Where's the obligatory URL to a H.264 decoder chip with a fully documented and open, royalty-free and unencumbered INTERFACE (we don't need a driver for BSD or Linux, because if it is truly an open chip, the driver will be developed)?
I have no issue with using some proprietary patent encumbered protocol or format where all the work to process it is inside a licensable piece of hardware (which could even have its own firmware and CPU built inside to do it all). If the manufacturer of the chip requires that it be pre-loaded with a binary blob, it's OK to do it this way, too, as long as they make the blob itself freely available and freely distributable as a separate file (it doesn't have to be integrated into GPL software when it's a separate file... for example the driver for the chip can create/proc/load-the-h264-blob-here and let an init script provide it from the file).
Having a better box to get better stuff is always a good thing. But having to get a better box just for the same old stuff done poorly is always a stupid thing. Let me know when they have the latest dual-socket octo-core i7 processor with 64GB of RAM in a nice portable netbook form factor.
... web sites continue to not warn their IE users about the security vulnerabilities in the clients those users are running. They could warn those users each time they visit with IE. But they don't. It's time the webmasters of the world start to do something about the problem and put a big full page notice in front of all IE based visitors warning them about the troubles with IE and urging them to switch to a safer browser (and give some links, too).
Converting the existing videos is not the issue. That can be done slowly. Converting new videos is where it's at. The obvious solution is for YT to offer the videos in TWO formats: the most efficient format, and the most efficient open format. Let the HTTP headers automatically determine that with the Accept statement, and provide a fallback via some Javascript on the page that allows selecting the preferred format in case something is not working. There should also be such a selection for reducing the video resolution, too (e.g. "show me only low definition because my ISP sucks and can't handle HD"). Don't worry about converting all the old videos. Convert the popular ones and put a link in the template to let people ask for a conversion on less popular ones. I'm sure there's a ton of videos out there no one watches anymore.
Things can change. There is enough bandwidth NOW (wasn't a few years ago). The real problem is Vorbis just isn't stable as a standard, yet. They need to push to get a stable "Vorbis V1" and put future work into "Vorbis V2". Youtube can simply offer the option of video formats based on the HTTP headers in the request. Seems to me based on what you say, we only need TWO formats, anyway... one for corporate profits and one for the people.
An apparent requirement was to squeeze the year into a single byte. They just did it very badly by choosing BCD format for the last 2 digits of the year, and assuming every new CS grad would know what that means, and would understand by examining the existing data field where 0x03 was present for 2003 and 0x04 was present for 2004 that it must be in BCD. Since BCD and plain binary share the same values for 2000 through 2009, it fully depended on the programmer reading AND UNDERSTANDING the documentation to get it right... if the documentation even reliably pointed this out.
We need to get away from BCD encodings. It was convenient for hardware level protocols because they allowed displays of decimal digits without further conversion. Do we do that anymore? Unlikely. We have software or firmware, and that can do decimal conversions just fine. All NEW communications protocols should from this day forward use only one of a binary format with a documented resolution and sufficient bits to last until at least the year 2200, or characters with the date in a format with year first, month next, and day of month after that, or a plain decimal count of days since the epoch. Where an epoch is needed, it must be clearly documented.
My home and work internet access providers, a major cable TV provider, and a major incumbent telco provider, both do not have native IPv6 available. This is in the USA, where we need some leadership to take action and mandate universal IPv6 access everywhere, with a timetable for government sites to be increasingly available ONLY via IPv6. Unfortunately, this country has lacked leadership for many presidential terms, and continues to have this issue.
Slashdot Mirror
This sounds like an excellent reason to avoid H.264. But what if a system were set up whereby all the H.264 decoding was done purely in the video card? The application (such as the Firefox browser) would identify an area of its display for video location. That area would be passed on via the video display layer (X and it's video chipset driver) as translated to the full display, to the video card/chipset. Associated with that identified display location would be a data stream, with flow control, as well as an additional substream for metadata such as decryption keys where needed. Then the browser merely feeds a raw bit stream that X passes on to the video card.
Is MPEG-LA going to want to claim licensing of the browser and/or display system (X) just because they are passing along a bit stream (that may even be encoded in something else besides an MPEG/H.264 format, so the software might never even know what it is) ?
Even if they don't claim a right to license the raw bitstream transmissions just because the data might contain something encoded in a format they hold rights to, there is still an issue around licensing "per encoding". They are wanting to charges licensing at that stage based on how many viewers are actually going to decode and view it, or even potential viewers (e.g. licensing of broadcasts by market size). None of the articles gave any info on how the market size fits in per video hosted on a web site, since the potential "market" for a web page is the entire world.
I emailed that organization about 3 years ago and specifically asked for licensing information. I got no answer. Perhaps they just don't want to address licensing issues for millions of individual web sites? But they clearly aren't coming out and saying those will be free, either.
I did contact Unisys about licensing LZW, for inside GIF, many years back when that was an issue. At least to their credit they did answer, and were willing to discuss it. The problem was, the terms just didn't want to recognize a small operation that was generating GIFs on the fly (so there would have been LZW encoding going on, or else uncompressed GIFs). They wanted to license based on factors that I could not provide, such as number of subscribers (since there were no subscribers ... they didn't understand the web very well back then). The only alternative was a flat rate that was around ten times my whole first years startup costs. The lady I spoke with at Unisys did personally understand the issues, and acknowledged to me that she could clearly see that the licensing structure didn't work for me, and that her management clearly "did not get it" with respect to web usage. She also acknowledged that they were unlikely to ever make any effort to straighten it out with respect to "small users" that, in total, represented less than one percent of their licensing revenue.
BTW, I would have switched to PNG for that project, but the PNG group made a serious error in not including basic animation within the standard. So don't get any idea that the open standards community does things well, either. PNG is a clear case of failing to completely address a need (they tried to replace GIF without addressing all of what GIF could do).
MPEG-LA licensing seems to be as equally messed up as Unisys was. Maybe the same clueless management is there? Or maybe it's all the owners of all the patent components they are bundling that have turned it into a camel?
Anyway, unless and until this is fixed (which I doubt will ever happen), then MPEG/H.264 is something for the open source, open standards, open access, open information, communities to stay away from. PNG, despite its omissions, did succeed to supplant a large portion of GIFs and managed to stay on as a viable image format. MNG, the motion successor to PNG, I'm not so sure of. JPEG did the rest and GIF pretty much was clobbered until the LZW patent ran out in most of the world.
PNG didn't do as well as GIF and/or JPEG in most cases. Yet it
But this is tele over the internet, right? If all you have is a computer and high speed internet, but no tele, do you, or do you not, have to pay a license fee? And what if (you Brits) are overseas and want to see the tele shows from back home?
... Linux users that cannot view the DRM broadcasts won't have to pay the license fee?
... are they counting the Linux market as part of their revenue stream?
Would it be possible to upload a program that gives the wheels and the robotic arm short command pulses in alternating directions, at a resonant frequency tuned by the extension of the arm, to rock the rover loose in one direction or the other? Is that what the "wheel wiggles" mentioned are? Was the arm being swung in sync with these wiggles?
There was no substance inside the Gatorade bottle? And there are science and technology teachers in this school (or at least there are supposed to be) that could have taken a look at this and immediately figured it out? How many Gatorade bottles are opaque? Does this school principal even have any technology and science education?
I'm just sick of stupidity being attracted to our schools. We need to educate kids, not dumb them down to the level of school administrators. We need this especially so in science and technology. And we need to have the very best quality at our technology magnet schools.
... before following any of the above advice. By all means do NOT let the client/customer write the license or you will end up being liable for everything.
Writing a separate license could get YOU into some new legal liabilities, including the expectation of support, reliability, suitability for their purposes, and possibly even financially liable for their failures.
Just tell them straight up that it appears they have made a grave error in the analysis of open source licenses and have assumed that the GPL license is universal in open source. Explain to them ONCE (and tell them this is their ONE and only chance to get this clue) that BSD is different than lots of other open source licenses.
But if you do decide to humor these idiots, you better have an experienced team of licensing lawyers review the license you have with them to be sure you didn't just stuck your neck out under their knife. They will want to pass on all liabilities to you. If they didn't make the mistake of misunderstanding BSD, then this is exactly what they are trying to do.
... out there, regardless of the coding language, who are developing and writing their code on those old punch card systems ... you insensitive clod!
... but try it in assembly language.
But try it in assembly language.
I'm not willing to give up on vertical alignment. And lots of code sections I've written, in addition to ascii-art comments to explain lots of code, really needs that vertical alignment. And that's not just leading alignment, it is internal alignment.
This won't break Python's indentation based syntax because one should be using consistent indentation. But many displays of proportional fonts will collapse multiple spaces into the space of one, and even Python becomes hard to read.
The solution is to have a proper display system that can do both proportional fonts AND controlled alignment at the same time, without mangling the code files themselves, for all active programming languages (and that's a LOT of them). Inserting invisible alignment into the code is not an option unless we can teach every language parse to remove such alignment elements before parsing the code for what it is coded for. Someone could do this with a new language I don't doubt. But it remains to be seen if anyone can do it in general for all existing active languages.
Oh, and if you do come up with a solution and it just can't manage to achieve it with COBOL, I won't cry. But it better work with assembly and microcode syntax.
So the next big question is, how long will it take for all the über geeks at Google to make it happen? I wonder if they can pull it off quicker than the time it takes to hire a new person.
Let me know when the "no plug-in" version is available.
Where's the obligatory URL to a H.264 decoder chip with a fully documented and open, royalty-free and unencumbered INTERFACE (we don't need a driver for BSD or Linux, because if it is truly an open chip, the driver will be developed)?
I have no issue with using some proprietary patent encumbered protocol or format where all the work to process it is inside a licensable piece of hardware (which could even have its own firmware and CPU built inside to do it all). If the manufacturer of the chip requires that it be pre-loaded with a binary blob, it's OK to do it this way, too, as long as they make the blob itself freely available and freely distributable as a separate file (it doesn't have to be integrated into GPL software when it's a separate file ... for example the driver for the chip can create /proc/load-the-h264-blob-here and let an init script provide it from the file).
Having a better box to get better stuff is always a good thing. But having to get a better box just for the same old stuff done poorly is always a stupid thing. Let me know when they have the latest dual-socket octo-core i7 processor with 64GB of RAM in a nice portable netbook form factor.
... web sites continue to not warn their IE users about the security vulnerabilities in the clients those users are running. They could warn those users each time they visit with IE. But they don't. It's time the webmasters of the world start to do something about the problem and put a big full page notice in front of all IE based visitors warning them about the troubles with IE and urging them to switch to a safer browser (and give some links, too).
Converting the existing videos is not the issue. That can be done slowly. Converting new videos is where it's at. The obvious solution is for YT to offer the videos in TWO formats: the most efficient format, and the most efficient open format. Let the HTTP headers automatically determine that with the Accept statement, and provide a fallback via some Javascript on the page that allows selecting the preferred format in case something is not working. There should also be such a selection for reducing the video resolution, too (e.g. "show me only low definition because my ISP sucks and can't handle HD"). Don't worry about converting all the old videos. Convert the popular ones and put a link in the template to let people ask for a conversion on less popular ones. I'm sure there's a ton of videos out there no one watches anymore.
Things can change. There is enough bandwidth NOW (wasn't a few years ago). The real problem is Vorbis just isn't stable as a standard, yet. They need to push to get a stable "Vorbis V1" and put future work into "Vorbis V2". Youtube can simply offer the option of video formats based on the HTTP headers in the request. Seems to me based on what you say, we only need TWO formats, anyway ... one for corporate profits and one for the people.
Wait until you see a cylinder full of 64GB memory cards, then you'll sing a different tune.
... just don't show ads to users in France.
But that is just Méxican law. So the solution is for Starbucks to not use the designs in México. Problem solved.
Then why isn't the Mexican government making that kind of claim?
An apparent requirement was to squeeze the year into a single byte. They just did it very badly by choosing BCD format for the last 2 digits of the year, and assuming every new CS grad would know what that means, and would understand by examining the existing data field where 0x03 was present for 2003 and 0x04 was present for 2004 that it must be in BCD. Since BCD and plain binary share the same values for 2000 through 2009, it fully depended on the programmer reading AND UNDERSTANDING the documentation to get it right ... if the documentation even reliably pointed this out.
We need to get away from BCD encodings. It was convenient for hardware level protocols because they allowed displays of decimal digits without further conversion. Do we do that anymore? Unlikely. We have software or firmware, and that can do decimal conversions just fine. All NEW communications protocols should from this day forward use only one of a binary format with a documented resolution and sufficient bits to last until at least the year 2200, or characters with the date in a format with year first, month next, and day of month after that, or a plain decimal count of days since the epoch. Where an epoch is needed, it must be clearly documented.
My home and work internet access providers, a major cable TV provider, and a major incumbent telco provider, both do not have native IPv6 available. This is in the USA, where we need some leadership to take action and mandate universal IPv6 access everywhere, with a timetable for government sites to be increasingly available ONLY via IPv6. Unfortunately, this country has lacked leadership for many presidential terms, and continues to have this issue.