Getting the code is admittedly more complicated than it needs to be (and we're working on that), but hyperbole like the parent post should not be modded up as "Informative". The steps are:
1. Sign up for the site, filling in a form with proposed user name, real name, company name, and email. 2. Receive confirmation URL, and visit included URL 3. Agree to site terms of use 4. Agree to RPSL (an OSI certified license) 5. Get source code via CVS/SSH
Why are we being hardasses about making sure that people agree to licenses? It's a combination of the way the legal system works, and our general conservativeness that stems from being a publicly traded company.
There are good reasons to ensure that "manifestation of assent" occurs, even for open source. I'll defer to Larry Rosen's excellent paper on the topic. Larry, as you may know, is the General Counsel for the Open Source Initiative, and while his opinion is only an opinion, it's a very well informed one.
As for the functionality, it's more than just "shells". There's complete software there, and it's the foundation of our commercial products. Additionally, the combination of Ogg Vorbis, SMIL 2.0, JPEG, GIF, and PNG is very powerful, and *all open source*. No RealAudio/RealVideo necessary, and the app is pretty unique. For an example which plays in the Helix Player (and versions of RealPlayer/RealOne Player with the Ogg Vorbis codec installed), check out the following link:
Your issue is one we struggle with a lot at RealNetworks. While the jury is still out as to how successful this will be in the long haul, I think the signs are encouraging that we're hitting something close to the right balance.
Since I agree with much of what you say, the answer to your implied question: "I don't know what pull you have over there..." is "obviously, not a lot".;-)
I will forward your comments on, though. One thing that would be very helpful is posting your comments on our official comment form.
You'll note that the origin for this story is CNet, and that the metric that they are using is download.com (owned by CNet). Since Kazaa.com actually links straight to download.com, it's not surprising that they have the highest numbers on download.com.
Over 335 million unique RealPlayer/RealOne Player registrations have been received by RealNetworks.
Other software makers (who don't use download.com) probably also have numbers higher than Kazaa.
I've always taken "preferential voting" to mean any voting system that lets you submit a ranked ballot. Condorcet and IRV/Alternative-Vote both fall in this category. I suppose that since you probably don't have the occasion to talk much about any preferential voting system other than alternative vote, the distinction between the term "preferential vote" and "alternative vote" is pretty meaningless.
There's a number of electoral reformers (myself included) who have a hard time convincing advocates of Australia's system that it still leads to a two party syste. Australia's system is called "Alternative Vote" in Australia, I believe, and called Instant Runoff Voting (IRV) in the U.S. It's a preference ballot, which is then used to simulate runoff elections. Though not thoroughly studied, it is our belief that IRV is no better than first-past-the-post at breaking up the two party system. Duverger really only studied first-past-the-post, from my understanding. We often point to Australia as evidence that the two-party system is still reinforced by IRV.
Another system which (we think) doesn't suffer similar problems is Condorcet's method. From a theoretical perspective, at least, it does a much better job of eliminating the spoiler problem, and therefore would hopefully break up a logjam induced by political parties.
The little dig at the end of the CmdrTaco's intro is absolutely correct. There's a pretty big link between voter apathy and the "lesser of two evils" problem. The root cause for the lesser of two evils problem is Duverger's Law, which gives us the two party system. The link between voter apathy and two-party systems is pretty unmistakable, and there's a lot of research on the subject showing it. Read the Wikipedia link above for good starting reference material.
Rob Lanphier p.s. Visit Electorama! for more on this subject
It seems to be popular to bash political correctness, but dammit, this is *exactly* why political correctness came into vogue. The "Anonymous Coward" two posts above is a racist, pure and simple.
The poster did not do any sort of formal study, did not engage in double-blind techniques or ensure that the sample was indeed representative. This is someone who sees a name like Somandepalli or Varadharajan on a resume and says "oh great, another one of those Indian programmers who can't problem solve their way out of a wet paper bag". They then proceed to use the interview period to prove that their firmly held believe is correct. Of course, the hapless interviewee senses that the deck is stacked against them, gets nervous and fumbles. Point proven.
What bullshit. I've got a lot experience working with programmers from all over the world, and the idea that Indian programmers aren't good problem solvers is blatently wrong and smacks of racism. Thanks for playing, come back when you have *proof* instead of anecdotal pap.
While having the most victories is a possible gauge,...
Yup, there's actually a name for that: Copeland's method. Not nearly as well known as Condorcet's, but is nice in that the tiebreaker is more intuitive to those that are used to sports matchups.
Rob Lanphier
(who is looking for an excuse to plug Electorama, a site about electoral reform)
The Ogg Vorbis support was designed by the Xiph.org Foundation mainly for the client. It could very well be that the plugin they wrote "just works" on the server, though I don't think anyone has tested that yet.
I imagine that we'll get things working on the server side before too long. Feel free to jump in at the Helix/Xiph development area to chip in.
Excellent point. That's one of the key differences between the RPSL and the GPL. We've got a dual-licensing model similar to the one described in the essay, but we retain the right to incorporate changes to the RPSL'd software.
We wish we could be GPL-compatible, but that is more of a restriction in the GPL than in the RPSL.
I guess I had hoped we would receive a little bit of credit where credit is due, but I guess not.
I'll take off my RealNetworks hat for a sec. I'm not a big fan of DRM solutions. I've seen the days of hardware dongles and other silly solutions that don't seem to go anywhere, and have not had a personal interest in being involved in that sort of thing. Many DRM systems are intrusive, and as I sit here on my Linux box without the ability to play back our DRM content, I understand why the community gets frustrated.
That said, you'll notice that I still work at RealNetworks. I feel that, as a whole, the company wants to do the right thing, and I'm hoping I can enlist the community's help in that.
As for the criticism of "ooo, DRM is bad bad bad, and anything associated with it is bad bad bad", here's my response to that:
I think what RealNetworks is doing with open source in the Helix Community could really change the landscape for the better.
As for DRM; I'm not personally involved in our DRM efforts, and don't plan to be, but I see it as a necessary evil. To really be in our business these day, one has to provide a solution (mind you, our business is not only software production, but content distribution through our RealOne SuperPass service). And I don't see it as immoral (as some do), just silly.
As for the legislative efforts relative to DRM, I'm told we are on record as opposing the broadcast flag provisions (still investigating). At any rate, I think we've been pretty good citizens when it comes to our positions on legislation.
This is a win for open formats. Transcoding is an ugly process, and DRM systems need to get their content from somewhere. If the input (and output) of a DRM system is an open format (e.g. Ogg Vorbis), then content providers can decide to go with that format, confident that should they ever need to protect that content with a DRM system down the road, there's a solution for them.
As for the other criticisms here, see my earlier posts. We realize we're not perfect, but we're hoping the community will still give us a shot.
It's even more misleading than you give it credit for. MPEG-4 is a very big spec, of which the ".mp4" part is only a small chunk. DoCoMo announced 3GPP support, which takes some parts from MPEG-4, but takes other parts from IETF and ITU specs.
Regarding Ogg + MPEG-4 video. The licensing terms for MPEG-4 Video are pretty gnarly. How about Ogg and H.263+ (which, incidently, is what the 3GPP standardized on). That combination nearly works today in Helix DNA Client. We're already committed to making this available in our mainline products like RealOne Player and Helix Universal Server.
The headline should be "3GPP Becoming Mobile-Phone Standard", and it's not all that surprising, but it's very good news for everyone (including RealNetworks, where I'm from). We've been doing a lot of work in the 3GPP, and it's great to see that work paying dividends. If you really want to find out what this stuff is about, look at the spec (and yes, I hate the fact that these are Word docs in zipfiles as much as anyone).
Much of the confusion around this subject comes from a lack of understanding of the difference between.mov,.mp4, and.3gp. DoCoMo's announcement was good news for 3GPP, and given the support throughout the Helix platform for 3GPP formats, codecs, and protocols, we view it as great news for the Helix Community.
As another poster pointed out, only a piece of 3GPP is based on Quicktime is the container file format itself (the bit that says "here's a 3000 byte chunk of data with this 32bit codec identifier"). Another piece (the protocol) is based on work RealNetworks pioneered (RTSP). Moreover, the Helix DNA Client supports the 3GPP specification today.
RealNetworks added MPEG-4 and 3GPP support 10 months ago with the RealSystem Mobile Server (see press release), and MPEG-4 support will be included in the Helix DNA Server when it is released in the near future.
As for the speculation about Apple releasing 3GPP encoding support, we would welcome them to the party. In early November we announced that a version of our Producer product for creating 3GPP content will ship in Q1 of 03. (see press release) Moreover, we offer our encoding framework as open source (and naturally open APIs) so that you can add support for whatever format you want to. We've given you a head start by implementing Ogg Vorbis support.
Again, the new phones sound great. Lots of new devices for Helix encoders and servers to work with.
The headline should be "3GPP support to your cell phone", and it's not all that surprising, but it's very good news for everyone (including RealNetworks, where I'm from). We've been doing a lot of work in the 3GPP, and it's great to see that work paying dividends. If you really want to find out what this stuff is about, look at the spec (and yes, I hate the fact that these are Word docs in zipfiles as much as anyone).
Much of the confusion around this subject comes from a lack of understanding of the difference between.mov,.mp4, and.3gp. DoCoMo's announcement was good news for 3GPP, and given the support throughout the Helix platform for 3GPP formats, codecs, and protocols, we view it as great news for the Helix Community.
As another poster pointed out, only a piece of 3GPP is based on Quicktime is the container file format itself (the bit that says "here's a 3000 byte chunk of data with this 32bit codec identifier"). Another piece (the protocol) is based on work RealNetworks pioneered (RTSP). Moreover, the Helix DNA Client supports the 3GPP specification today.
RealNetworks added MPEG-4 and 3GPP support 10 months ago with the RealSystem Mobile Server (see press release), and MPEG-4 support will be included in the Helix DNA Server when it is released in the near future.
As for the speculation about Apple releasing 3GPP encoding support, we would welcome them to the party. In early November we announced that a version of our Producer product for creating 3GPP content will ship in Q1 of 03. (see press release) Moreover, we offer our encoding framework as open source (and naturally open APIs) so that you can add support for whatever format you want to. We've given you a head start by implementing Ogg Vorbis support.
Again, the new phones sound great. Lots of new devices for Helix encoders and servers to work with.
> What's happening on this post is that employees of RealNetworks are adamantly spitting the company's in-house propaganda back at us and insisting it's true ("one chunk of rogue code!") when it's obviously not.
Maybe you know something that I don't, then. What is the "obviously not" true about what I said? I could be wrong...I've not done the audit myself, and I personally haven't been privvy to any "spyware" in the system. But, what I'm saying is true to the best of my knowledge.
Ugh...comparing us to a rapist child predator, and you get modded up to a 2?
Regardless of where you wanted to go with this analogy, what you are doing is driving a wedge between RealNetworks and the open source community. You. It's your post that many RealNetworks employees are going to read, and they are going to say "why are we even bothering?" The longtime open source fans here get demoralized, and the others just flip the idiot bit on the "Slashdot crowd".
The software you are complain about has always been free of charge, and for the past few years, supported in part by an advertising business. As I've addressed in another post, our reputation on the "spyware" front is based on one errant feature which collected useless data and which we eliminated long ago. It may have been obnoxious, but it's not even remotely worthy of a child rape comparison.
Personally, I'm doing everything I can to ensure we improve our reputation, both by getting the word out that we're working to improve our relationship with our customers (huge priority for all of us), and making sure we live up to a better reputation.
If you'd truly like to influence us on these types of issues, do two things:
Go through official channels. You've got people who are gathering statistics and studying the data and working to improve our relations with the community, rather than preaching to what is obviously the choir here.
Help make the Helix Community a success. If the community is successful, you'll have an alternate engine that can have whatever you want in it (and not have what you don't want).
I don't know why I chose that subject line, but whatever.:)
I appreciate that you recognize we're rolling up our sleeve pretty far to show there's nothing up it. The "spyware" complaints have persisted for years after someone found one rogue chunk of code that sent us a lot of useless information that was going in the bit bucket (if you look at what was being collected, it really wasn't interesting).
Nevertheless, you're absolutely right: if you don't trust us, build your own player.
I really don't think it would be possible to put together a compelling end-user multimedia application with what you dub the "UNIX/Linux" approach (literally using small command line programs). Could you point to a successful end-user multimedia application that does?
One thing I should clarify now....we are planning to release our server software under the terms of the RCSL only (our community source license) rather than RPSL (our open source license). The client and producer have both been released under RPSL/RCSL dual license.
This may impact your definition of a "free" server. However, the source code will be available to the community in the same way that our client and producer software are.
There are a *lot* of "interesting" parts to a streaming media system, of which the codecs comprise a small portion. On the client side, there's file format readers, the protocol engine, the audio device management, video alphablending, and an object model to tie it all together. On the producer side, there's input and output filters, variable bitrate encoding support, option for two-pass encoding, audio gain control, Firewire support.
Slashdot Mirror
Getting the code is admittedly more complicated than it needs to be (and we're working on that), but hyperbole like the parent post should not be modded up as "Informative". The steps are:
1. Sign up for the site, filling in a form with proposed user name, real name, company name, and email.
2. Receive confirmation URL, and visit included URL
3. Agree to site terms of use
4. Agree to RPSL (an OSI certified license)
5. Get source code via CVS/SSH
Why are we being hardasses about making sure that people agree to licenses? It's a combination of the way the legal system works, and our general conservativeness that stems from being a publicly traded company.
There are good reasons to ensure that "manifestation of assent" occurs, even for open source. I'll defer to Larry Rosen's excellent paper on the topic. Larry, as you may know, is the General Counsel for the Open Source Initiative, and while his opinion is only an opinion, it's a very well informed one.
As for the functionality, it's more than just "shells". There's complete software there, and it's the foundation of our commercial products. Additionally, the combination of Ogg Vorbis, SMIL 2.0, JPEG, GIF, and PNG is very powerful, and *all open source*. No RealAudio/RealVideo necessary, and the app is pretty unique. For an example which plays in the Helix Player (and versions of RealPlayer/RealOne Player with the Ogg Vorbis codec installed), check out the following link:
http://rtsp.org/2003/demos/oggsmil/oggdemo.smil
Once one starts looking at SMIL (especially SMIL 2.0), you begin to realize that a system that can support it does a lot.
Rob Lanphier
Helix Community Coordinator
For Helix Community, we have a dual-licensing model which gives the community an OSI certified license (RPSL), and a more commercially focused license (RCSL). Additionally, there are components that remain proprietary.
Where do you draw the line? That's always tough, but having the dual-license makes it easier to err on the side of opening up "too much".
Rob Lanphier
Helix Community Coordinator
Since I agree with much of what you say, the answer to your implied question: "I don't know what pull you have over there..." is "obviously, not a lot". ;-)
I will forward your comments on, though. One thing that would be very helpful is posting your comments on our official comment form.
Rob
Here's the URL to the free player:
http://www.real.com/freeplayer/
No, we don't require payment for the player.
Rob
I'm merely using my position at RealNetworks to get more karma on Slashdot. Seems to be working. ;-)
You'll note that the origin for this story is CNet, and that the metric that they are using is download.com (owned by CNet). Since Kazaa.com actually links straight to download.com, it's not surprising that they have the highest numbers on download.com.
Over 335 million unique RealPlayer/RealOne Player registrations have been received by RealNetworks.
Other software makers (who don't use download.com) probably also have numbers higher than Kazaa.
I've always taken "preferential voting" to mean any voting system that lets you submit a ranked ballot. Condorcet and IRV/Alternative-Vote both fall in this category. I suppose that since you probably don't have the occasion to talk much about any preferential voting system other than alternative vote, the distinction between the term "preferential vote" and "alternative vote" is pretty meaningless.
Rob
There's a number of electoral reformers (myself included) who have a hard time convincing advocates of Australia's system that it still leads to a two party syste. Australia's system is called "Alternative Vote" in Australia, I believe, and called Instant Runoff Voting (IRV) in the U.S. It's a preference ballot, which is then used to simulate runoff elections. Though not thoroughly studied, it is our belief that IRV is no better than first-past-the-post at breaking up the two party system. Duverger really only studied first-past-the-post, from my understanding. We often point to Australia as evidence that the two-party system is still reinforced by IRV.
Another system which (we think) doesn't suffer similar problems is Condorcet's method. From a theoretical perspective, at least, it does a much better job of eliminating the spoiler problem, and therefore would hopefully break up a logjam induced by political parties.
Rob
The little dig at the end of the CmdrTaco's intro is absolutely correct. There's a pretty big link between voter apathy and the "lesser of two evils" problem. The root cause for the lesser of two evils problem is Duverger's Law, which gives us the two party system. The link between voter apathy and two-party systems is pretty unmistakable, and there's a lot of research on the subject showing it. Read the Wikipedia link above for good starting reference material.
Rob Lanphier
p.s. Visit Electorama! for more on this subject
It seems to be popular to bash political correctness, but dammit, this is *exactly* why political correctness came into vogue. The "Anonymous Coward" two posts above is a racist, pure and simple.
The poster did not do any sort of formal study, did not engage in double-blind techniques or ensure that the sample was indeed representative. This is someone who sees a name like Somandepalli or Varadharajan on a resume and says "oh great, another one of those Indian programmers who can't problem solve their way out of a wet paper bag". They then proceed to use the interview period to prove that their firmly held believe is correct. Of course, the hapless interviewee senses that the deck is stacked against them, gets nervous and fumbles. Point proven.
What bullshit. I've got a lot experience working with programmers from all over the world, and the idea that Indian programmers aren't good problem solvers is blatently wrong and smacks of racism. Thanks for playing, come back when you have *proof* instead of anecdotal pap.
Rob
Yup, there's actually a name for that: Copeland's method. Not nearly as well known as Condorcet's, but is nice in that the tiebreaker is more intuitive to those that are used to sports matchups.
Rob Lanphier
(who is looking for an excuse to plug Electorama, a site about electoral reform)
The Ogg Vorbis support was designed by the Xiph.org Foundation mainly for the client. It could very well be that the plugin they wrote "just works" on the server, though I don't think anyone has tested that yet.
I imagine that we'll get things working on the server side before too long. Feel free to jump in at the Helix/Xiph development area to chip in.
Rob Lanphier
Helix Community Coordinator
We wish we could be GPL-compatible, but that is more of a restriction in the GPL than in the RPSL.
Rob Lanphier
Helix Community Coordinator
I'll take off my RealNetworks hat for a sec. I'm not a big fan of DRM solutions. I've seen the days of hardware dongles and other silly solutions that don't seem to go anywhere, and have not had a personal interest in being involved in that sort of thing. Many DRM systems are intrusive, and as I sit here on my Linux box without the ability to play back our DRM content, I understand why the community gets frustrated.
That said, you'll notice that I still work at RealNetworks. I feel that, as a whole, the company wants to do the right thing, and I'm hoping I can enlist the community's help in that.
As for the criticism of "ooo, DRM is bad bad bad, and anything associated with it is bad bad bad", here's my response to that:
- I think what RealNetworks is doing with open source in the Helix Community could really change the landscape for the better.
- As for DRM; I'm not personally involved in our DRM efforts, and don't plan to be, but I see it as a necessary evil. To really be in our business these day, one has to provide a solution (mind you, our business is not only software production, but content distribution through our RealOne SuperPass service). And I don't see it as immoral (as some do), just silly.
- As for the legislative efforts relative to DRM, I'm told we are on record as opposing the broadcast flag provisions (still investigating). At any rate, I think we've been pretty good citizens when it comes to our positions on legislation.
- This is a win for open formats. Transcoding is an ugly process, and DRM systems need to get their content from somewhere. If the input (and output) of a DRM system is an open format (e.g. Ogg Vorbis), then content providers can decide to go with that format, confident that should they ever need to protect that content with a DRM system down the road, there's a solution for them.
As for the other criticisms here, see my earlier posts. We realize we're not perfect, but we're hoping the community will still give us a shot.Rob Lanphier
Helix Community Coordinator
Regarding Ogg + MPEG-4 video. The licensing terms for MPEG-4 Video are pretty gnarly. How about Ogg and H.263+ (which, incidently, is what the 3GPP standardized on). That combination nearly works today in Helix DNA Client. We're already committed to making this available in our mainline products like RealOne Player and Helix Universal Server.
The headline should be "3GPP Becoming Mobile-Phone Standard", and it's not all that surprising, but it's very good news for everyone (including RealNetworks, where I'm from). We've been doing a lot of work in the 3GPP, and it's great to see that work paying dividends. If you really want to find out what this stuff is about, look at the spec (and yes, I hate the fact that these are Word docs in zipfiles as much as anyone).
.mov, .mp4, and .3gp. DoCoMo's announcement was good news for 3GPP, and given the support throughout the Helix platform for 3GPP formats, codecs, and protocols, we view it as great news for the Helix Community.
Much of the confusion around this subject comes from a lack of understanding of the difference between
As another poster pointed out, only a piece of 3GPP is based on Quicktime is the container file format itself (the bit that says "here's a 3000 byte chunk of data with this 32bit codec identifier"). Another piece (the protocol) is based on work RealNetworks pioneered (RTSP). Moreover, the Helix DNA Client supports the 3GPP specification today.
RealNetworks added MPEG-4 and 3GPP support 10 months ago with the RealSystem Mobile Server (see press release),
and MPEG-4 support will be included in the Helix DNA Server when it is released in the near future.
As for the speculation about Apple releasing 3GPP encoding support, we would welcome them to the party. In early November we announced that a version of our Producer product for creating 3GPP content will ship in Q1 of 03. (see press release) Moreover, we offer our encoding framework as open source (and naturally open APIs) so that you can add support for whatever format you want to. We've given you a head start by implementing Ogg Vorbis support.
Again, the new phones sound great. Lots of new devices for Helix encoders and servers to work with.
The headline should be "3GPP support to your cell phone", and it's not all that surprising, but it's very good news for everyone (including RealNetworks, where I'm from). We've been doing a lot of work in the 3GPP, and it's great to see that work paying dividends. If you really want to find out what this stuff is about, look at the spec (and yes, I hate the fact that these are Word docs in zipfiles as much as anyone).
.mov, .mp4, and .3gp. DoCoMo's announcement was good news for 3GPP, and given the support throughout the Helix platform for 3GPP formats, codecs, and protocols, we view it as great news for the Helix Community.
Much of the confusion around this subject comes from a lack of understanding of the difference between
As another poster pointed out, only a piece of 3GPP is based on Quicktime is the container file format itself (the bit that says "here's a 3000 byte chunk of data with this 32bit codec identifier"). Another piece (the protocol) is based on work RealNetworks pioneered (RTSP). Moreover, the Helix DNA Client supports the 3GPP specification today.
RealNetworks added MPEG-4 and 3GPP support 10 months ago with the RealSystem Mobile Server (see press release),
and MPEG-4 support will be included in the Helix DNA Server when it is released in the near future.
As for the speculation about Apple releasing 3GPP encoding support, we would welcome them to the party. In early November we announced that a version of our Producer product for creating 3GPP content will ship in Q1 of 03. (see press release) Moreover, we offer our encoding framework as open source (and naturally open APIs) so that you can add support for whatever format you want to. We've given you a head start by implementing Ogg Vorbis support.
Again, the new phones sound great. Lots of new devices for Helix encoders and servers to work with.
Maybe you know something that I don't, then. What is the "obviously not" true about what I said? I could be wrong...I've not done the audit myself, and I personally haven't been privvy to any "spyware" in the system. But, what I'm saying is true to the best of my knowledge.
Regardless of where you wanted to go with this analogy, what you are doing is driving a wedge between RealNetworks and the open source community. You. It's your post that many RealNetworks employees are going to read, and they are going to say "why are we even bothering?" The longtime open source fans here get demoralized, and the others just flip the idiot bit on the "Slashdot crowd".
The software you are complain about has always been free of charge, and for the past few years, supported in part by an advertising business. As I've addressed in another post, our reputation on the "spyware" front is based on one errant feature which collected useless data and which we eliminated long ago. It may have been obnoxious, but it's not even remotely worthy of a child rape comparison.
Personally, I'm doing everything I can to ensure we improve our reputation, both by getting the word out that we're working to improve our relationship with our customers (huge priority for all of us), and making sure we live up to a better reputation.
If you'd truly like to influence us on these types of issues, do two things:
I don't know why I chose that subject line, but whatever. :)
I appreciate that you recognize we're rolling up our sleeve pretty far to show there's nothing up it. The "spyware" complaints have persisted for years after someone found one rogue chunk of code that sent us a lot of useless information that was going in the bit bucket (if you look at what was being collected, it really wasn't interesting).
Nevertheless, you're absolutely right: if you don't trust us, build your own player.
- Helix DNA Client Documentation
- Helix DNA Producer Documentation
I really don't think it would be possible to put together a compelling end-user multimedia application with what you dub the "UNIX/Linux" approach (literally using small command line programs). Could you point to a successful end-user multimedia application that does?One thing I should clarify now....we are planning to release our server software under the terms of the RCSL only (our community source license) rather than RPSL (our open source license). The client and producer have both been released under RPSL/RCSL dual license.
This may impact your definition of a "free" server. However, the source code will be available to the community in the same way that our client and producer software are.
There are a *lot* of "interesting" parts to a streaming media system, of which the codecs comprise a small portion. On the client side, there's file format readers, the protocol engine, the audio device management, video alphablending, and an object model to tie it all together. On the producer side, there's input and output filters, variable bitrate encoding support, option for two-pass encoding, audio gain control, Firewire support.
As for the license, what's wrong with it?
Yeah, what he said. Trust me, our lawyers are *way* too paranoid to let us screw up like that. ;)
I meant to link to this Infoworld story. Oh well, one day I'll learn how cut 'n paste works under X. ;)