OSDev.org

Hi, everyone. New member here. This question is directed at all the Uniform Driver Interface (UDI) people out there.

I've known about UDI for a year or two now, reading as much as I can about it, reading posts on here about it, struggling to understand it, etc. I like the vision that it embodies and am willing to jump on the bandwagon. However, I have a few questions--not about UDI itself, but rather about the implications of adopting it--specifically about copyright issues.

So:

1. Does anyone know who currently owns the copyright to UDI? I get the impression that it has changed hands over the years.

2. The fact that it is copyrighted makes me a bit fearful of taking it on, especially since some of the talk about the owners of UDI almost gives the impression that you'll be sued for even thinking about UDI. Obviously, I guess, you can freely implement the standard, but I have to ask.

3. Say UDI turns out to have some deficiencies that need to be changed (as it invariably will, if it doesn't already.) If it is copyrighted, then it cannot be changed by just anyone, nor can derivative works be made from it. Since UDI has been defunct for years now, I don't see how this can possibly work, as apparently no one is around that is allowed to change it. This is the biggest reason why I am reticent to adopt UDI.

4. Is there anyone out there who is trying to make a UDI clone, so to speak, that would get around all the copyright issues? I would imagine such a task would be very difficult to do correctly without being deficient in some fundamental way, especially by a group of hackers.

Thanks.

kabure wrote:Hi, everyone. New member here. This question is directed at all the Uniform Driver Interface (UDI) people out there.

I've known about UDI for a year or two now, reading as much as I can about it, reading posts on here about it, struggling to understand it, etc. I like the vision that it embodies and am willing to jump on the bandwagon. However, I have a few questions--not about UDI itself, but rather about the implications of adopting it--specifically about copyright issues.

So:

1. Does anyone know who currently owns the copyright to UDI? I get the impression that it has changed hands over the years.

No one person owns the copyright - its owned by a variety of companies, some of which have since been bought out (E.G. the Santa Cruz Operation Inc, who were bought by Caldera, who then renamed themselves SCO and started suing people..., Sun, who's obvious successor in interest is Oracle, and Compaq, who's obvious successor in interest is HP, who also collaborated).

2. The fact that it is copyrighted makes me a bit fearful of taking it on, especially since some of the talk about the owners of UDI almost gives the impression that you'll be sued for even thinking about UDI. Obviously, I guess, you can freely implement the standard, but I have to ask.

The copyright of the specification has no bearing on implementations; a royalty free grant to use the spec is given in it. There is a [url=http://sourceforge.net/projects/projectudi/]BSD licensed reference implementation[/quote]

3. Say UDI turns out to have some deficiencies that need to be changed (as it invariably will, if it doesn't already.) If it is copyrighted, then it cannot be changed by just anyone, nor can derivative works be made from it. Since UDI has been defunct for years now, I don't see how this can possibly work, as apparently no one is around that is allowed to change it. This is the biggest reason why I am reticent to adopt UDI.

This is the biggest issue - the spec says "No right to create modifications or derivatives is granted pursuant to this license." and getting permission to do so could be difficult. The obvious solution should negotiation fail would be to recreate the specification from scratch, and then release it under a more liberal license (E.G. CC-BY-SA), which would be non-infringing.

4. Is there anyone out there who is trying to make a UDI clone, so to speak, that would get around all the copyright issues? I would imagine such a task would be very difficult to do correctly without being deficient in some fundamental way, especially by a group of hackers.

Thanks.

The above recreation from scratch would effectively be that. The UDI name could be used (There is no trademark on it), though a new logo would be needed (No real issue - the current one is very 2001!)

I note some people on the forum have been considering a bytecode based "UDI 2.0".

It would indeed be nice if our community (a team or a person) would create a new specification. I've been thinking about what to do with device driver implementations as well. A new "version" of UDI may be a good idea.

Creature wrote:It would indeed be nice if our community (a team or a person) would create a new specification. I've been thinking about what to do with device driver implementations as well. A new "version" of UDI may be a good idea.

Any changes would do well to keep things substantially the same. Its a solid spec, and most of it is good. Expanding it with bytecode support would be nice, but the existing mechanisms are solid and produce high performance drivers (UDI drivers were often found to outperform legacy drivers - even when UDI was implemented as a layer on top of the legacy driver interface!)

In the 'similar, but not the same as UDI' group there are two community efforts.

The Extensible Driver Interface was created by a member here, and allows source code compatibility between drivers.

The Common Driver Interface (CDI) was created on a German OSDev board that I've now forgotten the name of. I'm pretty sure the Pedigree project, amongst others, has a working implementation.

JackScott wrote:In the 'similar, but not the same as UDI' group there are two community efforts.

The Extensible Driver Interface was created by a member here, and allows source code compatibility between drivers.

The Common Driver Interface (CDI) was created on a German OSDev board that I've now forgotten the name of. I'm pretty sure the Pedigree project, amongst others, has a working implementation.

The problem with both is that they're too simple - they, quite simply, don't define enough to be useful in the way that UDI is.

They do not scale as well as UDI, have not had the same thought put into them, and haven't yet had any hardware interfaces defined. Many important device classes already have UDI interfaces.

UDI defines quite a lot. Yes, this makes implementation more complex; however, it is also why UDI drivers often outperform their legacy counterparts: UDI is a very good specification to build upon; and very well defined from a performance point of view. It makes no assumptions about the design of the system - EDI, for example, would be very difficult to implement properly in a microkernel where each driver is its own process, for example.

We all stand to benefit if we pick one interface to get behind - and the best of the interfaces is UDI, so lets pick that.

Personally, to throw in my 2 cents, we should all take UDI as a reference and design our own specification and release it under a non-restrictive license. I think as a group we could do this - and as Owen said, we all do stand to gain a lot if it takes off.

The most important thing is to make it a large collaborative effort. Otherwise someone may come along and think they have a better idea, and so on and so forth. We need to do it only once for it to be effective.

I think that a better way to implement an OS-independent driver interface would be as a part of a "firmware hypervisor" that implements a paravirtualization interface, as opposed to a library. Operating systems would be written exclusively for the hypervisor's paravirtualization interface rather than directly for hardware (the only OS hardware dependency would be on the CPU). Paravirtualization is already quite common, so why not use it for hardware abstraction rather than just for ease of running multiple operating systems simultaneously? A modularized hypervisor in which partitioning/multitasking is separated from hardware abstraction would have relatively little overhead when running a single operating system in non-partitioned mode. Also, there would be no license incompatiblity between drivers and operating systems because operating systems would not be linked with the hypervisor. I am in the process of creating a specification for a firmware hypervisor interface, called the Open XIOS Specification, as well as a hypervisor implementing the specification. I have just started coding on the bootloader for the hypervisor, and haven't set up a site yet, but I plan to set up a Sourceforge project soon. If anybody wants to help me, they are more than welcome to.

andrew_w wrote:Operating systems would be written exclusively for the hypervisor's paravirtualization interface...

...tossing out any chance of getting Windows or Linux on board, effectively killing the concept of a pervasive driver framework right away.

UDI is there; UDI has already had man-years of thought by pretty competent people behind it; UDI drivers can be used on Windows, Linux and BSD's; UDI is an option instead of mandatory.

And, if you look at it, UDI isn't that much different than your paravirtualization idea after all.

Not to shoot down your idea, but UDI has a pretty strong case in favor of it. The downsides is that its makers dropped the ball when the dot-com bubble burst (as the big bucks were no longer flowing quite as freely), and that the GNU/FSF gurus sniped at the concept because someone other than Linux might actually benefit from it.

Project UDI may be there as it is. However, we need to create a new specification. It doesn't have to be different. It could be a paraphrase of the official UDI specification. But it needs to be perceived as new to get widespread adoption.

The big players have already shot down UDI. We need to make something new and get a lot of drivers developed for it -- then present it to the community at large. With the right words we can have it become what it needs to become: a ubiquitous driver interface.

Why not just make a lot of UDI drivers, like what yours truly is trying to do for graphics hardware. Do you want ready-to-use, 3D-capable drivers? Get UDI </shameless plug>

The big players always end up spending resources on a native driverbase. An UDI fork does not change that. Microsoft just pays big money, GNU will forever keep rioting when someone mentions "public domain" in their presence.

Agreeing with Combuster. UDI is a very, very decent work. It doesn't need a rephrased spec, it just needs all the drivers it can get.

Any Open project needs critical mass. Once Wikipedia got enough articles, once OpenStreetMap got enough data, people jumped on the bandwaggon. So far, UDI fell short of this critical mass.

What UDI needs is people pushing, not forking / rephrasing.

I hosted an UDI site at my domain before, when a user here expressed his wish to give UDI a decent shove. Unfortunately there was no activity, so I scrapped the subdomain again.

But if someone here is willing to get behind this, I'll offer my webspace, bandwidth, a repository, website, whatever. Free. (It's about all I can do to support UDI on my end, and I really like the concept.)

So, if you're in a mind, give me the call and I've got this set up in <24 hours.

Solar wrote:Agreeing with Combuster. UDI is a very, very decent work. It doesn't need a rephrased spec, it just needs all the drivers it can get.

Any Open project needs critical mass. Once Wikipedia got enough articles, once OpenStreetMap got enough data, people jumped on the bandwaggon. So far, UDI fell short of this critical mass.

What UDI needs is people pushing, not forking / rephrasing.

Agreed, but the fact still remains: the UDI specification is copyrighted and unchangeable, at least by us, and whether the owners will ever get back to mediating it is debatable. Not to mention the fact that it is not an "open standard", which would regardless look not so good to the FOSS community. But if you have any ideas on how to subvert the copyright issue somehow so that we can do whatever we need, then I'm all ears, as I would love to see this take off.

I hosted an UDI site at my domain before, when a user here expressed his wish to give UDI a decent shove. Unfortunately there was no activity, so I scrapped the subdomain again.

But if someone here is willing to get behind this, I'll offer my webspace, bandwidth, a repository, website, whatever. Free. (It's about all I can do to support UDI on my end, and I really like the concept.)

So, if you're in a mind, give me the call and I've got this set up in <24 hours.

Thanks, that would be really cool. Speaking for myself, I'm not really up for an all-out attack at the moment, however a mailing list where we could at least discuss UDI in a focused manner might be a good idea.

I hosted an UDI site at my domain before, when a user here expressed his wish to give UDI a decent shove. Unfortunately there was no activity, so I scrapped the subdomain again.

I have the idea it's the same person that promised me to do a PIO transaction executer months ago...

kabure wrote:

Solar wrote:Agreeing with Combuster. UDI is a very, very decent work. It doesn't need a rephrased spec, it just needs all the drivers it can get.

Any Open project needs critical mass. Once Wikipedia got enough articles, once OpenStreetMap got enough data, people jumped on the bandwaggon. So far, UDI fell short of this critical mass.

What UDI needs is people pushing, not forking / rephrasing.

Agreed, but the fact still remains: the UDI specification is copyrighted and unchangeable, at least by us, and whether the owners will ever get back to mediating it is debatable. Not to mention the fact that it is not an "open standard", which would regardless look not so good to the FOSS community. But if you have any ideas on how to subvert the copyright issue somehow so that we can do whatever we need, then I'm all ears, as I would love to see this take off.

There is a simple way around the copyright issue, as I said: If we need to modify the specification in any way going forward, then we just rewrite it but maintain the interface that exists. Yes, it will be tricky and time consuming, but it is doable.

I hosted an UDI site at my domain before, when a user here expressed his wish to give UDI a decent shove. Unfortunately there was no activity, so I scrapped the subdomain again.

But if someone here is willing to get behind this, I'll offer my webspace, bandwidth, a repository, website, whatever. Free. (It's about all I can do to support UDI on my end, and I really like the concept.)

So, if you're in a mind, give me the call and I've got this set up in <24 hours.

Thanks, that would be really cool. Speaking for myself, I'm not really up for an all-out attack at the moment, however a mailing list where we could at least discuss UDI in a focused manner might be a good idea.

Since we have at least a couple of the long term members here using UDI, and some other people considering it, I'm also open to offering hosting of UDI related websites, projects and mailing lists. Anyone got any suggestions for a domain name we should use?