DJWillis
Random GP32/GP2X/Wiz & Pandora Moocher
ThorC said:If this is the case (which is great), it might be worth updating the wikipedia page, which makes the situation sound a lot worse. Missing firmware, missing uboot, violation in mplayer.
As Orkie mentions, efforts have been made to clean that article up but people just seem determined to spam that article and overwrite what is 'correct' with misunderstood interpretations or outdated information. It is worth remembering that this is a hobby and should not be the chore it so very often becomes; maintaining Wikipedia against spam is a full time job with very few prospects .
In the end that article (on the subject of the GPL anyway) is much like a number of threads that pop up here every now and then, full of half truths or interpretations that are made from a incorrect understandings or outdated viewpoints. You have to take the view as of now, what is gone is gone and all that.
Whilst I have no great love for GPH as a company and feel they could have handled things very differently the result is the same, to all major intents they are in compliance with the GPL and to mark them otherwise (often on semantics) would be a disservice to them. Especially when you compare them to some of the 'big name' violators that flaunt the GPL.
If there are specific violations then please do inform GPH, inform the maintainers of the GPL code (after all they are the only people who can take direct action) and by all means inform the community but don’t speculate on ‘possible violations’ as it just serves to fuel the misinformation (well IMHO anyway ).
Again, facts always speak louder then speculation .
You also have to remember that the numerous people with 'standing' that banded together to inform GPH of there dissatisfaction with the situation and that also proposed taking further action have been satisfied with the code releases.
On the subject of the video decoding object it is maybe best to think of it on the same lines that mobile operators use to keep there radio code separate from say a Linux powered phone (often choosing to run that radio code on another CPU core). Over simple overview I know but it’s broadly appropriate.
This decoder interface is public and shown in the code (it does not necessarily have to be documented mind you or even clear what flies over that interface) but the resulting engine is as closed as can be.
The MagicEyes decoder implementation broadly complies with this ideal but is not as graceful or as well segregated as it might be but I don’t think any of the mplayer maintainers seem anxious to challenge anything. The same binary object is used in MagicEyes MMSP2 WinCE implementation also.
Last edited by a moderator: