Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.

Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.

[Sven Luther]

On Fri, Jan 30, 2004 at 05:19:03PM +0100, Egbert Eich wrote:
> Benjamin Herrenschmidt writes:
> 
>  > Losing the ability of porting code straight from these to the fbdev
>  > drivers will basically kill all my efforts to turn the kernel radeonfb
>  > into a decent driver as I need to be able to re-use the code ATI puts
>  > in the XFree version. I suppose the same will happen to linux rivafb.
> 
> Relating to that: exchanging code between XFree86 and kernel has been a
> one-way road so far. The GPL the kernel is under doesn't allow us to
> port back improvements that have been made to the kernel to our drivers
> Even though this isn't covered by the GPL the author of the driver 
> or the changes could still give the permission to do so.
> 
> I whish there was a better exchange between kernel fbdev developers
> and driver developers here.

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.

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

Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.

[Egbert Eich]

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

Re: Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.

[Sven Luther]

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

Re: Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.

[Andrew C Aitchison]

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

Re: Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.

[Sven Luther]

On Sat, Jan 31, 2004 at 09:10:22AM +0000, Andrew C Aitchison wrote:
> 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.

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

Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.

[Thomas Winischhofer]

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

Re: Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.

[Mark Vojkovich]

On Fri, 30 Jan 2004, Sven Luther wrote:

> 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.
> 

   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

Re: Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.

[Ryan Underwood]

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]


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, <nemesis@icequake.net>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]