Sven Luther writes:
>
> Maybe a decision on both parts on this would be ok ? XFree86 could make
> sure the licence of the driver code would not conflict with the GPL,
> keeping the old one for example, and the fbdev driver authors would
> dual-licence the code, both GPL and the old xfree86 licence would do
> just fine. Benjamin, what do you think about this ?
>
> BTW, CCing this to the linux-fbdev mailing list.
>
Yes, a personal agreement between driver developers would also work.
However they tend to change and other people will make contributions
who all would have to agree also.
I don't know if a general dual license agreement in the kernel
file header would be possible. Also it could get removed once
the author changes. Just like the license in the XFree86 driver
could be amended.
Doing this now for existing fbdev driver would involve to ask
anyone who has contributed little more than a typo fix.
Egbert.
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
From: Sven Luther <hidden> Date: 2004-01-30 22:29:13
On Fri, Jan 30, 2004 at 08:25:40PM +0100, Egbert Eich wrote:
Sven Luther writes:
>
> Maybe a decision on both parts on this would be ok ? XFree86 could make
> sure the licence of the driver code would not conflict with the GPL,
> keeping the old one for example, and the fbdev driver authors would
> dual-licence the code, both GPL and the old xfree86 licence would do
> just fine. Benjamin, what do you think about this ?
>
> BTW, CCing this to the linux-fbdev mailing list.
>
Yes, a personal agreement between driver developers would also work.
However they tend to change and other people will make contributions
who all would have to agree also.
I don't know if a general dual license agreement in the kernel
file header would be possible. Also it could get removed once
the author changes. Just like the license in the XFree86 driver
could be amended.
I guess already some drivers have such a dual licencing.
Doing this now for existing fbdev driver would involve to ask
anyone who has contributed little more than a typo fix.
Yeah, that would be rather problematic, but anyway, most of the things
move from the XFree86 code to fbdev code, and most often, it is not code
that is copied, but the register information and such. It is always
easier to get specs if you are working for XFree86 than if you plan to
do some kernel driver work.
Friendly,
Sven Luther
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
From: Andrew C Aitchison <hidden> Date: 2004-01-31 09:10:30
On Fri, 30 Jan 2004, Sven Luther wrote:
Yeah, that would be rather problematic, but anyway, most of the things
move from the XFree86 code to fbdev code, and most often, it is not code
that is copied, but the register information and such. It is always
easier to get specs if you are working for XFree86 than if you plan to
do some kernel driver work.
On Sat, 31 Jan 2004, Benjamin Herrenschmidt wrote:
The fact that it is mostly a one way is mostly due to the fact that the
main problem here is seeking for HW informations.
For several years the mga fb kernel driver has supported dual head and/or
dvi on cards which aren't supported by the XFree86 driver (unless you
use the mga_hal). I've wanted to use kernel code to add this support to
XFree86, but been put off by the licence problem.
As I remember it, the pertinent register information here was reverse
engineered, so it is at least arguable that I'd be copying fbdev
intellectual property here if I'd extracted and reused it.
Perhaps I was wrong, but my understanding from my days in a software
house taught me that I'd be breaking copyright not just by lifting
lines of code, but also by reading the code and copying intellectual
property, including register information.
Besides there are only a few ways of writing code to twiddle a bit in
a register - I could easily duplicate a line of code while
reconstructing it from the register description, and it would be hard
to prove that I didn't just copy the line directly.
So, for one developer at least, the reason there has been no traffic
from fbdev to XFree86 is *directly* because of the licence issue.
--
Andrew C. Aitchison Cambridge
A.C.Aitchison@ntlworld.com
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
From: Sven Luther <hidden> Date: 2004-01-31 12:43:44
On Sat, Jan 31, 2004 at 09:10:22AM +0000, Andrew C Aitchison wrote:
On Fri, 30 Jan 2004, Sven Luther wrote:
quoted
Yeah, that would be rather problematic, but anyway, most of the things
move from the XFree86 code to fbdev code, and most often, it is not code
that is copied, but the register information and such. It is always
easier to get specs if you are working for XFree86 than if you plan to
do some kernel driver work.
On Sat, 31 Jan 2004, Benjamin Herrenschmidt wrote:
quoted
The fact that it is mostly a one way is mostly due to the fact that the
main problem here is seeking for HW informations.
For several years the mga fb kernel driver has supported dual head and/or
dvi on cards which aren't supported by the XFree86 driver (unless you
use the mga_hal). I've wanted to use kernel code to add this support to
XFree86, but been put off by the licence problem.
And, have you asked the mgafb driver author about this ?
You can hardly complain about lack of back traffic if you didn't ask him
about it, and if you did, it would be interesting to this discussion to
know what the problems where.
As I remember it, the pertinent register information here was reverse
engineered, so it is at least arguable that I'd be copying fbdev
intellectual property here if I'd extracted and reused it.
Perhaps I was wrong, but my understanding from my days in a software
house taught me that I'd be breaking copyright not just by lifting
lines of code, but also by reading the code and copying intellectual
property, including register information.
Yeah, sure. Which is way you ask for getting a licenced copy you can
use or something. I guess that this will be much more likely to happen
from a kernel fbdev driver author than from a commercial entity, will it
not ?
Besides there are only a few ways of writing code to twiddle a bit in
a register - I could easily duplicate a line of code while
reconstructing it from the register description, and it would be hard
to prove that I didn't just copy the line directly.
I doubt that this kind of stuff is possible to fall under copyright, or
else the copyright law is more broken than i thought. I know that a
bunch of C header files, with only datastructures and functions
declarations cannot be copyrighted.
So, for one developer at least, the reason there has been no traffic
from fbdev to XFree86 is *directly* because of the licence issue.
Yeah, but again, was it so because of a definite will on the fbdev
authors part, or because you didn't ask him ?
Friendly,
Sven Luther
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
From: Thomas Winischhofer <hidden> Date: 2004-01-31 14:15:49
Egbert Eich wrote:
Sven Luther writes:
> > Maybe a decision on both parts on this would be ok ? XFree86 could make
> sure the licence of the driver code would not conflict with the GPL,
> keeping the old one for example, and the fbdev driver authors would
> dual-licence the code, both GPL and the old xfree86 licence would do
> just fine. Benjamin, what do you think about this ?
> > BTW, CCing this to the linux-fbdev mailing list.
>
Yes, a personal agreement between driver developers would also work.
However they tend to change and other people will make contributions
who all would have to agree also. I don't know if a general dual license agreement in the kernel file header would be possible.
Yes, it is. See the current SiS driver source files.
Thomas
--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net http://www.winischhofer.net/
twini AT xfree86 DOT org
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
From: Mark Vojkovich <hidden> Date: 2004-01-31 21:48:20
On Fri, 30 Jan 2004, Sven Luther wrote:
On Fri, Jan 30, 2004 at 08:25:40PM +0100, Egbert Eich wrote:
quoted
Sven Luther writes:
>
> Maybe a decision on both parts on this would be ok ? XFree86 could make
> sure the licence of the driver code would not conflict with the GPL,
> keeping the old one for example, and the fbdev driver authors would
> dual-licence the code, both GPL and the old xfree86 licence would do
> just fine. Benjamin, what do you think about this ?
>
> BTW, CCing this to the linux-fbdev mailing list.
>
Yes, a personal agreement between driver developers would also work.
However they tend to change and other people will make contributions
who all would have to agree also.
I don't know if a general dual license agreement in the kernel
file header would be possible. Also it could get removed once
the author changes. Just like the license in the XFree86 driver
could be amended.
I guess already some drivers have such a dual licencing.
quoted
Doing this now for existing fbdev driver would involve to ask
anyone who has contributed little more than a typo fix.
Yeah, that would be rather problematic, but anyway, most of the things
move from the XFree86 code to fbdev code, and most often, it is not code
that is copied, but the register information and such. It is always
easier to get specs if you are working for XFree86 than if you plan to
do some kernel driver work.
You can take an XFree86 driver, regardless of what the copyright
says, and completely rewrite it as an fbdev driver (which is what
I believe usually happens) and this is not a violation of the
XFree86 copyright or even of the GPL. Copyright doesn't apply to
ideas or algorithms in a work. It's not a patent. It only applies
to the reproduction of the code.
Mark.
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
From: Ryan Underwood <hidden> Date: 2004-01-31 22:07:21
On Sat, Jan 31, 2004 at 09:10:22AM +0000, Andrew C Aitchison wrote:
For several years the mga fb kernel driver has supported dual head and/or
dvi on cards which aren't supported by the XFree86 driver (unless you
use the mga_hal). I've wanted to use kernel code to add this support to
XFree86, but been put off by the licence problem.
As I remember it, the pertinent register information here was reverse
engineered, so it is at least arguable that I'd be copying fbdev
intellectual property here if I'd extracted and reused it.
Perhaps I was wrong, but my understanding from my days in a software
house taught me that I'd be breaking copyright not just by lifting
lines of code, but also by reading the code and copying intellectual
property, including register information.
Petr Vandrovec, the author of the vast majority of matroxfb code, has
repeatedly granted requests to re-use the code under X11 license. Did
you even ask him?
--
Ryan Underwood, [off-list ref]