IPF and Openness

All news about KryoFlux go here.
phi2x
Posts: 3
Joined: Sat Feb 12, 2011 12:15 pm

Re: IPF and Openness

Post by phi2x » Sat Feb 12, 2011 12:32 pm

It's not only a matter of license. You have to realize that lots of emulators are coded in Java, Delphi, C#, etc...
So having an IPF C library, no matter the license, won't be of great help for those emulator authors.

The key thing here IMHO is that the IPF format has to be well documented in details. And that documentation being freely accessible for people to re-implement it their way if they choose to.
I don't think any open format can be a success without allowing that.

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: IPF and Openness

Post by IFW » Sat Feb 12, 2011 2:09 pm

Sure, and as you could see we do stuff in Java as well for the GUI so can perfectly understand this.
The best documentation is always the source code in the first place though - quite simply as it is a moving target.
Another reason to publish the source is to avoid unecessary duplicate work; if you feel so, you are more than welcome to add something new needed, rather than re-invent the wheel.
There is a long list of things that would fall in to that category already...

balrog
Posts: 17
Joined: Sat Feb 12, 2011 2:57 pm

Re: IPF and Openness

Post by balrog » Sat Feb 12, 2011 3:05 pm

I would recommend (and really hope to see) dual-licensing, with GPLv3 and MAME license. IMHO the GPLv3 prevents "predatory" commercial use, with its anti-tivoizaton and patent provisions. And it is viral, which in this case is a good thing, because it would apply to commercial use.
The MAME license would allow non-viral licensing but only for noncommercial use.

Also, a third option would be obtaining a license from the copyright holder, which would override and supersede either of the open-source licenses. Just PLEASE be careful with this, since granting permission to redistribute using more permissive terms than GPLv3 or MAME license would cause issues!

Again, I would do GPLv3 rather than GPLv2 mainly because of anti-tivoization provisions, which I feel is a good thing in this case.

One thing to keep in mind: if someone reads the source code and writes an independent implementation, they can license that implementation using whatever license they want. If they copy more than trivial quantities of code (this would be fair use), only then they'd be bound by the license.

(By the way, I'm not a lawyer, and this is just what I've learned over the years ... again, I really hope this goes GPLv3 / MAME license / "shareware licensing" for others.)

User avatar
karadoc
Posts: 138
Joined: Sun Oct 31, 2010 9:12 pm

Re: IPF and Openness

Post by karadoc » Sat Feb 12, 2011 10:37 pm

phi2x: I don't think there is much stopping a Java emulator from using the current library, made easier using JNA. I guess C# and Delphi would have alternative mechanisms. Of course, it is far from ideal.

Apart from what IFW said, something hasn't been said enough in this thread: What we are talking about here is what to do *now*. We have to be honest and say that we simply do not have the resources to document it right now. Once the source is available, we are very much hoping that others will help us with that, the source is very well documented after all. It is, as you say, very important to be documented. It's not a simple format, which makes it all the harder.

User avatar
karadoc
Posts: 138
Joined: Sun Oct 31, 2010 9:12 pm

Re: IPF and Openness

Post by karadoc » Sat Feb 12, 2011 11:08 pm

Balrog: Thanks for the heads up on that, especially the GPL3. That is certainly something to look into. We have a lot to think about, both for the near and longer term. This is all a bit new for us as a group, and this discussion has been very useful. Let that not be a sign of it ending though!

balrog
Posts: 17
Joined: Sat Feb 12, 2011 2:57 pm

Re: IPF and Openness

Post by balrog » Sun Feb 13, 2011 12:19 am

Yes. In general, GPL (v2 or v3) makes commercial use less desirable because whoever is using the code needs to make their program GPL as well to stay legally "in the clear." (And those who disobey GPL won't obey any other license either.) With a project like this one, where a noncommercial license, and individual per-case licensing, will also be available, the anti-tivoization provisions aren't a downside.

As for forking — I've generally seen this happen in few cases: when upstream refuses to collaborate, when upstream changes the licensing arbitrarily (XFree86/Xorg and cdrtools are two notable examples), and when a project stagnates. I don't know — the main goal here is for the spec to be constant, so what I'd do (and I don't know how hard this is) is have a test suite that can be used to verify that an implementation meets the spec. If someone wants to write their own implementation, they are free to, but a combination of GPL, permissive non-commercial, and individual per-case licensing should alleviate that problem. (Of course there will be those who want to run the code on unusual platforms, but if the code doesn't have major external dependencies this isn't really an issue.) Something non-GPL (BSD/permissive) becoming GPL often happens when interest in the former is lost, and the new people want it to be GPL. I may be wrong, but I haven't seen this with projects that aren't stagnated.

Also someone probably already pointed this out, but the binary kernel modules aren't exactly "approved" for use with the Linux kernel. Linus doesn't like them (I'd have to search for the actual text, but it's been said), and Linux does (or used to) print a warning when a binary module was loaded, indicating that there would be no support for issues with it, because of the proprietary code. (BTW GPLv3 has stronger provisions here — Linux would probably be GPLv3 but Linus dislikes anti-tivoization provisions [which can be good or bad, depending on application]).

By the way, JNA is lousy and a version written in Java would be nicer. Of course, more code to maintain, and a test suite may be useful here too.

I may be wrong with something I said, I'm just suggesting stuff :)

Are there any plans for the hardware/firmware (if applicable) specs (and code) to be available? I'm thinking only allowing noncommercial use there — but yes, some of us DO want to DIY the board!

TeaRex
Posts: 120
Joined: Tue Nov 30, 2010 5:36 am

Re: IPF and Openness

Post by TeaRex » Sun Feb 13, 2011 12:48 am

Interceptor wrote:I dont see why anyone wants to create their own ipf files though?
Maybe because they want that "Phantasie VII" IPF for DumbOS 13-bit systems NOW, or rather YESTERDAY, and not wait for you to create it?
Nor am I sure why anyone thinks they are qualified to do it?
Because nobody likes being told "you're too dumb to do this", even if they in fact are. See Egypt. :D

Edit: I didn't notice that there was more to this thread, sorry about answering to such an old thing.

balrog
Posts: 17
Joined: Sat Feb 12, 2011 2:57 pm

Re: IPF and Openness

Post by balrog » Sun Feb 13, 2011 1:00 am

As for junk images created by people not knowing what they are doing, the simple solution is to use private-public key cryptography, with each person ripping disks having their own key pair. It would be important for the private key to, well, remain private. A list of hashes should also be stored, in case a private key does leak and needs to be revoked.

TeaRex
Posts: 120
Joined: Tue Nov 30, 2010 5:36 am

Re: IPF and Openness

Post by TeaRex » Sun Feb 13, 2011 1:08 am

One more idea... have you thought about embedding a digital signature into your own SPS-released IPF files? This way an emulator could be configured to accept only your own, known-good files, or at least to warn if the file is unsigned or signed with another key. IPF currently has one HUGE advantage over other formats, there is not tons of garbage floating around the net in IPF format, only nice, working, uncracked, pristine game disks. It would be a shame if your publication of the details should destroy that advantage! Of course, for those (unsigned) IPFs already in existence, emulators could embed lists of message digests, if you'd release them.

Edit: Looks like balrog and me had the same idea at the same time...

User avatar
karadoc
Posts: 138
Joined: Sun Oct 31, 2010 9:12 pm

Re: IPF and Openness

Post by karadoc » Sun Feb 13, 2011 1:40 am

It's 12:30am here, so I will be quick:

Thanks for all the extra info on GPL balrog. I'll look over that more deeply tomorrow.

I wouldn't say JNA is lousy... JNI is certainly lousy, but I think JNA, as a technology, is very cool. I use it at work to call into legacy apps. Having to call native stuff at all isn't so great of course. I guess that is what you meant.

Test suite is a great idea. Unfortunately, that is resources away from doing preservation work. I think that would have to be something mainly left to others to be honest.

Signing IPF's was one thing we wanted to do before opening the code, and actually one of the main reasons that it has been delayed the last couple of years. Hashes for all current IPFs would be hard-coded in the library, and all new stuff would be signed (and emulators would state an IPF's origin, or maybe even, if we ask politely, flag it if it wasn't from us). This would be implemented in the library so it made it easy for emulators and tools to check and display that information. But again, it's time away from preservation work, which always has to be our priority, so we haven't been able to get to it. We were quite hoping that once the code is opened, this is one of the first things people could do for us...
Last edited by karadoc on Sun Feb 13, 2011 1:52 am, edited 1 time in total.
Reason: clarified signing stuff

Post Reply