Login or Register to Ask a Question and Join Our Community


UNIX and Linux RSS News

SCO's Proposed Findings of Fact and Conclusions of Law

Login to Discuss or Reply to this Discussion in Our Community

 
Thread Tools Search this Thread
Special Forums News, Links, Events and Announcements UNIX and Linux RSS News SCO's Proposed Findings of Fact and Conclusions of Law
# 1  
Old 04-20-2010
SCO's Proposed Findings of Fact and Conclusions of Law
Here it is, SCO's competing version of Proposed Findings of Fact and Conclusions of Law:
04/19/2010 - 853 - Proposed Findings of Fact by SCO Group. (Hatch, Brent) (Entered: 04/19/2010)

SCO insists still, despite the jury's verdict, that the intention of the parties to the APA in 1995 was to transfer the copyrights, and they'd like them now, please. They also ask for a ruling that Novell can't assert waivers regarding SCO's claims against IBM. However, SCO says in the first footnote that it will be filing a "renewed motion for judgment as a matter of law regarding copyright ownership under Fed. R. Civ. P. 50(b), and, in the alternative, for a new trial under Fed. R. Civ. P. 59. If this Court grants the Rule 50 motion, SCO's claim for specific performance is moot, and if this Court grants a new trial under Rule 59, the Court may defer ruling on the claim for specific performance."
So, there you are, ladies and gentlemen. The SCO Group.
When Judge Dale Kimball ruled against them, they went to the media and the appeals court, and claimed it was unfair. They got their day in court. And now that the jury SCO asked for has agreed with Judge Kimball that SCO didn't get the copyrights under the APA, SCO wants this new judge, the Hon. Ted Stewart, to hand them the victory anyway, since to SCO it's obvious the jury got it wrong as a matter of law.

More...
Login or Register to Ask a Question

Previous Thread | Next Thread
Login or Register to Ask a Question

LEARN ABOUT NETBSD

ubt

UBT(4)							   BSD Kernel Interfaces Manual 						    UBT(4)

NAME

     ubt -- USB Bluetooth driver

SYNOPSIS

     ubt* at uhub? port ? configuration ? interface ?

DESCRIPTION

     The ubt driver provides support for USB Bluetooth dongles to the Bluetooth protocol stack.

     USB Bluetooth dongles provide two interfaces, both of which the ubt driver claims.  The second interface is used for Isochronous data and
     will have several alternate configurations regarding bandwidth consumption, which can be set using the hw.ubtN.config sysctl(8) variable.
     The number of alternate configurations is indicated by the value in the hw.ubtN.alt_config variable, and the isoc frame size for the current
     configuration is shown in the hw.ubtN.sco_rxsize and hw.ubtN.sco_txsize variables.

     By default, configuration 0 is selected, which means that no bandwidth is used on the Isochronous interface and no SCO data can be sent.
     Consult the Bluetooth USB specification at https://www.bluetooth.org/ for complete instructions on setting bandwidth consumption.	The fol-
     lowing extract may be useful as a general guidance though details may differ between manufacturers.

     0	  No active voice channels
     1	  One voice channel with 8-bit encoding
     2	  Two voice channels with 8-bit encoding, or one voice channel with 16-bit encoding.
     3	  Three voice channels with 8-bit encoding
     4	  Two voice channels with 16-bit encoding
     5	  Three voice channels with 16-bit encoding

SEE ALSO

     bluetooth(4), uhub(4), sysctl(8)

HISTORY

     This ubt device driver was originally a character device written by David Sainty and Lennart Augustsson.  It was rewritten to support socket
     based Bluetooth access for NetBSD 4.0 by Iain Hibbert.

CAVEATS

     Isochronous data is seemingly not well supported over USB in the current system and to get SCO working, you may have to calculate the SCO
     packet size that the stack will use.  This is the sco_mtu value reported by the btconfig(8) command, and when combined with the SCO header (3
     bytes) should fit exactly into an integer number of Isochronous data frames where the frame size is indicated by the 'hw.ubtN.sco_txsize'
     sysctl variable.

     For example: I want one voice channel (which is all that is supported, for now) so am using configuration #2, with a frame length of 17
     bytes.  This gives possible values of:

	   (17 * 1) - 3 = 14
	   (17 * 2) - 3 = 31
	   (17 * 3) - 3 = 48
	   (17 * 4) - 3 = 65
	   (17 * 5) - 3 = 82
	   etc.

     btconfig(8) shows the maximum SCO payload as 64 bytes, so I am using the next smaller size of 48, to minimize the overhead of the 3 header
     bytes.

     The SCO packet size can be changed using the 'scomtu' option to btconfig(8).

     The failure mode is that the USB Bluetooth dongle locks up though generally removal/reinsertion will clear the problem.

BUGS

     The Isochronous configuration can only be changed when the device is not marked up.

BSD
								  August 27, 2006							       BSD