Re: New proposed DRM interface design

From: Jon Smirl
Date: Sat Sep 04 2004 - 13:08:50 EST


On Sat, 04 Sep 2004 18:43:16 +0100, Keith Whitwell
<keith@xxxxxxxxxxxxxxxxxxxx> wrote:
> > You may think that X on GL (gnuLonghorn) is a crazy idea. But
> > comptetive pressures from the Mac and Longhhorn will force us into
> > doing it so or later. I'd rather do it sooner.
> >
>
> Not a crazy idea at all, plus I like the name. But a fork could help relieve
> the tension between trying to maintain a stable DRM and the sorts of stuff
> that you need to do to move to the next level. And I recognize that I get
> grumpy when it sounds like existing functionality is threatened by your desire
> to push off in a certain technical direction. If gnuLonghorn/DRM makes a
> friendly/development fork off the existing DRM, things might go a little smoother.

I'm sure we'll get a cease and desist letter from Microsoft if we call
it gnuLonghorn.

Here's a completely different tack on the same problem. As I
understand things it would be better for DRM if DRM merged into the
Linux kernel tree/development process. Given that this is true for
Linux it is probably true for BSD too.

Developers hold the copyrights on their patches. We could mark each
patch going into Linux DRM as being BSD or GPL licensed. For example I
could add a bunch of existing fbdev code in a patch marked GPL. I
could then add the code for integrating it and making it work and mark
it as BSD. This scheme lets the BSD people extract driver changes out
of the Linux code base without licensing problems. The BSD marked
patches don't bother Linux since the BSD license is upwardly
compatible to GPL.

This does add some work to the BSD developers but it would make all of
the new code that doesn't copy preexisting GPL code fair game. I have
no problem marking any new code I write as being BSD licensed, I just
don't want to rewrite 80,000 lines of fbdev code.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/