Bug#383465: Contains obfuscated source code, DFSG violation?

2007-07-16 Thread Robert Millan [ackstorm]
On Wed, Nov 29, 2006 at 07:50:51PM -0500, David Nusinow wrote:
 
 The nouveau project is deobfuscating the code as they go. Even if their DRI
 work isn't ready for Lenny, we'll definitely be pulling their deobfuscated
 code.

Put aside what we do for Lenny, is there any technical problem in terms of
user support if we move this driver to non-free and let vesa and/or vga be
the default for nvidia users?

Given that the driver is 2D-only anyway, I don't see it as a big loss.  With
the vesa option, at least the non-free bits are moved down to firmware, where
it's no longer our responsability (read: if the driver is faulty and we can't
fix it, it would be faulty on all platforms, and I find that highly unlikely
since the card wouldn't work on pristine win32 either).

-- 
Robert Millan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#383465: Contains obfuscated source code, DFSG violation?

2007-07-16 Thread Andreas Barth
* Robert Millan [ackstorm] ([EMAIL PROTECTED]) [070716 12:21]:
 On Wed, Nov 29, 2006 at 07:50:51PM -0500, David Nusinow wrote:
  
  The nouveau project is deobfuscating the code as they go. Even if their DRI
  work isn't ready for Lenny, we'll definitely be pulling their deobfuscated
  code.
 
 Put aside what we do for Lenny, is there any technical problem in terms of
 user support if we move this driver to non-free and let vesa and/or vga be
 the default for nvidia users?

AFAIR, we still prefer this driver way over the hard non-free
binary-only driver from NVidia. In other words, given that the project
nouveau is making progress, changes are merged back, and this driver is
better then the binary-only driver, I think keeping the driver in main
is the right decision.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#383465: Contains obfuscated source code, DFSG violation?

2007-07-16 Thread David Nusinow
On Mon, Jul 16, 2007 at 12:14:14PM +0200, Robert Millan [ackstorm] wrote:
 On Wed, Nov 29, 2006 at 07:50:51PM -0500, David Nusinow wrote:
  
  The nouveau project is deobfuscating the code as they go. Even if their DRI
  work isn't ready for Lenny, we'll definitely be pulling their deobfuscated
  code.
 
 Put aside what we do for Lenny, is there any technical problem in terms of
 user support if we move this driver to non-free and let vesa and/or vga be
 the default for nvidia users?
 
 Given that the driver is 2D-only anyway, I don't see it as a big loss.  With
 the vesa option, at least the non-free bits are moved down to firmware, where
 it's no longer our responsability (read: if the driver is faulty and we can't
 fix it, it would be faulty on all platforms, and I find that highly unlikely
 since the card wouldn't work on pristine win32 either).

The nv driver does provide additional features over the vesa driver, most
notably the recent inclusion of randr 1.2 support. Because of this, I'd
rather not push people even further towards the proprietary driver.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#383465: Contains obfuscated source code, DFSG violation?

2006-11-29 Thread David Nusinow
On Tue, Nov 28, 2006 at 08:49:56PM +, Sam Morris wrote:
 I found some interesting links about this topic:
 
 http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/vga256/drivers/nv/Attic/README.RIVATNT.diff?r1=1.1.2.2r2=1.1.2.3hideattic=0only_with_tag=xf-3_3_3
 and
 http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/vga256/drivers/nv/Attic/nv3driver.c.diff?r1=1.1.2.5r2=1.1.2.6hideattic=0only_with_tag=xf-3_3_3
 
 If nvidia already 'forced' XFree86 to obfuscate their source code, it
 doesn't seem unlikely that they require obfuscation of the source for
 the 'nv' driver too.

They can't actually force obfuscation beause the code is under MIT/X11
(well... most of it. We need to clarify the situation of nv_hw.c badly).
The nouveau project is deobfuscating the code as they go. Even if their DRI
work isn't ready for Lenny, we'll definitely be pulling their deobfuscated
code.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#383465: Contains obfuscated source code, DFSG violation?

2006-11-28 Thread Sam Morris
I found some interesting links about this topic:

http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/vga256/drivers/nv/Attic/README.RIVATNT.diff?r1=1.1.2.2r2=1.1.2.3hideattic=0only_with_tag=xf-3_3_3
and
http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/vga256/drivers/nv/Attic/nv3driver.c.diff?r1=1.1.2.5r2=1.1.2.6hideattic=0only_with_tag=xf-3_3_3

If nvidia already 'forced' XFree86 to obfuscate their source code, it
doesn't seem unlikely that they require obfuscation of the source for
the 'nv' driver too.

-- 
Sam Morris
http://robots.org.uk/

PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078


signature.asc
Description: This is a digitally signed message part


Re: Bug#383465: Contains obfuscated source code, DFSG violation?

2006-08-30 Thread Xavier Bestel
On Tue, 2006-08-29 at 20:43, David Nusinow wrote:
 But what I'd like to do is set it to wishlist and title it Please
 de-obfuscate the nv driver.

I'm sure you know that, but isn't that what the nouveau project
http://nouveau.freedesktop.org is all about ? Maybe the nv driver
should be marked as problematic and the issue punted until the nouveau
driver is ready.

Xav


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Bug#383465: Contains obfuscated source code, DFSG violation?

2006-08-30 Thread David Nusinow
On Wed, Aug 30, 2006 at 10:48:16AM +0200, Xavier Bestel wrote:
 On Tue, 2006-08-29 at 20:43, David Nusinow wrote:
  But what I'd like to do is set it to wishlist and title it Please
  de-obfuscate the nv driver.
 
 I'm sure you know that, but isn't that what the nouveau project
 http://nouveau.freedesktop.org is all about ? Maybe the nv driver
 should be marked as problematic and the issue punted until the nouveau
 driver is ready.

I have yet to look at the sources. Has he started cleaning up the magic
numbers or is he just reverse-engineering the 3d stuff? Anyway, once the
project is well off the ground I'm excited to start shipping it.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#383465: Contains obfuscated source code, DFSG violation?

2006-08-29 Thread Xavier Bestel
On Tue, 2006-08-29 at 01:39, Matthew Garrett wrote:
 Sorry? 12 of the files in the source tree contain explicit Nvidia 
 copyright statements. The others tend to have no copyrights at all, but 
 are generally written by Mark Vojkovich who is an nvidia employee. 

True. But as the driver is distributed under the MIT licence, I don't
think it has to be under the preferred form for modification. Unless
Debian requires it ?

Xav



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#383465: Contains obfuscated source code, DFSG violation?

2006-08-29 Thread Daniel Stone
On Tue, Aug 29, 2006 at 01:21:26AM +0200, Steinar H. Gunderson wrote:
 On Thu, Aug 17, 2006 at 02:12:17PM +0100, Matthew Garrett wrote:
  The nv driver appears to be heavily obfuscated and is effectively 
  The idea that nvidia do not posess an electronic list of register names 
  and offsets is entirely implausible. The only rational explanation is 
  that register information is postprocessed out in order to reduce 
  information leakage. 
 
 Or that nVidia never wrote the driver in the first place. I cannot find any
 nVidia copyrights on it -- it seems to have been reverse-engineered and then
 written up by the current copyright holders.

The output of the below has been tidied up a bit to remove duplicates:
[EMAIL PROTECTED]:~/x/xorg/driver/xf86-video-nv/src% for i in *.[ch]; do echo 
-n $i:\  ; grep Copyright $i || echo no copyright; done 
nv_const.h: no copyright
nv_cursor.c: |*   Copyright 2003 NVIDIA, Corporation.  All rights reserved. 
  *|
nv_dac.c: |*   Copyright 2003 NVIDIA, Corporation.  All rights reserved.
   *|
nv_dga.c: no copyright
nv_dma.h: |*   Copyright 2003 NVIDIA, Corporation.  All rights reserved.
   *|
nv_driver.c:  * Copyright 1996-1997  David J. McKay
nv_hw.c: |*   Copyright 1993-2003 NVIDIA, Corporation.  All rights 
reserved.  *|
nv_include.h: no copyright
nv_local.h: |*   Copyright 1993-2003 NVIDIA, Corporation.  All rights 
reserved.  *|
nv_proto.h: no copyright
nv_setup.c: |*   Copyright 2003 NVIDIA, Corporation.  All rights reserved.  
 *|
nv_shadow.c:Copyright (c) 1999,  The XFree86 Project Inc. 
nv_type.h: no copyright
nv_video.c: no copyright
nv_xaa.c: |*   Copyright 2003 NVIDIA, Corporation.  All rights reserved.
   *|
nvreg.h:  * Copyright 1996-1997  David J. McKay
nvvga.h:  * Copyright 1996-1997  David J. McKay
riva_const.h: no copyright
riva_cursor.c:  * Copyright 1996-1997  David J. McKay
riva_dac.c:  * Copyright 1996-1997  David J. McKay
riva_dga.c: no copyright
riva_driver.c:  * Copyright 1996-1997  David J. McKay
riva_hw.c: |*   Copyright 1993-1999 NVIDIA, Corporation.  All rights 
reserved.  *|
riva_hw.h: |*   Copyright 1993-1999 NVIDIA, Corporation.  All rights 
reserved.  *|
riva_include.h: no copyright
riva_local.h: |*   Copyright 1993-1999 NVIDIA, Corporation.  All rights 
reserved.  *|
riva_proto.h: no copyright
riva_setup.c:  * Copyright 1996-1997  David J. McKay
riva_shadow.c:Copyright (c) 1999,  The XFree86 Project Inc. 
riva_tbl.h: |*   Copyright 1993-1999 NVIDIA, Corporation.  All rights 
reserved.  *|
riva_type.h: no copyright
riva_xaa.c: |*   Copyright 1993-1999 NVIDIA, Corporation.  All rights 
reserved.  *|

So, of those, a few Riva files for the ancient Riva 128 chipset are
copyright David J. McKay as well as nvreg.h and nvvga.h,
riva_shadow.c and nv_shadow.c are copyright XFree86, and
riva_include.h, riva_proto.h, riva_type.h, riva_dga.c, riva_const.h,
nv_video.c, nv_type.h, nv_proto.h, nv_include.h, nv_dga.c,
and nv_const.h have no copyright.  The rest are NVIDIA.

riva_shadow.c and nv_shadow.c implement a 'shadow framebuffer' option,
which isn't about hardware access.  The files were almost certainly just
taken from some other driver, with a quick sed run.

Assuming the dates for David McKay's copyright run correct, they are
almost nine years old now.  nvreg.h does not actually contain register
definitions, but is a fairly trivial set of macros and declaration of a
few pointers to register locations (extern unsigned char *nvDAC, et al).
nvvga.h contains a register definition for the NV1, which was released
in 1995.  All the fun parts of the Riva driver -- and this is for an
ancient chip -- are in NVIDIA-copyrighted files, like riva_hw.c:
VGA_WR08(chip-PCIO, 0x3D4, 0x19); tmp = VGA_RD08(chip-PCIO, 0x3D5);
VGA_WR08(chip-PCIO, 0x3D5, (offset  0x01F) | (tmp  ~0x1F));
VGA_WR08(chip-PCIO, 0x3D4, 0x2D); tmp = VGA_RD08(chip-PCIO, 0x3D5);
VGA_WR08(chip-PCIO, 0x3D5, (offset  0x60) | (tmp  ~0x60));
and riva_tbl.h:
static unsigned nv3TablePRAMIN[][2] =
{
{0x0500, 0x0001},
{0x0501, 0x007F},
{0x0200, 0x8000},
{0x0201, 0x00C20341},
{0x0204, 0x8001},
[...]

But 'nv' is the interesting one, since that supports current
hardware, and nv_hw.c is the one with genius section such as:
cr11 = VGA_RD08(pNv-PCIO, 0x3D5);
if(Lock) cr11 |= 0x80;
else cr11 = ~0x80;
VGA_WR08(pNv-PCIO, 0x3D5, cr11);

Sadly this isn't even remotely out of the ordinary for the nv driver:
it's one of the most benign sections I could find in the first function
of nv_hw.c.

For recent history, looking at:
http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-nv.git;a=shortlog
you can see that all code commits have been made either by Aaron
Plattner (an NVIDIA employee, as you can see from his email address,
also you can google him on site:lists.freedesktop.org to see him
offering 

Bug#383465: Contains obfuscated source code, DFSG violation?

2006-08-29 Thread Daniel Stone
On Tue, Aug 29, 2006 at 09:53:34AM +0200, Xavier Bestel wrote:
 True. But as the driver is distributed under the MIT licence, I don't
 think it has to be under the preferred form for modification. Unless
 Debian requires it ?

Um, the subject is about a DFSG violation, not a licence violation.
According to -legal, everything must be provided with its pure, original
source -- the head of the coder that hand-wrote some firmware, the
instruments used to record any particular Ogg Vorbis track, et al.
Random hex constants are apparently not source in firmware (and thus
distribution of such is a violation of the DFSG), but I fail to see
how random hex constants are source here either.

Cheers,
Daniel


signature.asc
Description: Digital signature


Bug#383465: Contains obfuscated source code, DFSG violation?

2006-08-29 Thread Marco d'Itri
On Aug 29, Daniel Stone [EMAIL PROTECTED] wrote:

 According to -legal, everything must be provided with its pure, original
 source -- the head of the coder that hand-wrote some firmware, the
 instruments used to record any particular Ogg Vorbis track, et al.
Let's be accurate here: according to some -legal kooks, everything
If you disagree with this line of tought then you should spend some of
your time on debian-legal arguing against it.

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Bug#383465: Contains obfuscated source code, DFSG violation?

2006-08-29 Thread Steinar H. Gunderson
On Tue, Aug 29, 2006 at 10:41:17AM +0300, Daniel Stone wrote:
 Or that nVidia never wrote the driver in the first place. I cannot find any
 nVidia copyrights on it -- it seems to have been reverse-engineered and then
 written up by the current copyright holders.
 The output of the below has been tidied up a bit to remove duplicates:

OK, my analysis was clearly incorrect. With the information you presented, I
agree with Matthew. :-)

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Bug#383465: Contains obfuscated source code, DFSG violation?

2006-08-29 Thread David Nusinow
On Thu, Aug 17, 2006 at 02:12:17PM +0100, Matthew Garrett wrote:
 Package: xserver-xorg-video-nv
 Version: 1:1.0.1.5-2
 Severity: serious
 
snip
 The idea that nvidia do not posess an electronic list of register names 
 and offsets is entirely implausible. The only rational explanation is 
 that register information is postprocessed out in order to reduce 
 information leakage. The shipped code is certainly not the preferred 
 form for modification, and according to prevailing attitudes on 
 debian-legal should be removed from Debian.

I'm not going to alter the severity because I agree with it to some degree.
But what I'd like to do is set it to wishlist and title it Please
de-obfuscate the nv driver. It is feasible to do so if you have the will
and the hardware (I lack the latter, and my commitments make me lack the
former). Ideally it'd be a script we could run over the code every time
rather than patch that we'd have to port upon each upstream release. 

If some enterprising Free Software advocate wants to work on this, they
have my full support and cooperation where I can offer it.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#383465: Contains obfuscated source code, DFSG violation?

2006-08-28 Thread Steinar H. Gunderson
On Thu, Aug 17, 2006 at 02:12:17PM +0100, Matthew Garrett wrote:
 The nv driver appears to be heavily obfuscated and is effectively 
 The idea that nvidia do not posess an electronic list of register names 
 and offsets is entirely implausible. The only rational explanation is 
 that register information is postprocessed out in order to reduce 
 information leakage. 

Or that nVidia never wrote the driver in the first place. I cannot find any
nVidia copyrights on it -- it seems to have been reverse-engineered and then
written up by the current copyright holders.

 The shipped code is certainly not the preferred form for modification

TBH, I don't think there is any other form in existence, unless you want to
count the proprietary drivers this probably was reverse engineered from at
some distant past.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#383465: Contains obfuscated source code, DFSG violation?

2006-08-28 Thread Matthew Garrett
Sorry? 12 of the files in the source tree contain explicit Nvidia 
copyright statements. The others tend to have no copyrights at all, but 
are generally written by Mark Vojkovich who is an nvidia employee. 

-- 
Matthew Garrett | [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#383465: Contains obfuscated source code, DFSG violation?

2006-08-17 Thread Matthew Garrett
Package: xserver-xorg-video-nv
Version: 1:1.0.1.5-2
Severity: serious

The nv driver appears to be heavily obfuscated and is effectively 
unmodifiable. Rather than symbolic constants, almost every reference to 
hardware is performed using undocumented hex. The only registers that 
appear to be documented are the legacy CRTC ones which are effectively 
identical over all hardware. Take for example NVBacklightEnable:

if((pNv-Chipset == 0x10DE0179) || 
   (pNv-Chipset == 0x10DE0189) || 
   (pNv-Chipset == 0x10DE0329))
{
   /* NV17,18,34 Apple iMac, iBook, PowerBook */
  CARD32 tmp_pmc, tmp_pcrt;
  tmp_pmc = pNv-PMC[0x10F0/4]  0x7FFF;
  tmp_pcrt = pNv-PCRTC0[0x081C/4]  0xFFFC;
  if(on) {
  tmp_pmc |= (1  31);
  tmp_pcrt |= 0x1;
  }
  pNv-PMC[0x10F0/4] = tmp_pmc;
  pNv-PCRTC0[0x081C/4] = tmp_pcrt;
 }

The idea that nvidia do not posess an electronic list of register names 
and offsets is entirely implausible. The only rational explanation is 
that register information is postprocessed out in order to reduce 
information leakage. The shipped code is certainly not the preferred 
form for modification, and according to prevailing attitudes on 
debian-legal should be removed from Debian.

-- 
Matthew Garrett | [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]