Excuse me for being a bit vague, but I'm trying to avoid the use of a name similar to "P9x" even in passing so that there is zero chance I get slapped with a trademark or copyright dispute.

All current code is based on WinUAE and E-UAE, the rest is from my interpretation of what those were doing. I've never seen an official DDK.

I've worked on an open source RTG driver on and off for a while and lately I'm seeing more people doing the same, which is awesome for the community.

I've just started a git repository for an open DDK for Amiga compatible drivers at https://github.com/jeperk/OpenVideoDDK

It's very early, I've just started getting old info together into the repository and I'm planning to revive my unfinished example OpenPCI Voodoo3 driver as time permits.

Most of it is based on WinUAE, but with hopefully correct translations of the PSSO_ offsets used in WinUAE to actual C structures.

I've also taken the comments in WinUAE and based on the code, written what I think are correct SAS/C style stubs for most functions.

It is not complete by any means, but having the information available can't hurt.

If anyone wants to contribute info or code, feel free to contact me.

Edit: I renamed the project to correct a typo (capital I in Video, thanks polluks), so the URL has changed.

Edit 2: Now under LGPL due to problematic nature of GPL and linking in Amiga-like systems.

I'm not sure what can be said about distributing source with no signed NDA. If you don't want people using your ABI, don't release binaries to the public.

I just think it's important to be able to find info on writing drivers for the platform.

Amiga 68k is currently dominated by this API, so that's what I'm trying to give an example of.

Aros 68k can use the .card files by way of the UAE wrapper code Aros includes, so it helps them too.

It's not a new RTG API standard like the Aros CGX RTG, just more information on using the current one most of us have.

I understand that a replacement is highly desirable, this is just the itch I chose to scratch at the moment.

Stay tuned for more GPL code coming for various projects I've been sitting on.

Excellent move

You can also add information present in the actual working driver of the SAGA  (VampireV2) driver which was developed by Jason McMullan and are also "legaly clean".

https://github.com/ezrec/saga-drivers

Excuse me for being a bit vague, but I'm trying to avoid the use of a name similar to "P9x" even in passing so that there is zero chance I get slapped with a trademark or copyright dispute.

Problem is: This doesn't change a thing concerning the requirement to license the P96 API. You're confusing the copyright on the code with the legal constraint to license the API for new drivers. Just reimplementing the DDK doesn't help there.

To solve the problem, you'd need to buy P96  - i.e. become its owner. This would allow you to re-define the license conditions.

This is a legal problem, not a technical problem.

Just ignore Thomas, really. He is not a lawyer, and he is not paying attention to what European courts have concluded on this, even in his own country.

imho if p96 binaries are being used against the intention of their owners, they can be simply taken down from the net, where they have been made available.

If they are used according to the conditions of the owners, there is no problem. Why hurt many fair users by unfair usage of some.

The problem is really that: You seem to want to build a new Amiga, and Amiga operating system. That's a noble goal, but instead of building it on solid grounds, projects like this one are build on sand. They open up holes, weak points where software and IP owners can attack quite easily.

If you want an independent open Amiga platform, you have to be serious about it and avoid *any* usage of proprietary software. That includes Kickstart, Workbench and P96. Which implies that you have to recreate *everything* yourself.

You cannot simply take a proprietary solution and hope to get away by attaching a "supposed to be open" interface wrapper around a copyrighted closed source code with (weird) licensing conditions attached to it. That's not how it works.

There are two options:

* Either, do everything yourself. Recreate kickstart, P96, workbench. This will "take a little time", but in the end, you've a project that is legally unreachable and something where you can define the direction, the licenses and the goals.

* Or refrain from patching, touching or wrapping proprietary software, and instead try to cooperate with the owners and try to negotiate to get what you want. This may include some payment of money, it may also "take a little time", but in the end, you may also have a solid product on solid grounds.

I personally consider "option b" the more promising one, and I'm not quite as pessimistic as you are in how far such goals can be met, but despite my opinion, "option a" is certainly also possible, and if you believe that this is better option, you should start right away.

What is not possible is to continuously interfere with copyrights and licenses of the owners and rights holders of proprietary software - it's creating a weak spot in the whole architecture and something I really consider a very very bad idea.

"Clean room development" or "cooperate". Take your poison.

That's not in Europe, so what is your point?

I too can toss around links...

http://www.bloomberg.com/news/articles/2012-05-02/copyright-can-t-block-software-reverse-engineering-court