"Respects Your Freedom" certification?


Roms are a separate entity. They are indeed closed source but that doesn't really matter. The program that executes the roms - the emulator - is usually open source and you can be pretty sure the emulator will not be able to execute malicious code. That is my main reason for advocating and using free software. I just don't trust closed source software.
Just wondering how you deal with stuff like DOSBox or other PC emulators?

D.
 
Unless you are making claims to be a representative of the FSF, your statements are irrelevant to the discussion.
That's just mean.
I too feel uneasy with :

Other Misleading Endorsements

Companies awarded RYF certification for a given product, must not distribute any product-related materials with endorsements or badges to proprietary software, such as "Works with Windows" or "Made for Mac" badges, because these would give an appearance of legitimacy to those proprietary packages, and may make users think the product requires them. However, we don't object to clear factual statements informing the user that the product also works with specific proprietary operating systems.
and

Termination

Failing to meet these requirements at any point can result in immediate revocation of certification. However, if the failure was unintentional we will look for a way to resolve the problem amicably by bringing the product into compliance with these terms.
Which mean that if ED at any point in time say "hey it works with android and the play store" (or the google apps for the matter), then the FSF is allowed to revoke RYF... I cannot read that in an other way. Ad if you're not a representative of the FSF then you cannot say otherwise : that's what the FSF show black and white on ther website...

Beside promoting emulation is promoting close source. If the source were open nobody would need an emulator in the first place... (and for those expecting that the emulator make sure the emulated program does nothing bad to your stuff, just read an emulator source... especially the dynarec part)
 
Last edited by a moderator:
Beside promoting emulation is promoting close source. If the source were open nobody would need an emulator in the first place... (and for those expecting that the emulator make sure the emulated program does nothing bad to your stuff, just read an emulator source... especially the dynarec part)
Care to explain what kind of harm a nes, snes, c64, genesis rom can do?

I am not fanatically against closed source software but my main objection against it is that I don't know for sure the developer can be trusted. The closed sourced programs that are currently available for the Pandora are created by developers I usually trust, so in that case - as an exception to my rule - I do install closed sourced software. That is my choice and my risk, but I don't want it to be installed in the default firmware/software.
 
Roms are a separate entity. They are indeed closed source but that doesn't really matter. The program that executes the roms - the emulator - is usually open source and you can be pretty sure the emulator will not be able to execute malicious code. That is my main reason for advocating and using free software. I just don't trust closed source software.
Just wondering how you deal with stuff like DOSBox or other PC emulators?


D.
Not using DosBox at the moment but I think you mean it is still possible to execute malicious code using them? 
 
Unless you are making claims to be a representative of the FSF, your statements are irrelevant to the discussion.
And if you go back to put that in context, it was in reply to someone who was making claims on behalf of the FSF that were contrary or lightening the language used on the FSF/RYF requirements site.

As far as I know, the FSF has yet to actually reply to attempts to contact them about these issues.
 
Unless you are making claims to be a representative of the FSF, your statements are irrelevant to the discussion.
And if you go back to put that in context, it was in reply to someone who was making claims on behalf of the FSF that were contrary or lightening the language used on the FSF/RYF requirements site.


As far as I know, the FSF has yet to actually reply to attempts to contact them about these issues.
...and you are making claims about the proper way to interpret the same language, that is no less preposterous than the one you replied to. By which I mean exactly that - I'm quite certain that you're both way out of the actual, only in different directions. 

But, the point is: It is a bit rich to berate someone else for not being an "official representative" when trying to interpret the FSF pages, whilst you yourself do that all the time. To me, it is all the same - Keep interpreting, both of you - but the hypocrisy is strong here.
 
Care to explain what kind of harm a nes, snes, c64, genesis rom can do?
I would doubt there is anything "evil" in these roms. Because these system are old and emulation at this point wasnt seen as a threat by the big corp's. But for nowaday system, I would be more carefull. If the major include new generation over new generation of system to block copy protection in CD and DVDs why wouldnt a game company try to protect their games against enulation. For example, the dolphin emulator emulated the wii while it was still a current gen console (well bigN would argu it is still current, but there are no more new games for it). A company could have hidden an x86 payload in the disc with a part of the game checking for an exact matching of the hardware timing and randomly load that payload and jump to it and tada you're screwed. On the console, at worst it could crash the game but within dolphin...
 
Last edited by a moderator:
i cant find the talk where RMS says its ok to emulate games. The question is what do about game cartridges, and the reply is something like "what damage can that do, you are effectively freeing up something that was out of bounds. Aging of cartridges and putting them in landfills was mentioned. Same talk is about hardware devices, the way forward and licensing thereof.
 
Roms are a separate entity. They are indeed closed source but that doesn't really matter. The program that executes the roms - the emulator - is usually open source and you can be pretty sure the emulator will not be able to execute malicious code. That is my main reason for advocating and using free software. I just don't trust closed source software.
Just wondering how you deal with stuff like DOSBox or other PC emulators?
 Not using DosBox at the moment but I think you mean it is still possible to execute malicious code using them?
Yes, you can. It won't affect your main linux install (obviously) but in the case of say, QEmu, it could wreak havoc on your virtual PC windows95 install or whatever. Malicious code is still malicious even when sandboxed this way. Granted, you can make backups of your HDD images and revert any changes but even so - you're still executing code for which you don't have the source.

Even the Amiga emulator (especially now that it has HDD support for WHDLoad) can become virus-ridden very quickly.

D.
 
Unless you are making claims to be a representative of the FSF, your statements are irrelevant to the discussion.
And if you go back to put that in context, it was in reply to someone who was making claims on behalf of the FSF that were contrary or lightening the language used on the FSF/RYF requirements site.

As far as I know, the FSF has yet to actually reply to attempts to contact them about these issues.
 ...and you are making claims about the proper way to interpret the same language, that is no less preposterous than the one you replied to. By which I mean exactly that - I'm quite certain that you're both way out of the actual, only in different directions. 

But, the point is: It is a bit rich to berate someone else for not being an "official representative" when trying to interpret the FSF pages, whilst you yourself do that all the time. To me, it is all the same - Keep interpreting, both of you - but the hypocrisy is strong here.
No, it IS different. Please go back and look at the context of what I was replying to and how I was replied to in turn. _wb_ had published his correspondence with the FSF. I added a few points that I felt should be included in the line of questioning. comradekingu took it on himself to reply on behalf of the FSF.

Context is important. You stripped that one line out of it's surrounding context to try to 'prove my hypocricy'. The reality is that it was 100% valid for the context that it was written in.
 
@sebt3 + ZXDunny
I agree there might be malicious code in roms or programs used by homecomputers. I had some virus infecting my Atari ST disks too back in the days and I assume they can still do harm within the emulators reach. 

That is not my main concern though. I want the firmware and apps as secure and open as possible. I just don’t like the idea of closed source apps going online or adjusting files on my sd card / hdd.

For private stuff - e.g. agenda - brainstorming - I even have a Pandora with no wifi and I regularly make back-ups.  

That is not the only reason for preferring FOSS. Free software will be available even when the original devs will not support it anymore. I would hate to see a nice game like Microbes unavailable for P2 because _wb_ didn't feel like porting it or releasing the source. This is even more applicable for more serious apps.  
 
Last edited by a moderator:
ZXDunny [and few other ppl ] showed already that Closed Software can be ported without any real problems. Only thing you'll need is to ask proper person. You dont need FOSS to get apps on OP 1 / OP 2. 

http://repo.openpandora.org/?page=detail&app=SpheresOfChaos.zxdunny.0312

http://repo.openpandora.org/?page=detail&app=forgetmenot.zxdunny.2994

as well as Pickles port of VVVVVVV

http://repo.openpandora.org/?page=detail&app=vvvvvv.pickle

and this is just a begining. How many of You send an email to indie dev with helping hand to port indie app/game to OP?
 
Last edited by a moderator:
Sure, but there are also enough examples of closed sourced stuff never ported to other devices. F-day comes to mind, a promise from Rlyeh from the GP32 boards. He had some amazing emulators that were all closed source and available for the GP32. He never ported them to the GP2X and also never released the source. 
Basically the code is now lost for new handheld generations. Personally I think this was a waste of good labour. If he had shared it we could have still enjoyed them and we would have probably still talked about the guy.
 
Last edited by a moderator:
Relying on the goodwill of the developer to port to your platform is a real problem in the linux world, and certainly even more-so for a niche device. Its not insurmountable, but it relies heavily on a personal wish to see it happen.
 
Last edited by a moderator:
Don't forget that sometimes devs die or otherwise become unreachable.
Indeed. More common is that devs just don't care or maybe think they can still make money from the project.

I like pinball and Visual Pinball became OS in 2010 and the competitor Future Pinball is still closed. Visual Pinball is still being improved by some very talented coders. Future Pinball was in the beginning the upcoming promising engine that would be the best pinball simulator ever.

It is graphically very nice, but it lacks some very essential physics. FP is not being improved but VP is now becoming graphically as powerful as FP was.

I have no idea why someone who is clearly not going to make any money anymore from a project wouldn't release the source. Could the reason be illegal / stolen code? Afraid for unpleasant remarks from peers?  
 
Last edited by a moderator:
I just received an answer from the FSF. Here it is:

Dear Jon,

Thank you for contacting us and I apologize for the delay in getting
back to you. The Openpandora project is very cool and I'm happy you
still have an active and lively community. Unfortunately, I'm not sure
it will be possible to award it RYF certification. More on that below.


> To my knowledge, all the shipped software is Free Software, with the
> exception of a binary blob GPU driver (the device has a TI OMAP3
> SoC, which includes a PowerVR SGX GPU) and some firmware that gets
> uploaded to the wifi chip.

Yes, unfortunately this would disqualify your project from being able
to be awarded RYF certification.

> "However, there is an exception for secondary embedded
> processors. The exception applies to software delivered inside
> auxiliary and low-level processors and FPGAs, within which software
> installation is not intended after the user obtains the
> product. This can include, for instance, microcode inside a
> processor, firmware built into an I/O device, or the gate pattern of
> an FPGA. The software in such secondary processors does not count as
> product software."
>
> As far as I understand, the above can be interpreted to mean that
> the non-free wifi chip firmware can be forgiven (since it does not
> run on the CPU), but the non-free GPU driver is still problematic
> since part of the driver runs on the CPU.

Unfortunately, neither the binary blob loaded onto the GPU nor the
firmware that gets loaded onto the wifi chipset would be covered by
our exception. (At least, I don't think it would based upon what you
have stated.) That is because our exception doesn't cover things that
are clearly intended to be user programmable parts of the device. So,
basically, if the source code you would need to provide a person to
reflash the device would need to contain a proprietary binary blob,
then this would not be considered "firmware built into an I/O device",
it would be software loaded by the user of the device. The exception
doesn't cover stuff that is loaded by a BIOS, a bootloader, or a
kernel.


> Question 1: Would it be necessary to remove the binary blob GPU
> driver from the OS shipped with the product in order to get the RYF
> certification?
>
> If the answer is yes, then the device would effectively not have a
> GPU (since there is no free alternative), which is probably not
> acceptable to the OpenPandora Team.

The answer is yes. I think that we would have a lot more RYF certified
devices today if we had more manufacturers releasing free software
GPUs. Hopefully the combined effort and pressure of the FSF and the
many different projects out there will be one thing that can help get
SoC manufacturers to release free software GPU drivers and firmware.


> On the OpenPandora, there are two main facilities for installing
> software. One is based on opkg, a package manager like Debian's
> APT. It is used mainly for updates to the core OS, and as far as I
> know all the packages in the default repository are free software.
> The other one is a community-maintained software repository known as
> "the repo" (http://repo.openpandora.org/), where anyone can upload
> software of any kind. It contains mostly free software, but also
> closed-source freeware and some closed-source commercial software.
>
> Question 2: I assume that this is fine w.r.t. RYF certification,
> right?

Well, we don't have a problem with the non-free repos being hosted on
the same servers. But our guidelines are such that the product must
not steer the user toward those non-free repos. For example, the FSF
is unable to endorse Debian GNU/Linux because it steers users toward
using the non-free repos. Granted, there are some differences between
our criteria for RYF certification and how we endorse distros, but,
'not steering users toward nonfree software' is one of they key things
they have in common. See
<http://www.gnu.org/distros/common-distros.html#Debian> for our
explanation of why we do not endorse Debian.


> Question 3: Does this count as endorsing proprietary software?


It depends on how it is done. I would need to look into it more
carefully to make an evaluation. But, it sounds like since it is more
than a simple statement of fact that it might be problematic.

> Currently the OpenPandora Team often uses the word "Linux" without
> "GNU" when referring to the OS, and they tend to use the words "Open
> Source" more often than "Free Software". I suppose that is something
> that would need to change.

Correct. Although it would be in the marketing materials associated
with the sale of the product. It wouldn't necessarily need to be the
case that we would expect you to police all bulletin boards or
whatnot. What is or is not considered part of the marketing materials
for a given project is something we would look into on a case by case
basis with each product or company seeking RYF certification.

> Question 4: Is this bounty reward paid for by the FSF or by the
> device manufacturer? The OpenPandora Team probably does not really
> have a budget for this.

The bounty program needn't provide monetary rewards. For instance, the
FSF awards GNU Bucks <https://www.gnu.org/help/gnu-bucks.html>. We are
pretty flexible with how you acknowledge or "reward" bug submissions
is pretty flexible.


Thanks again for taking the time to write to us. I hope for all of us
that we will see an end to this trend of SoC manufacturers shipping
GPUs and peripherals that require proprietary blobs in the
firmware. If and when we do, I expect the RYF program will see some
rapid growth from projects like yours and others.

Best of luck!

Josh

--
Joshua Gay
Licensing & Compliance Manager
Free Software Foundation
http://www.fsf.org/licensing


So we cannot ship a binary blob GPU driver and still get RYF certification - either we get a GPU with a FOSS driver, or we don't ship a GPU driver at all - this does not make the device unusable (e.g. on the current Pandora, there is quite a lot of stuff, including emulation of 3D game consoles, that does not use the GPU at all), but it's probably a deal-breaker to most of us. It would also not be an option to not ship the blob driver but to make it available somewhere and "steer the user" towards installing it.

A repo with non-free software is fine and can be hosted on ED's server. But the product cannot "steer the user" towards using the non-free software. So it would not be allowed to ship it with something like PNDManager like it is now (pointing to the non-free repo by default). It would be OK to make PNDManager show the FOSS software only by default, and make it require a user action to see the non-free software.

The videos showing non-free software might be problematic if they're part of the marketing material associated with the sale of the product, it would depend on how they are done. I assume that if the focus of the videos lies too heavily on non-free software (to the extent of implying that non-free software is necessary to really enjoy the device), it would be considered problematic. I assume that the video currently on the official OpenPandora website would be problematic, but the collection of videos ED made (which also includes lots of FOSS) would be OK. But it's something that would need to be discussed.

The marketing materials should also talk about "GNU/Linux" and "Free Software" - it would need to be discussed what is and what is not part of the marketing materials, but I assume that it includes the cardboard box, leaflets, and official web site; it most likely does not include the boards, wiki, etc.

The bounty rewards don't have to be monetary.

All in all, the first two points are probably the biggest issues. Finding a SoC with FOSS GPU drivers is probably hard, and not shipping a GPU driver at all is probably not an option. The only options would be to use BayTrail or to use a SoC with a Mali or Adreno GPU and ship the reverse-engineered FOSS driver. That or somehow convince PowerVR to release their driver or find someone to RE it, but those are quite unrealistic scenarios.

The point about the repo is also a big one: I think there's a majority here that wants non-free software that can be installed easily by noobs, which requires shipping the device with something that steers the user to installing non-free software. I would personally not mind to have only free software visible by default in PNDManager and to require an explicit user action to get to see the non-free software (and this explicit action cannot be instructed in the user manual!). I guess I'm in a minority here. But at least - and I think there is a general consensus about that - it would be useful to make it more clear what the license status is of software on the repo. The license field is currently kind of hidden and it's often not even specified - it's an optional field at the moment.
 
Back
Top