IPF and Openness

All news about KryoFlux go here.
User avatar
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: IPF and Openness

Post by IFW » Sun Feb 13, 2011 9:22 pm

Sure, IPFs are tagged and tags are easily extensible.
However, the existing files out there do not have digests, keys etc. and as discussed before users would probably prefer to know whether a file is something coming from Softpres, or not.

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

Re: IPF and Openness

Post by IFW » Sun Feb 13, 2011 9:26 pm

As for converting IPF into another format: you can do it, but you are guaranteed to lose information/precision/flexibility as the library supports the data according to the host application's requirements.
Therefore whatever data is returned is what the host application wanted at the time it was generated - a different host application may want something else depending on the use case (e.g. writing to a real disk vs emulation vs comparison tools etc).

Posts: 7
Joined: Sun Feb 06, 2011 3:43 am

Re: IPF and Openness

Post by MrX_Cuci » Thu Feb 17, 2011 5:41 pm

Jumping in here. If someone posts the hashes (probably already in the offline database XML from the softpress website) of the dumped files created by Softpress, that's enough for me. I then know the dump is good at least. I use the No-Intro.org dats now for checking, but it hasn't been updated in almost a year now. (your database hasn't been updated for a year?)

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

Re: IPF and Openness

Post by karadoc » Thu Feb 17, 2011 10:27 pm

I know what you mean, but I personally quite like the idea of an emulator telling you the origin of an IPF and you knowing by the signature being validated. When it comes to preservation, being able to securely verify the origin I think it is quite a compelling feature. But anyway, we already decided this is not a blocker on opening the source. It's just something we want.

The XML database has not been updated because I seem to have mislaid the edits. Apologies for that, I'll have to regenerate it, but just not got around to it yet.

Posts: 7
Joined: Sun Feb 06, 2011 3:43 am

Re: IPF and Openness

Post by MrX_Cuci » Thu Feb 17, 2011 11:44 pm

I know what you mean, but I don't see many emu authors implement the use of such a function. From a user point of view (not me included) this is considered annoying. Look at SNES (or MAME even) where the header and other info is being shown. I believe most users are not interested in such a function.

I now wished I mentioned the database lack of updates sooner. :) I hope you can fix it soon.

User avatar
Posts: 42
Joined: Thu Dec 02, 2010 1:29 am
Location: Oldenburg, Germany

Re: IPF and Openness

Post by OCMoe » Fri Feb 25, 2011 1:49 am

A little evangelization section up front, due to a common misunderstanding:
Interceptor wrote:I don't personally support gpl or viral licensing, certainly not for this, and I think it's a bit crap that gpl won't let you use free code that's not under gpl. Gpl has it's downsides any anyone using it would or should have given that due consideration.
What makes you think that? GPL is compatible to a lot of licenses. Being a more restrictive license than, e.g. "do what you want" BSD, it's easy to incorporate non-GPL code in GPL apps. Really free code (as in "speech", not "beer") works well with GPL. The popular OSI licenses allow you to pass on the code with more restrictions than before, so a GPL+BSD program would effectively be fully GPL licensed.

The GPL was not created to discourage commercial use of the code. It's purpose is to protect the rights of the user. Similar to the EE mantra of "if you didn't take it apart, you don't own it" it makes sure that everyone using such software is allowed to adapt it to her purposes. So even if you pay for it, you are allowed to modify it, pass it on for free, etc.. This makes commercial use of the code difficult. It's enough to stop most companies, and those that violate it soon see the error. Winner is always the user, as she gets full control.

The problem of someone exploiting other's works is not as bad as you may think, even if People try it all of the time. On ebay, there are regular attempts to sell stuff which you can legally download for free. Nevertheless, none of them is making serious (legal) money, the profitable schemes are actual crimes (fraud), which means the license doesn't even matter.

Keep in mind that the GPL is one of the oldest OSS licences. It is proven in court as well as in real life. While bad guys do exist, no GPL project has actual problems with commercial exploitation. The most famously (and perhaps most often) violated GPL project is busybox, which is commonly found on WiFi or ADSL routers and other embedded devices, but even this isn't a problem money-wise. People sue GPL-compliance so they can dabble with the gadgets they bought :)

Now turning off evangelization mode.

Actual recommendations from a decade of OSS publishing:
  • Dual-licensing is a must, unless you change your mind and say "who cares, just do it".
  • GPL is legally well-established world-wide. It's the safe bet if you want to be able to go to court over violations. In Germany there was a recent court judgement which resulted in financial compensation for GPL violation alone (not accounting any actual damage, just for the violation per se). Using GPLv3 would also incrase security against patent infringements, which is a real threat for your code (open or not), due to its advanced nature. Windows Phone 7 and iPhone emulators (should the latter ever be allowed) would require commercial licenses since both companies forbid "copy for free" licenses.
  • LGPL would be the real commercial-friendly alternative, preserving the openness of your code, making sure that any enhancements to your code will get published, but not otherwise discouraging sales of commercial products (if you are unfamiliar, it basically says "you must link dynamically so that users can modify/exchange if they want, and any changes you do to the LGPL code must be published, but not your app code"). People could easily sell apps using your code, but they wouldn't profit from selling the library itself. If I understand you correctly, it's not what you want.
  • An interesting case is the QPL (Qt Public License), which was heavily criticized in the OSS world for not actually being open -- it had a strong non-commercial clause, exactly what you want. If you want to start slowly, I think this is the best choice. You can assume that some lawyer worded it, making it more solid than a self-made "BSD+noncommerce" combination. Back when Qt was still owned by TrollTech, not Nokia, it was the initial license. With V4, they switched to GPL instead. (TrollTech used dual-licensing throughout for commercial customers).
  • I'm not terribly familiar with the CDDL (Sun), I think it does have some restrictions you might like.
  • As long as you don't accept patches (IMO that would be a bad decision), you can relicense whenever you want. If you do, check out the Apache foundation or the FSF for their "Copyright Assignment" forms/procedures, otherwise each and every contributor would have to agree with licensing changes.
  • A viral license has the advantage that if anyone comes up with something really clever (like some company-spent development effort), that would automatically contribute to your code base, if you want that. You said you didn't want their code, but you might change your mind if some R&D department uses your software as base and puts serious thought into improvements.
Hope this helps. I'm happy to see this kind of discussion. Judging by your current stance, I'd really suggest dual-licensing QPL/non-free and keep GPL in mind for later, plus accept patches that come with copyright assignment.

Posts: 1
Joined: Sat Feb 26, 2011 7:49 pm

Re: IPF and Openness

Post by Eclipse » Sat Feb 26, 2011 7:57 pm

You face a similar situation to what the makers of DD-WRT were in.
I believe their license is restrictive for personal use, and business have to buy a full license for commercial use.

The GPL is not a one glove fits all either. I believe there are certain variants that would suit your needs.
Incedentily registering it as a trademark might help. You are already covered by copyright automatically so you already can say what should happen with it. You could even issue the license in the same way most software companies do i.e. you own the right to use it but not alter or copy it, even if you own it on a physical medium.
Just some of my thoughts :)

Posts: 14
Joined: Sun Nov 07, 2010 2:32 am

Re: IPF and Openness

Post by firefly » Thu Mar 03, 2011 3:03 pm

I think this a a very good idea, to make the specification available.

One Example.

What would happen in say 10yrs time?
Will the SPS kryoflux team etc still exist in the form they are in now?
What would happen if you would like to support ipfs on a platform / machine / device / OS variant that does not exist now?
Would SPS or anyone with the skills / format knowledge / details / code be available or would this be lost ?


User avatar
Posts: 58
Joined: Wed Oct 06, 2010 10:17 am

IPF and Openness

Post by Interceptor » Thu Mar 03, 2011 6:29 pm

Well, we've already decided open is the best way, and were committed to doing it.

However "open" can come with or without license, and there are various license available.

And HOW we open it is what this thread is about :)

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

Re: IPF and Openness

Post by TeaRex » Tue Mar 08, 2011 6:35 pm

Well, I guess "it's done when it's done", but whatever you do I'm very much looking forward to it. Also to write support, even when it's not yet at 100% in the first release that does it.

Post Reply