Sigma Designs/XVid Update 98
Reagen Ward and many other people have written in with updates to the Sigma Designs/XVid situation, reported a few days ago. Sigma has replied in email and a press release that they intend to make the source code available, however, they seem to be paying lip service at best to the terms of the GNU Public License. Grant Gross from Newsforge has been pursuing the story and in a story yesterday and another today lays out the current situation.
If I understand it right... (Score:2, Interesting)
Apart from that, they did release the source code, and though it was "in wide parts identical or near identical to XVID source code," there are obviously some differences.
Well, if any of you XVID guys have a bit of time, instead of sitting on your hands in protest, maybe you could try out this new code and see if the jerks actually improved anything.
And it would take no skill at all to just take the SigmaDesigs code, overwrite their stupid copyright notices with the appropriate ones, and release the result as GPL. This is totally legal and someone can even do it this weekend (not necessarily the XVID developers, who have better things to do). I can't see how such a move could be legally contested. Or put it this way, if what I described is illegal, then the GPL means nothing--and I sure hope it's not come to that.
Re:Lip service? (Score:4, Interesting)
No, it's exactly what is supposed to happen.
They are probably referring to other things than the actual release. They don't give any credit to XVID. From the press release [sigmadesigns.com]:
"We are pleased to provide the development community with an open source MPEG-4 CODEC, and anticipate that this will accelerate technical improvements and enhance the proliferation of MPEG-4 content," stated Ken Lowe, Sigma Designs' vice president of business development. (emphasis mine)
It makes you think they did all the work. The download page [sigmadesigns.com] acknowledges that they "had utilized some routines posted by XVID as open source," but the tone is that they did all the hard work. Which isn't what I came to understand when reading the evindence [xvid.org].
Of course, now we have the source, it'll be interesting to make a more detailed study on how much code was copied.
XCard Opinion (Score:2, Interesting)
I got an XCard a few weeks ago courtesy of CDW (NewEgg didn't/don't sell them).
I stuck it in a crappy Compaq K6-2/500, and it works OK. The system is attached to the TV, and will play Media mapped of our house file server.
Opinion, the Media player software itself is complete shite... and you really ought to look at the kind of formats it cannot play. Plus I had some self encoded TV episodes using DivX 5, and they had a VBR MP3 audio stream, the XCard plays the audio, and the video is completely out of sync (speeding up, slowing down - as though it is using the VBR timings)... and the player crashes after 5 mins.
I am now in the process of getting a fast computer that can sit behind the TV, with a standard (well I'll use one recommended with TVTool - an excellent program for video out) TV out video card, and a wireless keyboard/trackball combo (Globalink) that I got for the current setup.
It would be preferable if the XCard can just output everything to the TV (i.e. windows display itself), because I have to have a monitor to control everything. So no the XCard doesn't fit my needs at all. And with all this legal shit, I wouldn't bother with it at all (due to the lack of formats it can't play), unless it addresses some of these fundamental concerns.
It's far from being over (Score:5, Interesting)
"First an update on the XviD situation. The release of the Sigma source code does not mean it's all over, it's far from being over. The license agreement which you have to agree to before you can download, and install the codec is not compatible with the GPL. Furthermore, it can now clearly be seen (download the source code and have a look for yourself) that the Sigma codec is pretty much a copy of the XviD codec, but all the copyright notices of the original developers have been removed and replaced. This does not only violate the GPL but copyright laws - you can't just take a program, change a few lines and change the copyright statements, you only have copyright protection for the parts you wrote on your own. And related to this the Sigma codec also contains code taken from the OpenDivX project [doom9.org], the files were outfitted with 2 different copyright notices which is quite funny."
I hope that Sigma will respect GPL licences. I will for sure stop every purchase of Sigma stuff where I work.
Re:XCard Opinion (Score:4, Interesting)
While all your other points on the card may or may not be valid (I'm not going to dispute them, in other words), I will take a moment to dispute this one. VBR MP3 audio streams in a DivX file is a complete and utter hack. Anyone who knows about the internals of AVI files will recognize this instantly. That it was made to work and play back correctly in Windows is actually due to a bug in the decoder itself, and should Microsoft ever fix this bug, all VBR MP3 audio interleaved in AVI files will suddenly either lose sync or perform exactly as the XCard.
References:
Can't find it on the new (redesigned) website, but here's the google cache.
http://216.239.53.100/search?q=cache:bqcAKNs_G2cC
Ensuring Benefit (Score:3, Interesting)
OK. Let's consider a counter-argument to this.
Companies using GPL code only benefits everyone IF the company adheres to the GPL. If a company simply takes code and uses it as a platform to jumpstart their development, they are the only ones that bennefit. And more importantly, the community that collaberated to bring value to the code in question looses.
And there is definately value to be found in a lot of these GPL projects. GPL code is being used more and more often by business not only to support their infrastructure, but to provide a boost to their development. Unfortanely there also seems to be an increase in businesses that attempt to simply take code in violation of its license.
In most cases we've been reading about, when a GPL violation is discovered, it usually ends up with a sheepish excuse and promise to release code in accordance with the GPL license. The problem is this is beginning to look like a standard tactic. Steal code, hope nobody figures it out... and if you do get caught, then cough up some code. In the end, you still have access to the code you needed to boost your project at the "expense" of having to give up modifications you had hoped to keep to yourself.
It seems to be strategy with little overall risk. And if so, it suggests the community is setting itself up to be constantly ripped off.
A punitive strategy for the community... and one that the origional poster suggests exists within the workings of the GPL license... is to make the entire code base a part of the risk. If you attempt to steal GPL code and are caught, you forfeit access to that code. This would increase the risk from not only releaseing code you would prefer to keep secret (but would have to anyway if you complied with the GPL), but also puts the entire code base you wish to use at risk. Being caught would mean returning to square one - a major hit to any development project or product. And it may be a risk that fewer will be willing to accept. Hopefully it will keep honest people honest.
Could the community benefit from more companies using its code? Sure. But those companies must understand the requirements of using that code and, ultimately, being a part of the community.
One final note. The GPL may seem strange to the hardcore competative business developer. But one familiar aspect of the GPL is that it is a license. I find it hard to believe anybody working within the IT industry is not familiar with having to deal with licenses. When you use applications and code that include a license, it should be second nature to review that license and decide if one wishes to comply with it - as strange as those requirements might be.
Re:The obvious thing to do now... (Score:3, Interesting)
As for theft of GPLed code, the GPL includes conditions already to handle that. The theif loses the right to use that code ever again. The author can ALWAYS take the infringer to court. Most likely, the FSF will help.
So if you have seen GPL infringment in action, why didn't YOU report it? Go get yourself a yahoo mail account and do so today. You can also go through an anonymous remailer (search google for one.)
Re:NS2k cards and stuff (Score:3, Interesting)
That's really sad. Perhaps Sigma could be encouraged to be more open as a way of making up for thier GPL faux-pas. I very much want to leverage a GCT Allwell iDVD3036 as a thin client set-top box, as it uses a low-power processor, with an em8400 MPEG decoder, and a CyberPro graphics chip (with two CCIR601 ports -- one for the em8400 -- digital overlay, yay!), but the em8400 and CyberPro are poorly supported -- the latter with proprietary XV extention drivers for XFree, but buggy, not doing alpha-blending and overlay properly. As this is a personal pet project, I certainly can't afford the US$15k (I'm told) CyberPro SDK.
Some here have noted that the "rogue programmer" excuse is lame on their part, but I can certainly attest to the very real risk of that happening. I once was involved in a project that deployed proprietary code on a GNU/Linux base, and made extensive use of GPL'd and open code (though our proprietary code was not extentions of any of that). With my encouragement, management hosted RMS to come and explain the "dos and don'ts" of mixing free and non-free code. Even so, programmers come and go, and cluefullness fades with time. Furthermore, while our build process was tuned to getting all the necessary binaries made, keeping track of sources to distribute (remember, there were hundreds of packages, mostly free, yet the non-free ones had to stay "very secret"), was very much an afterthought to the process and kludged in. I was forever afraid that someone would forget to tag what was free and what wasn't, or worse, get it wrong.
Sadly, while I tried my best to make sure that sources got distributed to our customers, the nature of the product was such that we'd have a few big ones, and not lots of little ones. (Think seven-figure contracts.) Furthermore, each customer would have little incentive to freely distribute the free code they received -- if they had to pay us millions for the app, they'd be damned if someone else get bits for free. So, while we complied with the GPL, our extentions to much of the GPL code (particuarly the Red Hat Anaconda installer), remain unavailable to the public at large.
The biggest problem, and one which Sigma does not face is that, while we'd put source on distribution CDs, our customers would get fully installed hardware, complete with maintenance contracts, and didn't care about installation CDs. If you make an installation and source CD, and install binaries on some hardware and just ship the hardware and not the CD, have you complied with the GPL? No, but making it clear that we either have to provide the CDs, or a transferrable written offer was a hard sell to management: "The customer does not WANT them". Convincing management that the requirement was one placed on us by the authors of the GPL code and not the customer took some doing, but I was persistent.
I'm in a similar situation today (for another employer), where installation CDs will likely not get to customers, but I've taken care to ensure that installation installs sources as well as binaries (we can afford the disk space, fortunately... so far).