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.
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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(-)
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -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
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -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
--- a/drivers/usb/core/file.c
+++ b/drivers/usb/core/file.c
@@ -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);
--- a/drivers/usb/core/hcd-pci.c
+++ b/drivers/usb/core/hcd-pci.c
@@ -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);
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -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);
/*-------------------------------------------------------------------------*/
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -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);
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -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);
-
--- a/drivers/usb/core/urb.c
+++ b/drivers/usb/core/urb.c
@@ -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);
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -96,6 +96,7 @@ struct usb_interface *usb_ifnum_to_if(co
return NULL;
}
+EXPORT_SYMBOL_GPL(usb_ifnum_to_if);
/**
* usb_altnum_to_altsetting - get the altsetting structure with a given
@@ -126,6 +127,7 @@ struct usb_host_interface *usb_altnum_to
}
return NULL;
}
+EXPORT_SYMBOL_GPL(usb_altnum_to_altsetting);
struct find_interface_arg {
int minor;
@@ -170,6 +172,7 @@ struct usb_interface *usb_find_interface
__find_interface);
return argb.interface;
}
+EXPORT_SYMBOL_GPL(usb_find_interface);
/**
* usb_release_dev - free a usb device structure when all users of it are finished.
@@ -369,6 +372,7 @@ struct usb_device *usb_get_dev(struct us
get_device(&dev->dev);
return dev;
}
+EXPORT_SYMBOL_GPL(usb_get_dev);
/**
* usb_put_dev - release a use of the usb device structure
@@ -382,6 +386,7 @@ void usb_put_dev(struct usb_device *dev)
if (dev)
put_device(&dev->dev);
}
+EXPORT_SYMBOL_GPL(usb_put_dev);
/**
* usb_get_intf - increments the reference count of the usb interface structure
@@ -402,6 +407,7 @@ struct usb_interface *usb_get_intf(struc
get_device(&intf->dev);
return intf;
}
+EXPORT_SYMBOL_GPL(usb_get_intf);
/**
* usb_put_intf - release a use of the usb interface structure
@@ -416,7 +422,7 @@ void usb_put_intf(struct usb_interface *
if (intf)
put_device(&intf->dev);
}
-
+EXPORT_SYMBOL_GPL(usb_put_intf);
/* USB device locking
*
@@ -489,7 +495,7 @@ int usb_lock_device_for_reset(struct usb
}
return 1;
}
-
+EXPORT_SYMBOL_GPL(usb_lock_device_for_reset);
static struct usb_device *match_device(struct usb_device *dev,
u16 vendor_id, u16 product_id)
@@ -578,6 +584,7 @@ int usb_get_current_frame_number(struct
{
return usb_hcd_get_frame_number(dev);
}
+EXPORT_SYMBOL_GPL(usb_get_current_frame_number);
/*-------------------------------------------------------------------*/
/*
@@ -612,6 +619,7 @@ int __usb_get_extra_descriptor(char *buf
}
return -1;
}
+EXPORT_SYMBOL_GPL(__usb_get_extra_descriptor);
/**
* usb_buffer_alloc - allocate dma-consistent buffer for URB_NO_xxx_DMA_MAP
@@ -646,6 +654,7 @@ void *usb_buffer_alloc(
return NULL;
return hcd_buffer_alloc(dev->bus, size, mem_flags, dma);
}
+EXPORT_SYMBOL_GPL(usb_buffer_alloc);
/**
* usb_buffer_free - free memory allocated with usb_buffer_alloc()
@@ -671,6 +680,7 @@ void usb_buffer_free(
return;
hcd_buffer_free(dev->bus, size, addr, dma);
}
+EXPORT_SYMBOL_GPL(usb_buffer_free);
/**
* usb_buffer_map - create DMA mapping(s) for an urb
@@ -718,6 +728,7 @@ struct urb *usb_buffer_map(struct urb *u
| URB_NO_SETUP_DMA_MAP);
return urb;
}
+EXPORT_SYMBOL_GPL(usb_buffer_map);
#endif /* 0 */
/* XXX DISABLED, no users currently. If you wish to re-enable this
@@ -755,6 +766,7 @@ void usb_buffer_dmasync(struct urb *urb)
DMA_TO_DEVICE);
}
}
+EXPORT_SYMBOL_GPL(usb_buffer_dmasync);
#endif
/**
@@ -790,6 +802,7 @@ void usb_buffer_unmap(struct urb *urb)
urb->transfer_flags &= ~(URB_NO_TRANSFER_DMA_MAP
| URB_NO_SETUP_DMA_MAP);
}
+EXPORT_SYMBOL_GPL(usb_buffer_unmap);
#endif /* 0 */
/**
@@ -834,6 +847,7 @@ int usb_buffer_map_sg(const struct usb_d
return dma_map_sg(controller, sg, nents,
is_in ? DMA_FROM_DEVICE : DMA_TO_DEVICE);
}
+EXPORT_SYMBOL_GPL(usb_buffer_map_sg);
/* XXX DISABLED, no users currently. If you wish to re-enable this
* XXX please determine whether the sync is to transfer ownership of
@@ -867,6 +881,7 @@ void usb_buffer_dmasync_sg(const struct
dma_sync_sg(controller, sg, n_hw_ents,
is_in ? DMA_FROM_DEVICE : DMA_TO_DEVICE);
}
+EXPORT_SYMBOL_GPL(usb_buffer_dmasync_sg);
#endif
/**
@@ -893,6 +908,7 @@ void usb_buffer_unmap_sg(const struct us
dma_unmap_sg(controller, sg, n_hw_ents,
is_in ? DMA_FROM_DEVICE : DMA_TO_DEVICE);
}
+EXPORT_SYMBOL_GPL(usb_buffer_unmap_sg);
/* format to disable USB on kernel command line is: nousb */
__module_param_call("", nousb, param_set_bool, param_get_bool, &nousb, 0444);
@@ -904,6 +920,7 @@ int usb_disabled(void)
{
return nousb;
}
+EXPORT_SYMBOL_GPL(usb_disabled);
/*
* Init
@@ -985,45 +1002,4 @@ static void __exit usb_exit(void)
subsys_initcall(usb_init);
module_exit(usb_exit);
-
-/*
- * USB may be built into the kernel or be built as modules.
- * These symbols are exported for device (or host controller)
- * driver modules to use.
- */
-
-EXPORT_SYMBOL(usb_disabled);
-
-EXPORT_SYMBOL_GPL(usb_get_intf);
-EXPORT_SYMBOL_GPL(usb_put_intf);
-
-EXPORT_SYMBOL(usb_put_dev);
-EXPORT_SYMBOL(usb_get_dev);
-EXPORT_SYMBOL(usb_hub_tt_clear_buffer);
-
-EXPORT_SYMBOL(usb_lock_device_for_reset);
-
-EXPORT_SYMBOL(usb_find_interface);
-EXPORT_SYMBOL(usb_ifnum_to_if);
-EXPORT_SYMBOL(usb_altnum_to_altsetting);
-
-EXPORT_SYMBOL(__usb_get_extra_descriptor);
-
-EXPORT_SYMBOL(usb_get_current_frame_number);
-
-EXPORT_SYMBOL(usb_buffer_alloc);
-EXPORT_SYMBOL(usb_buffer_free);
-
-#if 0
-EXPORT_SYMBOL(usb_buffer_map);
-EXPORT_SYMBOL(usb_buffer_dmasync);
-EXPORT_SYMBOL(usb_buffer_unmap);
-#endif
-
-EXPORT_SYMBOL(usb_buffer_map_sg);
-#if 0
-EXPORT_SYMBOL(usb_buffer_dmasync_sg);
-#endif
-EXPORT_SYMBOL(usb_buffer_unmap_sg);
-
MODULE_LICENSE("GPL");
Greg KH wrote:
> 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.
There are the commercial OpenSound drivers.
Regards,
Clemens
On Mon, Jan 28, 2008 at 09:13:16AM +0100, Clemens Ladisch wrote:
> Greg KH wrote:
> > 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.
>
> There are the commercial OpenSound drivers.
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
Greg KH wrote:
> On Mon, Jan 28, 2008 at 09:13:16AM +0100, Clemens Ladisch wrote:
>> Greg KH wrote:
>> > 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.
>>
>> There are the commercial OpenSound drivers.
>
> What are they? Do you have a link to them?
http://www.opensound.com/
> 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.)
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
On Fri, Jan 25 2008 at 20:02 +0200, Greg KH <[email protected]> wrote:
> 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
>
What about ndiswrapper and its windows binaries
are they covered through ndiswrapper by GPL?
(Unfortunately I use them, but less and less)
Boaz
On Mon, Jan 28, 2008 at 12:44:19PM +0200, Boaz Harrosh wrote:
> On Fri, Jan 25 2008 at 20:02 +0200, Greg KH <[email protected]> wrote:
> > 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.
>
> What about ndiswrapper and its windows binaries
> are they covered through ndiswrapper by GPL?
> (Unfortunately I use them, but less and less)
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
On Mon, Jan 28, 2008 at 10:58:55AM +0100, Clemens Ladisch wrote:
> Greg KH wrote:
> > On Mon, Jan 28, 2008 at 09:13:16AM +0100, Clemens Ladisch wrote:
> >> Greg KH wrote:
> >> > 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.
> >>
> >> There are the commercial OpenSound drivers.
> >
> > What are they? Do you have a link to them?
>
> http://www.opensound.com/
>
> > 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.)
>
> They aren't used widely (with Linux), and AFAIK the USB driver doesn't
> have anything to favor it over the ALSA driver.
Ok, then we don't have any issues :)
thanks,
greg k-h
On Mon, Jan 28 2008 at 18:13 +0200, Greg KH <[email protected]> wrote:
> On Mon, Jan 28, 2008 at 12:44:19PM +0200, Boaz Harrosh wrote:
>> On Fri, Jan 25 2008 at 20:02 +0200, Greg KH <[email protected]> wrote:
>>> 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.
>> What about ndiswrapper and its windows binaries
>> are they covered through ndiswrapper by GPL?
>> (Unfortunately I use them, but less and less)
>
> Sorry, but no, they are not going to work, due to the way that
> ndiswrapper is marked by the kernel module loader.
>
I was afraid of that, yes.
> Again, you should be getting a kernel warning every time you try to use
> a USB function today.
>
sigh, yes I do, but it's better then no networking.
> 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...)?
>
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)
> thanks,
>
> greg k-h
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
On Mon, Jan 28, 2008 at 06:44:14PM +0200, Boaz Harrosh wrote:
> 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.
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:
> 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.
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
>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.
>
..
> There are no known closed source USB drivers in the wild, so this
> patch should cause no problems.
There is the unicorn usb adsl modem driver (STM unicorn chip).
http://www.bewan.com/bewan/drivers/A1012-A1006-A904-A888-A983-0.9.3.tgz
There is some sources and a binary blob to be linked.
The only things I know from the binary blob is that sources should be 150 000
lines of C++.
Driver compile with gcc-3 but not with gcc-4 (because of the binary blob).
Gilles
On Fri, Feb 01, 2008 at 03:45:07PM +0100, Gilles Espinasse wrote:
> >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.
> >
> ..
> > There are no known closed source USB drivers in the wild, so this
> > patch should cause no problems.
>
> There is the unicorn usb adsl modem driver (STM unicorn chip).
> http://www.bewan.com/bewan/drivers/A1012-A1006-A904-A888-A983-0.9.3.tgz
> There is some sources and a binary blob to be linked.
>
> The only things I know from the binary blob is that sources should be 150 000
> lines of C++.
Wow, larger than all the in-kernel USB drivers, and the USB core
combined. That's an impressive display of horrible code :)
> Driver compile with gcc-3 but not with gcc-4 (because of the binary blob).
So they aren't even being used by modern distros, so there's not much to
worry about here...
thanks for the info.
greg k-h
On Fri, 25 Jan 2008 10:02:32 -0800
Greg KH <[email protected]> wrote:
> 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.
Yes, I have objections and I've told you before.
> 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.
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
On Sat, Feb 02, 2008 at 12:37:10PM +0100, Christer Weinigel wrote:
> On Fri, 25 Jan 2008 10:02:32 -0800
> Greg KH <[email protected]> wrote:
>
> > 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.
>
> Yes, I have objections and I've told you before.
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.)
> > 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.
>
> This is a bit disingenuous. Of course there are closed source USB
> drivers out there.
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.
> 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.
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].
> 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).
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...
> 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.
>
I would consider you are a bit fast to state that :
a7n8x-e:~# gcc -dumpversion
3.3.6
a7n8x-e:~# cat /etc/issue
Debian GNU/Linux 4.0 \n \l
So unicorn driver could still be compiled on the current stable Debian that
has been released in April 2007.
Gilles
On Sat, 2 Feb 2008 11:19:30 -0800
Greg KH <[email protected]> wrote:
>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.)
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.
> > 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.
>
> 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].
>
> 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. :)
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,
On Feb 3, 2008 1:48 PM, Christer Weinigel <[email protected]> wrote:
> 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.
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
Greg KH wrote:
> 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].
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.
Greg KH wrote:
> 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].
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,
On Feb 3, 2008 5:12 PM, David Newall <[email protected]> wrote:
> 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.
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)?
Pekka Enberg wrote:
> Hi David,
>
> On Feb 3, 2008 5:12 PM, David Newall <[email protected]> wrote:
>
>> 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.
>>
>
> So I am going to assume you're not trolling here (although some of
> your snarky remarks make that bit hard).
>
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.)
> 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?
>
Agreed.
> 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.
Let's consider a totally original USB driver. There are an infinite
number of them, some still to be written.
> If the USB developers want to
> annotate their code with EXPORT_SYMBOL_GPL, why the hell do you want
> to argue about it?
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.
> If you want to
> develop for Linux, you're most certainly better off always
> distributing your code under the GPLv2
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.
> 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)?
>
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,
On Feb 3, 2008 6:06 PM, David Newall <[email protected]> wrote:
> > 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)?
>
> 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.
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
Pekka Enberg wrote:
> 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.
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.
> Furthermore, many of the _kernel developers_ do not support
> proprietary drivers, so why do you insist on using Linux for that
> purpose?
You did read the rest of the mail you commented I hope?
> Seriously, you really really want to look at the BSDs or proprietary
> operating systems because they support your needs much better.
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
Hi David,
> > 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.
> Let's consider a totally original USB driver. There are an infinite
> number of them, some still to be written.
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.
> > If the USB developers want to
> > annotate their code with EXPORT_SYMBOL_GPL, why the hell do you want
> > to argue about it?
> 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.
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.
> > If you want to
> > develop for Linux, you're most certainly better off always
> > distributing your code under the GPLv2
>
> 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.
First of all we are talking about kernel modules here. Not the
userspace. So stop this FUD.
> > 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)?
> >
>
> 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.
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
On Sun, Feb 03, 2008 at 06:04:24PM +0100, Christer Weinigel wrote:
> Pekka Enberg wrote:
>> 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.
>
> Why? Because it is a gray area.
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
David Newall ha scritto:
> 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.
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.
Diego Zuccato wrote:
> 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.
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.
> 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.
Welcome to the modern world, companies spend so much money on protecting
themselves against potential lawsuit that it is silly.
/Christer
Hi Christer,
> > 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.
>
> 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).
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
Christer Weinigel ha scritto:
> 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".
ROFL! Well, since a lot of screwdriver types are easily available, I
don't think a judge could agree with 'em...
> 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).
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)...
[...]
> so hiding the source really doesn't help.
Well, we all agree on this... Now we just have to make THEM agree, too...
BYtE,
Diego.
On Mon, 2008-02-04 at 01:37 +1030, David Newall wrote:
[...]
> 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.
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
Bernd Petrovitsch writes:
> On Mon, 2008-02-04 at 01:37 +1030, David Newall wrote:
> [...]
>> 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.
>
> Are you sure that that is not only (the results of) propaganda of
> (certain) proprietary companies?
well, yes.
> 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, as is the case perhaps almost everywhere, governments prohibit devices
that can operate outside of local requirements.
> Or do you get a gun manufacturer before court just because someone
> committed a crime with a its gun?
Let's not confuse the issue.
Pekka Enberg writes:
> 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.
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.
Marcel Holtmann writes:
> if a new drivers is originally written for Linux, then you are breaking
> the GPL.
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.
> You driver was meant to be
> running as Linux kernel module and thus it is derivative work.
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.
> 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.
And that "hint" is a lie.
Hi David,
Marcel Holtmann writes:
> > You driver was meant to be running as Linux kernel module and thus it is
> > derivative work.
On Feb 5, 2008 1:39 PM, David Newall <[email protected]> wrote:
> 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.
What makes you qualified to make that statement (without giving any
evidence)? Are you're an expert on international copyright law?
On Die, 2008-02-05 at 21:48 +1030, David Newall wrote:
> Bernd Petrovitsch writes:
> > On Mon, 2008-02-04 at 01:37 +1030, David Newall wrote:
> > [...]
> >> 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.
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.
> > Are you sure that that is not only (the results of) propaganda of
> > (certain) proprietary companies?
>
> well, yes.
>
> > 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, as is the case perhaps almost everywhere, governments prohibit devices
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*?
> that can operate outside of local requirements.
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.
> > Or do you get a gun manufacturer before court just because someone
> > committed a crime with a its gun?
>
> Let's not confuse the issue.
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
> 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.
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,
> > 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.
>
> 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.
that is not clear-cut case. You link at run-time. Otherwise the module
would do nothing.
Regards
Marcel
Hi David,
> > if a new drivers is originally written for Linux, then you are breaking
> > the GPL.
>
> 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.
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.
> > You driver was meant to be
> > running as Linux kernel module and thus it is derivative work.
>
> 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.
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.
> > 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.
>
> And that "hint" is a lie.
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
Marcel Holtmann wrote:
> 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.
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
On Tue, Feb 05, 2008 at 10:09:07PM +1030, David Newall wrote:
> Marcel Holtmann writes:
>> if a new drivers is originally written for Linux, then you are breaking
>> the GPL.
>
> 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.
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
Hi Chris,
> > 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.
>
> 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.
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 :)
> 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.
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
Greg KH writes:
> 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.
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:
According to Pavel Roskin, Richard Stallman said:
> It is not in general the case that "dynamic linking cannot violate the
> GPL". It depends on circumstances. Running a non-free program in a
> process in a GNU/Linux system is not linking of any kind with Linux.
> The program probably links with GNU libc, but the license of GNU libc
> permits that.
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.
> 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
Still wrong.
> that authors of original works can decide for themselves. They have no
Only if they are original works.
> obligation to release under GPL, however they must take special care to
> ensure that the module does not (statically) link with the kernel. Richard
Also wrong.
You really should investigate a beginners text on intellectual property
law.
Alan
Diego Zuccato writes:
> David Newall ha scritto:
>> 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.
>
> Why "of course" ?
"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.
On Wed, Feb 06, 2008 at 09:44:36AM +1030, David Newall wrote:
> A kernel module is akin to a process. It uses services of the kernel
> without being part of the kernel.
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
> "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
David Newall wrote:
> 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.
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
On Tue, 5 Feb 2008 12:34:18 -0800
Greg KH <[email protected]> wrote:
> 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.
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.
On Wed, Feb 06, 2008 at 09:14:48PM +0100, Christer Weinigel wrote:
> On Tue, 5 Feb 2008 12:34:18 -0800
> Greg KH <[email protected]> wrote:
>
> > 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.
>
> 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?
How do you know that such legal action isn't already happening?
greg k-h
On Mon, 04 Feb 2008 22:38:11 +0100
Marcel Holtmann <[email protected]> wrote:
> 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.
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.
> 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.
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.
> 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.
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
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]
Am Wed, 6 Feb 2008 21:34:49 +0100
schrieb Christer Weinigel <[email protected]>:
>
> 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.
That has been done, hasn't it?
> 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.
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
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.
>
> 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.
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?
> > 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.
>
> 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 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.
> > 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.
>
> 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.
You got one of the Greenphones ;)
> 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.
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
> 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.
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
On Wed, 6 Feb 2008 12:28:10 -0800
Greg KH <[email protected]> wrote:
> On Wed, Feb 06, 2008 at 09:14:48PM +0100, Christer Weinigel wrote:
> > On Tue, 5 Feb 2008 12:34:18 -0800
> > Greg KH <[email protected]> wrote:
> >
> > > 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.
> >
> > 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?
>
> How do you know that such legal action isn't already happening?
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
On Tue, Feb 05, 2008 at 05:34:23PM -0600, Chris Friesen wrote:
> David Newall wrote:
>> 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.
>
> 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.
>...
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.
> Chris
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
On Tue, 5 Feb 2008 13:46:08 +0200
"Pekka Enberg" <[email protected]> wrote:
> Hi David,
>
> Marcel Holtmann writes:
> > > You driver was meant to be running as Linux kernel module and
> > > thus it is derivative work.
>
> On Feb 5, 2008 1:39 PM, David Newall <[email protected]> wrote:
> > 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.
>
> 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
On Feb 1 2008 15:45, Gilles Espinasse wrote:
>..
>> There are no known closed source USB drivers in the wild, so this
>> patch should cause no problems.
>
>There is the unicorn usb adsl modem driver (STM unicorn chip).
>http://www.bewan.com/bewan/drivers/A1012-A1006-A904-A888-A983-0.9.3.tgz
>There is some sources and a binary blob to be linked.
>
>The only things I know from the binary blob is that sources should be 150 000
>lines of C++.
It's 63 C++ files actually (wow, that even beats the blob-iness of nvidia!)
and a few files look rather empty. Their source would rather benefit
from getting a review on LKML.
On Wed, Feb 06, 2008 at 03:43:26PM -0500, Jon Smirl wrote:
> 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.
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
On Wed, 06 Feb 2008 21:55:45 +0100
Marcel Holtmann <[email protected]> wrote:
> > 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.
>
> 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 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... :-)
> > 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 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.
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.
> And btw. the fully supported Linux hardware is in a lot of cases not
> more expensive than the other ones.
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.
> > > 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.
> >
> > 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.
>
> You got one of the Greenphones ;)
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
On Wed, 06 Feb 2008 22:12:54 +0100, Christer Weinigel said:
> 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.
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
> 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.
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
Hi Christer,
On Tue, 5 Feb 2008 13:46:08 +0200
"Pekka Enberg" <[email protected]> wrote:
> > What makes you qualified to make that statement (without giving any
> > evidence)? Are you're an expert on international copyright law?
On Feb 6, 2008 11:12 PM, Christer Weinigel <[email protected]> wrote:
> 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.
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
Christer Weinigel ha scritto:
> 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... :-)
And break the HW :-) Actually, they could be happier, since then you
have to buy another...
[...]
> 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
[...]
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.
David Newall ha scritto:
> "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.
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.
Marcel Holtmann wrote:
>>> 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.
>>>
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.
>>> 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.
>>>
>> 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.
>>
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.
Alan Cox wrote:
>> 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
>>
^^^^^^^^^^^^^^^
>
> Only if they are original works.
>
Yes. That was stipulated.
>
>> obligation to release under GPL, however they must take special care to
>> ensure that the module does not (statically) link with the kernel. Richard
>>
>
> Also wrong.
>
> You really should investigate a beginners text on intellectual property
> law.
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.
Greg KH wrote:
> On Wed, Feb 06, 2008 at 09:44:36AM +1030, David Newall wrote:
>
>> A kernel module is akin to a process. It uses services of the kernel
>> without being part of the kernel.
>>
>
> No Linux does not work like this at all.
> ...
> 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.
If you know of something relevant, give pointers.
Alan Cox wrote:
>> "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,
In Australia, devices require approval from a regulatory body. Such
approval is withheld if appropriate safeguards are not applied.
> 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
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.
> Some (particularly US) companies choose to take a conservative view based
>
Also, particularly Australia and New Zealand. I can't imagine France or
Germany would be different. Where is it different?
> 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.
>
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.
Chris Friesen wrote:
> 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.
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.
>
> 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.
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.)
Greg KH wrote:
> On Wed, Feb 06, 2008 at 09:14:48PM +0100, Christer Weinigel wrote:
>
>> On Tue, 5 Feb 2008 12:34:18 -0800
>> Greg KH <[email protected]> wrote:
>>
>>
>>> 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.
>>>
>> 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?
>>
>
> How do you know that such legal action isn't already happening?
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.
Christer Weinigel wrote:
> 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.
>
This nicely expresses my position.
Hans-J?rgen Koch wrote:
> 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.
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.
Marcel Holtmann wrote:
> 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.
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.
Adrian Bunk wrote:
> On Tue, Feb 05, 2008 at 05:34:23PM -0600, Chris Friesen wrote:
>
>> David Newall wrote:
>>
>>> 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.
>>>
>> 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.
>> ...
>>
>
> 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.
>
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.
Pekka Enberg wrote:
> 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!
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."
Diego Zuccato wrote:
> David Newall ha scritto:
>
>> "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.
> If the device is well engineered, there's nothing the sw can do to
> make it work outside regulatory limits.
That's naive, since requirements differ in different jurisdictions, as
I'm sure you are perfectly aware.
> 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).
Precisely: One purpose of the driver is to enforce local compliance.
> 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.
In Australia it's illegal to own them (CB licensee; HAMs are allowed to
use them, although not on 27Mhz.)
> And it's a logical problem, too: why should the *driver* enforce a
> *technical* limit?
That's part of it's purpose. It permits a manufacturer to make a global
device that operates within local restrictions.
Chris Friesen wrote:
> Marcel Holtmann wrote:
>
>> 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.
>
> Not necessarily so. The developers feel that any code using that
> symbol is necessarily a derivative work,
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.
Greg KH wrote:
> On Tue, Feb 05, 2008 at 10:09:07PM +1030, David Newall wrote:
>
>> Marcel Holtmann writes:
>>
>>> if a new drivers is originally written for Linux, then you are breaking
>>> the GPL.
>>>
>> 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.
>>
>
> Again, you are wrong, as per the recommendations of every lawyer I have
> ever talked to (and unfortunatly, that's a lot...)
>
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.
Marcel Holtmann wrote:
> 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.
>>>
>> 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.
>>
>
> that is not clear-cut case. You link at run-time. Otherwise the module
> would do nothing.
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.
Marcel Holtmann wrote:
>>> if a new drivers is originally written for Linux, then you are breaking
>>> the GPL.
>>>
>> 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.
>>
>
> how to do you wanna write a new original Linux driver (modular or
> built-in) without creating derivative work.
>From what does it derive? Given a new, original work, created from
scratch, could you point to another work, better yet show lines of code
in common?
>>> You driver was meant to be
>>> running as Linux kernel module and thus it is derivative work.
>>>
>> 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.
>>
>
> 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.
>
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.
> 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.
>
EXPORT_SYMBOL_GPL is not a licence. Only a licence is a licence.
> 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.
>
Your desire is clear, but the facts are bound to disappoint you.
Alan Cox wrote:
>> 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.
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.
Hi David,
On Feb 7, 2008 3:31 PM, David Newall <[email protected]> wrote:
> 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."
Ok. I am not interested in continuing this discussion so please remove
from the cc. Thanks.
Pekka
Am Thu, 07 Feb 2008 23:49:42 +1030
schrieb David Newall <[email protected]>:
> Hans-Jürgen Koch wrote:
> > 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.
>
> 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.
What are you trying to say? You like the license but you're against
enforcing it?
> It's a bullish approach, technically incompetent,
What's incompetent?
> legally meaningless
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.
> and politically damaging.
That's your opinion because it's damaging _your_ political goals.
Hans
> Perhaps you might read up on unfair trade practices and contract law.
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.
> 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.
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
> In Australia, devices require approval from a regulatory body. Such
> approval is withheld if appropriate safeguards are not applied.
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.
> 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
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
> 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
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.
> 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.
Wrong again. In civil law in the USA and most of europe the test is
"balance of probability".
Alan
> > 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.
>
> 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
David Newall ha scritto:
> That's naive, since requirements differ in different jurisdictions, as
> I'm sure you are perfectly aware.
Naive? Who thinks a limit can be enforced by sw is naive!
He's missing a little detail: Internet. :-)
> Precisely: One purpose of the driver is to enforce local compliance.
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.
>> 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.
> In Australia it's illegal to own them (CB licensee; HAMs are allowed to
> use them, although not on 27Mhz.)
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).
>> And it's a logical problem, too: why should the *driver* enforce a
>> *technical* limit?
> That's part of it's purpose. It permits a manufacturer to make a global
> device that operates within local restrictions.
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.
Hans-Jürgen Koch wrote:
> Am Thu, 07 Feb 2008 23:49:42 +1030
> schrieb David Newall <[email protected]>:
>
>> 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.
>>
>
> What are you trying to say? You like the license but you're against
> enforcing it?
>
I told you: the GPL does not preclude inter-operation with non-GPL software.
>> It's a bullish approach, technically incompetent,
>>
>
> What's incompetent?
>
It's easily defeated.
>> legally meaningless
>>
>
> It is not legally meaningless if copyright holders publicly state how
> they interpret the license and what they consider a license violation.
>
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.
> 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.
>
>
>> and politically damaging.
>>
>
> That's your opinion because it's damaging _your_ political goals.
>
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.)
Alan Cox wrote:
>> 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.
>>
>
> First mistake: The GPL is not a contract it is a license.
Mea culpa. It is indeed a licence, which I did and do know. I really
did mean, "The licence (GPL)"
> 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
> 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.
In which case for each statement please give the case at appeal or higher
level which is the precedent for the interpretation.
> > 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.
> >
> EXPORT_SYMBOL_GPL is not a licence. Only a licence is a licence.
Export symbol is a guide. There is no reason to think that EXPORT_SYMBOL
symbols alone mean your work is somehow not derivative.
Alan Cox wrote:
>> In Australia, devices require approval from a regulatory body. Such
>> approval is withheld if appropriate safeguards are not applied.
>>
>
> We were talking about the USA.
We most certainly were not. We are talking about Linux, and everybody
wants it be used globally.
> 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.
>
Probably the same in Australia, for the same reason as in USA. Probably
the same in most countries.
>> 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
>>
>
> Diddums, thats what the license says.
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.
> 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.
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?
Alan Cox wrote:
>> 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.
>>
>
> Wrong again. In civil law in the USA and most of europe the test is
> "balance of probability".
>
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.
Alan Cox wrote:
>>> 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.
>>>
>> 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.
I'm glad to entertain. It's a pity you refuse to be educated. Closed
mind on the topic, perhaps?
> The test is "derivative works" not linking.
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.
> 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"
>
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."
> 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"
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."
> 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.
That would be improper as you'd well know if you knew the first thing
about the subject.
>
> 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.
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.
> 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.
Linux is GPL licencesed code you either follow the licence or don't use
it. It's very simple.
>
> 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
I don't actually care. If you want to do binary products then pick a
product you have the right to do that with.
> 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?
The market will ultimately decide which models of software development
are the right ones for which situation.
Alan
On Thu, Feb 07, 2008 at 09:07:38AM +0100, Diego Zuccato wrote:
> Christer Weinigel ha scritto:
>...
> [...]
>> 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
> [...]
> Urgh... I don't think NDAs and Open Source mix well... Are you sure your
> bosses KNOW Linux and the OS in general? :-)
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.
> BYtE,
> Diego.
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
> 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.
Diego Zuccato wrote:
> David Newall ha scritto:
>
>> That's naive, since requirements differ in different jurisdictions, as
>> I'm sure you are perfectly aware.
> Naive? Who thinks a limit can be enforced by sw is naive!
Of course. Naturally it's near impossible to prevent people from
tweaking the software. But reasonable restrictions are what regulatory
bodies expect.
> Precisely: One purpose of the driver is to enforce local compliance.
> It can't *enforce* it anyway, at least if the users are all around the
> world.
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!
>>> 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.
>> In Australia it's illegal to own them (CB licensee; HAMs are allowed to
>> use them, although not on 27Mhz.)
> 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).
What's your point? That it's easy to break the law? Nobody's arguing
against that.
>>> And it's a logical problem, too: why should the *driver* enforce a
>>> *technical* limit?
>> That's part of it's purpose. It permits a manufacturer to make a global
>> device that operates within local restrictions.
> Nope. The driver should simply make the device WORK. The USER must
> make sure to meet the local regulations.
Definitely no. The manufacturer must ensure it meets local
regulations. One way they do that is via the driver.
> The driver can help, but as long as it asks the user a country
> setting, its enforcement is nearly nothing!
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.)
> 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?
Are you asking if the manufacturer could lose their licence to sell the
product? It could happen. Regulators do wield significant powers.
> 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...
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.
> previous statements which seemed to say, "you've spoken to numerous
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
Alan Cox wrote:
>> 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.
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.
Alan Cox wrote:
>> 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.
>>
>
> In which case for each statement please give the case at appeal or higher
> level which is the precedent for the interpretation.
>
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.
>>> 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.
>>>
>>>
>> EXPORT_SYMBOL_GPL is not a licence. Only a licence is a licence.
>>
>
> Export symbol is a guide. There is no reason to think that EXPORT_SYMBOL
> symbols alone mean your work is somehow not derivative.
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.
Alan Cox wrote:
>> 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.
>>
>
> That would be improper as you'd well know if you knew the first thing
> about the subject.
>
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.
>> 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.
>>
>
> Why don't you just say "you are a liar" as I assume that is what you want
> to say.
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".
>> 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.
>>
>
> Linux is GPL licencesed code you either follow the licence or don't use
> it. It's very simple.
>
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.)
>> 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
>>
>
> I don't actually care. If you want to do binary products then pick a
> product you have the right to do that with.
>
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.
>> 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?
>>
>
> The market will ultimately decide which models of software development
> are the right ones for which situation.
>
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.
Am Fri, 08 Feb 2008 01:01:24 +1030
schrieb David Newall <[email protected]>:
> > It is not legally meaningless if copyright holders publicly state
> > how they interpret the license and what they consider a license
> > violation.
>
> 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.
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.
> It's equivalent to someone saying, "you are wrong," before you've
> even thought about saying something.
No. The GPL is about derived work. Derived code can obviously only
appear _after_ the original work.
>
> > 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.
> >
> >
> >> and politically damaging.
> >>
> >
> > That's your opinion because it's damaging _your_ political goals.
> >
>
> 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.
Nice to hear. So, if you're an advocate for open source drivers, why do
you have problems making them GPL?
> 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.)
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
Alan Cox wrote:
>> 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 wrote:
>> previous statements which seemed to say, "you've spoken to numerous
>>
>
> Please don't use "seemed to say" and then quote words I've never said.
> That's misleading, rude and also awful language style.
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.
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Hans-J?rgen Koch
> Sent: 2008 February 07 16:13
> To: David Newall
> Cc: Christer Weinigel; Marcel Holtmann; Diego Zuccato; Greg
> KH; [email protected]; [email protected]
> Subject: Re: [PATCH] USB: mark USB drivers as being GPL only
>
> 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?
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.
****************************************************************************************************************************************************************************************************************************************************
Hans-J?rgen Koch wrote:
> Am Fri, 08 Feb 2008 01:01:24 +1030
> schrieb David Newall <[email protected]>:
>
>>> It is not legally meaningless if copyright holders publicly state
>>> how they interpret the license and what they consider a license
>>> violation.
>>>
>> 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.
>>
>
> 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.
>
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."
>> Less there be further confusion: I am not an advocate for binary
>> drivers.
>>
>
> Nice to hear. So, if you're an advocate for open source drivers, why do
> you have problems making them GPL?
>
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.
> 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?
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]>:
> Hans-Jürgen Koch wrote:
> > Am Fri, 08 Feb 2008 01:01:24 +1030
> > schrieb David Newall <[email protected]>:
> >
> >>> It is not legally meaningless if copyright holders publicly state
> >>> how they interpret the license and what they consider a license
> >>> violation.
> >>>
> >> 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.
> >>
> >
> > 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.
>
> 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."
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.
>
>
> >> Less there be further confusion: I am not an advocate for binary
> >> drivers.
> >>
> >
> > Nice to hear. So, if you're an advocate for open source drivers,
> > why do you have problems making them GPL?
> >
>
> 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.
>
> > 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?
> 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.
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!
> 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.
Oh, come on! You cannot turn a derived work into an original work just
by distributing them seperately.
Thanks,
Hans
> 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
It would be highly improper given these were business discussions
involving companies using Linux.
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.
> >>>
> >> 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.
> >>
> >
> > that is not clear-cut case. You link at run-time. Otherwise the module
> > would do nothing.
>
> 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.
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
Hi Diego,
> > 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... :-)
> And break the HW :-) Actually, they could be happier, since then you
> have to buy another...
>
> [...]
> > 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
> [...]
> Urgh... I don't think NDAs and Open Source mix well... Are you sure your
> bosses KNOW Linux and the OS in general? :-)
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
Hi David,
> > 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.
> 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.
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
>> And it's a logical problem, too: why should the *driver* enforce a
>> *technical* limit?
>>
> That's part of it's purpose. It permits a manufacturer to make a global
> device that operates within local restrictions.
> --
>
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....
Alan Cox kirjoitti:
>> 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
>>
>
> 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.
>
>
>> 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.
>>
>
> Wrong again. In civil law in the USA and most of europe the test is
> "balance of probability".
>
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
> 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.
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:
> First mistake: The GPL is not a contract it is a license.
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.
>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".
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:
> 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.
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
Hans-Jürgen Koch wrote:
> 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.
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.
>> 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.
>>
>
> Oh, come on! You cannot turn a derived work into an original work just
> by distributing them seperately.
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:
> 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?
This is wrong for the reasons I stated.
Alan Cox wrote:
>> 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
>>
>
> 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.
Marcel Holtmann wrote:
> 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.
>>>>>
>>>>>
>>>> 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.
>>>>
>>>>
>>> that is not clear-cut case. You link at run-time. Otherwise the module
>>> would do nothing.
>>>
>> 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.
>>
>
> so how do you build this module that is not linked without using the
> Linux kernel.
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?
David Newall ha scritto:
>> Precisely: One purpose of the driver is to enforce local compliance.
>> It can't *enforce* it anyway, at least if the users are all around the
>> world.
> 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 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? :-)
> You'd probably get with
> crucifixion for a first offense!
ROFLASTC :-)
> What's your point? That it's easy to break the law? Nobody's arguing
> against that.
I was simply implying there are easier ways than others... And binary
drivers can't help...
>> Nope. The driver should simply make the device WORK. The USER must
>> make sure to meet the local regulations.
> Definitely no. The manufacturer must ensure it meets local
> regulations. One way they do that is via the driver.
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"...).
> 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.)
Allowing the lying user to download a driver for another country...
>> 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...
> 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.
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.
Lee Mathers ha scritto:
> 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....
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.
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.
> >>>>>
> >>>>>
> >>>> 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.
> >>>>
> >>>>
> >>> that is not clear-cut case. You link at run-time. Otherwise the module
> >>> would do nothing.
> >>>
> >> 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.
> >>
> >
> > so how do you build this module that is not linked without using the
> > Linux kernel.
> 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?
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
On Fri, 08 Feb 2008 13:25:33 +1030
David Newall <[email protected]> wrote:
> Alan Cox wrote:
> >> 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
> >>
> >
> > 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
> 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.
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
Alan Cox wrote:
> On Fri, 08 Feb 2008 13:25:33 +1030
> David Newall <[email protected]> wrote:
>
>
>> Alan Cox wrote:
>>
>>>> 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
>>>>
>>>>
>>> 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.
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.
> I hope it makes you very happy, welcome to
> my killfile.
Why would that bother me? You said it before, anyway. It was childish
then, and is childish now.
Marcel Holtmann wrote:
> 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.
>
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.
>From this we must conclude that any claim that kernel modules can only
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.
> 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.
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:
> Now, Alan has made a big issue over numerous legal opinions he has
> received, but he's been completely coy in the details.
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.
On Sat, Feb 09, 2008 at 05:10:04AM +1030, David Newall wrote:
> 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.
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
My, I am full of post scripts today. This one is a peace token for Alan.
David Newall wrote:
> there are more reliable and transparent sources [than Alan.] 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.
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.
On Friday 08 February 2008 14:08:21 David Newall wrote:
> I explained something poorly:
> > Now, Alan has made a big issue over numerous legal opinions he has
> > received, but he's been completely coy in the details.
>
> 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.
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.
Greg KH wrote:
> A "driver" is not an "application" as you tried to reference in your
> prior quotes.
I think your treating what the learned Professors said to literally.
> It is a tiny portion of the whole kernel,
The Copyright Act draws no such a distinction.
> and as such,
> does fall under the derivative works portion when it is run within the
> Linux kernel.
>
Section 0 of GPL: The act of running the Program is not restricted.
> 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.
>
I'd like to, but I've searched and searched and can't find them. Some
pointers, maybe a search term, would be useful.
> This is going to be my last response on this thread,
Good idea. I've spent too much time on this already, so I think I'll
join you.
On Fri, 08 Feb 2008 10:15:01 +0100, Marcel Holtmann said:
> 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
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)...
> 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)
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
On Friday 08 February 2008 16:36:37 Alan Cox wrote:
> > 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)
>
> 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.
Hi Valdis,
> > 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
>
> 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)...
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,
> > 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.
> >
> 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.)
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.
> USB drivers must NOT be restricted to GPL-licence only; that would
> damage Linux.
Not writing and publishing GPL drivers damages Linux. Nothing else.
> > 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.
>
> 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?
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
On Sat, 09 Feb 2008 05:10:04 +1030
David Newall <[email protected]> wrote:
> 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.
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
On Thu, 7 Feb 2008 18:49:39 +0100
Hans-Jürgen Koch <[email protected]> wrote:
> > 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.
>
> Oh, come on! You cannot turn a derived work into an original work just
> by distributing them seperately.
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?
On Feb 9, 2008 5:13 PM, Christer Weinigel <[email protected]> wrote:
> 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?
>
> 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?
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!
On Sat, 9 Feb 2008 17:41:00 +0200
"Pekka Enberg" <[email protected]> wrote:
> On Feb 9, 2008 5:13 PM, Christer Weinigel <[email protected]>
> wrote:
> > 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?
> >
> > 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?
>
> 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.
Ok good.
> 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.
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.
> 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."
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.
> Thanks for the straw man, though!
*sigh* Now you're just being insulting.
/Christer
On Feb 9, 2008 6:50 PM, Christer Weinigel <[email protected]> wrote:
> 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.
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.
Marcel Holtmann wrote:
> 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.
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.
> It makes no difference if you
> distribute the GPL library with it or not.
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?
> But hey (again), feel free to disagree with me here.
This argument has no basis in law or common sense. It's completely
off-the-wall.
And to Pekka Enberg:
>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.
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,
> > 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.
>
> 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.
>
> > It makes no difference if you
> > distribute the GPL library with it or not.
>
> 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?
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>
> > > It makes no difference if you
> > > distribute the GPL library with it or not.
> >
> > 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?
>
> 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
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,
> > > > It makes no difference if you
> > > > distribute the GPL library with it or not.
> > >
> > > 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?
> >
> > 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
>
> In the US, at least, the belief that "Linking", in *ANY* form, with a GPL
> library creates a derivative work, is fallacious.
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.
> 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.
Not even getting into this one since GTK+ is a LGPL based library. Get
your examples straight.
> 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.
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
On Sunday 10 February 2008 00:43:49 Marcel Holtmann wrote:
> Hi Daniel,
>
> > > > > It makes no difference if you
> > > > > distribute the GPL library with it or not.
> > > >
> > > > 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?
> > >
> > > 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#IfLibraryIsGP
> > >L
> > >
> > > http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingWithGP
> > >L
> >
> > In the US, at least, the belief that "Linking", in *ANY* form, with a GPL
> > library creates a derivative work, is fallacious.
>
> 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.
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".
> > 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.
>
> Not even getting into this one since GTK+ is a LGPL based library. Get
> your examples straight.
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.
> > 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.
>
> 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.
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.
> 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
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
On Sunday 10 February 2008 06:20:45 Alan Cox wrote:
> > 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
>
> 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.
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 ?
> 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.
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.
> 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.
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)
> 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
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.
On 10/02/2008, Daniel Hazelton <[email protected]> wrote:
>
> 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.
>
glibc is LGPL and will not force you to use GPL.
David Newall wrote on 03-02-08 16:07:
> Greg KH wrote:
>> 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].
>
> 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
>...
> *The fictitious author of an imaginary driver.
Please keep me out of this.
I did not write any driver, imaginary or otherwise.
Nor am I fictitious.
Truely yours,
bjd
On Sun, 10 Feb 2008 05:50:17 +0100, Marcel Holtmann said:
> 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
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....)
> 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"....
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