IPF and Openness

[Interceptor]

We hear you

It's writing support that's causing silence right now, but it's nearly there, and it's awesome.

[balrog]

Has there been any progress with the open-sourcing? Some of us are waiting patiently...

[mr.vince]

We know. We're still debating, but it seems like a deadlock atm. The reason is pretty easy to explain: We wanted to start with something that we feel comfortable with. As we have explained before we do like giving it to the community to use and explore. We don't want to give it to people trying to exploit and abuse it.

The deadlock occurs is where the "opposition" comes in. The conservative GPL "fanboys" just allow for black or white, anything that's not GPL is useless and they will just write their own piece if code if you don't throw away your rights and "surrender" to GPL. We have been discussing how much sense it makes to deliver the sources e.g. with MAME source just to find out the only ones using it will be the violators that just don't care about anything and take what they can get. This is of course a very negative scenario, but at least some people posting here / sending emails more or less lined out what to do or they would not be willing to use it.

Some people seem to think the IPF decoder lib just delivers methods to extract floppy data from the IPF which then can be fed of some kind of byte buffer. In reality, the IPF decoder library will create a virtual floppy in ram with all its anomalies, that can be used like data coming from a real floppy. Generic MFM decoding even uses a custom made WD 1771 emulator, that will again recreate all anomalies present in the original.

We have not stopped discussing, but the above makes it complicated. We also thought about releasing specs for the format, so everyone can create their own implementation, which would be similar to the PDF scenario. The format itself is very well documented with many free implementations available, but Adobe Reader still remains proprietary and the de facto standard for professionals.

For the record: The source of the IPF decoder library has already been given to interested developers and institutions (like national archives). We're not sitting on it, and everyone is invited to ask for it. The above is related to an "uncontrolled", public release. It's taken us 10 years to make it. Maybe this helps to understand we don't want to rush just to find out we picked the wrong choice.

[fluxcappy]

Practically, I believe it comes down to whether you want an open source license that lets you be rich, famous, or still in charge.
Pick one of the goals, and let the rest go. Open source is more of a gift or attention economy. Sell "technical support"/consulting service that go with the code. That's was a common way to monetize software even before open source licensing took off.

Looking at some practical examples, we have Linux. The Linux kernel is released under GPLv2.
Linus Torvalds is doing OK, and RedHat, SuSe, and other companies are making money leveraging the Linux code base as part
of their business models.

The Linux name is trademarked,so that a business has to license the trademark.
That gives the trademark holder a degree of control.

Nothing is preventing you from trademarking the IPF to protect the integrity of your work. It might not make
you rich, but you might get enough cash from trademark licensing to offset some of your personal expenses, and establish
the IPF "brand" as a useful preservation format.

Good luck

[mr.vince]

Just for the record: KryoFlux is sold to the community to a price that basically recoups direct production costs. We never intended to make it a mass product produced in China, so making it with the help of the friendly guys at Olimex for sure is a bit more pricey than having it done by small children's hands somewhere in Asia. I am exaggerating here. The important point is that commercial users or institutions pay (a lot) more money which is intended to help secure further development. We already supported "our" platforms (Amiga, Spectrum) to the max, so there is little left someone would do because it's just pure fun. To address the consulting part of your recommendation: despite the fact that the software very clearly states that it is for private, non-commercial use only, some institutions have chosen to buy a what we call Personal Edition in the web store. It is hard to overlook this fact, but hey, it's just some many hundreds of Euros cheaper to do so. What I am trying to say is: Just being honest seems to be out of fashion.

Our main motivation for making the lib open is not money. It's not fame (we never did this to become famous). Being in charge is actually nice because there are very few people that understand the technical basics of what the lib does; so better us than someone making it worse and wasting a decade of work and research put into it. We think opening it will show people it's good, how it was made and that it's more than a pure format decoder. And it will show them why they should be using it.

If we can reach the same goal with just doing a full documentation, then this might be the way to go. Even the closed source version as it is now has been pirated so many times (with pirated we mean people taking it an pressing it onto a CD to sell it), that it's hard to believe those would care about an open source licence.

Feels like we're just too much "prisoners" of our definition of being honest but... I don't want to become to philosophically here. I just wanted to show it's still an important point that will be addressed and we're still commited to it.

We're putting many hours a week into this... even if it does not show (because such internal things are not discussed in public).

[balrog]

Our main motivation for making the lib open is not money. It's not fame (we never did this to become famous). Being in charge is actually nice because there are very few people that understand the technical basics of what the lib does; so better us than someone making it worse and wasting a decade of work and research put into it. We think opening it will show people it's good, how it was made and that it's more than a pure format decoder. And it will show them why they should be using it.

If this is what you want, you're best off with GPLv3. Or even LGPLv3. That way, people can't take the code and close it.
Dual-licensing with a MAME-style (non-commercial license) would work great. Best of both worlds.

I've said this before, and probably nothing will happen and the code will remain closed for a long time. Whatever you do, please at least release the format spec. A closed format is exactly what none of us want.

[mr.vince]

Rest assured that hiding IPF spec is the last thing we're interested in. We just have to focus on things because time is precious...

As for the MAME licence... I don't see the advantage of using both GPL and MAME. To me GPL and a commercial licence would make sense, and MAME and a commercial one, too. What would be the benefit of having both MAME and GPL?

[TeaRex]

A simple question: What practical thing can WE, the users, do at this point to get write support closer (even just a bit) to being a usable reality? Donate money? Donate coding work? Donate legal services? Donate hardware? Keep hassling you? Stop hassling you?

Personally I don't really care whether your code is open or closed, but I do care about write support, and, to be honest, I would've held back on buying KryoFlux if I had known in December that it would take so long. I believe you when you say that back then you really did plan to release it in February, but, I'd love an honest answer: is there any actual progress on write support at this point in time? At all?

Thanks for your consideration.

As for the main topic of this thread, IMHO you'll have to decide whether being peeved with dishonest freeloaders, while totally and utterly understandable, isn't actually becoming a hindrance in the pursuit of the goals you have (or once had) with KryoFlux. I have the distinct fear that if there's still no progress a few months from now, this small community and the whole KryoFlux thing are going to fall apart as far as use by private persons is concerned. So that instead of becoming a household name in the retrocomputing scene, you'll end up dealing with stuffy big institutions only, surely a worthy goal in its own right, but probably not what you had in mind when you started the project. And it'd be a shame too, a waste of lots of good potential if I may say so.

I mean, what can a normal user of a System other than Amiga, ST, Amstrad or Speccy actually do with a KryoFlux right now that can't be done just as well with the previous solutions for unprotected disk transfers, such as X1541 family cables, fdrawcmd, SIO2PC or Apple Disk Transfer Pro. He can send you the dumps and hope that, a long long time from now, IPFs will appear in your database. And that's pretty much it. For many potential customers, that'll be too little to actually justify the expense of getting a KryoFlux, even though you're already selling them as cheap as you can without incurring a loss.

If old computers are your hobby, you'll want to do what hobbyists do: get creative, contribute to the hobby, help yourself and in the process help others as well. If all you could do in model trains was buying complete sets and use them as-is, it wouldn't have become popular. Tinkering and building your own stuff is what made it popular. I think the same principle applies here: give people some bits and pieces and a chance to pitch in, and they'll love you. Keep promising the perfect solution that already does it all for you, and they'll only get bored. And nothing kills sales (and reputations) as much as people being bored by your products. Remember, even a bad press is much better than no press.

[mr.vince]

We have been mailing about your concerns when you weren't comfortable with the way some things things were before you bought KF. You chose to buy KF anyway.

Regarding the options other solutions offer: There are many types of cars you can buy. Does that mean we only need one car? I see many pros for KryoFlux (variety of operating systems supported, USB, schematics available to build your own). And even if it would just work with sector dumps... there are other solutions that only work with sector dumps. We have documented the STREAM file format (viewtopic.php?f=2&t=177), so people can actually make use of it and transfer the data into whatever they need or want to use. Notice we called it "High Definition Flux Sampler for USB"? We wanted to be clear and help people understand what it is.

As for IPF: This has been a long journey. Many said they could do better. Still, there hasn't been as single format new format over the last decade that is able to actually store real disk data for multiple platforms at the same time, e.g. Amiga, AtariST and PC (I am talking of tri-formatted disks here).

As for code availability: We are talking an uncontrolled public release. There are already many people around the globe that have access to the source. They just asked. Several libraries and institutes have access to it as well. It can't be lost because it's stored in so many places already. We're not shy of showing it to someone. We would just be emarassed if we'd see someone selling it. That's it.

As for the hobby: We have been approached from many sides, including some very large libraries / archives. People need help with preservation. We actually have two options: Refuse, and leave many thing unpreserved. Or we turn this into something where people get paid to do it. That does not mean making money to buy Porsches for the whole crew. It means paying them in a way they are being paid right now by other companies to finance living. In fact there's so much work piling up, it's hard to decide where to start first.

I stand firm that if you want things preserved properly you can not leave it to the community. That's why there are libraries. We are working with libraries and share insights and technology. There are people that will be upset about me (us) complaining. They are going to call me (us) arrogant because they will assume we don't respect their efforts. The big risk in preservation is preserving things the wrong way. Now when you preserve a book, you start by collecting it. You can even just put it on a shelf for some time. It will not deteriorate as quickly as a floppy disk. Things become urgent when the material itself starts to deteriorate. I've seen this with books that are only 20 years old (cheap paper with too much acid in it). With digital preservation, the main problem is the transfer and if you lose a bit, notice to late and you are sacked because you can not go back. When you have a book and a word is barely readable, you can still read and understand the story itself. In a game, a track not found (which, as per Murphy's definition will contain program code) means the game will not run at all. So to be able to say "it's preserved!" you need to be able to define the encoding format used for storing data in the first place and verify against this. Otherwise you risk storing a modified, damaged or incomplete dump. Just playing a game does not ensure the copy is good. Because of this we draw a line between preservation and perservation. We don't say it's wrong doing something, even if you just collect sector dumps. It's actually very good people are doing this, and we like digging through various sources when looking for something ourselves. But we also think it's important to try and archive the real deal. Unfortunately the latter needs a lot of expertise and there are only few people that understand the scope of such a project.

As for writing: We always made clear preservation (ingestion) comes first. We hoped to get writing done much sooner, but approach A just did not work the way we expected it to work. Things like this happen in engineering, so we started working on approach B. This is already proven to work, but needs about ten times the work to get it done. I am not going into detail here right now. I just like to point out I'd like to kick myself in the butt for saying we are striving for something for christmas. We just lack the manpower to go faster atm. We are working on this every single day. We also had to work on some things inbetween, e.g. getting other institutes into making their own IPFs (which means that now other libraries can create IPFs on their own). Unfortunately it is very hard to find people skilled enough to help, and those who could, would just ask for a sallary we can't pay. Please do not forget: You bought a product produced in a batch of 100 units. The price you paid is to cover production costs. You might ask around and find out about setup prices for board production and assembly. Of course we'd have a margin if we could make batches of 10.000 units. I am not complaining here. I am just explaining why someone can't work on this full time. I just fear saying some date and put more pressure on this, again. All I can say is that the road is paved, the whole framework is coming together and my wording would be "soon".

[balrog]

The benefit of MAME and GPL:

MAME : for non-commercial use where copyleft is not an option.

GPL: for "Open Source Definiton"-compliant open source use This would allow commercial use (because of the Open Source Definiton forbidding Terms of Use restrictions), but the GPL (especially if it's GPLv3) would make people think twice (you have to open source your code if you use it).

The third option in such a setup: for-fee licensing with whatever terms you (the copyright owners) want, goes without saying. Anyone should be able to negotiate with you for any license you want to offer.

Does this make more sense?

Still, the spec is most important for me. Even if it's just a bunch of (hopefully documented!) header files.