It's not a dictatorship if nobody has to do what they say - and they have no way of compelling anyone to do so. What FSF and OSI do is leadership. And you know that I am not always happy with the leadership that either organization exercises. Like FSF and OSI, I take the trouble to review companies approach to the community and tell people whether or not I find them acceptable. If I were totally in left field, nobody would listen. Same with FSF and OSI.
About the RealNetworks Release Bruce Perens Free Software Evangelist 22-July-2002
RealNetworks is announcing today that some of their software will be released as Open Source or Free Software. While RealNetworks is making a significant contribution to Open Source, today's release does not include the "crown jewels" -- their "codecs", the encoding and decoding software for their proprietary RealAudio and RealVideo formats. I will go into more detail regarding what they are proposing to release, and when, in this message.
I'd also like to say what my role is in this. It is not to endorse, but to explain what's going on from an Open Source perspective. Some of the pieces announced today will be Open Source, but many will not be. Thus, I can't fully approve of what is going on. I will continue to lobby RealNetworks to follow today's step by going fully open, and I urge you to continue to use fully open codecs in preference to the RealNetworks ones.
It was entertaining to see the first sentence of the invitation that RealNetworks sent to some of the press:
> On Monday at 10am in SF, Eric Raymond, Bruce Perrins, Brian Bellendorf > etc. will all be attending a press conference with Real Networks and 30 > other top industry companies for a significant industry announcement.
I am flattered by their enthusiasm, especially since I'd told them repeatedly that I'd not be making an endorsement. This shows that RealNetworks may actually be able to deal with the Open Source community on the community's own terms. That will be essential if a real partnership is to come of today's announcement.
So, what is RealNetworks proposing? They plan to release code in 90 days. Some of the details of that code, including what parts are included in the release and how they are licensed, may change before then.
RealNetworks "client engine", the thing that lives in the desktop or the web browser and drives the client half of their codec, will be available under a license that is derived from the Apple Public Source License, but with goals much closer to the GNU General Public License. The license text includes a patent grant. Like the APSL and the NPL licenses, it grants RealNetworks a right to relicense your code under any license of their choice. So it is unlike the GPL in that it gives one party more rights than all others. This license has yet to be approved by the Open Source Initiative board, or accepted by the Free Software Foundation, or even fully reviewed by yours truly. It may have to be modified before it is worthy of acceptance by the community.
The Open Source client engine will probably include:
> - RTSP/RTP/RTCP/SDP network playback > - UDP support > - Local file playback > - Single source A/V > - A/V data type interface > - file format interface > - some A/V codec support (TBD; standards-based, probably MP3 and 3GPP > codecs)
I have an even longer list of other features that the Open Source client _may_ include, which I can't show you until they decide. On the list of functions that most likely won't be included, besides the codecs, there's a lot of utility and user-interface code.
So, we're getting some network protocols that go on top of IP and UDP, and do their best to provide continuous playback despite the fact that the Internet doesn't guarantee throughput or latency. On top of that are file formats and data objects, and other pieces necessary to make an Open Source player for some already-open file formats. It is likely that many of the client pieces will be applicable to servers and encoders as well, although RealNetworks is not placing their server and "encoder engine" in Open Source. Combining the Open Source player with RealNetworks proprietary codecs will produce a player for the RealAudio and RealVideo formats on new platforms where no player existed before.
Perhaps the greatest beneficiary of RealNetworks contribution could be the Ogg Vorbis audio format. Ogg is a fully Open Source codec, unencumbered by patents or royalty payment requirements, which offers audio quality comparable to, or better then, its proprietary competition. The Ogg encoder and servers, not just the client, are available as Open Source. The addition of RealNetworks network protocols and other utilities might make Ogg even better, and might facilitate the inclusion of Ogg as an option in RealNetworks proprietary products.
RealNetworks server and "encoder engine", without the actual codecs, will be under a "community source" license. This means that source code will be disclosed to people who sign an agreement, and those people will get a lot less than the full set of rights that come with Open Source licensing. Since other streaming servers and encoders are already fully Open Source, we can't expect the Open Source community to have much to do with this part of RealNetworks code. However, community source does make life easier for RealNetworks partners, whose business depends on this code and who might not have had source code until now.
The RealAudio and RealVideo codecs will be available in compiled form, as proprietary software that can be linked into a larger product. Again, no joy in the Free Software camp. However, these codecs will be available for use along with various Open Source pieces that Real is releasing, and thus it will be easier to for third parties to produce a half-proprietary Real-format player under Linux and on other operating systems where one is not supported today.
Why is Real doing this? Obviously, they are under pressure from Microsoft's Media Player, and would like to prevent that product from achieving market domination. Increasing open-ness is a weapon in that battle, because a perception of open-ness will make more people consider RealNetworks products as standards rather than just products. But RealNetworks may not be able to afford to be open enough - their revenue today depends on licensing fees for the use of their software, and unless they can change their business model somewhat, it will be difficult for them to achieve a real partnership with the Open Source community. That community has little to gain by replacing Microsoft's proprietary audio format with RealNetworks still-proprietary audio format. The Free Software folks will continue to develop Ogg Vorbis and other solutions, although perhaps in a way that is more compatible with RealNetworks proprietary software. Thus, I consider todays announcement to be only a first step for RealNetworks, with additional steps necessary if they are to succeed. On behalf of the Open Source and Free Software developers, I hope to be able to help RealNetworks take those additional steps.
"In a corporate sense" means that other standards bodies allow companies to insert revenue-generating patents into new standards. If MS can get a revenue generating patent into many new standards, it won't even have to sell software any longer. They can just charge everyone else for the right to make software.
RAND licensing terms do not necessarily allow Open Source implementations. It sounds like they may be offering OpenGL a royalty-free cross-license, but the terms of another recent Microsoft standards-related license explicitly ruled out GPL and LGPL implementations. They won't accept anything that they can't embrace-and-extend.
My understanding, last time I met with Boucher, was that part of this is a truth-in-advertising bill. It would require that DRM-restricted material be clearly labeled as such. I haven't seen the text yet.
The device you cite is dependent on a newly-discovered elementary particle called the put-on:-)
And be glad that free energy schemes don't work. If they did, and at large scale, they'd be the one technology with a real potential to significantly hasten the heat-death of the universe. Everything brings that event closer, but most ways of getting energy are effectively limited. Entropy is pollution, too.
This is sort of like source-code escrow, but not customer-specific.
In source-code escrow, the vendor promises to provide the source-code to the customer if the vendor goes out of business.
The problem is that bankruptcy courts often overturn source-code escrow clauses, because the source code turns out to be the firm's only salable asset.
The best solution is to free the code first, and for the customer to be careful not to become dependent on closed-source.
We'd really like you to join the work on GnuPG, and on GUI projects like GNOME. I think it would be most productive to write off the PGP code base and continue your work on the existing Free Software projects. We've gotten most of the hard work done already.
Studios like Disney, Pixar, and Dreamworks are installing PCI 3D cards in the animator and technical director's workstations. These were previously much more expensive SGI workstations, and are now IA-32 PCs running Linux and OpenGL.
It's not at all clear to me that Cg provides any advantage over OpenGL used from C/C++ for the sort of work that the high-end studios do.
The vanilla CPUs in render farms and the software renderers that run on them could be replaced by hardware rendering for the lower-quality work, but never for the highest. First, the render farm doesn't need the real-time facility of the GPU - the part the GPU does best, and the part that contributes most of the cost to the GPU. The render farm just needs to render a frame to disk, and can do this more cost-effectively with a software renderer and a general-purpose computer. Second, the GPU isn't as extensible as the software renderer, because it's cast in silicon. There will always be an effect you want that the GPU can't handle. And then, the GPU is built to render video fast, and trades off many aspects of the rendering algorithm that we really want when we render to film.
You will, however, see all of the studios buy arrays of GPUs for making rushes. These are less-than-full-quality playbacks that they use to review the animator's work-in-progress before final rendering.
If we got some really fast programmable gate-arrays, or GPUs with documented and programmable microcode, we could use them as a GPU is used, but in a way that might support the highest-quality rendering.
Pixar tried to make high-speed hardware for years, and we always found it to be a losing game. I wrote microcode for one of these beasts, a parallel bitslice engine that inspired today's MMX instructions. We could not keep up with the development of vanilla CPUs, and the CPUs ended up being more cost effective.
You are confusing the digital logic with the analog magnetic media. On the disk, there are no bits, there are just differing levels of magnetism. So, by erasing a disk, you don't necessarily get 1 picogauss (or whatever) back to exactly zero across all of the molecules of the domain under the head. It turns out that you can use some very sensitive instruments like a superconducting quantum interference detector to read "fossil magnetism". Some physics student will come along and explain this better than I have:-)
It depends how much respect the writer already has from the reader. If he has a lot, that tone might work. If not, it just makes him look like a whiner who can't even make an argument that's not ad-hominem. Remember that political writing is meant to influence somebody, and you don't need influencing on this issue. You will read it differently from the target audience, and unfortunately they are the folks who matter - not the already-converted. Some people find it very difficult to put themselves in the place of the target audience, or even to understand what the target audience is.
Well said. If you've been around here for a few years, you may remember that I used to be famous for walking off of Free Software projects in a huff. I haven't done any of that in a while. Part of it was becoming a dad and thus having my priorities readjusted. Part was that I had to learn not to act that way in order to better influence people. But I am still liable to stomp around the room or bang on the wall, in private. It just has to stop there.
Some weblogs let you modify or even withdraw a comment. On Slashdot, you can only have it moderated down. Twitter could have stated his point better - he regrets calling her a ninny. I've said things on Slashdot that have subtracted from my point, too.
In fighting all of this nasty DRM, it's often necessary to translate the problem for people who don't care one bit about Free Software. We either make friends with that sort of person, or we don't have enough influence to fight this. Jane Black got a look at my lobbying notes during my recent visit to Hollings, Boucher, Boxer, Lee, and the Department of Commerce. Yes, she painted us as underdogs with religion and abstract ideas. But she aired material on the problem. She'll understand even more of it when she follows up this report. I'd really rather the community maintain a good relationship with her, and with the press in general. We need them more than they need us, even when they don't understand everything we would like. They are our main path to political influence.
Thus, I'd like you to take that into consideration next time, and if other folks would moderate your post into oblivion right now, that might be the best thing that could happen to it. Sorry.
I don't think you're right regarding the patent issue. The patented code can be contained in an MIT-licensed code fragment and the MIT license can be converted to GPL by anyone.
What you said. Geez. Is our own team starting to believe the Microsoft FUD?
This story is completely bogus!
on
Two Helpings of WINE
·
· Score: 3, Informative
The LGPL does not prevent proprietary software. It doesn't even prevent it from being static-linked! It doesn't prevent anyone from making their money. It doesn't prevent them from implementing closed DRM schemes. The whole premise of the story is invalid. here!
Slashdot for getting the story wrong. Anyone else who got the story wrong - which might mean Wine Magazine, but I haven't read it. The LGPL's effect is essentially the same as the BSD license. You can link any proprietary code to it.
Slashdot Mirror
It's not a dictatorship if nobody has to do what they say - and they have no way of compelling anyone to do so. What FSF and OSI do is leadership. And you know that I am not always happy with the leadership that either organization exercises. Like FSF and OSI, I take the trouble to review companies approach to the community and tell people whether or not I find them acceptable. If I were totally in left field, nobody would listen. Same with FSF and OSI.
Bruce
Bruce
About the RealNetworks Release
Bruce Perens
Free Software Evangelist
22-July-2002
RealNetworks is announcing today that some of their software will be
released as Open Source or Free Software. While RealNetworks is making a
significant contribution to Open Source, today's release does not include
the "crown jewels" -- their "codecs", the encoding and decoding software
for their proprietary RealAudio and RealVideo formats. I will go into more
detail regarding what they are proposing to release, and when, in this
message.
I'd also like to say what my role is in this. It is not to endorse, but
to explain what's going on from an Open Source perspective. Some of the
pieces announced today will be Open Source, but many will not be. Thus,
I can't fully approve of what is going on. I will continue to lobby
RealNetworks to follow today's step by going fully open, and I urge you to
continue to use fully open codecs in preference to the RealNetworks ones.
It was entertaining to see the first sentence of the invitation that
RealNetworks sent to some of the press:
> On Monday at 10am in SF, Eric Raymond, Bruce Perrins, Brian Bellendorf
> etc. will all be attending a press conference with Real Networks and 30
> other top industry companies for a significant industry announcement.
I am flattered by their enthusiasm, especially since I'd told them
repeatedly that I'd not be making an endorsement. This shows that
RealNetworks may actually be able to deal with the Open Source community
on the community's own terms. That will be essential if a real partnership
is to come of today's announcement.
So, what is RealNetworks proposing? They plan to release code in 90
days. Some of the details of that code, including what parts are included
in the release and how they are licensed, may change before then.
RealNetworks "client engine", the thing that lives in the desktop or the
web browser and drives the client half of their codec, will be available
under a license that is derived from the Apple Public Source License, but
with goals much closer to the GNU General Public License. The license text
includes a patent grant. Like the APSL and the NPL licenses, it grants
RealNetworks a right to relicense your code under any license of their choice.
So it is unlike the GPL in that it gives one party more rights than all
others. This license has yet to be approved by the Open Source Initiative
board, or accepted by the Free Software Foundation, or even fully reviewed by
yours truly. It may have to be modified before it is worthy of acceptance by
the community.
The Open Source client engine will probably include:
> - RTSP/RTP/RTCP/SDP network playback
> - UDP support
> - Local file playback
> - Single source A/V
> - A/V data type interface
> - file format interface
> - some A/V codec support (TBD; standards-based, probably MP3 and 3GPP
> codecs)
I have an even longer list of other features that the Open Source client
_may_ include, which I can't show you until they decide. On the list of
functions that most likely won't be included, besides the codecs, there's
a lot of utility and user-interface code.
So, we're getting some network protocols that go on top of IP and UDP,
and do their best to provide continuous playback despite the fact that
the Internet doesn't guarantee throughput or latency. On top of that are
file formats and data objects, and other pieces necessary to make an Open
Source player for some already-open file formats. It is likely that many
of the client pieces will be applicable to servers and encoders as well,
although RealNetworks is not placing their server and "encoder engine"
in Open Source. Combining the Open Source player with RealNetworks
proprietary codecs will produce a player for the RealAudio and RealVideo
formats on new platforms where no player existed before.
Perhaps the greatest beneficiary of RealNetworks contribution could
be the Ogg Vorbis audio format. Ogg is a fully Open Source codec,
unencumbered by patents or royalty payment requirements, which
offers audio quality comparable to, or better then, its proprietary
competition. The Ogg encoder and servers, not just the client, are
available as Open Source. The addition of RealNetworks network protocols
and other utilities might make Ogg even better, and might facilitate the
inclusion of Ogg as an option in RealNetworks proprietary products.
RealNetworks server and "encoder engine", without the actual codecs,
will be under a "community source" license. This means that source code
will be disclosed to people who sign an agreement, and those people will
get a lot less than the full set of rights that come with Open Source
licensing. Since other streaming servers and encoders are already fully
Open Source, we can't expect the Open Source community to have much to
do with this part of RealNetworks code. However, community source does
make life easier for RealNetworks partners, whose business depends on
this code and who might not have had source code until now.
The RealAudio and RealVideo codecs will be available in compiled form, as
proprietary software that can be linked into a larger product. Again, no joy
in the Free Software camp. However, these codecs will be available for use
along with various Open Source pieces that Real is releasing, and thus it will
be easier to for third parties to produce a half-proprietary Real-format player
under Linux and on other operating systems where one is not supported today.
Why is Real doing this? Obviously, they are under pressure from
Microsoft's Media Player, and would like to prevent that product
from achieving market domination. Increasing open-ness is a weapon in
that battle, because a perception of open-ness will make more people
consider RealNetworks products as standards rather than just products.
But RealNetworks may not be able to afford to be open enough - their
revenue today depends on licensing fees for the use of their software, and
unless they can change their business model somewhat, it will be difficult
for them to achieve a real partnership with the Open Source community.
That community has little to gain by replacing Microsoft's proprietary
audio format with RealNetworks still-proprietary audio format. The Free
Software folks will continue to develop Ogg Vorbis and other solutions,
although perhaps in a way that is more compatible with RealNetworks
proprietary software. Thus, I consider todays announcement to be only a
first step for RealNetworks, with additional steps necessary if they are
to succeed. On behalf of the Open Source and Free Software developers, I
hope to be able to help RealNetworks take those additional steps.
Respectfully Submitted
Bruce Perens
Bruce
Bruce
Bruce
It does strike me that we don't wield our power effectively.
Thanks
Bruce
I got to introduce Boucher and RMS.
Bruce
And be glad that free energy schemes don't work. If they did, and at large scale, they'd be the one technology with a real potential to significantly hasten the heat-death of the universe. Everything brings that event closer, but most ways of getting energy are effectively limited. Entropy is pollution, too.
- http://my.ais.net/~lawmsf/articl15.htm
- http://www.wernick.com/Articles/1986Jun01%20Sou
r ce %20Code%20Escrow.pdf
- http://www.softescrow.com/faq.html
ThanksBruce
In source-code escrow, the vendor promises to provide the source-code to the customer if the vendor goes out of business.
The problem is that bankruptcy courts often overturn source-code escrow clauses, because the source code turns out to be the firm's only salable asset.
The best solution is to free the code first, and for the customer to be careful not to become dependent on closed-source.
Bruce
We'd really like you to join the work on GnuPG, and on GUI projects like GNOME. I think it would be most productive to write off the PGP code base and continue your work on the existing Free Software projects. We've gotten most of the hard work done already.
Thanks
Bruce
Hold out for a girlfriend who shades higher-order surfaces. Also, hold out for a girlfriend with higher-order surfaces!
It's not at all clear to me that Cg provides any advantage over OpenGL used from C/C++ for the sort of work that the high-end studios do.
The vanilla CPUs in render farms and the software renderers that run on them could be replaced by hardware rendering for the lower-quality work, but never for the highest. First, the render farm doesn't need the real-time facility of the GPU - the part the GPU does best, and the part that contributes most of the cost to the GPU. The render farm just needs to render a frame to disk, and can do this more cost-effectively with a software renderer and a general-purpose computer. Second, the GPU isn't as extensible as the software renderer, because it's cast in silicon. There will always be an effect you want that the GPU can't handle. And then, the GPU is built to render video fast, and trades off many aspects of the rendering algorithm that we really want when we render to film.
You will, however, see all of the studios buy arrays of GPUs for making rushes. These are less-than-full-quality playbacks that they use to review the animator's work-in-progress before final rendering. If we got some really fast programmable gate-arrays, or GPUs with documented and programmable microcode, we could use them as a GPU is used, but in a way that might support the highest-quality rendering.
Pixar tried to make high-speed hardware for years, and we always found it to be a losing game. I wrote microcode for one of these beasts, a parallel bitslice engine that inspired today's MMX instructions. We could not keep up with the development of vanilla CPUs, and the CPUs ended up being more cost effective.
Bruce
Bruce
Thanks
Bruce
Thanks
Bruce
Thus, I'd like you to take that into consideration next time, and if other folks would moderate your post into oblivion right now, that might be the best thing that could happen to it. Sorry.
Bruce
Bruce
What you said. Geez. Is our own team starting to believe the Microsoft FUD?
Bruce
In other words, this is much ado about nothing.
Bruce
Bruce