USB: mark USB drivers as being GPL only

FYI, this is a patch that will be sent out in the next round to Linus for inclusion in 2.6.25.

If anyone has any objections about it, please let me know.

thanks,

greg k-h

--------

From: Greg Kroah-Hartman <[email protected]>
Subject: USB: mark USB drivers as being GPL only

Over two years ago, the Linux USB developers stated that they believed there was no way to create a USB kernel driver that was not under the GPL. This patch moves the USB apis to enforce that decision.

There are no known closed source USB drivers in the wild, so this patch should cause no problems.

---
 Documentation/feature-removal-schedule.txt |   16 -------
 drivers/usb/core/driver.c                  |   10 ++--
 drivers/usb/core/file.c                    |    4 -
 drivers/usb/core/hcd-pci.c                 |   10 ++--
 drivers/usb/core/hcd.c                     |   18 ++++----
 drivers/usb/core/hub.c                     |    5 +-
 drivers/usb/core/message.c                 |   32 +++++---------
 drivers/usb/core/urb.c                     |   15 +++----
 drivers/usb/core/usb.c                     |   62 ++++++++---------------------
 9 files changed, 61 insertions(+), 111 deletions(-)

@@ -156,22 +156,6 @@ Who:	Arjan van de Ven <[email protected]
 
 ---------------------------
 
-What:	USB driver API moves to EXPORT_SYMBOL_GPL
-When:	February 2008
-Files:	include/linux/usb.h, drivers/usb/core/driver.c
-Why:	The USB subsystem has changed a lot over time, and it has been
-	possible to create userspace USB drivers using usbfs/libusb/gadgetfs
-	that operate as fast as the USB bus allows.  Because of this, the USB
-	subsystem will not be allowing closed source kernel drivers to
-	register with it, after this grace period is over.  If anyone needs
-	any help in converting their closed source drivers over to use the
-	userspace filesystems, please contact the
-	[email protected] mailing list, and the developers
-	there will be glad to help you out.
-Who:	Greg Kroah-Hartman <[email protected]>
-
----------------------------
-
 What:	vm_ops.nopage
 When:	Soon, provided in-kernel callers have been converted
 Why:	This interface is replaced by vm_ops.fault, but it has been around

@@ -325,7 +325,7 @@ int usb_driver_claim_interface(struct us
 
 	return retval;
 }
-EXPORT_SYMBOL(usb_driver_claim_interface);
+EXPORT_SYMBOL_GPL(usb_driver_claim_interface);
 
 /**
  * usb_driver_release_interface - unbind a driver from an interface

@@ -370,7 +370,7 @@ void usb_driver_release_interface(struct
 	iface->needs_remote_wakeup = 0;
 	usb_pm_unlock(udev);
 }
-EXPORT_SYMBOL(usb_driver_release_interface);
+EXPORT_SYMBOL_GPL(usb_driver_release_interface);
 
 /* returns 0 if no match, 1 if match */
 int usb_match_device(struct usb_device *dev, const struct usb_device_id *id)

@@ -542,7 +542,7 @@ const struct usb_device_id *usb_match_id
 
 	return NULL;
 }
-EXPORT_SYMBOL_GPL_FUTURE(usb_match_id);
+EXPORT_SYMBOL_GPL(usb_match_id);
 
 static int usb_device_match(struct device *dev, struct device_driver *drv)
 {

@@ -745,7 +745,7 @@ int usb_register_driver(struct usb_drive
 
 	return retval;
 }
-EXPORT_SYMBOL_GPL_FUTURE(usb_register_driver);
+EXPORT_SYMBOL_GPL(usb_register_driver);
 
 /**
  * usb_deregister - unregister a USB interface driver

@@ -769,7 +769,7 @@ void usb_deregister(struct usb_driver *d
 
 	usbfs_update_special();
 }
-EXPORT_SYMBOL_GPL_FUTURE(usb_deregister);
+EXPORT_SYMBOL_GPL(usb_deregister);
 
 #ifdef CONFIG_PM
 

@@ -204,7 +204,7 @@ int usb_register_dev(struct usb_interfac
 exit:
 	return retval;
 }
-EXPORT_SYMBOL(usb_register_dev);
+EXPORT_SYMBOL_GPL(usb_register_dev);
 
 /**
  * usb_deregister_dev - deregister a USB device's dynamic minor.

@@ -245,4 +245,4 @@ void usb_deregister_dev(struct usb_inter
 	intf->minor = -1;
 	destroy_usb_class();
 }
-EXPORT_SYMBOL(usb_deregister_dev);
+EXPORT_SYMBOL_GPL(usb_deregister_dev);

@@ -144,7 +144,7 @@ int usb_hcd_pci_probe (struct pci_dev *d
 	dev_err (&dev->dev, "init %s fail, %d\n", pci_name(dev), retval);
 	return retval;
 } 
-EXPORT_SYMBOL (usb_hcd_pci_probe);
+EXPORT_SYMBOL_GPL(usb_hcd_pci_probe);
 
 
 /* may be called without controller electrically present */

@@ -179,7 +179,7 @@ void usb_hcd_pci_remove (struct pci_dev 
 	usb_put_hcd (hcd);
 	pci_disable_device(dev);
 }
-EXPORT_SYMBOL (usb_hcd_pci_remove);
+EXPORT_SYMBOL_GPL(usb_hcd_pci_remove);
 
 
 #ifdef	CONFIG_PM

@@ -314,7 +314,7 @@ done:
 
 	return retval;
 }
-EXPORT_SYMBOL (usb_hcd_pci_suspend);
+EXPORT_SYMBOL_GPL(usb_hcd_pci_suspend);
 
 /**
  * usb_hcd_pci_resume - power management resume of a PCI-based HCD

@@ -416,7 +416,7 @@ int usb_hcd_pci_resume (struct pci_dev *
 
 	return retval;
 }
-EXPORT_SYMBOL (usb_hcd_pci_resume);
+EXPORT_SYMBOL_GPL(usb_hcd_pci_resume);
 
 #endif	/* CONFIG_PM */
 

@@ -435,5 +435,5 @@ void usb_hcd_pci_shutdown (struct pci_de
 	if (hcd->driver->shutdown)
 		hcd->driver->shutdown(hcd);
 }
-EXPORT_SYMBOL (usb_hcd_pci_shutdown);
+EXPORT_SYMBOL_GPL(usb_hcd_pci_shutdown);
 

@@ -971,7 +971,7 @@ long usb_calc_bus_time (int speed, int i
 		return -1;
 	}
 }
-EXPORT_SYMBOL (usb_calc_bus_time);
+EXPORT_SYMBOL_GPL(usb_calc_bus_time);
 
 
 /*-------------------------------------------------------------------------*/

@@ -1427,7 +1427,7 @@ void usb_hcd_giveback_urb(struct usb_hcd
 		wake_up (&usb_kill_urb_queue);
 	usb_put_urb (urb);
 }
-EXPORT_SYMBOL (usb_hcd_giveback_urb);
+EXPORT_SYMBOL_GPL(usb_hcd_giveback_urb);
 
 /*-------------------------------------------------------------------------*/
 

@@ -1667,7 +1667,7 @@ int usb_bus_start_enum(struct usb_bus *b
 		mod_timer(&hcd->rh_timer, jiffies + msecs_to_jiffies(10));
 	return status;
 }
-EXPORT_SYMBOL (usb_bus_start_enum);
+EXPORT_SYMBOL_GPL(usb_bus_start_enum);
 
 #endif
 

@@ -1774,7 +1774,7 @@ struct usb_hcd *usb_create_hcd (const st
 			"USB Host Controller";
 	return hcd;
 }
-EXPORT_SYMBOL (usb_create_hcd);
+EXPORT_SYMBOL_GPL(usb_create_hcd);
 
 static void hcd_release (struct kref *kref)
 {

@@ -1789,14 +1789,14 @@ struct usb_hcd *usb_get_hcd (struct usb_
 		kref_get (&hcd->kref);
 	return hcd;
 }
-EXPORT_SYMBOL (usb_get_hcd);
+EXPORT_SYMBOL_GPL(usb_get_hcd);
 
 void usb_put_hcd (struct usb_hcd *hcd)
 {
 	if (hcd)
 		kref_put (&hcd->kref, hcd_release);
 }
-EXPORT_SYMBOL (usb_put_hcd);
+EXPORT_SYMBOL_GPL(usb_put_hcd);
 
 /**
  * usb_add_hcd - finish generic HCD structure initialization and register

@@ -1922,7 +1922,7 @@ err_register_bus:
 	hcd_buffer_destroy(hcd);
 	return retval;
 } 
-EXPORT_SYMBOL (usb_add_hcd);
+EXPORT_SYMBOL_GPL(usb_add_hcd);
 
 /**
  * usb_remove_hcd - shutdown processing for generic HCDs

@@ -1964,7 +1964,7 @@ void usb_remove_hcd(struct usb_hcd *hcd)
 	usb_deregister_bus(&hcd->self);
 	hcd_buffer_destroy(hcd);
 }
-EXPORT_SYMBOL (usb_remove_hcd);
+EXPORT_SYMBOL_GPL(usb_remove_hcd);
 
 void
 usb_hcd_platform_shutdown(struct platform_device* dev)

@@ -1974,7 +1974,7 @@ usb_hcd_platform_shutdown(struct platfor
 	if (hcd->driver->shutdown)
 		hcd->driver->shutdown(hcd);
 }
-EXPORT_SYMBOL (usb_hcd_platform_shutdown);
+EXPORT_SYMBOL_GPL(usb_hcd_platform_shutdown);
 
 /*-------------------------------------------------------------------------*/
 

@@ -494,6 +494,7 @@ void usb_hub_tt_clear_buffer (struct usb
 	schedule_work (&tt->kevent);
 	spin_unlock_irqrestore (&tt->lock, flags);
 }
+EXPORT_SYMBOL_GPL(usb_hub_tt_clear_buffer);
 
 static void hub_power_on(struct usb_hub *hub)
 {

@@ -3116,7 +3117,7 @@ re_enumerate:
 	hub_port_logical_disconnect(parent_hub, port1);
 	return -ENODEV;
 }
-EXPORT_SYMBOL(usb_reset_device);
+EXPORT_SYMBOL_GPL(usb_reset_device);
 
 /**
  * usb_reset_composite_device - warn interface drivers and perform a USB port reset

@@ -3187,4 +3188,4 @@ int usb_reset_composite_device(struct us
 	usb_autosuspend_device(udev);
 	return ret;
 }
-EXPORT_SYMBOL(usb_reset_composite_device);
+EXPORT_SYMBOL_GPL(usb_reset_composite_device);

@@ -147,7 +147,7 @@ int usb_control_msg(struct usb_device *d
 
 	return ret;
 }
-
+EXPORT_SYMBOL_GPL(usb_control_msg);
 
 /**
  * usb_interrupt_msg - Builds an interrupt urb, sends it off and waits for completion

@@ -238,6 +238,7 @@ int usb_bulk_msg(struct usb_device *usb_
 
 	return usb_start_wait_urb(urb, timeout, actual_length);
 }
+EXPORT_SYMBOL_GPL(usb_bulk_msg);
 
 /*-------------------------------------------------------------------*/
 

@@ -465,7 +466,7 @@ nomem:
 	sg_clean (io);
 	return -ENOMEM;
 }
-
+EXPORT_SYMBOL_GPL(usb_sg_init);
 
 /**
  * usb_sg_wait - synchronously execute scatter/gather request

@@ -569,6 +570,7 @@ void usb_sg_wait (struct usb_sg_request 
 
 	sg_clean (io);
 }
+EXPORT_SYMBOL_GPL(usb_sg_wait);
 
 /**
  * usb_sg_cancel - stop scatter/gather i/o issued by usb_sg_wait()

@@ -604,6 +606,7 @@ void usb_sg_cancel (struct usb_sg_reques
 	}
 	spin_unlock_irqrestore (&io->lock, flags);
 }
+EXPORT_SYMBOL_GPL(usb_sg_cancel);
 
 /*-------------------------------------------------------------------*/
 

@@ -652,6 +655,7 @@ int usb_get_descriptor(struct usb_device
 	}
 	return result;
 }
+EXPORT_SYMBOL_GPL(usb_get_descriptor);
 
 /**
  * usb_get_string - gets a string descriptor

@@ -827,6 +831,7 @@ int usb_string(struct usb_device *dev, i
 	kfree(tbuf);
 	return err;
 }
+EXPORT_SYMBOL_GPL(usb_string);
 
 /**
  * usb_cache_string - read a string descriptor and cache it for later use

@@ -927,6 +932,7 @@ int usb_get_status(struct usb_device *de
 	kfree(status);
 	return ret;
 }
+EXPORT_SYMBOL_GPL(usb_get_status);
 
 /**
  * usb_clear_halt - tells device to clear endpoint halt/stall condition

@@ -985,6 +991,7 @@ int usb_clear_halt(struct usb_device *de
 
 	return 0;
 }
+EXPORT_SYMBOL_GPL(usb_clear_halt);
 
 /**
  * usb_disable_endpoint -- Disable an endpoint by address

@@ -1253,6 +1260,7 @@ int usb_set_interface(struct usb_device 
 
 	return 0;
 }
+EXPORT_SYMBOL_GPL(usb_set_interface);
 
 /**
  * usb_reset_configuration - lightweight device reset

@@ -1328,6 +1336,7 @@ int usb_reset_configuration(struct usb_d
 	}
 	return 0;
 }
+EXPORT_SYMBOL_GPL(usb_reset_configuration);
 
 static void usb_release_interface(struct device *dev)
 {

@@ -1677,22 +1686,3 @@ int usb_driver_set_configuration(struct 
 	return 0;
 }
 EXPORT_SYMBOL_GPL(usb_driver_set_configuration);
-
-// synchronous request completion model
-EXPORT_SYMBOL(usb_control_msg);
-EXPORT_SYMBOL(usb_bulk_msg);
-
-EXPORT_SYMBOL(usb_sg_init);
-EXPORT_SYMBOL(usb_sg_cancel);
-EXPORT_SYMBOL(usb_sg_wait);
-
-// synchronous control message convenience routines
-EXPORT_SYMBOL(usb_get_descriptor);
-EXPORT_SYMBOL(usb_get_status);
-EXPORT_SYMBOL(usb_string);
-
-// synchronous calls that also maintain usbcore state
-EXPORT_SYMBOL(usb_clear_halt);
-EXPORT_SYMBOL(usb_reset_configuration);
-EXPORT_SYMBOL(usb_set_interface);
-

@@ -42,6 +42,7 @@ void usb_init_urb(struct urb *urb)
 		INIT_LIST_HEAD(&urb->anchor_list);
 	}
 }
+EXPORT_SYMBOL_GPL(usb_init_urb);
 
 /**
  * usb_alloc_urb - creates a new urb for a USB driver to use

@@ -73,6 +74,7 @@ struct urb *usb_alloc_urb(int iso_packet
 	usb_init_urb(urb);
 	return urb;
 }
+EXPORT_SYMBOL_GPL(usb_alloc_urb);
 
 /**
  * usb_free_urb - frees the memory used by a urb when all users of it are finished

@@ -89,6 +91,7 @@ void usb_free_urb(struct urb *urb)
 	if (urb)
 		kref_put(&urb->kref, urb_destroy);
 }
+EXPORT_SYMBOL_GPL(usb_free_urb);
 
 /**
  * usb_get_urb - increments the reference count of the urb

@@ -106,6 +109,7 @@ struct urb * usb_get_urb(struct urb *urb
 		kref_get(&urb->kref);
 	return urb;
 }
+EXPORT_SYMBOL_GPL(usb_get_urb);
 
 /**
  * usb_anchor_urb - anchors an URB while it is processed

@@ -444,6 +448,7 @@ int usb_submit_urb(struct urb *urb, gfp_
 
 	return usb_hcd_submit_urb(urb, mem_flags);
 }
+EXPORT_SYMBOL_GPL(usb_submit_urb);
 
 /*-------------------------------------------------------------------*/
 

@@ -514,6 +519,7 @@ int usb_unlink_urb(struct urb *urb)
 		return -EIDRM;
 	return usb_hcd_unlink_urb(urb, -ECONNRESET);
 }
+EXPORT_SYMBOL_GPL(usb_unlink_urb);
 
 /**
  * usb_kill_urb - cancel a transfer request and wait for it to finish

@@ -553,6 +559,7 @@ void usb_kill_urb(struct urb *urb)
 	--urb->reject;
 	mutex_unlock(&reject_mutex);
 }
+EXPORT_SYMBOL_GPL(usb_kill_urb);
 
 /**
  * usb_kill_anchored_urbs - cancel transfer requests en masse

@@ -595,11 +602,3 @@ int usb_wait_anchor_empty_timeout(struct
 				  msecs_to_jiffies(timeout));
 }
 EXPORT_SYMBOL_GPL(usb_wait_anchor_empty_timeout);
-
-EXPORT_SYMBOL(usb_init_urb);
-EXPORT_SYMBOL(usb_alloc_urb);
-EXPORT_SYMBOL(usb_free_urb);
-EXPORT_SYMBOL(usb_get_urb);
-EXPORT_SYMBOL(usb_submit_urb);
-EXPORT_SYMBOL(usb_unlink_urb);
-EXPORT_SYMBOL(usb_kill_urb);

There are the commercial OpenSound drivers.

Regards,
Clemens

What are they? Do you have a link to them? And why have I not heard from any user of them for the past two years (we have had a kernel warning for over 2 years for this issue.)

thanks,

greg k-h

http://www.opensound.com/

They aren't used widely (with Linux), and AFAIK the USB driver doesn't have anything to favor it over the ALSA driver.

As far as my (biased) opinion is of interest, I'm not objecting against your patch.

Regards,
Clemens

Ok, then we don't have any issues :)

thanks,

greg k-h

What about ndiswrapper and its windows binaries
are they covered through ndiswrapper by GPL?
(Unfortunately I use them, but less and less)

Boaz

Sorry, but no, they are not going to work, due to the way that ndiswrapper is marked by the kernel module loader.

Again, you should be getting a kernel warning every time you try to use a USB function today.

What USB drivers for wireless devices are not yet supported by Linux becides the Marvell-based ones (which some of us are actively working on...)?

thanks,

greg k-h

I was afraid of that, yes.

sigh, yes I do, but it's better then no networking.

I'm not even sure, its an old vaio pII 512MZ. Still works like a charm with Linux. I use a chokoloku usb dangle that I dismantled and assembled inside the laptop case. I use the original windows drivers that came with it.

Last time I checked with 2.6.20 it did not work, but I should now try 2.6.24 as I know things have advanced a lot. (It works and I'm just lazy)

Thank you, I do support what you are doing here. Just the ndiswrapper is a special case. But I guess I, as a user, can always use it anyway, right? But not the commercial distros. Don't stop the transition on my account.

Boaz

Yes, as a user, you are free to do whatever you want with the source code :)

thanks,

greg k-h

Greg KH <[email protected]> said on Fri, 25 Jan 2008 10:02:32 -0800:

The near paperweight of Avermedia A828 Hybrid FM Volar nevertheless works with their closed module[1] at least as a digital tuner and a pretty crap FM tuner, despite the warning in syslog that it will no longer work in short order. Yes, I was suckered in by their claim that "it works under Linux", wasn't I?

I would have thought it would be fairly easy to write open drivers for it, given that it has pretty standard chips:
Cypress FX2, WM8739, Conexant CX2584x, Xceive XC3028 and Zarlink MT352

[1] http://www.avermedia.com/EN/default.aspx?TYPE=test.htm&PT=downloadD1&tv_TCAT_POS=0&CATNO0=D&IDX=2.1&CNT=1&CATNO1=D2&PID=471071067-1556&UCN=BAB4C
http://www.avermedia.com/images/www.avermedia.com_EN/A828_LinuxDrv_v0.07_x86Beta.zip

Yes, I have objections and I've told you before.

This is a bit disingenuous. Of course there are closed source USB
drivers out there. I've written multiple of them during my life as a consultant. The nature of closed source drivers is that they quite often are written for custom hardware that isn't used by that many people, so you have probably not seen them, but they are definitely out there in the wild.

For some of these drivers, being in kernel space is very important since they transfer large amounts of data with very tight latency requirements. It may, in theory, be possible to do the same thing in userspace with multiple cooperative threads and libusb, but it would be much more complex and much more error prone (it's hard to do control loops where you need about 40 us turnaround time).

Yes, I'd much prefer if all companies would just publish their sources as GPL, but some companies, rightly or nor, believe that they expose too much information about their custom hardware if they do. And I do feel that such a rabid GPL-stance is going to alienate those companies. Most of those companies also select one kernel for their custom hardware and use that kernel for a long time, so for them this feature removal will come as a bit of a surprise.

/Christer

You sent one message on this topic to me, back in Feb of 2007, disagreeing that you could write a userspace USB driver running at full speed in a non-racey manner.

Unfortunately, many other userspace USB drivers seem to disprove your statement, including a number of vision systems running in military applications (tanks running Linux!). Perhaps this is just a matter of using the api properly :)

I do know that the current usbfs interface is a major pain, hence the work to create usbfs2. I know those developers could use the help in getting that cleaned up and into the kernel tree.

Also see the rapid development these days in wrappers around usbfs. There is competing projects right now with OpenUSB and the revitalization of the old libusb project. I know those developers are looking for examples where their new frameworks do not meet the needs of developers for stuff exactly like you describe (lots of threads, async callbacks, high throughput, cross-platform portability, etc.)

Again, I have asked for examples, and only received 2. One (sound driver) is totally not needed at all, as the kernel provides that capability, and the other hasn't run in a modern distro for years.

It comes down to the simple fact, if you wish to use Linux, abide by the license it comes under. To do otherwise is both disenginous and illegal[1].

See statement above about vision systems in tanks, it can, and is done all the time...

If a company wants to keep a driver closed, then use another operating system, it's not like there isn't other options out there. I hear the BSDs and Microsoft are quite comfortable with things like that. :)

thanks,

greg k-h

[1] This is the public position of my personal lawyers, my employer's lawyers, and a number of other companies whom hold copyright on the Linux kernel tree. So it's not like this is a minority decision these days...

Yes, I did spend quite a lot of time the last time looking for usable USB APIs, and I did not manage to find any. Unfortunately, my time is also limited, and I'd much prefer to work on getting support for Samsungs ARM CPUs into Linux. When I'm doing paid work for a customer and they want to a proprietary driver, I'm not going to spend a lot of my free time on working around that decision. I explain to them that binary drivers are definitely in a grey area and they might get in trouble about it, but at the end it is their decision.

So in other words you want to crack down on GPL violations, and you're going to ignore anyone who does have a proprietary driver as "not relevant" or "it can be done with usbfs" (maybe). So why even ask on the mailing list? Just do it.

Saying "use BSD" instead isn't a good answer for me since I don't know BSD well enough. And personally, I want to see Linux everywhere; I think it's a lot better to have Linux + a proprietary driver in an embedded system than BSD or Windows CE. It means that the customers get used to Linux, and if I can get them to at least contribute back a bit (any improvements to the core kernel for example), to me that is a lot better than giving a lot more money to BillG.

Later, when I can show them how much easier everything gets if they use open drivers (I'd never have managed to get my latest Samsung platform up and running as quickly as I did without the patches I got from Sandeep Patil, and by posting my patches to his patches I got some feedback that helped me fix a bunch of bugs). But it usually takes some time to convince a company that the things they get back is more valuable than keeping things proprietary. So I think Linux as a whole gains a lot more by being a bit lenient about proprietary drivers. That is why I'm opposed this change of yours.

/Christer

Hi Christer,

Why are we discussing this again? The Linux kernel is distributed under the GPLv2 and even though there are some legal gray areas regarding derived work (think nvidia and ati binary blobs here), the license is not friendly towards proprietary drivers at all. Furthermore, many of the _kernel developers_ do not support proprietary drivers, so why do you insist on using Linux for that purpose?

Seriously, you really really want to look at the BSDs or proprietary operating systems because they support your needs much better.

Pekka

Why? Because it is a gray area. I still have my reservations about the GPL being as viral as FSF says it is. Greg KH's lawyer says one thing, some legal departments I've talked to say something else (or they express it in laywerese, but it boils down to "you can probably get away with it") and apparently both nvidia's and ati's legal departmens think so too.

And because I belive it's very important not to scare away Linux users unneccesarily. Yes, the kernel does not, and should not be friendly towards proprietary drivers, but there is a difference between not being friendly and being actively hostile.

You did read the rest of the mail you commented I hope?

So you'd rather have the Nokia 770 use BSD because Nokia couldn't find a low power WLAN chip with a GPLed driver? You'd rather see Nokia spend man-years on improving the support for the TI OMAP CPU's somewhere else than Linux? Yes, it sucks that the on WLAN Nokia 770 doesn't have an open driver, but I'm very happy that Nokia has spent all that effort on getting Linux to run well on the 770 and has given 99% of that work back to the Linux community. (Actually, I think there is a GPLed driver for the WLAN now, but that driver would most probably not have been written unless the Nokia 770 hardware had been out there so that frustrated Linux hackers decided to do something about it).

And why is it ok for nvidia and ati to have proprietary drivers? Is it ok just because people are afraid to alienate them if they push too hard? Having no 3D graphics at all on Linux is a nightmare scenario for the distro makers, so I guess that's why people try not to rock the boat too much. So why don't you send in a patch that makes all EXPORTS into EXPORT_GPL? That would be the only honest course of action according to you, wouldn't it?

/Christer

No, it really is not a gray area at all, especially when you are writing a new driver for Linux. Go talk to a lawyer if you want the details.

thanks,

greg k-h

If we're still talking about whether a kernel module is required to be released under GPL, then yes, this is not a gray area. This is something that authors of original works can decide for themselves. They have no obligation to release under GPL, however they must take special care to ensure that the module does not (statically) link with the kernel. Richard Stallman (apparently, according to Pavel Roskin, although he didn't forward Richard's message as requested) said it nicely:

A kernel module is akin to a process. It uses services of the kernel without being part of the kernel. However in order to use the kernel it might very well statically link with kernel support functions, such as copy_from_user(). This, it may not do without garnering a requirement to be released under GPL. That being said, a module can be written such that it only dynamically links with the kernel. Ndiswrapper is an example of how this can be done: None of the drivers that work under ndiswrapper make any direct use of the kernel, not in any way, indeed a wrapper could be written for a different operating system. There is no obligation for ndis drivers to be released under GPL, and even though they are not, they break no licence condition by calling services, even those exported as GPL-only.

Bringing this back to the point, the notion that some exported symbols may be accessed by proprietary modules and others can't is wrong. The licence under which Linux is released makes no mention of this possibility, and so no such condition exists. In order to prevent proprietary modules from using a symbol, that symbol must be provided in such a way that a second module can only statically link to it. I think that precludes exporting it via EXPORT_SYMBOL or EXPORT_SYMBOL_GPL.

Summarising the point: To claim all USB drivers must be released under GPL is wrong.

Still wrong.

Only if they are original works.

Also wrong.

You really should investigate a beginners text on intellectual property law.

Alan

                     ^^^^^^^^^^^^^^^

Yes. That was stipulated.

Perhaps you might read up on unfair trade practices and contract law. The contract (GPL) doesn't prevent me from using GPL work, in fact it encourages me. Neither can it impose conditions upon original work authored by a third party.

You do realise, I suppose, that it's easily feasible to write a Linux kernel module on a non-Linux platform, and in fact without even using any GPL software in its production. How could such a work possibly be derivative? How could it be affected by GPL?

And please, don't give wishy-washy "lawyers tell me it's so" non-answers. Give something real.

I'm familiar with them to some extent because I have run companies in the past and continue to do so as a sideline to my Red Hat work. I also spend more time than I'd like talking to lawyers about licencing.

First mistake: The GPL is not a contract it is a license.

If the GPL was a contract it could most certainly impose conditions upon original works. Contract law permits to write things like "If you buy the source for this package you agree not to write a competing product for three years even if an origina work".

Alan

Mea culpa. It is indeed a licence, which I did and do know. I really did mean, "The licence (GPL)"

No Linux does not work like this at all.

Like Alan said, you really need to brush up on your basic IP law, as well as some basic technical issues regarding how the Linux kernel works before trying to make statements like this.

Also see the various issues surrounding "loadable modules" and Samba, and how they have successfully enforced the "linking" and other type issues that are being discussed here (shims, "GPL condoms", etc.) with regards to the GPLv2 and derivative works.

good luck,

greg k-h

If you know of something relevant, give pointers.

The issue is all about "derivative works" in copyright law.

Ndiswrapper is in a good position because the closed-source drivers were originally written for another OS so it's pretty well impossible to argue that they are derived from linux.

However, if I were to write a new GPL shim and then a new closed-source module that uses the shim to access kernel symbols, it is entirely possible that a court could rule that my closed-source module is a derivative work of the linux kernel because it was written specifically to run on linux.

On the other hand if I were to sit down and write an OS-agnostic proprietary chunk of code, and then write a new GPL shim to use it under linux (and maybe other shim layers for other OS's as well), I _might_ be okay. But I would have to be prepared to prove that the proprietary code was not derived from the Linux kernel.

Chris

IANAL, but when looking at the "But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License" of the GPLv2 I would still consult a lawyer before e.g. selling a laptop with a closed-source driver loaded through ndiswrapper.

cu
Adrian

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

If that were true, you couldn't legally install more than one program on a computer without permission from all the copyright holders without specific license permission.

A "work based on the Program" is the same as a derivative work. A laptop with an assortment of different programs on it is not a work, it is a collection of works.

DS

Don't ignore, "mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License." Static linking certainly makes something part of the whole; dynamic linking doesn't.

Wrong again. You really are quite amusing. The test is "derivative works" not linking. Linking is a meaningless (in law) computing term with no place. Legal precedent for combining of works is drawn from things like shipping a book and a commentary on the book together, putting music to films, putting photos in a book. These are not "linking"

And I know what the lawyers I've talked to have said about the case of shipping proprietary modules with the OS. Its a pretty definite "bad idea"

Alan

I'm glad to entertain. It's a pity you refuse to be educated. Closed mind on the topic, perhaps?

That is one of the terms used. Another, which I pointed out to your apparent glee, is "aggregation." Both terms are relevant only because they were chosen for use in GPL.

Whatever the precedent is, and I'll take your word on it even though it's more hearsay, it's explicitly covered by that part of the licence referring to "mere aggregation."

Now, that's more like it. It sounds somewhat believable, unlike your previous statements which seemed to say, "you've spoken to numerous lawyers and they've all said that proprietary modules violate GPL." I paraphrased you, and if that's not what you meant then please take the opportunity to refine your claims. "Bad idea" is legal speak for, "I'll fight it for you, but you can lose." That's a big step away from "dynamic modules must be governed by GPL."

Please don't use "seemed to say" and then quote words I've never said. That's misleading, rude and also awful language style. I've not said anything is definite because as I said before there is no caselaw.

We know the GPL is enforcable (Germany and US)
We have good reason to believe works can be derivative across all sorts of boundaries (non computing caselaw, cases that never went to court - eg objective C)

Nobody has yet sued anyone to my knowledge over the module case because quite frankly the list of blatant binary only shipping of GPL code without licence, sources or offers people will keep us busy for quite some time yet.

I actually don't expect to see that case tested - it isn't in anyones interest to test it right now. ATI are being good boys at last, the other big vendors that did binary modules are moving away and in several cases I know have been told 'no more binary modules' and Nvidia are a company without a processor in a world where graphics is going to be on CPU soon. Lets say I don't own any Nvidia shares.

Alan

No, it's called, "paraphrasing," and it's quite normal in a conversation. You say something, I tell you what I think you said, you refine your language, and the process continues until we're happy that a semantic consensus has been reached. In that spirit, should I now understand that what you meant is that *you* *think* that kernel modules must be released under GPL. Should I accept that you didn't mean that numerous lawyers had told you that this was factually so?

Of course, this begs the question of why there would be a MODULE_LICENSE("proprietary"). You may hold beliefs as understood above, but it seems guaranteed that the opinions of those who count are divided.

Actually, static linking does not, since the whole is not a "work". Under copyright law, a "work" can only be made by creative effort. Static linking is not creative effort, so it cannot create a work. If it were, the linker would be entitled to copyright on the new work, which makes no sense at all.

An exception might exist if there were a large number of equally good ways to perform the link and the person who lined it had to creatively chose a method. But normally, anything purely dominated by functional considerations (which statically linking almost always is) is not considered sufficiently creative.

If you statically link work "X" to work "Y", the result is *not* work "Z", derivative from "X" and "Y". It is parts of work "X" and parts of work "Y" mechanically combined. A group of combined works follows the license for each of the individual works from which sufficient protectable expression has been taken.

A "derivative work" is a new work, and can only be formed by creative effort not in the works it is claimed to be derivative of.

And to Alan Cox, who write:

A license is a form of contract in which part of the compensation one party receives is rights to the intellectual property of the other party.

Sure, and those things would apply to anyone who has accepted the contract. Why do you think the GPL couldn't say those things and enforce them against anyone who had agreed to the GPL?

How is agreeing to release source code any different from agreeing not to write a competing product? (Except that a court may be more likely to enforce the latter than the former, of course.)

And to Marcel:

When there is only one way to do it, you cannot copyright that one way. You need a patent for that. So, no, it's not a derivative work because what was taken is the one way to do it, and "one way to do it" is not protectable expression. A derivative work only applies when protectable expression is taken.

DS

A lot of software is written specifically to run on Linux, but that doesn't mean it's derived from Linux. In the case of user-space code it's widely understood that no licence restrictions are conferred. The argument relating to kernel modules is that a module is somehow different because it runs in kernel mode. I can't see it, and in view of the status of user-space code, strong arguments would have to be made.

No. Holders of Linux copyrights would have to prove that the proprietary code is derived from the kernel. They have the burden of proof, and defence needs merely show that their arguments are wrong. (So if the proof is faulty, the case fails even if the code is derivative.)

Actually that is also questionable. The only reason it is fairly certain in Linux is Linus went to the trouble of stating that interpretation was intended in the COPYING file and saying he sees it that way.

Wrong again. In civil law in the USA and most of europe the test is "balance of probability".

Alan

No, I'm right. The word "proof" is appropriate in context. (I write in plain English, not Legalese.) I certainly didn't intend "proof" to mean "mathematically certain." Anybody who pretends that proof in court means that must be ignorant or trying to deceive.

I'm afraid you are wrong despite your desperate attempts to reinterpret your own comments. The civil law is "balance of probability". Those are the precise words used. As it is a dispute between two civil parties with no assumed right or wrong it is a matter of which interpretation is most likely "proof" doesn't come into it whatever version of proof you want to pick this email.

"burden of proof" is a specific term with a specific meaning in law.

I've had this argument before. The conclusion is that spiteful people insist on using the legal meaning for words which have explicitly been said using plain English. If you are spiteful, then by all means rant about legal terms, but do so knowing that everybody understand what I mean.

Even in civil matters, it is necessary for the appellant to present a case and the respondent may simply pick holes in it.

Further, don't forget that copyright violation is a criminal matter in some jurisdictions. I it is so in Australia, and attracts penalties that include imprisonment. In Australia, and I wonder if it isn't so in USA, the legal interpretation that you so keenly insist upon, must therefore apply.

I shall not engage in further debate about what the legal meaning is of plain English terms. It's a stupid argument suitable only for stupid people.

Alan Cox kirjoitti:

What is the "propability" that drivers using the interfaces now declared as "EXPORT_SYMBOL_GPL" are derived from the Linux kernel source code instead of some definitive documentation?

As you all (should) know there is a book called "Linux Device Drivers, 3rd Edition" published by O'Reilly (ISBN 0-596-00590-3)". All the USB kernel interfaces are documented there. One of the authors is Greg Kroah-Hartman which makes this book "definite" source of information on Linux USB driver programming. I assume Greg is the author of the USB related sections.

The "legal" question is what is that which one is license the one that applies? Is it the licecense of the kernel (GPL) or is it the license of the documentation (no restrictions on usage)?

The "moral" question is that why did Greg author a book that declares these USB interfaces as "free to use" and soon after that made a decision that they are no longer "free to use"?

Best regards,

Hannu

Yes, I wrote that, and if you look at that chapter, it states it is based on the GPL licensed documentation that comes from the kernel itself, which was written by a lot of other people as well.

There is no such license on that documentation.

Where did I ever declare these interfaces as "free to use in violation of the GPL" anywhere? If you look at the examples that I wrote for that book, they are all licensed under the GPLv2 only.

Same goes for the Windows Driver book. You can use the Windows driver development kit and API, as long as you follow their license. And that license explicitly forbids using it in code that is under an open source license. Is describing those interfaces in a book somehow also "immoral"?

geesh, this thread is just insane, time to just ignore it...

greg k-h

I think you're being dishonest. This isn't really about Linux and it being licensed under GPL, is it? Not if you're being 100% honest. This is really about Beejay's* kernel module; and you are attempting to force her to release that under GPL. You should 'fess up, that the change is 0% technical, 0% unavoidable and 100% political. This does, of course, disadvantage Linux with respect to many classes of devices, for example GSM transceivers when used in those parts of the world^ where regulatory requirements prohibit modification of power or frequency settings, which effectively prohibits open-source driver.

An unbending bias towards GPL is impractical in many markets. It also hands an additional point or two of market share to Microsoft; who no doubt will be immensely grateful.

*The fictitious author of an imaginary driver.
^Probably all of the world.

David Newall ha scritto:

Why "of course" ?
In the cited example it's illegal to go outside certain parameters SOMEWHERE (if it was illegal everywhere, the the hardware shouldn't allow it and the sw could do nothing... not considering hw mods). Another example is WiFi: USA, Europe and Japan allows a different number of channels. But every AP I have had simply asks which country the user is in, then allows only a limited choice for the channel to use. If I'm in Europe but tell my AP that I'm in Japan, it lets me choose channel 13 (Europe allows up to ch 11). If the "cops" find it out, they prosecute ME, not my AP! It's not a TECHNICAL limit, it's a LEGAL one. So there's no point in keeping a driver closed *just* because else someone could hack it to make it work outside the allowed parameters: even a closed driver is hackable (just reverse engineer it...).

Think about this scenario: a closed source driver contains:
if(power<100)

	setpower(power);
else
	setpower(100);

to limit tx power and make it legal. Then the user finds this 100 and replaces it with 255 (inside the binary-only module), actually allowing for more than twice (if power is in mW) the legally permitted power.
Is it legal?
I don't think so (and I doubt you can find any lawyer that does). But it's not THE DRIVER that's doing something illegal. It's THE USER.
It would be equally illegal if the driver was open source. Simpler to do, but equally illegal.
Another example: how do you detect, from a driver, if the user actually got a license/permission from the government (somewhere it's needed, or you need to pay an annual fee) to use the device? You can't. Does this missing check make the device illegal? Nope. Just its USE.

I stop here cause it's already too OT.

BYtE,
Diego.

It isn't that easy. The "Tamper-Proof Torx" screws on a vacuum cleaner or a toaster won't stop anybody from opening up the thing, I mean every little hardware store stocks those Torx bits. But by using a slightly odd screw, the company can say "look, we'we done all we can to stop them, but the user bypassed our security device, and it's not our fault". Apparently Intel and Atheros are trying to protect themselves in a similar way, they Open Source everything except for the regulatory daemon (Intel) or HAL object file (Atheros). Why? Because they belive that if they give away the sources to those parts they do the software equivalent of putting a normal Phillips screw in a home appliance. (Personally I think what they are doing is ridiculous, but apparently those companies' lawyers dont' agree).

It's of course possible to argue that normal users don't compile their own drivers, they use a driver from their distribution maker, and compiling a hacked driver which allows them to override the limits is just as hard as it is for a Windows user to replace the driver binary with a hacked binary which overrides the limits, so hiding the source really doesn't help.

Welcome to the modern world, companies spend so much money on protecting themselves against potential lawsuit that it is silly.

/Christer

Hi Christer,

while the HAL case of Atheros might be still true despite the fact that an OpenHAL has been around for a long time now. The Intel argument is out of the picture since quite some time. The regulatory daemon was an interim solution and has been replaced by a proper firmware solution. So please get your examples up-to-date.

You might wanna now point to hiding something in firmware, but the hardware, firmware, driver separation (with being hardware and firmware closed source) is an accepted solution. It is a clean separation. Interface wise and license wise. Remember that nobody inside the community ever asked for any kind of IP or trade secrets. We only want specifications so we can write the drivers under an appropriate open source license. If the specification describes an API exposed via firmware then that is perfectly fine.

Regards

Marcel

So how does that invalidate my point? Intel did jump through a lot of hoops to avoid giving away the code that controls their radio. When the regulatory daemon stuff got too much complaints, they finally redid their firmware to avoid the daemon. But they still have not exposed the details on how to control their radio.

Yes, that is a nice solution. Provided that you have any firmware at all. But price is everything, chips become dumber and dumber and more control functions are pushed to the host. If you want to sell a device in Korea, price is everything; if you can shave off 30 cents by putting the firmware in ROM, or by using 1.5 mbits of flash instead of 2 mbits, that means an increase in market share or profit margins.

I definitely agree. I think it's stupid of companies to hide away their documentation out of fear of, well, something. I find it extremely frustrating when I bought a device touted as "the first open Linux mobile", just to find out that it used a binary-only kernel module for the M-Systems DiskOnChip. A quite nice phone, but due to that one module, it was completely impossible to use anything but the ancient 2.4 kernel it came with.

I also think that my customers, that decided to keep their kernel modules binary only, made a big mistake and have told them so. But I still think it's better for the Linux community to be a bit soft on such companies for a while. It's better to let them get away with it for a while, and slowly try to convince them about the error of their ways, rather than see them go with Windows CE or a BSD.

/Christer

Am Wed, 6 Feb 2008 21:34:49 +0100
schrieb Christer Weinigel <[email protected]>:

That has been done, hasn't it?

If somebody prefers an other OS for license reasons only, let them. You cannot have open source software without open source license. If a company chooses Linux, they do it for technical reasons, and because they're able to modify the sources to suit their needs. Whatever advantages they see in Linux, they have to know that they have to accept its license. Just saying "I like your software but your license is stupid" is childish. Use CE instead.

Thanks,
Hans

Nobody is saying "I don't like your licence." The issue is a technical restriction in Linux that attempts to restrict non-GPL software from running under it. It's a bullish approach, technically incompetent, legally meaningless and politically damaging.

Am Thu, 07 Feb 2008 23:49:42 +1030
schrieb David Newall <[email protected]>:

What are you trying to say? You like the license but you're against enforcing it?

What's incompetent?

It is not legally meaningless if copyright holders publicly state how they interpret the license and what they consider a license violation. In the end, a court must decide, but lots of courts will at least look at the statements the copyright holders made over the years.

That's your opinion because it's damaging _your_ political goals.

Hans

I told you: the GPL does not preclude inter-operation with non-GPL software.

It's easily defeated.

Copyright-holders' opinions mean nothing. In the particular case of EXPORT_SYMBOL_GPL, copyright-holders' opinions are clearly flawed because they make a statement about code that they do not even know of. It's equivalent to someone saying, "you are wrong," before you've even thought about saying something.

How ludicrous. That's as much a nonsense as EXPORT_SYMBOL_GPL. You have no idea what my political goals are.

Less there be further confusion: I am not an advocate for binary drivers. That role is reserved for others. However that does not stop me from criticising something that is obviously wrong. Stating that only a GPL code is permitted to use a symbol contravenes the GPL, because the GPL states no such requirement. Saying that it's impossible for code that uses the symbol to be non-GPL (as has been claimed) is a lie at worst, and a hope at best. Nobody claiming such a thing could know it to be true. (It is not true.)

Am Fri, 08 Feb 2008 01:01:24 +1030
schrieb David Newall <[email protected]>:

What are you talking about? That's what every GPL-licensed library does. By putting a library under the GPL, the copyright-holder clearly states that he considers all programs that link against that library a derived work. And that he therefor requires these programs to be GPL, too, no matter if these programs already exist or not.

The LGPL exists to allow the linked program to be non-GPL, remember? But the kernel is GPL, and not LGPL. And all these arguments that a kernel module does not "link" against the kernel code, is therefor not a derived work, and not bound by the GPL's restrictions, is just artificial nonsense.

No. The GPL is about derived work. Derived code can obviously only appear _after_ the original work.

Nice to hear. So, if you're an advocate for open source drivers, why do you have problems making them GPL?

Using a symbol from a library means linking to it, and that creates a derived work. Why should it be different when using kernel symbols?

Thanks,
Hans

There's an interesting parallel in the SCO vs Novell case.

Dave

*************************************************************************************************************************************************************************************************************************************************

NICE CTI Systems UK Limited ("NICE") is registered in England under company number, 3403044. The registered office of NICE is at Tollbar Way, Hedge End, Southampton, Hampshire SO30 2ZP.

Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately.

Monitoring: NICE may monitor incoming and outgoing e-mails.

Viruses: Although we have taken steps toward ensuring that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.

****************************************************************************************************************************************************************************************************************************************************

Your last sentence, above: That is what EXPORT_SYMBOL_GPL attempts to do. The place to state such a requirement is in the licence, not in the source code. That is what I am talking about. I can't provide you with software under a licence that says, "you are free to use this software in any way you want," and later say, "oh, but in the source code is tells you that you must take a break every two hours of use."

I don't, but EXPORT_SYMBOL_GPL doesn't do that. It makes an ambit claim, that might coerce an author into making a driver GPL, but might also cause them to exit the Linux market. I have a problem with driving manufacturers away from Linux.

I don't agree with your claim, but I'm going to explain something else:
The GPL doesn't require software that *uses* GPL code to itself be GPL. It requires software that is *distributed* as part of a GPL work to itself be GPL. At time of distribution, a kernel module is neither using nor linked to the kernel.

Am Fri, 08 Feb 2008 03:20:26 +1030
schrieb David Newall <[email protected]>:

The license says that derivative work has to be GPL. Naturally, every sensible and practically usable license has gray areas. We know that and we live with that. But if there's room for interpretation, it's perfectly OK and helpful, if the copyright holder states what his interpretation is. If you use an EXPORT_SYMBOL_GPL symbol in non-GPL code, you know that the owner of the work doesn't agree with you license-wise. You had to cheat, e.g. by setting your MODULE_LICENCE to "GPL", and deliberately acted against the wishes of the copyright holder. Here in Germany, the GPL is enforceable, and such evidence will at least weaken your position. You won't get away with just saying you didn't know the copyright holder's position. Even printouts of some mails in this thread could be used to prove that you knew.
IANAL, there hasn't been such a case AFAIK, and you might well leave the court unharmed. But can you (or anyone else) be sure? That's what it's all about.

Yes it does. Chapter 2b requires any part that is derived from a GPL work to be GPL, too. As you well know.
Just to help you a bit: The only argument you could use is that a kernel module, even if it uses GPL'ed kernel code, is not a derivative work. You _might_ succeed with that interpretation, even before a German court, and even if it can be proven that you knew that the original author doesn't agree with you. Come on, try it!

Oh, come on! You cannot turn a derived work into an original work just by distributing them seperately.

Thanks,
Hans

How can an author form the opinion that another work is derivative, when it hasn't even necessarily been written yet?

EXPORT_SYMBOL_GPL is no statement of the author's beliefs. It's an algorithm of restriction, and it affects original, non-derivative works.

That's not what I said. From the start, I've made clear that I'm talking of original, non-derivative works. You said that mere linking makes that non-derivative work derivative:

This is wrong for the reasons I stated.

No, but the other way doesn't work either.

Lets say that I write a piece of code, a B-tree algorithm. If I take that piece of code and put it in the Linux kernel and distribute it as a statically linked binary kernel, then quite obviously the whole is a derived work of the original Linux kernel and my b-tree code. If I refuse to give the source code to my b-tree code [1] I have obviously violated the GPL. That is very clear and I don't think anyone disputes that.

What is more disputed is if my b-tree code is a derivative work of the kernel or not. In my opinion it is not, that b-tree code is my original work and I can ship it as a part of a proprietary product if I want to. If I distribute it as a .o file and somebody links it into the kernel, that is the end users decision, and the GPL explicitly says "Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted [...]".

But lets say that the b-tree code uses Linux-only primitives such as kmalloc or spinlocks, and that I wrote the code specifically for the Linux kernel, does that make it into a derivative work? kmalloc is only a function call, so I'd say that is too trivial to be copyrightable, APIs or just directories mapping names to numbers are not copyrightable. The spinlocks are a bit more troublesome since they are implemented as macros or inline functions so they do pull in some code from the header files. On the other hand, since they in a way form an API, and are the only way of interoperating with the kernel, they might not be copyrightable either. Then there's the question of fair use which might also make it possible to legally use those functions anyway, even if they are copyrightable.

What if I do a trivial replace of the kmalloc calls with malloc and the spinlock calls with pthread locks instead, has my code been forever tainted by being written for Linux so that I can't do that anymore? What if I go the other way and write my code using the posix functions to begin with and do the equally trivial replace of malloc with kmalloc?

So static linking vs dynamic linking really isn't the question. But linking something statically and distributing the resulting binary without providing source, that is a very blatant violation of the GPL,
so that is fairly easy to bring to court. As far as I know, the
question if using the kernel header files creates a derivative work or not has not been decided in court though, and until it has it is a bit of a gray zone. And even if it is decided in a court in Germany for example, that ruling might not apply in the states or in Australia. The Berne convention is supposed to harmonise the copyright laws all over the world, but there are still differences between countries.

Every time Harald Welte sues a company and that company settles by paying up, it strengthens the position that the GPL is valid, but since those settlements are made outside of court, no outsider can tell why they settled. Was it because the company had blatantly violated the GPL by refusing to give away source (a lot of WLAN routers made by Chinese companies seemed to fall into that category), was it because they were using GPLed source in their drivers (a lot of binary modem drivers was modified versions of the serial driver straight from the Linux kernel, an obvious violation), or was it because the court hinted that they would actually consider an original device driver written for Linux as a derivative work? Or was it just because the companies felt that the fight wasn't worth the time and money, and it's easier to settle than to spend a lot of money on a fight, especially since there's always a small risk that you can get hurt in a fight?

Patent trolls use the same tactics, they sue small companies and offer them settlements which are less risky than fighting it out in court, so most small companies settle. The trolls then use those settlements as "proof" that their claims are valid, and with the settlement money they take on bigger victims. Now, I do consider Welte's suits a wee bit [2] more valid than patent trolls, and I'm happy he has the energy to do that. But using his victories, which usually seem to be regarding very blatant GPL violations, as some kind of proof in the derivative-work-or-not debate, isn't really valid.

/Christer (rambling again)

[1] Or if I give the source code to the recipient and say "here's the source code, but you can't give it to someone else".

[2] That is an understatement, ok?

As the copyright owner, you're free to distribute the original parts as you wish as long as it doesn't contain anything that is derived work. So, when you remove those kmalloc/spin_lock calls, you're _obviously not_ tainted. But that doesn't mean you're free to distribute it when it _does_ contain derived work. Besides, a device driver can't even be compared to something as trivial as b-tree implementation that uses kmalloc/spin_lock in terms of "is it derived work or not."

Thanks for the straw man, though!

Ok good.

So it magically becomes a derived work if I do a:

#define malloc(n) kmalloc(n, 0)
#define pthread_mutex_lock(l) spin_lock(l)

at the beginning of the file? My guess is that it is much to trivial to be considered a creative expression and thus would not be covered by copyright. Meaning it would not be a derivative work.

A device driver isn't that hard either. I can write a device driver with a hand tied behind my back, to write a good balancing tree, I'd have to spend a lot more time reading up on algorithms. So "trivial" is a matter of background.

And once again, I don't believe API copyrights are valid, because in that case Wine would have been sued out of the water a long time ago.

*sigh* Now you're just being insulting.

/Christer

It doesn't matter how "hard" it was to write that code. What matters is whether your code requires enough copyrighted aspects of the original work to constitute as derived work. There's a huge difference between using kmalloc and spin_lock and writing a driver that is built on to of the full USB stack of Linux kernel, for example.

Hi Christer,

find an Intel engineer that worked on it. There is a bigger story behind it and I am not telling it.

And btw. it is perfectly fine that Intel is not giving full access to their radios. Why should they?

I heard this all before and I don't buy it anymore. At some point the companies in Asia will understand that the whole picture looks different and that not always cheap, cheap, cheap is best for their margins.

And btw. the fully supported Linux hardware is in a lot of cases not more expensive than the other ones.

You got one of the Greenphones ;)

I disagree here. They either play by the roles or they really do pay Microsoft or go with BSD. I really couldn't care less.

Regards

Marcel

The asian companies for the most part don't care about giving programming info away including for wireless. Why should they - even if the FCC pees on one of them they just set up another 8)

Alan

Again, I missed who wrote the above. I'm reminded of Apple computer, who explaining some engineering decisions in the Apple ][ pointed out that an additional 10c in components adds $10 to the retail price (or
something rather like that.) Cheap, cheap, cheap helps market share
far more than quality.

That depends on the market. Also the software cost is dominant not the hardware cost so saving 10c on licensing by not using Windows kind of wipes out any questions.

Alan

Software cost is fixed, whereas hardware is per-unit, so saving 10c in production at an expense of $1,000,000 in development can be an easy win.

I think it is perfectly within their rights to do so. I think it's kind of silly to try to hide it, if someone wants to boost the maximum transmit power, they're going to hack the firmware anyway. But if it makes Intel happy, well... :-)

I've been hoping that they will understand that too. So far it has been a futile hope. It is soo fun to write a design spec saying "Whatever you do, do not use this chip, it sucks. Yes, I know it is 50 cents cheaper than the competition, but it is not worth it." just too see exactly that chip being put into the product.

Mmm. I've actually put consulting on the shelf for a while and have become employed by CSR instead. They have a really nice, and as far as I've understood, fairly good and price competitive WIFI chip for low power systems such as mobile phones or PDAs. I've gotten a preliminary go ahead from the bosses to provide documentation under an NDA to Linux developers that would like to write GPL drivers for it. I just haven't had time to do anything more about it yet. And since I'm fairly new to CSR and are located at a remote office, it takes time to find the right people to talk to.

How could you guess? :-) Actually, I got three of them, and all of them lie unused in a box at work.

And the OpenMoko sucks. Or actually, it doesn't suck at all, I'm thinking of buying one just for fun, it's just that I like buttons on a phone, and really don't want a touch screen. So I like the OpenMoko project in every way, it's just not the right phone for me.

/Christer

Christer Weinigel ha scritto:

And break the HW :-) Actually, they could be happier, since then you have to buy another...

[...]

[...]
Urgh... I don't think NDAs and Open Source mix well... Are you sure your bosses KNOW Linux and the OS in general? :-)

BYtE,
Diego.

Developing GPL'ed Linux drivers with an NDA on the documentation has been done in hundreds of cases.

It's less nice than having free documentation but not a problem.

cu
Adrian

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Hi Diego,

talk to Greg KH about this. Have NDAs and open source work together is really simple. Have the NDA say that you can use all provided documentation to write an open source driver and publish it under GPL. A lot of companies are okay with this these days. The Linux Foundation should have NDA template texts for this.

Regards

Marcel

Then you should keep away from the kernel. The last thing that Linux needs is someone who doesn't care if Linux succeeds or fails. "I don't care" will lead to failure.

Hi David,

I actually care about Linux certainly more than you do. I care about the copyright of my kernel contributions and the contributions of others. Not caring about these things is what is the worst. It means you disrespect all the work that a lot of people and companies have put into Linux.

And don't quote we with "I don't care". Alan already complained about your quoting style. Don't put words in my mouth that I never said.

The Linux kernel is licensed under GPL. If you don't like, go and play with someone else. You can quote me on that one.

Regards

Marcel

This nicely expresses my position.

Christer Weinigel ha scritto:

ROFL! Well, since a lot of screwdriver types are easily available, I don't think a judge could agree with 'em...

Well, then why close the driver? Simply place the check in the firmware. Much harder to find, since it have to run on proprietary HW. The OS driver instead runs on standard (and usualli well-known) HW. Keeping the screws similitude, closing the driver is more like using a Torx, while placing checks in the FW is more like using a lock-only screw (already seen some)...

[...]

Well, we all agree on this... Now we just have to make THEM agree, too...

BYtE,
Diego.

"Of course", because in many parts of the world, a device who's manufacturer fails to take reasonable steps to prevent it from being used outside regulatory limits is illegal. Providing source code not only is a failure to take those reasonable steps, but is quite the opposite. It may even be viewed as encouraging users to use it inappropriately.

To my knowledge there is no caselaw on this for software, nor is it clearly so simple - many vendors do provide source, many vendors provide windows drivers where any end user can click to specify their country and can lie trivially. Many users retrofit US firmware to non US devices and its trivial to do. Its a hard problem - if I get on the train I can change regulatory domain and wireless regulations mid trip. I'm not even sure at what point the wireless rules are deemed to change between the UK and France either - there isn't any caselaw for that ;)

Some (particularly US) companies choose to take a conservative view based on their pessimistic reading of the intent of the US regulator plus the ability of the regulator to do a lot of damage to their business.

The notion they are illegal is a real unknown and the market seems split on views of this.

Alan

In Australia, devices require approval from a regulatory body. Such approval is withheld if appropriate safeguards are not applied.

Yes it is; but what is simple, is to understand that lack of such safeguards, even though they are imperfect, does result in refusal to approve.

Also, particularly Australia and New Zealand. I can't imagine France or Germany would be different. Where is it different?

That is what I was saying: To require that only GPL-licenced USB drivers may be used with Linux puts Linux at a disadvantage in the market. The embedded market is simply huge. Microsoft would _love_ Linux to fail there, because that's what's necessary for Wince to win.

We were talking about the USA. I am not aware of any Australian answers to the specific question of software as an appropriate safeguard. The US requires appropriate safeguards but no court has actually established an interpretation of them.

Diddums, thats what the license says. Requiring ac cinema pays the movie company puts a cinema at a disadvantage in the market from those who don't pay. That is why we have laws to try and ensure that crime is not profitable.

Alan

We most certainly were not. We are talking about Linux, and everybody wants it be used globally.

Probably the same in Australia, for the same reason as in USA. Probably the same in most countries.

That's what you claim it says, but has any court, anywhere, agreed with you? You claim the authority of others (i.e. numerous lawyers), but I don't believe you have that authority. You're just starting hearsay. You've never said what lawyers and you've never told us what they actually said.

I see that you have a clear political agenda, and I respect it in principle, but you're claiming that things are so in pursuit of that agenda when you don't *know* that they are. You don't need to stretch any truths to spread adoption of GPL, and doing so is not respectable.

I don't understand this, but I do understand that an essential question being considered is whether or not Linux can participate in a market that prohibits GPL drivers, whether explicitly, or more likely through pressure from regulatory bodies. Doing this would be a mistake. Probably a big one.

Don't telling people to switch to BSD, as some have done; they might do it. Where would Linux be if embedded devices used BSD instead? Don't think they can't. Don't think Linux has a technical advantage. Lose the embedded market, and that's where it would be felt first, and Linux volumes fall by what? 50%? 90%? Would you care if servers followed?

That would be improper as you'd well know if you knew the first thing about the subject.

Why don't you just say "you are a liar" as I assume that is what you want to say. Then I have to read less words before I find you funny.

Linux is GPL licencesed code you either follow the licence or don't use it. It's very simple.

I don't actually care. If you want to do binary products then pick a product you have the right to do that with.

The market will ultimately decide which models of software development are the right ones for which situation.

Alan

It would not be improper to say that "such and such a lawyer said this and that." I'm not proposing that you breach their copyright in their opinions, but there is such a thing as fair use, and I expect you to use it or stop bringing it up. Anything less than that starts to sound odd.

Various reasons. I don't know that you're a liar and I'm too much the gentleman to accuse you of that without being quite sure of my facts. As it happens I assume you're not lying, but I do suspect you of having misrepresented what was said to you. I don't say you've done this out of malice; it's possible you've read things into opinions given to you that weren't meant; or even inaccurately remembered what was said. Mostly, I think what I've already said: In other words, I think you've put a spin on the opinions in pursuit of your own agenda. You've already watered down your claims, being that you now say, "bad idea".

Okay, that I understand. That is simple. But it's irrelevant to the topic under discussion, which is to seek to restrict access to modules based on their specific licence conditions. The GPL makes no such restriction, and it is improper and legally meaningless, from a licence point of view, to claim that EXPORT_SYMBOL_GPL forms a condition of licence. It doesn't. (There may be DMCA considerations, but I hope that everyone from Stallman to Torvalds would hasten to disclaim them.)

Please don't refer to me in this way. Say, rather, "if someone wants to do binary products." Putting that aside, Linux is such a product. There is nothing in the GPL that suggests it may not be used with proprietary products, and much to say that it may.

Presumably you mean "product," and not "model of software development," since later in no way relates to the topic. The market will ultimately decide which product is right. It would be a great shame if Linux dwindled. There's no shortage of fully open source operating systems, but the one enjoying success which requires source to be distributed with (hardware) product is Linux. I don't want that to change. I make purchasing decisions for clients based on availability of source. BSD isn't useful. Annex used BSD (there was no GPL) and their product was poorer for it. I don't particularly like binary drivers, but I like binary-only operating systems even less.

There's no need to play brinksmanship with manufacturers. Please don't take Linux away from my router, and my modem, and my access point, and my telephone, and my printer.

It would be highly improper given these were business discussions involving companies using Linux.

Then you should never have brought it up. Since you never really said what any lawyer told you, let's just forget that you did bring it up.

I thought you would care that lawyers had discussed the matter. But no you simply want to waste the lists time until everyone else gives up on you and you can say you "won". I hope it makes you very happy, welcome to my killfile.

Alan

I care, but I have no way of knowing what was advised. I bet you a dollar they never said that all kernel modules are derivative. You haven't said that they did, but the entire argument supporting, let me call it "pro-EXPORT_SYMBOL_GPL", is based on the concept that they did.

Why would that bother me? You said it before, anyway. It was childish then, and is childish now.

David Newall ha scritto:

If the device is well engineered, there's nothing the sw can do to make it work outside regulatory limits.
Sometimes there's simply NOTHING the SW can do to *avoid* it. Think about a CB radio. International standard is 5W (well, somewhere it's 3, IIRC, but that's another story: nobody produces a special model with a final amplifier for only 3W, everyone produces the 5W and turns down power in some other way). But linear amplifiers are commonly sold. And (at least in Italy) it's not illegal to buy one, even if it can boost antenna power to 1000W. It's illegal just to USE it. If a citizen of a country where only 3W are allowed opens his CB and removes the limiter, it makes the use of THAT CB illegal, not the use of that MODEL: untampered ones are still legal!

And it's a logical problem, too: why should the *driver* enforce a *technical* limit? It's up to the device. If the driver tells my WiFi device to use 10W, should it fail? I think so! IMO there's no judge that can rule out that an open source driver is encouraging users to use a device over its regulatory limits: there are easier ways (like lying about the configured country, to get more channels or more power) than hacking a driver. Else it should be ruled "reasonable" having to sell different drivers in different countries (no user-selectable country to choose, no lying possible... as long as the user doesn't download an updated driver...).

The key is "reasonable". IMVHO enforcing a limit with a driver is not a "reasonable step to prevent use outside regulatory limits". There are more effective ways to enforce those limits that costs about the same.

BYtE,
Diego.

That's naive, since requirements differ in different jurisdictions, as I'm sure you are perfectly aware.

Precisely: One purpose of the driver is to enforce local compliance.

In Australia it's illegal to own them (CB licensee; HAMs are allowed to use them, although not on 27Mhz.)

That's part of it's purpose. It permits a manufacturer to make a global device that operates within local restrictions.

David Newall ha scritto:

Naive? Who thinks a limit can be enforced by sw is naive! He's missing a little detail: Internet. :-)

It can't *enforce* it anyway, at least if the users are all around the world. At most it can *suggest*. Then it's up to the user to make sure to meet the local laws.

Then Australian shops can ask for the licence. And what about online shops? Ebay? They'll send you an unmarked package (same as letting you download another country's driver). The result is that you can have your LA more easyly than going to a local shop or tampering with your CB (or tampering whith the local version of the driver).

Nope. The driver should simply make the device WORK. The USER must make sure to meet the local regulations. The driver can help, but as long as it asks the user a country setting, its enforcement is nearly nothing! The simpler way for the user to trick it into using illegal settings is simply to lie! It's like if your LA had a switch on it, allowing you to select the country.
Another example. Think about what happens if you're right: the user gets caught with a WiFi card operating on an illegal channel, but the system appears correctly configured (location-wise). When analyzed, it turns out that, due to a bug in the driver, the card uses that channel (for example 13) because the user only changed the country setting when flying back from Japan (where he used channel 13) and channel limiter didn't kick in. Is the manufacturer responsible? If you're right, he is and must pay, remove that device from shops and replace sold ones. Or at least make sure all users update their drivers with others without that bug...
A real can of worms...

BYtE,
Diego.

Of course. Naturally it's near impossible to prevent people from tweaking the software. But reasonable restrictions are what regulatory bodies expect.

Yes it can. You're confusing the software with different or modified
software. Different things. And by the way, if you modify the software to defeat the restrictions you are committing a criminal act, or you would be if you did it in Australia. You'd probably get with crucifixion for a first offense!

What's your point? That it's easy to break the law? Nobody's arguing against that.

Definitely no. The manufacturer must ensure it meets local regulations. One way they do that is via the driver.

You're correct, but that's still how it is. In fact, some manufacturers provide country specific drivers simply to shore up this weakness. (They'd only do that to protect their regulatory approval.)

Are you asking if the manufacturer could lose their licence to sell the product? It could happen. Regulators do wield significant powers.

That's the most likely result. That would be what I expect would happen. This is why manufacturers view open source licences dimly in certain markets, of which radio communications is just one example.

David Newall ha scritto:

You said it! Gotcha! :-)
There's no difference if what I'm going to modify is the binary or the source: it's a criminal act anyway. So why not release the source? :-)

ROFLASTC :-)

I was simply implying there are easier ways than others... And binary drivers can't help...

Well, the driver must trust the user, that's my point.
If the user lies, the driver can't know (well, it could, but I don't think it could be considered "reasonable"...).

Allowing the lying user to download a driver for another country...

And it's a reason to release open drivers, so that everybody can check there's no such bug. And, if found, it can be fixed with a lot less effort.

BTW I've now asked a lawyer... Waiting his answer.

BYtE,
Diego.

Then the hardware vendor needs to review there practices. If you want to limit the ability of your technology do not include it. I realize that this has become large revenue stream for many company's. What they do not realize is that they have created a Wack-a-Mole situation. Just look at the Digital Satellite TV industry.

Companies used to Produce one logic board and selectively remove certain resistors or ic's to limit the end users ability. The end user could still solder the missing chips etc to by pass but much more difficult. Way I see it is let the companies does as they please as they will bury themselves in the long run.

Now we have hardware ASIC that depend on the most part a (dll in windows) or .ko .o file under linux to provide the entire instruction set. Think Winmodems, Winprinters etc....

Lee Mathers ha scritto:

Well, winmodem case is the only I could *almost* understand closed-source drivers: the algorithms used *are* the modem. It's not a simple firmware upload.
What I really don't understand are graphic cards producers... If what they say about the card is true, then there's no "advanced" algorithm in the driver, just (at most) a firmware uploader (that's better suited off-kernel anyway)...

Bohf!

BYtE,
Diego.

Winmodem is all about patents, the modem standards come from ISO so are created by all out corporate warfare with the winner getting the patent money. Its why we had X2 v 56K, its why they took so long to get anything done 8)

Graphics interfaces can be very clever and critical to performance. 3Dfx for example had some very clever register layout tricks to get PCI bursting of commands.

Personally I wish someone would just get around to putting the basic rasterising ops (including texture scaling/mapping to 2D plane) into the CPU. It would be more useful than half of MMX to have a "load texturepointer, load step and angle, rep textureop" sequence in the CPU

Alan

On Mon, 2008-02-04 at 01:37 +1030, David Newall wrote:
[...]

Are you sure that that is not only (the results of) propaganda of (certain) proprietary companies?

Usually the *user* (at home, wherever) sets "illegal" values. So it's the users responsibility and the manufacturer, importer or sellers don't care (if only that can't prevent other "illegal" actions like "beating some to death with $WLAN_ROUTER").

Or do you get a gun manufacturer before court just because someone committed a crime with a its gun?
Feel free to use other comparisons like "knifes" or "cars" if you need more harmless examples ....

Bernd

Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

well, yes.

Or, as is the case perhaps almost everywhere, governments prohibit devices that can operate outside of local requirements.

Let's not confuse the issue.

BTW the (trivial?) solution for the hardware manufacturer: People must use/download some signed binary blurb which actually configures the limits of the configurable values.

There are rumors/stories that even the FCC in .us doesn't go after producers/vendors/sellers of devices which may be operated beyond governmental requirements. With exactly my comparison BTW. Does the FCC forbid the *operating* or the *distribution*?

At least in .at it is not forbidden to import and/or sell devices which *can* be operated outside some local law requirements. If *you* configure it wrong, *you* have violated the law/rules and it is thus in *your* responsibility.

The first reason is that there are European Union laws which basically override the local Austrian laws - but we can ignore that as it is a European Union thing.

One (non-technical) reason is that even those requirements change over time.

Another reason is that e.g. setting the transmit power on some common WLAN devices to the minimal possible values (which the hardware allows) doesn't imply staying within legal bounds: I can have a (common of the shelf!) high-quality antenna and not-so-bad cabling and than I'm beyond the officially allowed maximum transmit power.

A third (non-technical) reason is that I (as a pure private person/organization) may have some explicit governmental exception of the governmental limits (for whatever reason).

I concur that there might be governments which forbid importing/selling/distributing devices where legal usage is absolutely not possible.
But historically at least in .at, these devices were simply marked "for export only". "Problem" solved.

It's IMHO precisely the issue (at least with my understanding of law stuff): Which action is illegal and who is responsible for it.

Bernd

Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

David Newall wrote on 03-02-08 16:07:

Please keep me out of this.

I did not write any driver, imaginary or otherwise. Nor am I fictitious.
Truely yours,

bjd

By the way, I'm almost certain that the COPYING file is the first, last and only document specifying licence conditions, and nothing in that prevents a proprietary driver from including a patch that, for example, globally replaces ALL GPL-only symbols by the less restrictive ones. In fact, you'd be in a bit of strife down under if you tried to say otherwise. We've got quite strong consumer protection laws down here. You're just not allowed to claim additional licence conditions based on source code commentary.

It's just games and hot air, isn't it?

Hi David,

So I am going to assume you're not trolling here (although some of your snarky remarks make that bit hard).

A vendor is, of course, allowed to distribute a patch (under the GPLv2 proper) that removes the license checks no doubt‚ but it doesn't change the fact whether the actual driver they're distributing (under a proprietary license) is derived work or not (one way or another). And, _if_ you're distributing a derived work that is not under the GPLv2, you're breaking the law. I think we can agree on this?

As there is some controversy over the definition of derived work (think Linus' comments on porting a driver or a filesystem from another operating system here), we use the EXPORT_SYMBOL_GPL annotations as a big warning sign that what you're doing is likely to be considered as a derived work. If the USB developers want to annotate their code with EXPORT_SYMBOL_GPL, why the hell do you want to argue about it? They know the code better than you and as copyright holders they can actually sue those parties distributing proprietary code they think is derived work.

Bringing up Linux world domination or Microsoft market share in these kind of discussion is totally pointless. The license is what it is (GPLv2) and it seems unlikely to change at this point. If you want to develop for Linux, you're most certainly better off always distributing your code under the GPLv2; otherwise you really really want to consult an IP lawyer to be sure. But what I don't understand is why people insist using the Linux kernel for something it clearly can never really properly support (proprietary code)?

Thanks. I'm not trolling. Perhaps I was a bit snarky; it's an issue I feel strongly about. (I'm sure others feel just as strongly, but differently.)

Agreed.

Let's consider a totally original USB driver. There are an infinite number of them, some still to be written.

Have I the wrong end of the stick? Isn't that mark restricting an
interface to GPL _callers_? Isn't it a technical switch that means,
"Don't use my software if yours isn't (also) GPL"? As such it's mere political rhetoric, devoid of any binding power.

I agree; but let's not disadvantage applications where regulatory requirements prohibit GPL code, nor applications where the proprietor simply chooses to keep the work proprietary. A proprietary module is simply a piece of software. Many people couldn't use Linux if they couldn't run proprietary software on it.

That's defeatist. Of course the Linux kernel can properly support ("run") proprietary code. It would be a miserable excuse for an operating system if it couldn't.

Hi David,

I think you're missing my point: as long as the license stays the way it is now, you can never distribute proprietary code unless you've consulted a lawyer and even then you run the risk of being sued for infringement if the copyright holder thinks what you have is derived work. The GPLv2 and thus Linux was never designed to allow proprietary code and arguing that is pointless, isn't it? There are much better alternatives available and people interested in proprietary code should be looking there.

Pekka

Yes I can, if the proprietary code is not linked with GPL code (and the proprietary code is original). Loadable modules are not linked. This is a very clear-cut case.

Hi David,

that is not clear-cut case. You link at run-time. Otherwise the module would do nothing.

Regards

Marcel

That's why it's allowed. The module isn't linked when it's distributed, and the author doesn't do or cause the linking; the user does. And the user never distributes in the linked state. Distribution is key to GPL.

Hi David,

so how do you build this module that is not linked without using the Linux kernel. Hence derivative work. Hence dynamic linking at runtime of binary only code is violating the GPL.

Same goes for dynamic linking at runtime against GPL libraries. Nobody thinks that is possible and ships binary applications that link against GPL libaries. So why do you think you can distribute a binary only kernel module.

Regards

Marcel

You could hand code in assembler, using Microsoft's assembler under Windows. You could compile from C, using GCC on FreeBSD. But that's immaterial. A module which is an original, non-derivative work, is, well, original and non-derivative. Do you say that it must be otherwise? Why would that be?

Hi David,

since when does the language make any difference.

Anyway you are still under the impression that a Linux kernel module can be original work in the end. We keep telling you that could be a wrong assumption which is based on the view of many of the kernel developers and of most of the lawyers that looked at this specific topic.

Let me repeat this. Ask a legal counsel before you go ahead with your assumption. You might get away with it or you might not. What Greg, Alan and I try to tell you is that using EXPORT_SYMBOL or EXPORT_SYMBOL_GPL will create derivative work, but if you don't wanna believe us, that is your prerogative. So go ahead, but don't complain if you actually get sued for copyright infringement at some point and tell the court you didn't know.

And while you are talking to a lawyer. Ask him/her if it is okay to create a binary only application that uses a GPL library. Tell him/her that it is original work. Good luck :)

Regards

Marcel

Yes, I am of that view. I accept that I could be wrong, but that also means that I could be right. We agree, so far. The important point is that I could be right. What will be done when somebody brings forth such an work? Will the restriction in EXPORT_SYMBOL_GPL be removed, or will the driver be unfairly restricted from using those other modules? You did agree I could be right, so positing such a driver, what happens? (I predict nothing; the driver is unfairly restricted.)

Now, Alexander Terekhov has forwarded some links to me, relating to the question of whether or not a Linux kernel module can be original. Bear in mind that these links relate to U.S. Copyright Law.

In http://digital-law-online.info/lpdi1.0/treatise27.html, Professor Lee A Hollaar discusses derivative work and linking with libraries. He says:

Some have claimed that an application program that needs a library for its operation is a derivative work of that library. They take that position because the application program is "based on" the library because it was written to use the subroutines and other aspects of the library.

Such a position is misplaced. Even though the definition of a derivative work contained in Section 101 seems to support such a reading when it talks about a derivative work’s being "based upon one or more preexisting works," the examples all illustrate derivative works where the original work is somehow incorporated or recast in the derivative work:

A "derivative work" is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a "derivative work". {FN109: 17 U.S.C. §101
<http://www4.law.cornell.edu/uscode/17/101.html>}

This need to use a portion of the original work in the derivative work is stated in the legislative history of the Copyright Act of 1976, where the drafters discussed when the derivative work exclusive right is infringed:

To be an infringement the "derivative work" must be "based upon the copyrighted work," and the definition in section 101 refers to "a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted." Thus, to constitute a violation of section 106(2), the infringing work must incorporate a portion of the copyrighted work in some form;

Let me say it: A work that incorporates no portion of a copyrighted work is not derivative. He goes on to say:

It could be argued that the component program really does include portions of the library that it uses – data structures that are passed as parameters, or even the parameter lists themselves. But elements dictated by external considerations are filtered out when trying to determine whether there is copyright infringement.

Elsewhere he says, by implication, that "elements like the overall program structure or architecture and data structures that are ... dictated by external or efficiency considerations" are not "protected by the original program’s copyright".

He finishes this part of his treatise by saying:

No other conclusion makes sense. If it were not the case, then any program using the applications program interfaces (APIs) of an operating system could be considered a derivative work of that operating system.

Another germane reference provided by Alexander

A lengthy article by Prof. Dr. Lothar Determann can be found at
http://www.usfca.edu/law/determann/softwarecombinations060403.pdf
(DANGEROUS LIAISONS – SOFTWARE COMBINATIONS AS DERIVATIVE WORKS?). In the abstract, Prof. Dr. Determann writes:

The article concludes that most forms of software combinations are less dangerous than commonly assumed, because they do not constitute derivative works (but instead either compilations or sui generis aggregations outside the scope of the copyright owner’s exclusive rights), and a number of statutes and legal doctrines significantly limit a copyright owner’s ability to contractually prohibit software combinations that do not also constitute derivative works under copyright law.

In the Introduction he says:

[C]ourts and commentators have not yet developed general rules for the qualification of software combinations as derivative works, and the place and role of derivative works within the statutory context of compilations, collective works and other types of aggregations does not seem to have been examined in depth yet with respect to software combinations.

be derivative is wrong. The courts haven't given us direction yet, so nobody knows for sure. He goes on to explain a bit about what it is to be a new and non-derivative work:

If the creator of a new work takes very little of an existing work or takes only non-protectable content (e.g., ideas, facts) or changes so much that the new work does not bear a close resemblance to the existing work, the new creation is simply a new work of authorship––and not a derivative of the existing work. After all, most new works are influenced to some extent by existing works.

He repeats this:

[A] new (non-derivative) work[:] (if only very little of or non-protectable elements of the existing materials are present in the new work or if the new work does not bear a substantial resemblance to the existing work)

He goes on to discuss the Copyright Act, and quotes from it:

In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.

This defeats a claim that all kernel modules are derivative by virtue of XXX.

Prof. Dr. Determann directly address the GPL. Others have suggested, in the course of this discussion, that a Linux kernel module is intended to be used with Linux and that that brings them into the scope of the GPL. Prof. Dr. Determann says this:

It is worth noting, however, that the GPL generally permits end users to execute GPLed code in any combination they want. According to Section 0 of the GPL, "[t]he act of running the Program is not restricted." As a result, software companies do not have to be concerned about invoking the "viral" effect of the GPL based on a contributory liability theory if they distribute their add-on programs separately, i.e., not in context with any GPLed code, even if the add-on programs are intended for combination with a particular version of GPLed code. End users who run add-on programs with the GPLed code would not infringe, because the GPL allows execution without any restrictions.

He also addresses the question of dynamic linking:

Consequently, dynamic linking to GPLed programs would not normally trigger the application of the GPL to the linking program, even if both programs are distributed together.

He concludes:

Software combinations are less dangerous liaisons as some have recently argued, particularly in the context of the GPL.

Under the U.S. Copyright Act, a combination of a computer program with other software results in the preparation of a derivative work only if the combination (a) is sufficiently permanent, (b) contains significant and creative portions of the other software, (c) is creative in its own right, and (d) involves significant and creative internal changes to the other software. Most software combinations fail to meet one or more of these requirements and constitute either compilations, collective works, or non-copyrightable aggregations, and neither affect copyright owners’ adaptation rights under Section 106 of the U.S. Copyright Act.

Now, Alan has made a big issue over numerous legal opinions he has received, but he's been completely coy in the details. He has been spreading hearsay. I have presented quite definite opinions from learned and respected practitioners. He has presented nothing. It does rather seem that he is quite wrong, and his recent huffiness, including the emotive "liar" confrontation, nicely shows the balance between the two arguments.

The reasonable conclusion is that an original, non-derivative USB driver can be written, and let's face it, a number of them have been referred to in the course of this discussion.

USB drivers must NOT be restricted to GPL-licence only; that would damage Linux.

My thanks go to Alexander Terekhov for providing some very informative links.

Where does this come from? It's right out of left field. Since I've never suggested such a thing, could you please do me the courtesy of retracting the suggestion that I have?

I explained something poorly:

The point I wanted to make is that a few people have said that lawyers say that kernel modules are derivative, but I only remember Alan saying that he had actually spoken with the lawyers. Therefore I infer that this somewhat widely held opinion originates from him. My point was to those people who have been taking him at his word, and was to point out that there are more reliable and transparent sources. Don't take his word on it. Take the words of real experts in the law, because instead of a mere four word conclusion, they explain everything.

My, I am full of post scripts today. This one is a peace token for Alan.

I do realise that my later postings come across harshly for Alan, and that they might seem to be attacking him. Of course, he did set himself up for that with his own snide and personal attacks on me. However, I took no offense and likewise intended none. I have not intended anything personally. I'm sure he's a jolly reliable bloke, and I can see he's a hard worker for, and advocate of, Linux, and that he's enormously respected. Nobody is right all the time and this, I believe, is a case where he is wrong. I hope nobody is upset that I pointed it out. I also hope that the ideas behind EXPORT_SYMBOL_GPL might be reconsidered.

The one technically inclined lawyer that I asked about this said that the Lexmark decision meant that code using an API did not mean the work was a derivative of the API. However, in the case of the Linux Kernel, the code is meant to function inside a much larger framework and the API available to modules includes large amounts of "boilerplate code" buried behind handy chunks of code like "list_for_each".

The problem, he said, was that, in the US, such code is included in the module in a mechanical and wholly automated process. Which means that the module doesn't automatically inherit the GPL license. But, he cautioned me, this does not mean that a court couldn't (and/or wouldn't) rule that a module written specifically for Linux is a derivative of the kernel.

He also cautioned that, although the Bern Convention broadly controlled international copyright laws, specific countries do seem to have laws that cover the "kernel module" situation much better than the US laws and that those laws do apparently make a module a derivative of the kernel.

His overall statement on it was that, in his opinion, whether a given module is a derivative or not would depend on the amount of "original" work contained in it compared to the number of places where linux specific code is used. He also stated that, while disagreeing with the idea that parts of an API could be "so deeply embedded that using them creates a derivative work", it would be a good idea to always pay attention to the beliefs of the developers of the code, because it is their opinion that will start the legal problems.

In other words "EXPORT_SYMBOL_GPL" isn't his idea of "a good legal idea", but people ignoring this and doing things that circumvent this will, eventually, have problems with the people who hold the copyright on the code. (In addition, he stated that circumventing the "EXPORT_SYMBOL_GPL" bit might also be in violation of the DMCA, but he isn't sure if a court would see it in the same light as someone cracking the CSS key on a DVD expressly for the purpose of creating pirated copies)

DRH

Dialup is like pissing through a pipette. Slow and excruciatingly painful.

There was a good analysis of that argument on the list some time ago. I think the conclusion was fairly definitively no as the GPL explicitly gives the right to modify GPL code. You are therefore aready "authorised" to make such a change.

It might have a significance in terms of intent but thats for lawyers to argue over.

Alan

I think that's why he said he "Wasn't Sure" - as was pointed out in another post, the Lexmark ruling appears to apply for more than the "interface" portion of the ruling.

And Alan, while it might be legal to make the changes, making them for the sole purpose of using them in a proprietary module - when the people who actually hold the copyright have said "I think this is so core to the kernel that anything using it is a derivative work" - is what he thought *MIGHT* be legally actionable under the DMCA.

DRH

Dialup is like pissing through a pipette. Slow and excruciatingly painful.

A "driver" is not an "application" as you tried to reference in your prior quotes. It is a tiny portion of the whole kernel, and as such, does fall under the derivative works portion when it is run within the Linux kernel.

So the comparison is quite different, sorry.

Again, see the Samba decisions that have happened in the past when companies have tried to add modules to it that are not under the GPL. They have failed every single time, so there is a lot of precedent for this kind of thing.

And again, this is not just my opinion. It is the legal opinion my lawyers and the lawyers of many large companies who deal with Linux every day.

If you wish to disagree with this, fine. Consult with your own lawyer and make up your own mind.

lkml and linux-usb is not for legal discussions, that's like asking lawyers for medical advice, you might get some good opinions, but then again, you can get a lot of crackpot ideas.

This is going to be my last response on this thread,

greg k-h

I think your treating what the learned Professors said to literally.

The Copyright Act draws no such a distinction.

Section 0 of GPL: The act of running the Program is not restricted.

I'd like to, but I've searched and searched and can't find them. Some pointers, maybe a search term, would be useful.

Good idea. I've spent too much time on this already, so I think I'll join you.

Hi David,

whatever you feel you get away with, but hey I am not a lawyer and my reading is that any kernel module is derivative work and thus has to be placed under GPL. Feel free to disagree with me. If you think you can convince me, than you are under the wrong impression. Since even if (and this is a big if) I am wrong, my action won't lead to a copyright violation. Yours however would if you are wrong. So pick your battle.

Not writing and publishing GPL drivers damages Linux. Nothing else.

Lets phrase this in better words as Valdis pointed out: You can't distribute an application (binary or source form) under anything else than GPL if it uses a GPL library. It makes no difference if you distribute the GPL library with it or not.

But hey (again), feel free to disagree with me here.

Regards

Marcel

This simply cannot be correct. The only way it could be true is if the work was a derivative work of a GPL'd work. There is no other way it could become subject to the GPL.

So this argument reduces to -- any work that uses a library is a derivative work of that library. But this is clearly wrong. For work X to be a derivative work of work Y, it must contain substantial protected expression from work Y, but an application need not have any expression from the libraries it uses.

If you do not distribute the GPL library, the library is simply being used in the intended, ordinary way. You do not need to agree to, nor can you violate, the GPL simply by using a work in its ordinary intended way.

If the application contains insufficient copyrightable expression from the library to be considered a derivative work (and purely functional things do not count), then it cannot be a derivative work. The library is not being copied or distributed. So how can its copyright be infringed?

This argument has no basis in law or common sense. It's completely off-the-wall.

And to Pekka Enberg:

The legal standard is not whether it "requires" copyrighted aspects but whether it *contains* them. The driver does not contain the USB stack. The aspects of the USB stack that the driver must contain are purely functional -- its API.

You simply can't have it both ways. If the driver must contain X in order to do its job, then X is functional and cannot make the driver a derivative work. You cannot protect, by copyright, every way to accomplish a particular function. Copyright only protects creative choices among millions of (at least arguably) equally good choices.

DS

Hi David,

go ahead and create an application that uses a GPL only library. Then ask a lawyer if it is okay to distribute your application in binary only form without making the source code available (according to the GPL).

http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfLibraryIsGPL

http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingWithGPL

Regards

Marcel

On Saturday 09 February 2008 23:50:17 Marcel Holtmann wrote:
<snip>

In the US, at least, the belief that "Linking", in *ANY* form, with a GPL library creates a derivative work, is fallacious. Were I to create an application that uses, say, GTK for the interface the protected expression is my "unique and creative" use of the GTK API for creating the specific interface and any other code I have written using the API. I hold sole license to the copyright on that code and am able to license said code under the specific license of my choice.

Why? Because the pre-processor is what is including any GPL'd code in my application and expanding any macros. That is a purely mechanical process and hence the output is not able to be separately copyrighted - if it could be, then the copyright would be held by the *COMPILER*, and I am *NOT* bound by the license on that code. The same applies if GPL'd code is included in my application during the linking process. QED: The "Linking" argument used by most people is wholly fallacious in at least one major country - and if I'm not mistaken, the output from an automated process is similarly not considered as carrying a separate copyright in all nations that are signatories of or follow the Bern Convention.

(And yes, this also applies to some GPL'd tools that RMS extended "GPL Exemptions" to - such as "Bison". There is, generally, no need for such an exemption, because the process by which the GPL'd code is included in the final binary is wholly mechanical.)

DRH
PS: The above information is a very condensed form of the result of several past conversations on this list about copyright law and the GPL as well as my own, private discussions with lawyers. I'm being lazy here and not searching various archives of LKML to give pointers to the past discussions.

Dialup is like pissing through a pipette. Slow and excruciatingly painful.

Hi Daniel,

that is how FSF states it and it seems that most legal departments of big companies (US and EU based) are not taking any risk on this. So it seems that someone actually has to prove in court that these assumptions for the GPL case are wrong.

Not even getting into this one since GTK+ is a LGPL based library. Get your examples straight.

The GPL is a license. Nobody is talking about the copyright of your code here. You always have the copyright on your code. The point is that you have to license your code under GPL (when using a GPL library) and you are distributing your code.

Regards

Marcel

The FSF is making a claim that can be traced back to the beliefs of one person - RMS - and that propagate their views. As I stated in the original, this is not just my opinion, but that of two different lawyers I've spoken to and also the stated belief of numerous people on LKML.

The fact is that the GPL only affects a "derivative work" in a viral manner. Merely using a GPL'd libraries API is not enough to make a program a "derivative work".

And the LGPL was created because of the FSF propagated belief that using a GPL'd library means your application is automatically a "derivative work" and hence must be released under the GPL. So the LGPL was created with the "automatic" 'linking' exemption. It is not necessary and never has been.

This is why, even if the FSF claims what I've said above (that linking code with the GPL doesn't propagate the GPL into the non-GPL code) most companies won't risk it... Because the FSF has taken actions that are the exact opposite of their words.

Yes, It is "my" code and "my" copyright. However, by the absolutely *common* belief that "linking to GPL libraries makes a program a derivative work" it would mean that I no longer have the freedom to license my code under the license of my choosing, because the *mechanical* process of linking has caused the GPL's "viral" clause to spread to cover my code.

And you're absolutely wrong. It doesn't matter that the library is GPL'd at all. My code *cannot*, under any circumstances, be affected by the GPL license on the library. Because the libraries API *cannot* be copyrighted and any GPL'd code which winds up in the final binary got there via a "mechanical process" and doesn't affect my right to release the code under a license of my choosing.

Any other belief is fallacious. Claiming otherwise would mean that any program that uses any library on a windows system makes an application a derivative work of that library.

DRH
PS: I'm going to shut up again, because I've been party in my fill of these copyright/derivative work discussions (on both sides) and have had the problems with the "FSF Line" repeatedly pointed out to me.

Dialup is like pissing through a pipette. Slow and excruciatingly painful.

And its not pirating Windows because Norton Ghost put Microsoft copyright material in your hard disk either - thats a mechanical process too. Right
- no. Nor can the gcc compiler hold the copyright as you suggest as it is not a legal person.

The compiler might perform a process which combines your creative work with another and thus creates a derivative work. It might do that with libgcc. In many cases the FSF is being careful when it makes sure specific things don't happen just as Linus did with the kernel. Sometimes it is best to make sure no judge got a bit carried away and instead to create certainty in advance.

If you really think what you claim then I'll #include your entire work, flog it binary only and assure you it can't be derivative as you said so. That's entirely mechanical - in fact I can clain a defence of 'estoppel' given your previous statement, so you probably wouldn't be able to sue me for it even if it was otherwise a violation.

There is btw lots of possibly useful caselaw in the area of books. People have spent time litigating and thus established some clearer answers to questions like whether you need copyright owners permission for

- Two books in the same box
- Two books in the same cover
- A book that quotes another
- A book that uses the characters of another
- A book which is a sequel/prequel to another
- One book inserted sectionally into another

Similarly in music questions about

- Compilations
- Remixes
- Sampling
- Setting to film
- Covers

have all been somewhat heavily litigated as you might expect from that industry.

It would not be reasonable to expect caselaw in these areas to drive caselaw in software.

Alan

It takes someone telling the program to do it. The act of instructing the program is the actual "criminal" act. This is a 'Straw Man'. Next ?

Yes, of course, and I'll never argue otherwise. However, what I was saying is that it is the claim of the FSF that, in no uncertain terms, a C program that uses the standard C library interface and is linked to glibc instead of, say, the old Borland libc, is automatically GPL because it's been linked to GPL code.

And in the case of the "Bison Exception", lets think of it this way... A company writes a configuration file parser and is selling the software to other companies for use on their Solaris and SysV machines. The board decides to sell the software for linux and the employee in charge of the linux build uses the standard GNU tools for the entire process, including Bison. Even without the exception it wouldn't make the program a derivative of Bison or even come close to putting the code under the GPL.

Straw man. Again.

But... You'd have fallen afoul of the "intent". Action follows intent, and so does the law. (At least in the US)

And I've actually read almost all the court cases that have a bearing on this. (I don't step into a discussion unprepared)

If the process of linking could create a derivative work, the *EVERY* program that runs on *ANY* OS would be a derivative of that OS, because the program is linked to the OS at run-time.

DRH
PS: It is time for me to shut up now. I'm sick (bronchitis) and when sick, I tend to get very combative and come off like a troll.

Dialup is like pissing through a pipette. Slow and excruciatingly painful.

glibc is LGPL and will not force you to use GPL.

What happens if I ship a binary-only program that uses *either* a GPL library or a custom library with the same API? "If you don't have the Frobozz-Foo library, you'll have to supply your own work-alike"....

(Note that this is in fact the *usual* case - very few programs actually check that they are linking against a Genuine GPL(tm) library, they just want the *API*, so providing a work-alike is sufficient....)

It depends whether it is a derived work. It doesn't matter if you paint it green, hang from trees while writing it or recompile it backwards while chanting - the legal boundary is the one from copyright law and that is where you must look for precedent and answers whether from prior computing cases or from equivalents in other areas.

Alan

Mercy, no, with friends like Alexander you don't need any enemies...

He's been fighting windmills for ages. I wouldn't trust his legal opinion at all. He might have some some points, sometimes, but it gets totally lost in all the noise that he produces.

/Christer

It's perfectly legal to create such an application.

It only gets interesting if you *distribute* it...

(And yes, this is where you *have* to be pedantic about the wording used)...

Hi Valdis,

true, true and true. However I was under the impression we passed that discussion point, that you can do whatever inside your own walls :)

Regards

Marcel

Hi David,

if a new drivers is originally written for Linux, then you are breaking the GPL. There is no other way to name this. Using EXPORT_SYMBOL or EXPORT_SYMBOL_GPL make no difference here. You driver was meant to be running as Linux kernel module and thus it is derivative work. While there is a gray area, but this case has always been pretty clear.

What are you arguing here. It makes no difference if it is technical or not. The EXPORT_SYMBOL_GPL gives you a clear hint that when using this symbol, you have to obey to the GPL. Even the EXPORT_SYMBOL is protected by the same GPL license. And thus both has the same binding power to be used from GPL modules only.

At this point I would strongly advise to talk to lawyer since you are obvious missing the point here.

First of all we are talking about kernel modules here. Not the userspace. So stop this FUD.

In userspace, yes, the kernel would "run" proprietary code fully legally without any problem. As a kernel module, the only safe answer is no. And in case of EXPORT_SYMBOL_GPL, it is pretty clear. You would obviously violate the license.

Regards

Marcel

Completely wrong. However if the driver is distributed as built-in, then it would need to be licensed under GPL. This means that a driver can be written and distributed as a module under any licence, proprietary or otherwise, presumably with the restriction that it may NOT be built-in.

It is precisely the fact that it is a loadable module, and does not form part of the kernel, that removes the requirement to distribute it under GPL.

And that "hint" is a lie.

Hi David,

What makes you qualified to make that statement (without giving any evidence)? Are you're an expert on international copyright law?

Are you? You've made some very definite statements about copyright law. Things that I've been told are definitely in a gray area and not at all as clear cut as you and the FSF likes to say. FSF has a very clear agenda, and taking what they say as the gospel is a big mistake.

If I link a binary .o file into a static kernel image, does that make it a derivative work of the kernel? It most definitely violates the GPL in that the total is a derivative work, but does it really make the .o file a derivative work? What if I let the user do the linking at runtime? But as Alan Cox wrote, how the linking is done doesn't decide if it is a derivative work or not, copyright law does.

So what does make it a derivative work then?

If I use an in kernel API, but from a piece of code which is external to the kernel, is that really a derived work? If you say it is, do you realise that you are advocating something which is very close to an API copyright, something which I think most open source people are very adverse to. If API copyrights were valid, Wine, or editline, or lesstiff would be in a lot of trouble.

Of course, the Linux headers don't only define an API, they also contain a lot of inline code. But if I don't care about an extra jump, I could write a glue layer between the Linux kernel and some proprietary code that wraps all inline functions. In that case, is a module written against that glue layer a derivative work of the kernel?

If I write a glue layer that allows me to run the same driver in userspace via libusb and directly in the kernel, and give the user a choice to link my binary .o file either the userspace or kernel space glue, does that make my code a derivative work of the kernel? Most probably not, it is independent of the kernel in that case.

So where is the line in the sand that makes it clearly a derivative work? It's up to the courts to decide, and until there is a clear and final court ruling it is a gray area. Lawyers can guess at what the outcome might be, and some companies are apparently willing to take the risk that it isn't as clear cut as you think.

/Christer

And in fact, at least in the US, current case law states that when there's only one practical way to write something (which is the case in an API, you either code it the way the API says or you don't get a correctly functioning program), it's not copyrightable.

See "scenes a faire" in http://www.copyright-laws.com/pgs/protect-rights.html

Hi Christer,

I have simply stated that (1) the problem boils down to what is derived work and what is no and (2) the developers use the EXPORT_SYMBOL_GPL as a hint of what they think to be derived work (not necessarily tested in court). The _logical conclusion_ of these two simple facts is, of course, to _not use_ functions marked as EXPORT_SYMBOL_GPL unless you're willing to test your belief in court.

Now I see you really want to argue about this but could you please do it on some other list than the LKML? We use this list for real work too, you know, and right now you're only contributing noise. Thanks!

Pekka

This *is* real work. You have blinded yourself to the fact that this discussion is preliminary to a proposed change.

Or put another way, if you want to kill the discussion then the answer to "shall we" is "no."

Hi David,

Ok. I am not interested in continuing this discussion so please remove from the cc. Thanks.

Pekka

That would be your own personal strange opinion.

Having actually spent time with lawyers on the subject the question that matters for the GPL is the line between a derivative work and a non-derivative work. The former the GPL covers - the latter it does not. That is totally independent of the technical implementation of the loading and combining of the code.

There is even at least one case where the lawyers on both sides of a dispute have concurred that something is derivative because it was closely dependant on a backend that it communicated with by pipes and was useless without that backend and clearly built solely to use it.

Mechanism is not important, whether you are doing RPC calls, dynamic linking or static linking isn't part of the creative process.

The only exception to the derivative work question is usual system calls. I don't think anyone expects those to create a derivative work anyway but just in case the law gets a bit carried away the COPYING file for the kernel explicitly covers this to ensure there is certainty about running totally seperate proprietary applications on the Linux kernel.

Alan

Hi David,

how to do you wanna write a new original Linux driver (modular or built-in) without creating derivative work. This is not possible and due to the fact that it is derivative work the driver becomes automatically licensed under GPL. This is not a gray area.

The gray area that exists if you have code that was written for some other operating system and licensed under some proprietary license in the first place. And now that code is used in conjunction with a glue layer to make it loadable as kernel module.

That is such a nonsense. Stop distributing FUD and start talking to a lawyer. You are clearly under some weird impression what the GPL means and what it implies.

If the developers say that this symbol can only be used in GPL code (and with EXPORT_SYMBOL_GPL it is quite clear) then you have to obey to that license or don't use this symbol at all.

If you use that symbol inside non-GPL (meaning you link at runtime) then you are in violation of the GPL license. We can't make it much clearer.

Regards

Marcel

Not necessarily so. The developers feel that any code using that symbol is necessarily a derivative work, but at the end of the day it would be up to the legal system to decide whether it really is or not.

If the courts decided that the symbol could be used and the driver wouldn't be a derivative work, it would be perfectly legal to use a GPL'd shim to "re-export" the symbol, essentially stripping off the GPL-only protection for that symbol.

In our group all kernel modules that we write are GPL'd, as it lets us sleep at night, simplifies our lives, and makes the lawyers much happier. Other people may be willing to take more risks.

Chris

Hi Chris,

I agree with you that a court can decide that the usage of a EXPORT_SYMBOL_GPL symbol is not derivative work, but I see the likelihood of this happening as almost non existent. And even if so then you still have to deal with the fact that the license of this symbol is clearly GPL. No questions asked about that, because it says so and due technical means you can't load a non-GPL kernel module that uses EXPORT_SYMBOL_GPL symbol without tainting the kernel.

The same fact is valid in userspace where you can't link (not even runtime) a GPL library into a non-GPL program.

However if anyone wants to fight the license, be my guest and do so :)

All big companies are going this way. And licenses beside, there are valid technical points in making your driver open source and get it merged upstream. Just a hint for all these binary-only people :)

Regards

Marcel

Not sure who wrote the above, but it contains a glaring legal error:
Developers choose an invalid forum to impose licence conditions when they choose to do so via EXPORT_SYMBOL_GPL. The licence that prevails is GPL, and nowhere does it say that protected works may only be used by other GPL works. In fact, such a notion is alien to the GPL.

Of course courts are the proper forum to decide "fact" from opinion, but a statement of claim, which is a necessary preliminary to such an action, must state from what the alleged offending work is derived. The fact that claim of violation is made before any violating work has been identified, or even created, does work against such an action. A half-decent lawyer should be able to have any such action dismissed on that basis alone.

I wonder if it isn't fraud to offer a work under the GPL and then to try to impose new conditions.

The problem with that is this: To be derivative, a work has to be derived from another work. That's what "derivative" means. Is it by prescience that those marking symbols as EXPORT_SYMBOL_GPL know that only things derived from something else are capable of using them? Derived from what? The use of a separate module does not make something derivative. It makes it a client. Any binding between the two modules occurs only at runtime, and is purely ephemeral.

I make this charge: Some, perhaps much, of the GPL-exported symbols have been mislabelled. There is no prescience, and those who labelled them such are really trying (and failing) to claim an additional licence condition.

I further make this claim: an attempt to add a licence condition in that fashion is illegal, at least it is under various Australian laws, but I expect it's a similar story elsewhere. For a start, it's an attempt to vary licence conditions after the contract is made, and also without due notice. It also attempts to unfairly restrict trade. It's probably fraud, in that it purports to be a work provided under GPL, while silently claiming a different (and largely unstated) licence.

The EXPORT_SYMBOL_GPL should be removed, because it's based on a lie. You cannot know that only GPL works are capable of using the symbol; you cannot know that all works that do use it are derivative of something; you cannot even say, a priori, what they are derived from.

scratch, could you point to another work, better yet show lines of code in common?

It's nonsense, it's a reasonable reading of the GPL. What I am doing is telling you what the GPL says, not what you wish it said.

EXPORT_SYMBOL_GPL is not a licence. Only a licence is a licence.

Your desire is clear, but the facts are bound to disappoint you.

In which case for each statement please give the case at appeal or higher level which is the precedent for the interpretation.

Export symbol is a guide. There is no reason to think that EXPORT_SYMBOL symbols alone mean your work is somehow not derivative.

I am giving my opinion. By contrast, you have claimed to be giving the opinion of numerous lawyers. I hate to be so blunt, but that is the naked truth. You could improve that situation.

No argument, other than with, "export symbol is a guide." My argument
with that is that one could mistakenly infer that "export symbol"
includes "EXPORT_SYMBOL_GPL." The latter is not a guide, is it? It
restricts a symbol from use by proprietary modules.

Again, you are wrong, as per the recommendations of every lawyer I have ever talked to (and unfortunatly, that's a lot...)

It's fine for you to feel differently, and you yourself can act however you want to, but as you do not hold any copyright on any portions of the Linux kernel code, please do not speak as if your statements hold any weight.

In the end, it's up to the copyright holders to enforce the license. And as I have stated in the past, a number of them have made public statements as to what they think about this issue. And it corresponds exactly with what Marcel has stated above.

So if you wish to violate the copyright of others, you take the risk that you might be caught and punished, something that you and your legal council needs to take into account.

thanks,

greg k-h

So when do you sue Nvidia, ATI, Atheros, Broadcom[1], M-Systems/Sandisk[2] or Nokia? All those companies distribute binary drivers for Linux without providing source code?

/Christer

[1] WIFI chips and drivers used by Cisco, Asus and a lot of other manufacturers.

[2] DiskOnChip devices used in lots of embedded systems, among others the Troll Tech Greenphone.

How do you know that such legal action isn't already happening?

greg k-h

I don't. But AFAIK no such lawsuits have been made public so far.

ATI/AMD are moving in the right direction already, looking at open sourcing their drivers. (How is that going by the way, I haven't had time to keep up lately). And that I guss might be thanks to the competition from Intel on the graphics side. Or is it due to legal pressure out of the public eye? Or has ATI just realised that the Linux market is big enough that going open source might gain them enough market share to be worth is?

Anyway, I'm definitely going to vote with my wallet the next time I buy a laptop. My last laptop had an Intel graphics chip, because of the open source graphics drivers. I chose to buy a slower Intel chip instead of a faster Radeon model. And if something comes out of ATI before I buy a new one, I'll have to graphics chip manufacturers to choose from.

But would ATI really have been interested in open sourcing their graphics drives now if they had been sued out of the water a couple of years ago when they did their first binary drivers for Linux? I don't know.

/Christer

Is it? Or are you falsely implying that it is? I hope it is; that will help add fact to an otherwise opinion-ridden topic.

These words carry little weight as they are hearsay. You say that somebody told you something, but you don't who and you don't say precisely what, and on that basis you claim a conclusion. What you surely mean is that it's your opinion that I'm wrong, based on your interpretation of recommendations by lawyers. And since when did a lawyer ever give their opinion unequivocally? In my experience they always mince their words, providing no bankable guarantee.

There a company that is providing a common API for writting Windows and Linux drivers. Last time I was using a Macraigor JTAG it was based on this proprietary dual platform driver.

http://www.macraigor.com/cgi_bin/counters/unicounter.pl?name=counters/ocd_cmdr_linux&deliver=http://www.macraigor.biz/gnu/mcgr-hwsupport-4.8-0.i386.rpm

The dual platform driver was from Jungo.
http://www.jungo.com/

WinDriver™ USB for Linux automates and simplifies the development of user-mode Linux device drivers and hardware control applications for USB peripheral devices. No Linux kernel knowledge or kernel level programming required.

Jon Smirl
[email protected]

Yes, I know all about Jungo, and have never heard anything good about them from either the Windows developers I know, or anyone who has tried to get their stuff working on Linux using their framework.

I would not recommend their stuff at all, it's much easier to just write a native Linux and Windows driver instead. Especially with the new Windows Driver Framework, which helps those developers out a lot more these days.

thanks,

greg k-h