Thanks for clarifying my understanding of the GPL. Other folks have
also addressed this issue including Alan Cox who clarified the
differences between GPL and LGPL for me.
I think that what the situation comes down to is this:
1) If you want to write native Linux drivers, do so.
2) If you want to write Linux UDI drivers and restrict them to GPL
OS's like Linux, release them under the GPL license.
3) If you want to write UDI drivers, distribute them as source and
allow them to be distributed in multiple commercial OS's as well as
OS's like Linux, you'd probably use LGPL licensing or something
similar.
4) If you want to write UDI drivers but not release source or you want
more restrictions on the use, use corresponding licensing terms.
5) As pointed out in other posts, use a combination of the above licensing.
No technological restriction exists in Linux, Commercial OS's, or UDI
to prevent any of the above... it's strictly a matter of deciding what
your target audience and personal preferences are and finding the best
license vehicle(s) to achieve that.
Note that for option 2 it's definitely possible that another person(s)
that wanted to achieve wider distribution could also write a UDI
driver for the same device and use less restrictive licensing.
The truly philosophical issue here is one of publicly available source
and how to realistically participate in both a public and a commercial
environment. I'd rather not embroil UDI in this issue which is not
central to the development of the technology. Linux development has
coalesced around GPL as a way to help the "common man". UDI
development is a group of commercial companies who've overcome
competitive concerns to work on a public specification as another way
to help the "common man". It would be better to focus on the
benevolent benefits of any form of cooperation between the two groups;
if on the other hand there are folks (in any community) who do not
wish to participate in UDI for philosophical reasons then I don't
think there's anyone trying to make them do otherwise.
Project UDI is a public and open group working on a public and open
specification. We welcome anyone who'd like to participate from
either a specification or a development perspective.
-Kevin
Erik Corry writes:
>
> In article <13834.39383.828566.222591@pc-eng-013> you wrote:
> > Not necessarily. My point in making the statement was that any OS
> > supporting UDI could make use of UDI drivers developed by Linux
> > developers.
>
> I don't think so. There are serious license impediments.
> See below.
>
> Also, I doubt that UDI will be as nice a driver interface
> as Linux-native. That makes in unlikely that UDI drivers
> will be developed in large numbers by people primarily
> targeting Linux.
>
> > The converse is also equally valid... that the Linux
> > community will benefit by "commercially" developed UDI drivers.
>
> That may happen. Linus has stated that his interpretation of
> the GPL is that non-GPL driver modules (not compiled-in drivers)
> are allowed. GPLled UDI drivers would be even less trouble.
>
> > ...
>
> Unfortunately, you don't seem to understand the GPL. That
> is quite critical in this situation.
>
> > I'm not enough of a lawyer to fully respond. My impression is that if
> > someone releases a UDI driver under GPL that any OS vendor can
> > redistribute that driver as part of their OS
>
> Yes, but they won't want to. See below for why.
>
> > although they are (a) not allowed to charge for that driver
>
> A popular misconception. You can charge what you want for
> GPL software. But you can't prevent people from undercutting
> you by reselling it.
>
> > (b) must make the source for that driver available to their
> > customers upon demand,
>
> Unfortunately for the commercial OS developers, the
> combination of the driver and the OS is regarded as a
> derived work. That means that if they distribute the
> GPL driver with the OS, the OS is also under the GPL,
> i.e. they have to release source code and allow people to
> use the OS royalty-free. I don't think most OS vendors
> would be willing to do that.
>
> There is some controversy about how to interpret the
> derived work clause of the GPL, but you will find my
> interpretation is shared by almost all the Linux community.
> Anyone disagreeing should expect a test case and some
> very bad publicity at the least. Be Inc. recently ran
> into this and backed down rather than fight it out.
>
> There is a solution: The authors of a GPL driver could
> agree to rerelease it under different license, for example
> the X11R3 license. But all authors must agree, and many
> Linux drivers have several authors. I can't see this
> happening on a large scale unless someone is actually
> paying the driver writers.
>
> Note that from the point of view of most Linux contributors
> this is not an unfortunate consequence of the GPL, it's
> part of the reason we write Linux stuff in the first place.
> We like it that way. People who disagree can release
> under two licenses, as Larry Wall (perl) does.
>
> Perhaps you should be talking more with the Free/Open/NetBSD
> people. Their license is much more flexible in this regard.
>
> By the way, I really don't want to start a license flame war
> here. I am not saying that any license is better or worse
> than any other. People are free to choose the license they
> like for the software they release. It's just that X-like
> licenses are more suitable for Mr. Quick's purposes (tight
> integration into non-open-source OSs).
>
> --
> Erik Corry erik@arbat.com Ceterum censeo, Microsoftem esse delendam!
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
-- ________________________________________________________________________ Kevin Quick Interphase Corporation Engineering Dallas, Texas kquick@iphase.com http://www.iphase.com 214.654.5173- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/