[GIT PATCH] more Driver core patches for 2.6.19

[GIT PATCH] more Driver core patches for 2.6.19

[Greg KH]

Here are some more driver core patches for 2.6.19

They contain:
	- minor driver core bugfixes and memory savings
	- debugfs bugfixes and inotify support added.
	- userspace io driver interface added.  This allows the ability
	  to write userspace drivers for some types of hardware much
	  easier than before, going through a simple interface to get
	  accesses to irqs and memory regions.  A small kernel portion
	  is still needed to handle the irq properly, but that is it.
	- other minor cleanups and fixes.

All of these patches have been in the -mm tree for a while.

Please pull from:
	git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/
or if master.kernel.org hasn't synced up yet:
	master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/

Patches will be sent as a follow-on to this message to lkml for people
to see.

thanks,

greg k-h

 Documentation/DocBook/kernel-api.tmpl |    4 +
 Documentation/DocBook/uio-howto.tmpl  |  434 +++++++++++++++++++++++
 drivers/Kconfig                       |    1 +
 drivers/Makefile                      |    1 +
 drivers/base/class.c                  |    2 +
 drivers/base/platform.c               |    4 +-
 drivers/uio/Kconfig                   |   39 ++
 drivers/uio/Makefile                  |    4 +
 drivers/uio/uio.c                     |  618 +++++++++++++++++++++++++++++++++
 drivers/uio/uio_dummy.c               |  174 +++++++++
 drivers/uio/uio_events.c              |  119 +++++++
 drivers/uio/uio_irq.c                 |   86 +++++
 drivers/uio/uio_parport.c             |   84 +++++
 fs/debugfs/inode.c                    |   39 ++-
 include/linux/platform_device.h       |    2 +-
 include/linux/uio_driver.h            |   71 ++++
 kernel/module.c                       |   25 ++
 kernel/power/Kconfig                  |    9 +-
 18 files changed, 1700 insertions(+), 16 deletions(-)
 create mode 100644 Documentation/DocBook/uio-howto.tmpl
 create mode 100644 drivers/uio/Kconfig
 create mode 100644 drivers/uio/Makefile
 create mode 100644 drivers/uio/uio.c
 create mode 100644 drivers/uio/uio_dummy.c
 create mode 100644 drivers/uio/uio_events.c
 create mode 100644 drivers/uio/uio_irq.c
 create mode 100644 drivers/uio/uio_parport.c
 create mode 100644 include/linux/uio_driver.h

---------------

Akinobu Mita (1):
      driver core: delete virtual directory on class_unregister()

Andrew Morton (1):
      Driver core: "platform_driver_probe() can save codespace": save codespace

David Brownell (1):
      Driver core: deprecate PM_LEGACY, default it to N

Hans J. Koch (4):
      UIO: Add the User IO core code
      UIO: Documentation
      UIO: dummy test module for the uio core
      UIO: irq test module for the uio core

Kay Sievers (1):
      Driver core: show "initstate" of module

Mathieu Desnoyers (5):
      DebugFS : inotify create/mkdir support
      DebugFS : coding style fixes
      DebugFS : file/directory creation error handling
      DebugFS : more file/directory creation error handling
      DebugFS : file/directory removal fix

Scott Wood (1):
      Driver core: Make platform_device_add_data accept a const pointer

[PATCH 5/14] Driver core: show "initstate" of module

[Greg KH]

From: Kay Sievers <kay.sievers@vrfy.org>

Show the initialization state(live, coming, going) of the module:
  $ cat /sys/module/usbcore/initstate
  live

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 kernel/module.c |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index d9eae45..b565eae 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -824,9 +824,34 @@ static inline void module_unload_init(struct module *mod)
 }
 #endif /* CONFIG_MODULE_UNLOAD */
 
+static ssize_t show_initstate(struct module_attribute *mattr,
+			   struct module *mod, char *buffer)
+{
+	const char *state = "unknown";
+
+	switch (mod->state) {
+	case MODULE_STATE_LIVE:
+		state = "live";
+		break;
+	case MODULE_STATE_COMING:
+		state = "coming";
+		break;
+	case MODULE_STATE_GOING:
+		state = "going";
+		break;
+	}
+	return sprintf(buffer, "%s\n", state);
+}
+
+static struct module_attribute initstate = {
+	.attr = { .name = "initstate", .mode = 0444, .owner = THIS_MODULE },
+	.show = show_initstate,
+};
+
 static struct module_attribute *modinfo_attrs[] = {
 	&modinfo_version,
 	&modinfo_srcversion,
+	&initstate,
 #ifdef CONFIG_MODULE_UNLOAD
 	&refcnt,
 #endif
-- 
1.4.4.2

[PATCH 6/14] driver core: delete virtual directory on class_unregister()

[Greg KH]

From: Akinobu Mita <akinobu.mita@gmail.com>

Class virtual directory is created as the need arises.
But it is not deleted when the class is unregistered.

Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/base/class.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/base/class.c b/drivers/base/class.c
index f098881..8bf2ca2 100644
--- a/drivers/base/class.c
+++ b/drivers/base/class.c
@@ -163,6 +163,8 @@ int class_register(struct class * cls)
 void class_unregister(struct class * cls)
 {
 	pr_debug("device class '%s': unregistering\n", cls->name);
+	if (cls->virtual_dir)
+		kobject_unregister(cls->virtual_dir);
 	remove_class_attrs(cls);
 	subsystem_unregister(&cls->subsys);
 }
-- 
1.4.4.2

[PATCH 7/14] DebugFS : inotify create/mkdir support

[Greg KH]

From: Mathieu Desnoyers <compudj@krystal.dyndns.org>

Add inotify create and mkdir events to DebugFS.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 fs/debugfs/inode.c |   12 ++++++++++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index 137d76c..020da4c 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -24,6 +24,7 @@
 #include <linux/kobject.h>
 #include <linux/namei.h>
 #include <linux/debugfs.h>
+#include <linux/fsnotify.h>
 
 #define DEBUGFS_MAGIC	0x64626720
 
@@ -87,15 +88,22 @@ static int debugfs_mkdir(struct inode *dir, struct dentry *dentry, int mode)
 
 	mode = (mode & (S_IRWXUGO | S_ISVTX)) | S_IFDIR;
 	res = debugfs_mknod(dir, dentry, mode, 0);
-	if (!res)
+	if (!res) {
 		inc_nlink(dir);
+		fsnotify_mkdir(dir, dentry);
+	}
 	return res;
 }
 
 static int debugfs_create(struct inode *dir, struct dentry *dentry, int mode)
 {
+	int res;
+
 	mode = (mode & S_IALLUGO) | S_IFREG;
-	return debugfs_mknod(dir, dentry, mode, 0);
+	res = debugfs_mknod(dir, dentry, mode, 0);
+	if (!res)
+		fsnotify_create(dir, dentry);
+	return res;
 }
 
 static inline int debugfs_positive(struct dentry *dentry)
-- 
1.4.4.2

[PATCH 8/14] DebugFS : coding style fixes

[Greg KH]

From: Mathieu Desnoyers <compudj@krystal.dyndns.org>

Minor coding style fixes along the way : 80 cols and a white space.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 fs/debugfs/inode.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index 020da4c..05d1a9c 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -55,7 +55,8 @@ static struct inode *debugfs_get_inode(struct super_block *sb, int mode, dev_t d
 			inode->i_op = &simple_dir_inode_operations;
 			inode->i_fop = &simple_dir_operations;
 
-			/* directory inodes start off with i_nlink == 2 (for "." entry) */
+			/* directory inodes start off with i_nlink == 2
+			 * (for "." entry) */
 			inc_nlink(inode);
 			break;
 		}
@@ -143,7 +144,7 @@ static int debugfs_create_by_name(const char *name, mode_t mode,
 	 * block. A pointer to that is in the struct vfsmount that we
 	 * have around.
 	 */
-	if (!parent ) {
+	if (!parent) {
 		if (debugfs_mount && debugfs_mount->mnt_sb) {
 			parent = debugfs_mount->mnt_sb->s_root;
 		}
-- 
1.4.4.2

[PATCH 9/14] DebugFS : file/directory creation error handling

[Greg KH]

From: Mathieu Desnoyers <compudj@krystal.dyndns.org>

Fix error handling of file and directory creation in DebugFS.

The error path should release the file system because no _remove will be called
for this erroneous creation.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 fs/debugfs/inode.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index 05d1a9c..d6c5fb5 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -206,13 +206,15 @@ struct dentry *debugfs_create_file(const char *name, mode_t mode,
 
 	pr_debug("debugfs: creating file '%s'\n",name);
 
-	error = simple_pin_fs(&debug_fs_type, &debugfs_mount, &debugfs_mount_count);
+	error = simple_pin_fs(&debug_fs_type, &debugfs_mount,
+			      &debugfs_mount_count);
 	if (error)
 		goto exit;
 
 	error = debugfs_create_by_name(name, mode, parent, &dentry);
 	if (error) {
 		dentry = NULL;
+		simple_release_fs(&debugfs_mount, &debugfs_mount_count);
 		goto exit;
 	}
 
-- 
1.4.4.2

[PATCH 10/14] DebugFS : more file/directory creation error handling

[Greg KH]

From: Mathieu Desnoyers <compudj@krystal.dyndns.org>

Correct dentry count to handle creation errors.

This patch puts a dput at the file creation instead of the file removal :
lookup_one_len already returns a dentry with reference count of 1. Then,
the dget() in simple_mknod increments it when the dentry is associated
with a file. In a scenario where simple_create or simple_mkdir returns
an error, this would lead to an unwanted increment of the reference
counter, therefore making file removal impossible.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 fs/debugfs/inode.c |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index d6c5fb5..554f4a9 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -162,6 +162,7 @@ static int debugfs_create_by_name(const char *name, mode_t mode,
 			error = debugfs_mkdir(parent->d_inode, *dentry, mode);
 		else 
 			error = debugfs_create(parent->d_inode, *dentry, mode);
+		dput(*dentry);
 	} else
 		error = PTR_ERR(*dentry);
 	mutex_unlock(&parent->d_inode->i_mutex);
@@ -273,6 +274,7 @@ EXPORT_SYMBOL_GPL(debugfs_create_dir);
 void debugfs_remove(struct dentry *dentry)
 {
 	struct dentry *parent;
+	int ret = 0;
 	
 	if (!dentry)
 		return;
@@ -284,11 +286,15 @@ void debugfs_remove(struct dentry *dentry)
 	mutex_lock(&parent->d_inode->i_mutex);
 	if (debugfs_positive(dentry)) {
 		if (dentry->d_inode) {
-			if (S_ISDIR(dentry->d_inode->i_mode))
-				simple_rmdir(parent->d_inode, dentry);
-			else
+			if (S_ISDIR(dentry->d_inode->i_mode)) {
+				ret = simple_rmdir(parent->d_inode, dentry);
+				if (ret)
+					printk(KERN_ERR
+						"DebugFS rmdir on %s failed : "
+						"directory not empty.\n",
+						dentry->d_name.name);
+			} else
 				simple_unlink(parent->d_inode, dentry);
-		dput(dentry);
 		}
 	}
 	mutex_unlock(&parent->d_inode->i_mutex);
-- 
1.4.4.2

[PATCH 11/14] DebugFS : file/directory removal fix

[Greg KH]

From: Mathieu Desnoyers <compudj@krystal.dyndns.org>

Fix file and directory removal in debugfs. Add inotify support for file removal.

The following scenario :
create dir a
create dir a/b

cd a/b (some process goes in cwd a/b)

rmdir a/b
rmdir a

fails due to the fact that "a" appears to be non empty. It is because
the "b" dentry is not deleted from "a" and still in use. The same
problem happens if "b" is a file. d_delete is nice enough to know when
it needs to unhash and free the dentry if nothing else is using it or,
if someone is using it, to remove it from the hash queues and wait for
it to be deleted when it has no users.

The nice side-effect of this fix is that it calls the file removal
notification.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 fs/debugfs/inode.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index 554f4a9..c692487 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -286,6 +286,7 @@ void debugfs_remove(struct dentry *dentry)
 	mutex_lock(&parent->d_inode->i_mutex);
 	if (debugfs_positive(dentry)) {
 		if (dentry->d_inode) {
+			dget(dentry);
 			if (S_ISDIR(dentry->d_inode->i_mode)) {
 				ret = simple_rmdir(parent->d_inode, dentry);
 				if (ret)
@@ -295,6 +296,9 @@ void debugfs_remove(struct dentry *dentry)
 						dentry->d_name.name);
 			} else
 				simple_unlink(parent->d_inode, dentry);
+			if (!ret)
+				d_delete(dentry);
+			dput(dentry);
 		}
 	}
 	mutex_unlock(&parent->d_inode->i_mutex);
-- 
1.4.4.2

[PATCH 12/14] Driver core: "platform_driver_probe() can save codespace": save codespace

[Greg KH]

From: Andrew Morton <akpm@osdl.org>

This function can be __init

Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/base/platform.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index d1df4a0..0338289 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -473,7 +473,7 @@ EXPORT_SYMBOL_GPL(platform_driver_unregister);
  * Returns zero if the driver registered and bound to a device, else returns
  * a negative error code and with the driver not registered.
  */
-int platform_driver_probe(struct platform_driver *drv,
+int __init_or_module platform_driver_probe(struct platform_driver *drv,
 		int (*probe)(struct platform_device *))
 {
 	int retval, code;
-- 
1.4.4.2

[PATCH 13/14] Driver core: Make platform_device_add_data accept a const pointer

[Greg KH]

From: Scott Wood <scottwood@freescale.com>

platform_device_add_data() makes a copy of the data that is given to it,
and thus the parameter can be const.  This removes a warning when data
from get_property() on powerpc is handed to platform_device_add_data(),
as get_property() returns a const pointer.

Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/base/platform.c         |    2 +-
 include/linux/platform_device.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 0338289..f9c903b 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -212,7 +212,7 @@ EXPORT_SYMBOL_GPL(platform_device_add_resources);
  *	pointer.  The memory associated with the platform data will be freed
  *	when the platform device is released.
  */
-int platform_device_add_data(struct platform_device *pdev, void *data, size_t size)
+int platform_device_add_data(struct platform_device *pdev, const void *data, size_t size)
 {
 	void *d;
 
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 20f47b8..8bbd459 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -39,7 +39,7 @@ extern struct platform_device *platform_device_register_simple(char *, unsigned
 
 extern struct platform_device *platform_device_alloc(const char *name, unsigned int id);
 extern int platform_device_add_resources(struct platform_device *pdev, struct resource *res, unsigned int num);
-extern int platform_device_add_data(struct platform_device *pdev, void *data, size_t size);
+extern int platform_device_add_data(struct platform_device *pdev, const void *data, size_t size);
 extern int platform_device_add(struct platform_device *pdev);
 extern void platform_device_del(struct platform_device *pdev);
 extern void platform_device_put(struct platform_device *pdev);
-- 
1.4.4.2

[PATCH 14/14] Driver core: deprecate PM_LEGACY, default it to N

[Greg KH]

From: David Brownell <david-b@pacbell.net>

Deprecate the old "legacy" PM API, and more importantly default it to "n".
Virtually nothing in-tree uses it any more.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 kernel/power/Kconfig |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 710ed08..ed29622 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -20,13 +20,14 @@ config PM
 	  sending the processor to sleep and saving power.
 
 config PM_LEGACY
-	bool "Legacy Power Management API"
+	bool "Legacy Power Management API (DEPRECATED)"
 	depends on PM
-	default y
+	default n
 	---help---
-	   Support for pm_register() and friends.
+	   Support for pm_register() and friends.  This old API is obsoleted
+	   by the driver model.
 
-	   If unsure, say Y.
+	   If unsure, say N.
 
 config PM_DEBUG
 	bool "Power Management Debug Support"
-- 
1.4.4.2

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Linus Torvalds]

On Wed, 13 Dec 2006, Greg KH wrote:
>
> 	- userspace io driver interface added.  This allows the ability
> 	  to write userspace drivers for some types of hardware much
> 	  easier than before, going through a simple interface to get
> 	  accesses to irqs and memory regions.  A small kernel portion
> 	  is still needed to handle the irq properly, but that is it.

Ok, what kind of ass-hat idiotic thing is this?

	irqreturn_t uio_irq_handler(int irq, void *dev_id)
	{
	        return IRQ_HANDLED;
	}

exactly what is the point here? No way will I pull this kind of crap. You 
just seem to have guaranteed a dead machine if the irq is level-triggered, 
since it will keep on happening forever.

Please remove.

YOU CANNOT DO IRQ'S BY LETTING USER SPACE SORT IT OUT!

It's really that easy. The irq handler has to be _entirely_ in kernel 
space. No user-space ass-hattery here.

And I don't care one whit if it happens to work on parport with an old 
legacy ISA interrupt that is edge-triggered. That's not even the 
interesting case. Never will be.

NAK NAK NAK NAK.

		Linus

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Greg KH]

On Wed, Dec 13, 2006 at 12:12:04PM -0800, Linus Torvalds wrote:
> 
> 
> On Wed, 13 Dec 2006, Greg KH wrote:
> >
> > 	- userspace io driver interface added.  This allows the ability
> > 	  to write userspace drivers for some types of hardware much
> > 	  easier than before, going through a simple interface to get
> > 	  accesses to irqs and memory regions.  A small kernel portion
> > 	  is still needed to handle the irq properly, but that is it.
> 
> Ok, what kind of ass-hat idiotic thing is this?
> 
> 	irqreturn_t uio_irq_handler(int irq, void *dev_id)
> 	{
> 	        return IRQ_HANDLED;
> 	}
> 
> exactly what is the point here? No way will I pull this kind of crap. You 
> just seem to have guaranteed a dead machine if the irq is level-triggered, 
> since it will keep on happening forever.

It's a stupid test module for the uio core for isa devices.  It's not
the main code, or core.

> Please remove.
> 
> YOU CANNOT DO IRQ'S BY LETTING USER SPACE SORT IT OUT!

I agree, that's why this code doesn't let userspace sort it out.  You
have to have a kernel driver to handle the irq.

> It's really that easy. The irq handler has to be _entirely_ in kernel 
> space. No user-space ass-hattery here.

Agreed.

> And I don't care one whit if it happens to work on parport with an old 
> legacy ISA interrupt that is edge-triggered. That's not even the 
> interesting case. Never will be.

I agree.  But that's all that this test module did.  It handled an isa
interrupt that was edge triggered.

> NAK NAK NAK NAK.

Ok, I can pull this example module out if you want, but people seem to
want examples these days.  If I do that, any objection to the rest?

thanks,

greg k-h

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Linus Torvalds]

On Wed, 13 Dec 2006, Greg KH wrote:
>
> It's a stupid test module for the uio core for isa devices.  It's not
> the main code, or core.

Doesn't matter.

IT IS SO FUNDAMENTALLY AND HORRIBLY WRONG THAT I REFUSE TO HAVE IT IN MY 
TREE.

As an "example", the _only_ thing it can possibly ever do is to just 
confuse people - in other words, it's an _anti_example, not a real one.

> Ok, I can pull this example module out if you want, but people seem to
> want examples these days.  If I do that, any objection to the rest?

I'm really not convinced about the user-mode thing unless somebody can 
show me a good reason for it. Not just some "wouldn't it be nice" kind of 
thing. A real, honest-to-goodness reason that we actually _want_ to see 
used.

No features just for features sake.

So please push the tree without this userspace IO driver at all. And if 
you actually have a real user, not just an example, that is worthy and 
shows why such a driver in user space is actually a good thing, _then_ we 
can push that.

In other words, I'd like to see code that uses this that is actually 
_better_ than an in-kernel driver in some way.

For USB, the user-mode thing made sense. You have tons of random devices, 
and the abstraction level is higher to begin with. Quite frankly, I simply 
don't even see the same being true for something like this.

Btw: there's one driver we _know_ we want to support in user space, and 
that's the X kind of direct-rendering thing. So if you can show that this 
driver infrastructure actually makes sense as a replacement for the DRI 
layer, then _that_ would be a hell of a convincing argument.

There may be others. Feel free to fill in the blank: ________.

		Linus

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Linus Torvalds]

On Wed, 13 Dec 2006, Linus Torvalds wrote:
> 
> Btw: there's one driver we _know_ we want to support in user space, and 
> that's the X kind of direct-rendering thing. So if you can show that this 
> driver infrastructure actually makes sense as a replacement for the DRI 
> layer, then _that_ would be a hell of a convincing argument.

Btw, the other side of this argument is that if a user-space driver 
infrastructure can _not_ help the DRI kind of situation, then it's largely 
by definition not interesting. Merging something like that would just mean 
that we end up with multiple _different_ user-space helper infrastructure 
shells, which sounds distinctly unpalatable.

		Linus

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Arjan van de Ven]

On Wed, 2006-12-13 at 13:08 -0800, Linus Torvalds wrote:
> 
> On Wed, 13 Dec 2006, Linus Torvalds wrote:
> > 
> > Btw: there's one driver we _know_ we want to support in user space, and 
> > that's the X kind of direct-rendering thing. So if you can show that this 
> > driver infrastructure actually makes sense as a replacement for the DRI 
> > layer, then _that_ would be a hell of a convincing argument.
> 
> Btw, the other side of this argument is that if a user-space driver 
> infrastructure can _not_ help the DRI kind of situation, then it's largely 

with DRI you have the case where "something" needs to do security
validation of the commands that are sent to the card. (to avoid a
non-privileged user to DMA all over your memory)

That and a tiny bit of resource management is the bulk of the kernel DRM
code... and I don't think userspace can do it fundamentally better.
Sure you could pipe things to a root daemon instead of doing a system
call. But I don't see that being superior.

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Muli Ben-Yehuda]

On Wed, Dec 13, 2006 at 10:15:47PM +0100, Arjan van de Ven wrote:

> with DRI you have the case where "something" needs to do security
> validation of the commands that are sent to the card. (to avoid a
> non-privileged user to DMA all over your memory)

We also have the interesting case where your card is behind an
isolation-capable IOMMU, so if you let userspace program it, you need
a userspace-accessible DMA-API for IOMMU mappings (or to pre-map
everything in the IOMMU, which loses on some of the benefits of
isolation-capable IOMMUs (i.e., only map what you need to use right
now)).

Cheers,
Muli

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Hans-Jürgen Koch]

Am Donnerstag, 14. Dezember 2006 10:30 schrieb Muli Ben-Yehuda:
> On Wed, Dec 13, 2006 at 10:15:47PM +0100, Arjan van de Ven wrote:
> 
> > with DRI you have the case where "something" needs to do security
> > validation of the commands that are sent to the card. (to avoid a
> > non-privileged user to DMA all over your memory)
> 
> We also have the interesting case where your card is behind an
> isolation-capable IOMMU, so if you let userspace program it, you need
> a userspace-accessible DMA-API for IOMMU mappings (or to pre-map
> everything in the IOMMU, which loses on some of the benefits of
> isolation-capable IOMMUs (i.e., only map what you need to use right
> now)).

Userspace IO (UIO) was never intended to replace all kinds of possible
drivers. We wanted to address the situation where a manufacturer of
industrial I/O cards wants to do a large part of his driver in userspace
to simplify his development process. That's all.
Most of these I/O cards have registers or dual ported RAM that can be
mapped to userspace. This is possible with a standard kernel and is done
every day. Problem is that you can't handle interrupts. UIO simply adds
this capability and offers a standardized interface.
The code Greg added to his tree can do this for most hardware found
on industrial IO boards. That's all we wanted to achieve for now. If 
somebody wants to support more sophisticated things, suggestions are
welcome.

Hans

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Thomas Gleixner]

On Wed, 2006-12-13 at 12:58 -0800, Linus Torvalds wrote:
> In other words, I'd like to see code that uses this that is actually 
> _better_ than an in-kernel driver in some way.
> 
> For USB, the user-mode thing made sense. You have tons of random devices, 
> and the abstraction level is higher to begin with. Quite frankly, I simply 
> don't even see the same being true for something like this.

We started to work on this for industrial I/O devices. Many of them are
dual port memory based, others are dedicated chips for motion control or
field busses.

The design requires to have an in kernel stub driver with interrupt
handler which is capable to handle shared interrupts. User space
_cannot_ override an irq_disable(), it just has access to the chip
registers of the device, which is possible right now as well.

The risk, that such a driver stalls the kernel is exactly the same as
the risk you have with any other badly written driver.

This is a real world example of such a drivers interrupt handler:

/*
 * The chip specific portion of the interrupt handler. The framework code
 * takes care of userspace notification when we return IRQ_HANDLED
 */
static irqreturn_t sercos_handler(int irq, void *dev_id, struct pt_regs *reg)
{
        /* Check, if this interrupt is originated from the SERCOS chip */
        if (!(sercos_read(IRQ_STATUS) & SERCOS_INTERRUPT_MASK))
                return IRQ_NONE;

        /* Acknowledge the chip interrupts */
        sercos_write(IRQ_ACK1, SERCOS_INTERRUPT_ACK1);
        sercos_write(IRQ_ACK2, SERCOS_INTERRUPT_ACK2);

        return IRQ_HANDLED;
}

With a full kernel driver we need:

1. Interrupt handler
	check interrupt
	acknowledge interrupt
	copy data from/to chip into a kernel buffer
	wakeup user space task
2. read data from driver, which goes through copy to user
3. do calculations
4. write data to driver, which goes through copy from user

After changing the driver concept we have only:
1. Interrupt handler
	check interrupt
	acknowledge interrupt
	wakeup user space task
2. User space task handles the mmaped chip directly

The change gave a serious performance gain in the range of 20% after the
application was optimized for dealing with the chip directly.

There are tons of such exotic hardware devices out there, which now have
either a closed source driver or an out of tree patch with an horrible
amount of individual ioctl functions to get to the same point with less
performance.

> Btw: there's one driver we _know_ we want to support in user space, and 
> that's the X kind of direct-rendering thing. So if you can show that this 
> driver infrastructure actually makes sense as a replacement for the DRI 
> layer, then _that_ would be a hell of a convincing argument.

I did not look closely into that, but I think that it is a valid usage
candidate. The interface of graphic cards is user space mappable and it
probably needs some interrupt handling + notification mechanism as well
as the devices mentioned above.

	tglx

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Benjamin Herrenschmidt]

> Btw: there's one driver we _know_ we want to support in user space, and 
> that's the X kind of direct-rendering thing. So if you can show that this 
> driver infrastructure actually makes sense as a replacement for the DRI 
> layer, then _that_ would be a hell of a convincing argument.

And even X is trying to move away from that at least partially... With
the DRI driver handling IRQs and processing command buffers... except
for cards with multiple hardware contexts, but then, we are in a case
similar to Infiniband where the HW is -designed- to have specific areas
mapped into user space, and there is still a kernel driver to arbitrate,
decide who gets what, establish those mappings, etc...

Thus X isn't even a good example :-)

Ben.

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Greg KH]

On Wed, Dec 13, 2006 at 12:58:24PM -0800, Linus Torvalds wrote:
> I'm really not convinced about the user-mode thing unless somebody can 
> show me a good reason for it. Not just some "wouldn't it be nice" kind of 
> thing. A real, honest-to-goodness reason that we actually _want_ to see 
> used.
> 
> No features just for features sake.

Ok, Thomas just showed at least one example of where this interface is a
big advantage over the all-in-kernel model.  I'll work with him and try
to dig up other real examples before submitting this code again.

In the mean time, I'll leave it in my tree and it will get some more
exposure in the -mm releases.

> So please push the tree without this userspace IO driver at all.

Done.

Please pull from:
	master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/

It contains the changes listed below.

thanks,

greg k-h


 drivers/base/class.c            |    2 ++
 drivers/base/platform.c         |    4 ++--
 fs/debugfs/inode.c              |   39 ++++++++++++++++++++++++++++++---------
 include/linux/platform_device.h |    2 +-
 kernel/module.c                 |   25 +++++++++++++++++++++++++
 kernel/power/Kconfig            |    9 +++++----
 6 files changed, 65 insertions(+), 16 deletions(-)

---------------

Akinobu Mita (1):
      driver core: delete virtual directory on class_unregister()

Andrew Morton (1):
      Driver core: "platform_driver_probe() can save codespace": save codespace

David Brownell (1):
      Driver core: deprecate PM_LEGACY, default it to N

Kay Sievers (1):
      Driver core: show "initstate" of module

Mathieu Desnoyers (5):
      DebugFS : inotify create/mkdir support
      DebugFS : coding style fixes
      DebugFS : file/directory creation error handling
      DebugFS : more file/directory creation error handling
      DebugFS : file/directory removal fix

Scott Wood (1):
      Driver core: Make platform_device_add_data accept a const pointer

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Duncan Sands]

> I'm really not convinced about the user-mode thing unless somebody can 
> show me a good reason for it. Not just some "wouldn't it be nice" kind of 
> thing. A real, honest-to-goodness reason that we actually _want_ to see 
> used.

Qemu?  It would be nice if emulators could directly drive hardware:
useful for reverse engineering windows drivers for example.

Duncan.

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Hans-Jürgen Koch]

Am Donnerstag, 14. Dezember 2006 09:49 schrieb Duncan Sands:
> > I'm really not convinced about the user-mode thing unless somebody can 
> > show me a good reason for it. Not just some "wouldn't it be nice" kind of 
> > thing. A real, honest-to-goodness reason that we actually _want_ to see 
> > used.
> 
> Qemu?  It would be nice if emulators could directly drive hardware:
> useful for reverse engineering windows drivers for example.

I really think there is a big misunderstanding in this whole discussion.
Userspace IO (UIO) was never intended to be a generic userspace 
interface to all kinds of hardware. I completely agree with Linus and all
others who expressed that opinion that a full-fledged kernel module is the,
let's say, most beautiful way of writing a driver. But it's not always the
best way. Let's look at a real world example:

A small German manufacturer produces high-end AD converter cards. He sells
100 pieces per year, only in Germany and only with Windows drivers. He would
now like to make his cards work with Linux. He has two driver programmers
with little experience in writing Linux kernel drivers. What do you tell him?
Write a large kernel module from scratch? Completely rewrite his code 
because it uses floating point arithmetics?

And even if they did that, do we really want it? Do we want to add large
kernel modules for each exotic card? With UIO, everything becomes much cleaner:

* They let somebody write the small kernel module they need to handle 
interrupts in a _clean_ way. This module can easily be checked and could
even be included in a mainline kernel.

* They do the rest in userspace, with all the libraries and tools they're
used to. That's what they _can_ do.

Note that this is a _technical_ reason. I'm not talking about all that
licensing possibilities that were discussed here.

UIO's intention is to allow manufacturers of industrial IO hardware to
support Linux without the need to hire half a dozen experienced kernel
developers. It makes their kernels more stable and easier to maintain.
We don't get flooded with requests to include large modules for exotic
hardware into the mainline kernel. 

The alternative is what we have at the moment: Manufacturers don't support
Linux at all, because it's too difficult to handle for them, or they do
it in a way that either violates our licence or leads to unstable 
customized kernels (or both).

So, your qemu suggestion is certainly interesting. But, really, we never
thought of such a general thing while we were working at that code.
I thought I had to make that clear. Reading this thread, one could get
the impression we wanted to start a revolution and handle all hardware
in userspace from now on. This is definetly wrong.

Hans

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Olivier Galibert]

On Thu, Dec 14, 2006 at 10:56:03AM +0100, Hans-Jürgen Koch wrote:
> A small German manufacturer produces high-end AD converter cards. He sells
> 100 pieces per year, only in Germany and only with Windows drivers. He would
> now like to make his cards work with Linux. He has two driver programmers
> with little experience in writing Linux kernel drivers. What do you tell him?
> Write a large kernel module from scratch? Completely rewrite his code 
> because it uses floating point arithmetics?

Write a small kernel module which:
- create a device node per-card
- read the data from the A/D as fast as possible and buffer it in main
  memory without touching it
- implements a read interface to read data from the buffer
- implement ioctls for whatever controls you need

And that's it.  All the rest can be done in userspace, safely, with
floating point, C++ and everything.  If the driver programmers are
worth their pay, their driver is probably already split logically at
where the userspace-kernel interface would be.

And small means small, like 200 lines or so, more if you want to have
fun with sysfs, poll, aio and their ilk, but that's not a necessity.

  OG.

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Hans-Jürgen Koch]

Am Donnerstag, 14. Dezember 2006 12:51 schrieb Olivier Galibert:
> On Thu, Dec 14, 2006 at 10:56:03AM +0100, Hans-Jürgen Koch wrote:
> > A small German manufacturer produces high-end AD converter cards. He sells
> > 100 pieces per year, only in Germany and only with Windows drivers. He would
> > now like to make his cards work with Linux. He has two driver programmers
> > with little experience in writing Linux kernel drivers. What do you tell him?
> > Write a large kernel module from scratch? Completely rewrite his code 
> > because it uses floating point arithmetics?
> 
> Write a small kernel module which:

What you suggest is not a "small kernel module". It's what we have now,
writing a complete driver.

> - create a device node per-card

That's what UIO does, plus some standard sysfs files, that tell you e.g.
the size of the cards memory you can map. There are standard file names
that allow you e.g. to automatically search for all registered uio 
drivers and their properties.

> - read the data from the A/D as fast as possible and buffer it in main
>   memory without touching it

If the card already has that data in its dual port RAM, you do an
unneccessary copy.

> - implements a read interface to read data from the buffer

Here you do the next unneccessary copy.

> - implement ioctls for whatever controls you need

Implementing ioctls for everything is bad coding style and a has bad
performance. I said "high-end AD card", that means you have a 
signal processor on that board, want to download firmware to it 
and so on. You end up copying lots of data between user space
and kernel space.

> 
> And that's it.  

Yes, that's a complete kernel driver that you'd never get into
a mainline kernel. Furthermore, the card manufacturer would have to
employ at least two experienced Linux _kernel_ programmers. That's
too much for a small company who's business is something different.

> All the rest can be done in userspace, safely, with 
> floating point, C++ and everything.  If the driver programmers are
> worth their pay, their driver is probably already split logically at
> where the userspace-kernel interface would be.
> 
> And small means small, like 200 lines or so, more if you want to have
> fun with sysfs, poll, aio and their ilk, but that's not a necessity.

You can achieve 100 lines with uio, including sysfs and poll. What you
describe would never fit in 200 lines for a non-trivial card.

Hans

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Olivier Galibert]

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

On Thu, Dec 14, 2006 at 01:45:16PM +0100, Hans-Jürgen Koch wrote:
> What you suggest is not a "small kernel module". It's what we have now,
> writing a complete driver.

Who says a complete driver has to be big?


> That's what UIO does, plus some standard sysfs files, that tell you e.g.
> the size of the cards memory you can map. There are standard file names
> that allow you e.g. to automatically search for all registered uio 
> drivers and their properties.

Which makes the userspace code much more complex than needed.


> If the card already has that data in its dual port RAM, you do an
> unneccessary copy.

Unnecessary only if
  [card data rate]*[maximum userspace latency] < [dual port ram size].

Doing the buffering in the kernel where it belongs changes the right
part of the equation to [buffer size], which can be orders of
magnitude way bigger.  And you can have the card DMA into the buffer
directly if you feel like it.


> > - implements a read interface to read data from the buffer
> 
> Here you do the next unneccessary copy.

You can mmap, you can splice(), none is really hard.


> > - implement ioctls for whatever controls you need
> 
> Implementing ioctls for everything is bad coding style and a has bad
> performance.

I thought the ALSA guys always said their stuff was high performance?

In any case, if ioctl is too slow for your controls, it means that
your ioctls are too low level, as in register access instead of
"reboot card at address x".  And uio, with its lack of protection
against wandering interrupts, can't cut it.


> I said "high-end AD card", that means you have a 
> signal processor on that board, want to download firmware to it 
> and so on. You end up copying lots of data between user space
> and kernel space.

You're allowed to implement write() too.


> Yes, that's a complete kernel driver that you'd never get into
> a mainline kernel. Furthermore, the card manufacturer would have to
> employ at least two experienced Linux _kernel_ programmers. That's
> too much for a small company who's business is something different.

So they have a choice between learning a minimum of linux kernel
internals, or a minimum of uio.  I suspect the hidden kinks of uio and
relative lack of documentation make the kernel route *way* easier.


> You can achieve 100 lines with uio, including sysfs and poll. What you
> describe would never fit in 200 lines for a non-trivial card.

Ok, 200 is an exaggeration.  Here is a 600-lines 2.4 driver that does
what I say, with direct dma to the internal buffer from the card and
userland-driven firmware upload.  I know that a 2.6 version would
actually be smaller.

  OG.


[-- Attachment #2: iiadc64.c --]
[-- Type: text/x-csrc, Size: 14658 bytes --]

//========================= Official Notice ===============================
//
// "This software was developed at the National Institute of Standards
// and Technology by employees of the Federal Government in the course of
// their official duties. Pursuant to Title 17 Section 105 of the United
// States Code this software is not subject to copyright protection and
// is in the public domain.
//
// The NIST Data Flow System (NDFS) is an experimental system and is
// offered AS IS. NIST assumes no responsibility whatsoever for its use
// by other parties, and makes no guarantees and NO WARRANTIES, EXPRESS
// OR IMPLIED, about its quality, reliability, fitness for any purpose,
// or any other characteristic.
//
// We would appreciate acknowledgement if the software is used.
//
// This software can be redistributed and/or modified freely provided
// that any derivative works bear some notice that they are derived from
// it, and any modified versions bear some notice that they have been
// modified from the original."
//
//=========================================================================




#include <linux/version.h>
#include <linux/module.h>
#include <linux/delay.h>
#include <linux/errno.h>
#include <linux/fs.h>
#include <linux/kernel.h>
#include <linux/major.h>
#include <linux/slab.h>
#include <linux/mm.h>
#include <linux/poll.h>
#include <linux/pci.h>
#include <linux/signal.h>
#include <asm/io.h>
#include <linux/ioport.h>
#include <asm/pgtable.h>
#include <asm/page.h>
#include <linux/sched.h>
#include <asm/segment.h>
#include <linux/types.h>
#include <linux/wrapper.h>
#include <linux/interrupt.h>
#include <linux/kmod.h>
#include <linux/vmalloc.h>
#include <linux/init.h>

#include "iiadc64.h"

#define DEBUG_AL(format, a...) printk(KERN_WARNING format, ##a)
#define DEBUG_ER(format, a...) printk(KERN_WARNING format, ##a)
#define DEBUG_WR(format, a...) printk(KERN_WARNING format, ##a)
#define DEBUG_IN(format, a...) printk(KERN_WARNING format, ##a)
#define DEBUG_TR(format, a...) printk(KERN_WARNING format, ##a)

enum{ MODE_MEMORY, MODE_RING, MODE_MAILBOX };
enum{ RING_SIZE = 4096*4096 };

static int iiadc64_open(struct inode *, struct file *);
static int iiadc64_release(struct inode *, struct file *);
static int iiadc64_ioctl(struct inode *, struct file *, unsigned int, unsigned long);
static ssize_t iiadc64_read(struct file *, char *, size_t, loff_t *);
static ssize_t iiadc64_write(struct file *, const char *, size_t, loff_t *);

static struct file_operations iiadc64_fops = {
  open:    iiadc64_open,
  release: iiadc64_release,
  ioctl:   iiadc64_ioctl,
  read:    iiadc64_read,
  write:   iiadc64_write
};

struct iiadc64_state {
  struct pci_dev *dev;
  unsigned long iobase;
  unsigned int irq;
  unsigned char  *memory;
  int access_mode, access_mbox;
  int irqen;
  int irqtick;
  int ring_rpos, ring_wpos;
  int dropouts;
  spinlock_t lock;

#if LINUX_VERSION_CODE >= 0x20300
  wait_queue_head_t ring_wait;
#else
  struct wait_queue *ring_wait;
#endif
} is;


/* [DaveM] I've recoded most of this so that:
 * 1) It's easier to tell what is happening
 * 2) It's more portable, especially for translating things
 *    out of vmalloc mapped areas in the kernel.
 * 3) Less unnecessary translations happen.
 *
 * The code used to assume that the kernel vmalloc mappings
 * existed in the page tables of every process, this is simply
 * not guarenteed.  We now use pgd_offset_k which is the
 * defined way to get at the kernel page tables.
 */

/* Given PGD from the address space's page table, return the kernel
 * virtual mapping of the physical memory mapped at ADR.
 */
static inline unsigned long uvirt_to_kva(pgd_t *pgd, unsigned long adr)
{
  unsigned long ret = 0UL;
  pmd_t *pmd;
  pte_t *ptep, pte;
  
  if (!pgd_none(*pgd)) {
    pmd = pmd_offset(pgd, adr);
    if (!pmd_none(*pmd)) {
      ptep = pte_offset(pmd, adr);
      pte = *ptep;
      if(pte_present(pte)) {
	ret  = (unsigned long) page_address(pte_page(pte));
	ret |= (adr & (PAGE_SIZE - 1));
				
      }
    }
  }
  return ret;
}

static inline unsigned long uvirt_to_bus(unsigned long adr) 
{
  unsigned long kva, ret;

  kva = uvirt_to_kva(pgd_offset(current->mm, adr), adr);
  ret = virt_to_bus((void *)kva);
  return ret;
}

static inline unsigned long kvirt_to_bus(unsigned long adr) 
{
  unsigned long va, kva, ret;

  va = VMALLOC_VMADDR(adr);
  kva = uvirt_to_kva(pgd_offset_k(va), va);
  ret = virt_to_bus((void *)kva);
  return ret;
}

/* Here we want the physical address of the memory.
 * This is used when initializing the contents of the
 * area and marking the pages as reserved.
 */
static inline unsigned long kvirt_to_pa(unsigned long adr) 
{
  unsigned long va, kva, ret;

  va = VMALLOC_VMADDR(adr);
  kva = uvirt_to_kva(pgd_offset_k(va), va);
  ret = __pa(kva);
  return ret;
}

static void * rvmalloc(signed long size)
{
  void * mem;
  unsigned long adr, page;

  mem=vmalloc_32(size);
  if (mem) 
    {
      memset(mem, 0, size); /* Clear the ram out, no junk to the user */
      adr=(unsigned long) mem;
      while (size > 0) 
	{
	  page = kvirt_to_pa(adr);
	  mem_map_reserve(virt_to_page(__va(page)));
	  adr+=PAGE_SIZE;
	  size-=PAGE_SIZE;
	}
    }
  return mem;
}

static void rvfree(void * mem, signed long size)
{
  unsigned long adr, page;
        
  if (mem) 
    {
      adr=(unsigned long) mem;
      while (size > 0) 
	{
	  page = kvirt_to_pa(adr);
	  mem_map_unreserve(virt_to_page(__va(page)));
	  adr+=PAGE_SIZE;
	  size-=PAGE_SIZE;
	}
      vfree(mem);
    }
}

static unsigned int iiadc64_mailbox_read(int box)
{
  int counter = 100000;
  int mask = 0xf0000 << (box*4);
  while(!(inl(is.iobase + 0x34) & mask) && (--counter));
  if(!counter)
    DEBUG_ER("iiadc64:  Timeout on mailbox %d read\n", box);
  return inl(is.iobase + 0x10 + 4*box);
}

static int iiadc64_mailbox_check_read(int box)
{
  int mask = 0xf0000 << (box*4);
  return (inl(is.iobase + 0x34) & mask) != 0;
}

static void iiadc64_mailbox_write(int box, unsigned int data)
{
  int counter = 100000;
  int mask = 0xf << box;
  while((inl(is.iobase + 0x34) & mask) && (--counter));
  if(!counter)
    DEBUG_ER("iiadc64:  Timeout on mailbox %d write\n", box);
  outl(data, is.iobase + 4*box);
}

static void iiadc64_irq(int irq, void *dev_id, struct pt_regs *regs)
{
  unsigned int istat;
  istat = inl(is.iobase + 0x38);

  if(istat & 0x20000) {
    unsigned int request = iiadc64_mailbox_read(1);

    if(request == 1) {
      spin_lock(&is.lock);
      is.ring_wpos = 0;
      is.ring_rpos = 0;
      is.dropouts = 0;
      spin_unlock(&is.lock);

      iiadc64_mailbox_write(0, 0);
    } else {
      int delta;
      int csize;
      request *= 4096;
      delta = request - is.ring_wpos;
      if(delta < 0)
	delta += RING_SIZE;

      spin_lock(&is.lock);
      csize = is.ring_wpos - is.ring_rpos;
      if(csize < 0)
	csize += RING_SIZE;
      if(csize + delta > RING_SIZE)
	is.dropouts++;

      is.ring_wpos = request;
      is.irqtick++;
      spin_unlock(&is.lock);
      wake_up_interruptible(&is.ring_wait);
    }
  }

  if(istat & 0x800000)
    outl(istat, is.iobase + 0x38);
}

static void iiadc64_reset(void)
{
  unsigned int intcsr;
  unsigned int timeout;
  unsigned int val;

  if(is.irqen)
    intcsr = 0x003f1400;
  else
    intcsr = 0x003f0000;

  outl(intcsr, is.iobase + 0x38);
  outl(0x0f000000, is.iobase + 0x3c);
  timeout = HZ/10;
  do {
    current->state = TASK_INTERRUPTIBLE;
    timeout = schedule_timeout(timeout);
  } while (timeout);
  outl(0x00000000, is.iobase + 0x3c);
  timeout = HZ/5;
  do {
    current->state = TASK_INTERRUPTIBLE;
    timeout = schedule_timeout(timeout);
  } while (timeout);

  if(is.irqen)
    outl(0x00000600, is.iobase + 0x3c);

  val = iiadc64_mailbox_read(0);
  if(val != 0x1f)
    DEBUG_ER("iiadc64: Wrong value in mailbox 0 after reset : %08x\n", val);
  else
    DEBUG_IN("iiadc64: Reset successful\n");

  while(iiadc64_mailbox_check_read(0))
    (void)iiadc64_mailbox_read(0);

  is.ring_rpos = 0;
  is.ring_wpos = 0;
}

static int iiadc64_open(struct inode *inode, struct file *file)
{
  is.access_mode = MODE_MEMORY;
  is.irqtick = 0;
  is.ring_wpos = is.ring_rpos = 0;
  is.dropouts = 0;
  if(request_irq(is.irq, iiadc64_irq, SA_SHIRQ, "iiadc64", &is)) {
    DEBUG_ER("iiadc64: Couldn't get shared irq %d\n", is.irq);
    return -EIO;
  }
  is.irqen = 1;
  iiadc64_reset();
  
  MOD_INC_USE_COUNT;
  return 0;
}

static int iiadc64_release(struct inode *inode, struct file *file)
{
  is.irqen = 0;
  iiadc64_reset();
  free_irq(is.irq, &is);
  
  MOD_DEC_USE_COUNT;
  return 0;
}

static int iiadc64_ioctl(struct inode *inode, struct file *file, unsigned int cmd, unsigned long param)
{
  switch(cmd) {
  case II_RESET:
    iiadc64_reset();
    break;

  case II_MODE_MEMORY:
    is.access_mode = MODE_MEMORY;
    break;

  case II_MODE_RING:
    is.access_mode = MODE_RING;
    break;

  case II_MODE_MAILBOX: {
    int mbox, err;
    err = get_user(mbox, (int *)param);
    if(err)
      return err;
    if(mbox<0 || mbox>3)
      return -EINVAL;
    
    is.access_mode = MODE_MAILBOX;
    is.access_mbox = mbox;
    break;
  }

  case II_PCI_TABLE: {
    unsigned int adr;
    int err;
    int i;
    err = get_user(adr, (unsigned int *)param);
    if(err)
      return err;

    for(i=0; i<RING_SIZE/4096; i++) {
      iiadc64_mailbox_write(0, 1);
      iiadc64_mailbox_write(0, adr++);
      iiadc64_mailbox_write(0, kvirt_to_bus((unsigned long)is.memory+i*4096));
    }

    break;
  }

  case II_RUN: {
    unsigned int adr;
    int err;
    err = get_user(adr, (unsigned int *)param);
    if(err)
      return err;
	
    iiadc64_mailbox_write(0, 3);
    iiadc64_mailbox_write(0, adr);
    break;
  }

  default:
    return -ENOTTY;
  }
  return 0;
}

static ssize_t iiadc64_read(struct file *file, char *buf, size_t size, loff_t *offset)
{
  switch(is.access_mode) {
  case MODE_MEMORY: {
    size_t cur_size;
    int adr = *offset / 4;
    
    cur_size = size;
    while(cur_size > 0) {
      size_t block_size = cur_size;
      unsigned int *data = (unsigned int *)is.memory;
      size_t cb_size;
      
      if(block_size > PAGE_SIZE)
	block_size = PAGE_SIZE;
      
      cur_size -= block_size;
      cb_size = block_size;
      
      while(cb_size) {
	iiadc64_mailbox_write(0, 2);
	iiadc64_mailbox_write(0, adr++);
	*data++ = iiadc64_mailbox_read(0);
	cb_size -= 4;
      }
      
      if(copy_to_user(buf, (const void *)is.memory, block_size))
	return -EFAULT;
      buf += block_size;
    }
    
    *offset += size;
    return size;
  }
  case MODE_RING: {
    size_t cur_size;
    unsigned long flags;
    int avail, dropouts;

    cur_size = size;
    while(cur_size) {
      size_t block_size;
      spin_lock_irqsave(&is.lock, flags);
      while(is.ring_wpos == is.ring_rpos) {
	spin_unlock_irqrestore(&is.lock, flags);

	interruptible_sleep_on(&is.ring_wait);
	if (signal_pending(current)) {
	  DEBUG_TR("iiadc64: ERESTARTSYS\n");
	  return -ERESTARTSYS;
	}
	spin_lock_irqsave(&is.lock, flags);
      }

      avail = is.ring_wpos - is.ring_rpos;
      spin_unlock_irqrestore(&is.lock, flags);

      if(avail < 0)
	avail += RING_SIZE;

      block_size = cur_size;
      if(block_size > avail)
	block_size = avail;
      if(block_size + is.ring_rpos > RING_SIZE)
	block_size = RING_SIZE - is.ring_rpos;

      if(copy_to_user(buf, (const void *)(is.memory + is.ring_rpos), block_size))
	return -EFAULT;

      spin_lock_irqsave(&is.lock, flags);
      is.ring_rpos += block_size;
      if(is.ring_rpos == RING_SIZE)
	is.ring_rpos = 0;

      dropouts = is.dropouts;
      is.dropouts = 0;
      spin_unlock_irqrestore(&is.lock, flags);

      if(dropouts)
	DEBUG_ER("iiadc64:  Dropout detected\n");

      buf += block_size;
      cur_size -= block_size;
    }
    *offset += size;
    return size;
  }
  case MODE_MAILBOX: {
    size_t cur_size = size;
    for(;;) {
      unsigned int val = iiadc64_mailbox_read(is.access_mbox);
      if(put_user(val, (unsigned int *)buf))
	return -EFAULT;
      buf += sizeof(unsigned int);
      if(cur_size <= sizeof(unsigned int))
	break;
      cur_size -= sizeof(unsigned int);
    }
    *offset += size;
    return size;
  }
  default:
    return -ENOTTY;
  }
}

static ssize_t iiadc64_write(struct file *file, const char *buf, size_t size, loff_t *offset)
{
  switch(is.access_mode) {
  case MODE_MEMORY: {
    size_t cur_size;
    int adr = *offset / 4;
    
    cur_size = size;
    while(cur_size > 0) {
      size_t block_size = cur_size;
      unsigned int *data = (unsigned int *)is.memory;
      
      if(block_size > PAGE_SIZE)
	block_size = PAGE_SIZE;
      
      if(copy_from_user((void *)is.memory, buf, block_size))
	return -EFAULT;
      buf += block_size;
      cur_size -= block_size;
      
      while(block_size) {
	iiadc64_mailbox_write(0, 1);
	iiadc64_mailbox_write(0, adr++);
	iiadc64_mailbox_write(0, *data++);
	block_size -= 4;
      }
    }
    
    *offset += size;
    return size;
  }
  case MODE_MAILBOX: {
    size_t cur_size = size;
    for(;;) {
      unsigned int val;
      if(get_user(val, (unsigned int *)buf))
	return -EFAULT;
      iiadc64_mailbox_write(is.access_mbox, val);
      buf += sizeof(unsigned int);
      if(cur_size <= sizeof(unsigned int))
	break;
      cur_size -= sizeof(unsigned int);
    }
    *offset += size;
    return size;
  }
  default:
    return -ENOTTY;
  }
}


#ifdef MODULE
int init_module(void)
#else
  int iiadc64_init(void)
#endif
{
  DEBUG_AL("IIADC64 minimal kernel driver (c) 1999 Olivier Galibert\n");

  is.dev = pci_find_device(0x10e8, 0x807f, 0);
  if(!is.dev) {
    DEBUG_ER("iiadc64: Unable to find the DSP board\n");
    return -EIO;
  }

#if LINUX_VERSION_CODE >= 0x20400
  if(pci_enable_device(is.dev))
    return -EIO;

  pci_set_master(is.dev);

  is.iobase = pci_resource_start(is.dev, 0);
#else
  is.iobase = is.dev->base_address[0] & PCI_BASE_ADDRESS_IO_MASK;
#endif
  is.irq = is.dev->irq;
  is.memory = rvmalloc(RING_SIZE);

  if(!is.memory) {
    DEBUG_ER("iiadc64: Couldn't allocate ring buffer\n");
    return -EIO;
  }

  if (register_chrdev(II_MAJOR, "iiadc64", &iiadc64_fops)) {
    DEBUG_ER("iiadc64: Unable to register character device\n");
    return -EIO;
  }

  DEBUG_IN("iiadc64: DSP board found, io at 0x%lx, irq %u\n", is.iobase, is.irq);

#if LINUX_VERSION_CODE >= 0x20300
  init_waitqueue_head(&is.ring_wait);
#else
  is.ring_wait = 0;
  init_waitqueue(&is.ring_wait);
#endif

  is.lock = SPIN_LOCK_UNLOCKED;

  iiadc64_reset();

  return 0;
}

#ifdef MODULE
void cleanup_module(void)
{
  rvfree(is.memory, RING_SIZE);
  unregister_chrdev(II_MAJOR, "iiadc64");
}
#endif

[-- Attachment #3: iiadc64.h --]
[-- Type: text/x-chdr, Size: 1477 bytes --]

//========================= Official Notice ===============================
//
// "This software was developed at the National Institute of Standards
// and Technology by employees of the Federal Government in the course of
// their official duties. Pursuant to Title 17 Section 105 of the United
// States Code this software is not subject to copyright protection and
// is in the public domain.
//
// The NIST Data Flow System (NDFS) is an experimental system and is
// offered AS IS. NIST assumes no responsibility whatsoever for its use
// by other parties, and makes no guarantees and NO WARRANTIES, EXPRESS
// OR IMPLIED, about its quality, reliability, fitness for any purpose,
// or any other characteristic.
//
// We would appreciate acknowledgement if the software is used.
//
// This software can be redistributed and/or modified freely provided
// that any derivative works bear some notice that they are derived from
// it, and any modified versions bear some notice that they have been
// modified from the original."
//
//=========================================================================



#ifndef __IIADC64_H
#define __IIADC64_H

#include <linux/ioctl.h>

#define II_MAJOR 121

#define II_RESET		_IO(II_MAJOR, 0)
#define II_MODE_MEMORY		_IO(II_MAJOR, 1)
#define II_MODE_RING		_IO(II_MAJOR, 2)
#define II_MODE_MAILBOX		_IOR(II_MAJOR, 3, int)
#define II_PCI_TABLE		_IOR(II_MAJOR, 4, unsigned int)
#define II_RUN			_IOR(II_MAJOR, 5, unsigned int)

#endif

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Alan]

On Thu, 14 Dec 2006 10:56:03 +0100
Hans-Jürgen Koch <hjk@linutronix.de> wrote:

> * They let somebody write the small kernel module they need to handle 
> interrupts in a _clean_ way. This module can easily be checked and could
> even be included in a mainline kernel.

And might as well do the mmap work as well. I'm not clear what uio gives
us that a decently written pair of PCI and platform template drivers for
people to use would not do more cleanly.

Also many of these cases you might not want stuff in userspace but the
uio model would push it that way which seems to be an unfortunate side
effect. Yes some probably do want to go that way but not all.

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Hans-Jürgen Koch]

Am Donnerstag, 14. Dezember 2006 13:39 schrieb Alan:
> On Thu, 14 Dec 2006 10:56:03 +0100
> Hans-Jürgen Koch <hjk@linutronix.de> wrote:
> 
> > * They let somebody write the small kernel module they need to handle 
> > interrupts in a _clean_ way. This module can easily be checked and could
> > even be included in a mainline kernel.
> 
> And might as well do the mmap work as well. I'm not clear what uio gives
> us that a decently written pair of PCI and platform template drivers for
> people to use would not do more cleanly.

* Creation of /dev device files.
* Creation of standardized sysfs files.
* Interrupt registration and handling.
* mmap for physical and logical memory.
* read, poll, and fasync for interrupt handling.
* a predefined, clean design that the hardware manufacturer can use.

> 
> Also many of these cases you might not want stuff in userspace but the
> uio model would push it that way which seems to be an unfortunate side
> effect. Yes some probably do want to go that way but not all.

Alright, but everybody has the choice. If the alternative is to have no
Linux drivers at all because it's too expensive, then somebody might
consider UIO. To have the big parts of the driver in userspace allows
them to remain stable across different kernel versions. Driver updates
can take place without changing the kernel. For some manufacturers 
these will be strong arguments in favor of UIO.

Hans
 

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Jan Engelhardt]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 544 bytes --]


On Dec 14 2006 10:56, Hans-Jürgen Koch wrote:
>
>A small German manufacturer produces high-end AD converter cards. He sells
>100 pieces per year, only in Germany and only with Windows drivers. He would
>now like to make his cards work with Linux. He has two driver programmers
>with little experience in writing Linux kernel drivers. What do you tell him?
>Write a large kernel module from scratch? Completely rewrite his code 
>because it uses floating point arithmetics?

They use floating point in (Windows) kernelspace? Oh my.


	-`J'
-- 

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Hans-Jürgen Koch]

Am Donnerstag, 14. Dezember 2006 18:02 schrieb Jan Engelhardt:
> 
> On Dec 14 2006 10:56, Hans-Jürgen Koch wrote:
> >
> >A small German manufacturer produces high-end AD converter cards. He sells
> >100 pieces per year, only in Germany and only with Windows drivers. He would
> >now like to make his cards work with Linux. He has two driver programmers
> >with little experience in writing Linux kernel drivers. What do you tell him?
> >Write a large kernel module from scratch? Completely rewrite his code 
> >because it uses floating point arithmetics?
> 
> They use floating point in (Windows) kernelspace? Oh my.

To be honest, I never really understood where kernel space starts and user space
ends in Windows, so I'm not sure about this :-)

Hans

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Jan Engelhardt]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 480 bytes --]


On Dec 14 2006 18:17, Hans-Jürgen Koch wrote:
>> 
>> They use floating point in (Windows) kernelspace? Oh my.
>
>To be honest, I never really understood where kernel space starts and user space
>ends in Windows, so I'm not sure about this :-)

Well, in Windows 95/98 you could do inportb (inb) and friends from "userspace"
without an extra kernel driver. Maybe it just always ran in kernelspace,
explains why many say 95/98 was less stable than the NT-based versions.

	-`J'
-- 

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Lee Revell]

On Thu, 2006-12-14 at 18:02 +0100, Jan Engelhardt wrote:
> On Dec 14 2006 10:56, Hans-Jürgen Koch wrote:
> >
> >A small German manufacturer produces high-end AD converter cards. He sells
> >100 pieces per year, only in Germany and only with Windows drivers. He would
> >now like to make his cards work with Linux. He has two driver programmers
> >with little experience in writing Linux kernel drivers. What do you tell him?
> >Write a large kernel module from scratch? Completely rewrite his code 
> >because it uses floating point arithmetics?
> 
> They use floating point in (Windows) kernelspace? Oh my.

Yes, definitely.  For example lots of Windows sound drivers do AC3
decoding in kernelspace.  Of course the vendors usually lie and say it's
done in hardware...

Lee

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Jan Engelhardt]

On Dec 16 2006 15:13, Lee Revell wrote:
>On Thu, 2006-12-14 at 18:02 +0100, Jan Engelhardt wrote:
>> 
>> They use floating point in (Windows) kernelspace? Oh my.
>
>Yes, definitely.

Explains why Windows is so slow ;-) [FPU restore and stuff...]

On that matter, when does the Linux kernel do proper FPU handling? At context
switches? If so, would not that make a kthread fpu-capable?

>For example lots of Windows sound drivers do AC3 decoding in kernelspace.
>Of course the vendors usually lie and say it's done in hardware...

They don't need to lie, the user buys it anyway...


	-`J'
-- 

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Bernd Petrovitsch]

On Thu, 2006-12-14 at 10:56 +0100, Hans-Jürgen Koch wrote:
[....]
> A small German manufacturer produces high-end AD converter cards. He sells
> 100 pieces per year, only in Germany and only with Windows drivers. He would
> now like to make his cards work with Linux. He has two driver programmers
> with little experience in writing Linux kernel drivers. What do you tell him?
> Write a large kernel module from scratch? Completely rewrite his code 
> because it uses floating point arithmetics?

Find a Linux kernel guru/company and pay him/them for
-) an evaluation if it is "better" (for whatever better means) to port
the driver
     or write it from scratch and
-) do the better thing.

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

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Hans-Jürgen Koch]

Am Donnerstag, 14. Dezember 2006 18:34 schrieb Bernd Petrovitsch:
> On Thu, 2006-12-14 at 10:56 +0100, Hans-Jürgen Koch wrote:
> [....]
> > A small German manufacturer produces high-end AD converter cards. He sells
> > 100 pieces per year, only in Germany and only with Windows drivers. He would
> > now like to make his cards work with Linux. He has two driver programmers
> > with little experience in writing Linux kernel drivers. What do you tell him?
> > Write a large kernel module from scratch? Completely rewrite his code 
> > because it uses floating point arithmetics?
> 
> Find a Linux kernel guru/company and pay him/them for
> -) an evaluation if it is "better" (for whatever better means) to port
> the driver
>      or write it from scratch and
> -) do the better thing.

Good idea - whatever "porting" means. There are lots of Windows drivers out there
that are also partly user space using that Kithara stuff. They have most of their
driver in a dll. So that is similar to what we want with UIO - except that we 
handle interrupts in a clean way, they don't.
If you need to port such a driver, simply writing a kernel module and a user space
library would change so much of the concept that you can start rewriting it from
scratch. And you'll have a large kernel module to maintain. OK, the guru/company
can earn money with it, at least as long as the customer doesn't realize it is
not the best solution for him.

Hans

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Bernd Petrovitsch]

On Thu, 2006-12-14 at 18:47 +0100, Hans-Jürgen Koch wrote:
> Am Donnerstag, 14. Dezember 2006 18:34 schrieb Bernd Petrovitsch:
> > On Thu, 2006-12-14 at 10:56 +0100, Hans-Jürgen Koch wrote:
> > [....]
> > > A small German manufacturer produces high-end AD converter cards. He sells
> > > 100 pieces per year, only in Germany and only with Windows drivers. He would
> > > now like to make his cards work with Linux. He has two driver programmers
> > > with little experience in writing Linux kernel drivers. What do you tell him?
> > > Write a large kernel module from scratch? Completely rewrite his code 
> > > because it uses floating point arithmetics?
> > 
> > Find a Linux kernel guru/company and pay him/them for
> > -) an evaluation if it is "better" (for whatever better means) to port
> > the driver
> >      or write it from scratch and
> > -) do the better thing.
> 
> Good idea - whatever "porting" means. There are lots of Windows drivers out there

Yes, I didn't want to open that can of worms.

> that are also partly user space using that Kithara stuff. They have most of their
> driver in a dll. So that is similar to what we want with UIO - except that we 
> handle interrupts in a clean way, they don't.
> If you need to port such a driver, simply writing a kernel module and a user space
> library would change so much of the concept that you can start rewriting it from

Of course, if "better" means "as cheap as possible no matter what", this
is probably the way to go.
Tough luck if you get into technical problems .....

> scratch. And you'll have a large kernel module to maintain. OK, the guru/company
> can earn money with it, at least as long as the customer doesn't realize it is
> not the best solution for him.

Depending on the definition of "best".

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

Re: [GIT PATCH] more Driver core patches for 2.6.19

[James Courtier-Dutton]

Duncan Sands wrote:
>> I'm really not convinced about the user-mode thing unless somebody can 
>> show me a good reason for it. Not just some "wouldn't it be nice" kind of 
>> thing. A real, honest-to-goodness reason that we actually _want_ to see 
>> used.
> 
> Qemu?  It would be nice if emulators could directly drive hardware:
> useful for reverse engineering windows drivers for example.
> 
> Duncan.

I have reverse engineered many windows drivers, and what you suggest is 
not at all helpful. For reverse engineering, one wants to see what is 
happening. I.e. capture all the IO, MMIO and DMA accesses.
Your suggestion bypasses this possibility.
For reverse engineering windows drivers, one puts breakpoints in the 
HAL.DLL code or replaces the HAL.DLL code with a debugging version of it 
  while actually running windows.

Your approach runs into problems.
e.g
There is a register on the card that sets the DMA base address, but you 
don't know which register this is. If you let the driver inside QEMU 
write to this register, it will write values suitable for the Virtual 
machine instead of values suitable to for host OS. The DMA transaction 
will write all over the wrong memory location resulting in CRASH.

One might be able to get round some of these problem with a combination 
of QEMU and a hacked up HAL.DLL, but it will be complicated.

James

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Michael K. Edwards]

On 12/13/06, Linus Torvalds <torvalds@osdl.org> wrote:
> Ok, what kind of ass-hat idiotic thing is this?

C'mon, Linus, tell us how you _really_ feel.

Seriously, though, please please pretty please do not allow a facility
for "going through a simple interface to get accesses to irqs and
memory regions" into the mainline kernel, with or without toy ISA
examples.  Embedded systems integrators have enough trouble with chip
vendors who think that exposing the device registers to userspace
constitutes a "driver".  The correct description is more like "porting
shim for MMU-less RTOS tasks"; and if the BSP vendors of the world can
make a nickel supplying them, more power to them.  Just not in
mainline, please.

Cheers,
- Michael

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Greg KH]

On Wed, Dec 13, 2006 at 12:38:05PM -0800, Michael K. Edwards wrote:
> Seriously, though, please please pretty please do not allow a facility
> for "going through a simple interface to get accesses to irqs and
> memory regions" into the mainline kernel, with or without toy ISA
> examples.

Why?  X does it today :)

> Embedded systems integrators have enough trouble with chip vendors who
> think that exposing the device registers to userspace constitutes a
> "driver".

Yes, and because of this, they create binary only drivers today.  Lots
of them.  All over the place.  Doing crazy stupid crap in kernelspace.

Then there are people who do irq stuff in userspace but get it wrong.
I've seen that happen many times in lots of different research papers
and presentations.

This interface does it correctly, and it allows those people who for
some reason feel they do want to keep their logic in non-gpl code, to do
it.

It also allows code that needs floating point to not be in the kernel
and in one instance using this interface actually sped up the device
because of the lack of the need to go between kernel and userspace a
bunch of times.

> The correct description is more like "porting shim for MMU-less RTOS
> tasks"; and if the BSP vendors of the world can make a nickel
> supplying them, more power to them.  Just not in mainline, please.

Again, X does this today, and does does lots of other applications.
This is a way to do it in a sane manner, to keep people who want to do
floating point out of the kernel, and to make some embedded people much
happier to use Linux, gets them from being so mad at Linux because we
keep changing the internal apis, and makes me happier as they stop
violating my copyright by creating closed drivers in the kernel.

thanks,

greg k-h

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Martin Bligh]

Greg KH wrote:
> On Wed, Dec 13, 2006 at 12:38:05PM -0800, Michael K. Edwards wrote:
>> Seriously, though, please please pretty please do not allow a facility
>> for "going through a simple interface to get accesses to irqs and
>> memory regions" into the mainline kernel, with or without toy ISA
>> examples.
> 
> Why?  X does it today :)

Umm ... and you're trying to use the current X model for a positive
example of what we should be doing? that's ... interesting.

>> Embedded systems integrators have enough trouble with chip vendors who
>> think that exposing the device registers to userspace constitutes a
>> "driver".
> 
> Yes, and because of this, they create binary only drivers today.  Lots
> of them.  All over the place.  Doing crazy stupid crap in kernelspace.

So let's come out and ban binary modules, rather than pussyfooting
around, if that's what we actually want to do.

It comes down to a question of whether we have enough leverage to push
them into doing what we want, or not - are we prepared to call their
bluff?

The current half-assed solution of chipping slowly away at things by
making them EXPORT_SYMBOL_GPL one by one makes little sense - would
be better if we actually made an affirmative decision one way or the
other. And yes, I know which side of that argument you'd fall on ;-)

> Again, X does this today, and does does lots of other applications.
> This is a way to do it in a sane manner, to keep people who want to do
> floating point out of the kernel, and to make some embedded people much
> happier to use Linux, gets them from being so mad at Linux because we
> keep changing the internal apis, and makes me happier as they stop
> violating my copyright by creating closed drivers in the kernel.

I don't see how this really any different than letting them create
GPL shims to export data to binary modules (aside from all the legal
wanking over minutae details, which really isn't that interesting).

M.

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Andrew Morton]

On Wed, 13 Dec 2006 13:32:50 -0800
Martin Bligh <mbligh@mbligh.org> wrote:

> So let's come out and ban binary modules, rather than pussyfooting
> around, if that's what we actually want to do.

Give people 12 months warning (time to work out what they're going to do,
talk with the legal dept, etc) then make the kernel load only GPL-tagged
modules.

I think I'd favour that.  It would aid those people who are trying to
obtain device specs, and who are persuading organisations to GPL their drivers.

(Whereas the patch which is proposed in this thread hinders those people)

GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Greg KH]

On Wed, Dec 13, 2006 at 01:47:21PM -0800, Andrew Morton wrote:
> On Wed, 13 Dec 2006 13:32:50 -0800
> Martin Bligh <mbligh@mbligh.org> wrote:
> 
> > So let's come out and ban binary modules, rather than pussyfooting
> > around, if that's what we actually want to do.
> 
> Give people 12 months warning (time to work out what they're going to do,
> talk with the legal dept, etc) then make the kernel load only GPL-tagged
> modules.
> 
> I think I'd favour that.  It would aid those people who are trying to
> obtain device specs, and who are persuading organisations to GPL their drivers.

Ok, I have no objection to that at all.  I'll whip up such a patch in a
bit to spit out kernel log messages whenever such a module is loaded so
that people have some warning.

thanks,

greg k-h

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Greg KH]

On Wed, Dec 13, 2006 at 02:09:11PM -0800, Greg KH wrote:
> On Wed, Dec 13, 2006 at 01:47:21PM -0800, Andrew Morton wrote:
> > On Wed, 13 Dec 2006 13:32:50 -0800
> > Martin Bligh <mbligh@mbligh.org> wrote:
> > 
> > > So let's come out and ban binary modules, rather than pussyfooting
> > > around, if that's what we actually want to do.
> > 
> > Give people 12 months warning (time to work out what they're going to do,
> > talk with the legal dept, etc) then make the kernel load only GPL-tagged
> > modules.
> > 
> > I think I'd favour that.  It would aid those people who are trying to
> > obtain device specs, and who are persuading organisations to GPL their drivers.
> 
> Ok, I have no objection to that at all.  I'll whip up such a patch in a
> bit to spit out kernel log messages whenever such a module is loaded so
> that people have some warning.

Here you go.  The wording for the feature-removal-schedule.txt file
could probably be cleaned up.  Any suggestions would be welcome.

thanks,

greg k-h

-----------
From: Greg Kroah-Hartmna <gregkh@suse.de>
Subject: Notify non-GPL module loading will be going away in January 2008

Numerous kernel developers feel that loading non-GPL drivers into the
kernel violates the license of the kernel and their copyright.  Because
of this, a one year notice for everyone to address any non-GPL
compatible modules has been set.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 Documentation/feature-removal-schedule.txt |    9 +++++++++
 kernel/module.c                            |    6 +++++-
 2 files changed, 14 insertions(+), 1 deletion(-)

--- gregkh-2.6.orig/Documentation/feature-removal-schedule.txt
+++ gregkh-2.6/Documentation/feature-removal-schedule.txt
@@ -281,3 +281,12 @@ Why:	Speedstep-centrino driver with ACPI
 Who:	Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
 
 ---------------------------
+
+What:	non GPL licensed modules will able to be loaded successfully.
+When:	January 2008
+Why:	Numerous kernel developers feel that loading non-GPL drivers into the
+	kernel violates the license of the kernel and their copyright.
+
+Who:	Greg Kroah-Hartman <greg@kroah.com> or <gregkh@suse.de>
+
+---------------------------
--- gregkh-2.6.orig/kernel/module.c
+++ gregkh-2.6/kernel/module.c
@@ -1393,9 +1393,13 @@ static void set_license(struct module *m
 		license = "unspecified";
 
 	if (!license_is_gpl_compatible(license)) {
-		if (!(tainted & TAINT_PROPRIETARY_MODULE))
+		if (!(tainted & TAINT_PROPRIETARY_MODULE)) {
 			printk(KERN_WARNING "%s: module license '%s' taints "
 				"kernel.\n", mod->name, license);
+			printk(KERN_WARNING "%s: This module will not be able "
+				"to be loaded after January 1, 2008 due to its "
+				"license.\n", mod->name);
+		}
 		add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
 	}
 }

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jonathan Corbet]

Greg's patch:

> +			printk(KERN_WARNING "%s: This module will not be able "
> +				"to be loaded after January 1, 2008 due to its "
> +				"license.\n", mod->name);

If you're going to go ahead with this, shouldn't the message say that
the module will not be loadable into *kernels released* after January 1,
2008?  I bet a lot of people would read the above to say that their
system will just drop dead of a New Year's hangover, and they'll freak.
I wouldn't want to be the one getting all the email at that point...

jon

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Greg KH]

On Wed, Dec 13, 2006 at 05:43:29PM -0700, Jonathan Corbet wrote:
> Greg's patch:
> 
> > +			printk(KERN_WARNING "%s: This module will not be able "
> > +				"to be loaded after January 1, 2008 due to its "
> > +				"license.\n", mod->name);
> 
> If you're going to go ahead with this, shouldn't the message say that
> the module will not be loadable into *kernels released* after January 1,
> 2008?  I bet a lot of people would read the above to say that their
> system will just drop dead of a New Year's hangover, and they'll freak.
> I wouldn't want to be the one getting all the email at that point...

Heh, good point.

An updated version is below.

Oh, and for those who have asked me how we would enforce this after this
date if this decision is made, I'd like to go on record that I will be
glad to take whatever legal means necessary to stop people from
violating this.

Someone also mentioned that we could just put a nice poem into the
kernel module image in order to be able to enforce our copyright license
in any court of law.

	Full bellies of fish
	Penguins sleep under the moon
	Dream of wings that fly

thanks,

greg k-h

--------------

From: Greg Kroah-Hartmna <gregkh@suse.de>
Subject: Notify non-GPL module loading will be going away in January 2008

Numerous kernel developers feel that loading non-GPL drivers into the
kernel violates the license of the kernel and their copyright.  Because
of this, a one year notice for everyone to address any non-GPL
compatible modules has been set.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 Documentation/feature-removal-schedule.txt |    9 +++++++++
 kernel/module.c                            |    7 ++++++-
 2 files changed, 15 insertions(+), 1 deletion(-)

--- gregkh-2.6.orig/Documentation/feature-removal-schedule.txt
+++ gregkh-2.6/Documentation/feature-removal-schedule.txt
@@ -281,3 +281,12 @@ Why:	Speedstep-centrino driver with ACPI
 Who:	Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
 
 ---------------------------
+
+What:	non GPL licensed modules will able to be loaded successfully.
+When:	January 2008
+Why:	Numerous kernel developers feel that loading non-GPL drivers into the
+	kernel violates the license of the kernel and their copyright.
+
+Who:	Greg Kroah-Hartman <greg@kroah.com> <gregkh@novell.com>
+
+---------------------------
--- gregkh-2.6.orig/kernel/module.c
+++ gregkh-2.6/kernel/module.c
@@ -1393,9 +1393,14 @@ static void set_license(struct module *m
 		license = "unspecified";
 
 	if (!license_is_gpl_compatible(license)) {
-		if (!(tainted & TAINT_PROPRIETARY_MODULE))
+		if (!(tainted & TAINT_PROPRIETARY_MODULE)) {
 			printk(KERN_WARNING "%s: module license '%s' taints "
 				"kernel.\n", mod->name, license);
+			printk(KERN_WARNING "%s: This module will not be able "
+				"to be loaded in any kernel released after "
+				"January 1, 2008 due to its license.\n",
+				mod->name);
+		}
 		add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
 	}
 }

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Linus Torvalds]

On Wed, 13 Dec 2006, Greg KH wrote:
> 
> 	Full bellies of fish
> 	Penguins sleep under the moon
> 	Dream of wings that fly

Snif. That touched me deep inside.

		Linus

PS. Or maybe it was the curry I ate yesterday. 

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Michael K. Edwards]

fish for birds alone?
no, teach suits how to leave more
fish to go around

Cheers,
- Michael

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Grzegorz Kulewski]

Hi,

I think that...

On Wed, 13 Dec 2006, Greg KH wrote:
> From: Greg Kroah-Hartmna <gregkh@suse.de>

... (most probably) there...

> Subject: Notify non-GPL module loading will be going away in January 2008
>
> Numerous kernel developers feel that loading non-GPL drivers into the
> kernel violates the license of the kernel and their copyright.  Because
> of this, a one year notice for everyone to address any non-GPL
> compatible modules has been set.
>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

... or (less probably) there...

is a typo in your name. :-)


Thanks,

Grzegorz Kulewski


PS. Are you _really_ sure you want this change accepted into mainline 
kernel?

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Greg KH]

On Thu, Dec 14, 2006 at 02:30:26AM +0100, Grzegorz Kulewski wrote:
> Hi,
> 
> I think that...
> 
> On Wed, 13 Dec 2006, Greg KH wrote:
> >From: Greg Kroah-Hartmna <gregkh@suse.de>
> 
> ... (most probably) there...
> 
> >Subject: Notify non-GPL module loading will be going away in January 2008
> >
> >Numerous kernel developers feel that loading non-GPL drivers into the
> >kernel violates the license of the kernel and their copyright.  Because
> >of this, a one year notice for everyone to address any non-GPL
> >compatible modules has been set.
> >
> >Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
> ... or (less probably) there...
> 
> is a typo in your name. :-)

Heh, thanks.  I've also fixed up the wording in the
feature-removal-schedule.txt file to say:
	What:  non-GPL-licensed modules will no longer be loaded.

The wording I had before was not very easy to understand.

> PS. Are you _really_ sure you want this change accepted into mainline 
> kernel?

Yes, I do.

thanks,

greg k-h

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Linus Torvalds]

On Wed, 13 Dec 2006, Greg KH wrote:
> 
> Numerous kernel developers feel that loading non-GPL drivers into the
> kernel violates the license of the kernel and their copyright.  Because
> of this, a one year notice for everyone to address any non-GPL
> compatible modules has been set.

Btw, I really think this is shortsighted.

It will only result in _exactly_ the crap we were just trying to avoid, 
namely stupid "shell game" drivers that don't actually help anything at 
all, and move code into user space instead.

What was the point again?

Was the point to alienate people by showing how we're less about the 
technology than about licenses?

Was the point to show that we think we can extend our reach past derived 
work boundaries by just saying so? 

The silly thing is, the people who tend to push most for this are the 
exact SAME people who say that the RIAA etc should not be able to tell 
people what to do with the music copyrights that they own, and that the 
DMCA is bad because it puts technical limits over the rights expressly 
granted by copyright law.

Doesn't anybody else see that as being hypocritical?

So it's ok when we do it, but bad when other people do it? Somehow I'm not 
surprised, but I still think it's sad how you guys are showing a marked 
two-facedness about this.

The fact is, the reason I don't think we should force the issue is very 
simple: copyright law is simply _better_off_ when you honor the admittedly 
gray issue of "derived work". It's gray. It's not black-and-white. But 
being gray is _good_. Putting artificial black-and-white technical 
counter-measures is actually bad. It's bad when the RIAA does it, it's bad 
when anybody else does it.

If a module arguably isn't a derived work, we simply shouldn't try to say 
that its authors have to conform to our worldview.

We should make decisions on TECHNICAL MERIT. And this one is clearly being 
pushed on anything but.

I happen to believe that there shouldn't be technical measures that keep 
me from watching my DVD or listening to my music on whatever device I damn 
well please. Fair use, man. But it should go the other way too: we should 
not try to assert _our_ copyright rules on other peoples code that wasn't 
derived from ours, or assert _our_ technical measures that keep people 
from combining things their way.

If people take our code, they'd better behave according to our rules. But 
we shouldn't have to behave according to the RIAA rules just because we 
_listen_ to their music. Similarly, nobody should be forced to behave 
according to our rules just because they _use_ our system. 

There's a big difference between "copy" and "use". It's exatcly the same 
issue whether it's music or code. You can't re-distribute other peoples 
music (becuase it's _their_ copyright), but they shouldn't put limits on 
how you personally _use_ it (because it's _your_ life).

Same goes for code. Copyright is about _distribution_, not about use. We 
shouldn't limit how people use the code.

Oh, well. I realize nobody is likely going to listen to me, and everybody 
has their opinion set in stone. 

That said, I'm going to suggest that you people talk to your COMPANY 
LAWYERS on this, and I'm personally not going to merge that particular 
code unless you can convince the people you work for to merge it first.

In other words, you guys know my stance. I'll not fight the combined 
opinion of other kernel developers, but I sure as hell won't be the first 
to merge this, and I sure as hell won't have _my_ tree be the one that 
causes this to happen.

So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees 
first. This is not something where we use my tree as a way to get it to 
other trees. This is something where the push had better come from the 
other direction.

Because I think it's stupid. So use somebody else than me to push your 
political agendas, please.

		Linus

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Martin J. Bligh]

Linus Torvalds wrote:
> 
> On Wed, 13 Dec 2006, Greg KH wrote:
>> Numerous kernel developers feel that loading non-GPL drivers into the
>> kernel violates the license of the kernel and their copyright.  Because
>> of this, a one year notice for everyone to address any non-GPL
>> compatible modules has been set.
> 
> Btw, I really think this is shortsighted.
> 
> It will only result in _exactly_ the crap we were just trying to avoid, 
> namely stupid "shell game" drivers that don't actually help anything at 
> all, and move code into user space instead.

I don't think pushing the drivers into userspace is a good idea at all,
that wasn't what I was getting at. Pushing the problem into a different
space doesn't fix it. IMHO, we're not a microkernel, and drivers for
hardware belong in the kernel.

Whether we allow binary kernel modules or not, I don't think we should
allow an API for userspace drivers - obviously that's not my call, it's
yours, but at least I don't want my opinion / intent misinterpreted.

 > What was the point again?
 >
 > Was the point to alienate people by showing how we're less about the
 > technology than about licenses?

The point of banning binary drivers would be to leverage hardware
companies into either releasing open source drivers, or the specs for
someone else to write them. Whether we have that much leverage is
debatable ... I suspect we do in some cases and not in others. It'll
cause some pain, as well as some gain, but I think we'd live through
it pretty well, personally.

The details of the legal minutiae are, I feel, less interesting than
what goal we want to acheive. If we decided to get rid of binary
drivers, we could likely find a way to achieve that. Is it a worthwhile
goal?

I've done both Linux support, where binary drivers are involved, before,
as well as supporting Sequent's Dynix/PTX in the face of a similar
situation with CA Unicenter. It makes life extremely difficult, if not
impossible for a support organisation, for fairly obvious and well known
reasons. When there are two binary drivers from different vendors in
there, any semblence of support becomes farcical.

The Ubuntu feisty fawn mess was a dangerous warning bell of where we're
going. If we don't stand up at some point, and ban binary drivers, we
will, I fear, end up with an unsustainable ecosystem for Linux when
binary drivers become pervasive. I don't want to see Linux destroyed
like that.

I don't think the motive behind what we decide to do should be decided
by legal stuff, though I'm sure we'd have to wade through that to
implement it. It's not about that ... it's about what kind of ecosystem
we want to create, and whether that can be successful or not. Indeed,
there are good arguments both for and against binary drivers on that
basis.

But please can we have the pragmatic argument about what we want to
achieve, and why ... rather than the legal / religious arguments about
licenses? The law is a tool, not an end in itself.

If you don't feel it's legitimate to leverage that tool to achieve a
pragmatic end, fair enough. But please don't assume that the motivation
was legal / religious, at least not on my part.

Perhaps, in the end, we will decide we'd like to ban binary drivers,
but can't. Either for pragmatic reasons (e.g. we don't have enough
leverage to create the hardware support base), or for legal ones
(we don't think it's enforcable). But we seem to be muddled between
those different reasons right now, at least it seems that way to me.

I think allowing binary hardware drivers in userspace hurts our ability
to leverage companies to release hardware specs. The 'grey water' of
binary kernel drivers convinces a lot of them to release stuff, and
Greg and others have pushed that cause, all credit to them. In one way,
it does make the kernel easier to support, but I don't think it really
helps much to make a supportable *system*.

M.

RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Hua Zhong]

> I think allowing binary hardware drivers in userspace hurts 
> our ability to leverage companies to release hardware specs. 

If filesystems can be in user space, why can't drivers be in user space? On what *technical* ground?

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Alan]

On Wed, 13 Dec 2006 22:01:15 -0800
"Hua Zhong" <hzhong@gmail.com> wrote:

> > I think allowing binary hardware drivers in userspace hurts 
> > our ability to leverage companies to release hardware specs. 
> 
> If filesystems can be in user space, why can't drivers be in user space? On what *technical* ground?

The FUSE file system interface provides a clean disciplined interface
which allows an fs to live in user space. The uio layer (if its ever
fixed and cleaned up) provides some basic hooks that allow a user space
program to arbitarily control hardware and make a nasty undebuggable mess.

uio also doesn't handle hotplug, pci and other "small" matters.

Now if you wanted to make uio useful at minimum you would need

-  PCI support
-  The ability to mark sets of I/O addresses for the card as
"unmappable", "read only", "read-write", "any read/root write", "root
read/write"
-  A proper IRQ handler
-  A DMA interface
-  The ability to describe sharing rules

Which actually is a description of the core of the DRM layer.

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Hans-Jürgen Koch]

Am Donnerstag, 14. Dezember 2006 12:14 schrieb Alan:
> On Wed, 13 Dec 2006 22:01:15 -0800
> "Hua Zhong" <hzhong@gmail.com> wrote:
> 
> > > I think allowing binary hardware drivers in userspace hurts 
> > > our ability to leverage companies to release hardware specs. 
> > 
> > If filesystems can be in user space, why can't drivers be in user space? On what *technical* ground?
> 
> The FUSE file system interface provides a clean disciplined interface
> which allows an fs to live in user space. The uio layer (if its ever
> fixed and cleaned up) provides some basic hooks that allow a user space
> program to arbitarily control hardware and make a nasty undebuggable mess.

You think it's easier for a manufacturer of industrial IO cards to
debug a (large) kernel module?

> 
> uio also doesn't handle hotplug, pci and other "small" matters.

uio is supposed to be a very thin layer. Hotplug and PCI are already
handled by other subsystems. 

> 
> Now if you wanted to make uio useful at minimum you would need
> 

The majority of industrial IO cards have registers and/or dual port RAM
that can be mapped to user space (even today). We want to add a simple
way to handle interrupts for such cards. That's all.
The fact that there might be some sort of hardware/interrupts/situations
where this is not possible or not so simple isn't that important at the
moment. We can extend the UIO system if somebody actually requires these
extensions.

Hans

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Alan]

On Thu, 14 Dec 2006 12:31:16 +0100
Hans-Jürgen Koch <hjk@linutronix.de> wrote:
> You think it's easier for a manufacturer of industrial IO cards to
> debug a (large) kernel module?

You think its any easier to debug because the code now runs in ring 3 but
accessing I/O space.


> > uio also doesn't handle hotplug, pci and other "small" matters.
> 
> uio is supposed to be a very thin layer. Hotplug and PCI are already
> handled by other subsystems. 

And if you have a PCI or a hotplug card ? How many industrial I/O cards
are still ISA btw ?


Alan

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Hans-Jürgen Koch]

Am Donnerstag, 14. Dezember 2006 13:42 schrieb Alan:
> On Thu, 14 Dec 2006 12:31:16 +0100
> Hans-Jürgen Koch <hjk@linutronix.de> wrote:
> > You think it's easier for a manufacturer of industrial IO cards to
> > debug a (large) kernel module?
> 
> You think its any easier to debug because the code now runs in ring 3 but
> accessing I/O space.

For the intended audience, yes.

> 
> 
> > > uio also doesn't handle hotplug, pci and other "small" matters.
> > 
> > uio is supposed to be a very thin layer. Hotplug and PCI are already
> > handled by other subsystems. 
> 
> And if you have a PCI or a hotplug card ? How many industrial I/O cards
> are still ISA btw ?

Who is talking about ISA? All cards we had in mind are PCI. Of course
you have to do the usual initialization work in your probe/release or
init/exit functions. These are just a few lines you find in any
beginners device-driver-writing book. I don't think that the UIO 
framework could simplify that in a sensible way.

Hans

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Greg KH]

On Thu, Dec 14, 2006 at 01:54:24PM +0100, Hans-J??rgen Koch wrote:
> Am Donnerstag, 14. Dezember 2006 13:42 schrieb Alan:
> > > > uio also doesn't handle hotplug, pci and other "small" matters.
> > > 
> > > uio is supposed to be a very thin layer. Hotplug and PCI are already
> > > handled by other subsystems. 
> > 
> > And if you have a PCI or a hotplug card ? How many industrial I/O cards
> > are still ISA btw ?
> 
> Who is talking about ISA? All cards we had in mind are PCI. Of course
> you have to do the usual initialization work in your probe/release or
> init/exit functions. These are just a few lines you find in any
> beginners device-driver-writing book. I don't think that the UIO 
> framework could simplify that in a sensible way.

Agreed, you still have to write a kernel driver to handle the pci
probe/disconnect functions and the pci id stuff to use the uio core
properly.  That's not in question here at all and please don't think
that uio even attempts to handle this, as that is not what it's job is.

Think of uio as just a "class" of driver, like input or v4l.  It's still
up to the driver writer to provide a proper bus interface to the
hardware (pci, usb, etc.) in order for the device to work at all.

thanks,

greg k-h

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Alan]

> Think of uio as just a "class" of driver, like input or v4l.  It's still
> up to the driver writer to provide a proper bus interface to the
> hardware (pci, usb, etc.) in order for the device to work at all.

Understood. That leads me to ask another question of the folks who deal
with a lot of these cards. How many could reasonably be described by the
following

		bar to map, offset, length, ro/rw, root/user, local-offset
(x n ?)
		interrupt function or null

It seems if we have a lot of this kind of card that all fit that pattern
it might actually get more vendors submitting updates if we had a single
pci driver that took a struct of the above as the device_id field so
vendors had to write five lines of IRQ code, a struct and update a PCI
table ? That seems to have mostly worked with all the parallel/serial
boards.

Alan

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Greg KH]

On Thu, Dec 14, 2006 at 06:26:26PM +0000, Alan wrote:
> > Think of uio as just a "class" of driver, like input or v4l.  It's still
> > up to the driver writer to provide a proper bus interface to the
> > hardware (pci, usb, etc.) in order for the device to work at all.
> 
> Understood. That leads me to ask another question of the folks who deal
> with a lot of these cards. How many could reasonably be described by the
> following
> 
> 		bar to map, offset, length, ro/rw, root/user, local-offset
> (x n ?)
> 		interrupt function or null
> 
> It seems if we have a lot of this kind of card that all fit that pattern
> it might actually get more vendors submitting updates if we had a single
> pci driver that took a struct of the above as the device_id field so
> vendors had to write five lines of IRQ code, a struct and update a PCI
> table ? That seems to have mostly worked with all the parallel/serial
> boards.

I think that something like this might work out, and it would be a good
goal to get there eventually.  But I would like to see a few drivers
using the uio core to see where we can consolidate things like this
first.

thanks,

greg k-h

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jan Engelhardt]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 749 bytes --]


On Dec 14 2006 12:42, Alan wrote:
>On Thu, 14 Dec 2006 12:31:16 +0100
>Hans-Jürgen Koch <hjk@linutronix.de> wrote:
>> You think it's easier for a manufacturer of industrial IO cards to
>> debug a (large) kernel module?
>
>You think its any easier to debug because the code now runs in ring 3 but
>accessing I/O space.

A NULL fault won't oops the system, but of course the wrong inb/inw/inl() or
outb* can fubar the machine.


>> > uio also doesn't handle hotplug, pci and other "small" matters.
>> 
>> uio is supposed to be a very thin layer. Hotplug and PCI are already
>> handled by other subsystems. 
>
>And if you have a PCI or a hotplug card ? How many industrial I/O cards
>are still ISA btw ?

Something called PC104 out there.


	-`J'
-- 

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Arjan van de Ven]

On Thu, 2006-12-14 at 13:55 +0100, Jan Engelhardt wrote:
> On Dec 14 2006 12:42, Alan wrote:
> >On Thu, 14 Dec 2006 12:31:16 +0100
> >Hans-Jürgen Koch <hjk@linutronix.de> wrote:
> >> You think it's easier for a manufacturer of industrial IO cards to
> >> debug a (large) kernel module?
> >
> >You think its any easier to debug because the code now runs in ring 3 but
> >accessing I/O space.
> 
> A NULL fault won't oops the system,

.. except when the userspace driver crashes as a result and then the hw
still crashes the hw (for example via an irq storm or by tying the PCI
bus or .. )

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jan Engelhardt]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 768 bytes --]


On Dec 14 2006 14:10, Arjan van de Ven wrote:
>On Thu, 2006-12-14 at 13:55 +0100, Jan Engelhardt wrote:
>> >On Thu, 14 Dec 2006 12:31:16 +0100
>> >Hans-Jürgen Koch wrote:
>> >
>> >You think its any easier to debug because the code now runs in ring 3 but
>> >accessing I/O space.
>> 
>> A NULL fault won't oops the system,
>
>.. except when the userspace driver crashes as a result and then the hw
>still crashes the hw (for example via an irq storm or by tying the PCI
>bus or .. )

hw crashes the hw? Anyway, yes it might happen, the more with non-NULL pointers
(dangling references f.ex.)
However, if the userspace part is dead, no one acknowledges the irq, hence an
irq storm (if not caused by writing bogus stuff into registers) should not
happen.
>
>

	-`J'
-- 

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Geert Uytterhoeven]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1156 bytes --]

On Thu, 14 Dec 2006, Jan Engelhardt wrote:
> On Dec 14 2006 14:10, Arjan van de Ven wrote:
> >On Thu, 2006-12-14 at 13:55 +0100, Jan Engelhardt wrote:
> >> >On Thu, 14 Dec 2006 12:31:16 +0100
> >> >Hans-Jürgen Koch wrote:
> >> >
> >> >You think its any easier to debug because the code now runs in ring 3 but
> >> >accessing I/O space.
> >> 
> >> A NULL fault won't oops the system,
> >
> >.. except when the userspace driver crashes as a result and then the hw
> >still crashes the hw (for example via an irq storm or by tying the PCI
> >bus or .. )
> 
> hw crashes the hw? Anyway, yes it might happen, the more with non-NULL pointers
> (dangling references f.ex.)
> However, if the userspace part is dead, no one acknowledges the irq, hence an
> irq storm (if not caused by writing bogus stuff into registers) should not
> happen.

Shared level IRQ?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[James Morris]

On Wed, 13 Dec 2006, Martin J. Bligh wrote:

> The point of banning binary drivers would be to leverage hardware
> companies into either releasing open source drivers, or the specs for
> someone else to write them.

IMHO, it's up to the users to decide if they want to keep buying hardware 
which leads to inferior support, less reliability, decreased security and 
all of the other ills associated with binary drivers.  Let them also 
choose distributions which enact the binary driver policies they agree 
with.

Linux is precisely not about forcing people to do things.


- James
-- 
James Morris
<jmorris@namei.org>

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Adrian Bunk]

On Thu, Dec 14, 2006 at 03:03:10AM -0500, James Morris wrote:
> On Wed, 13 Dec 2006, Martin J. Bligh wrote:
> 
> > The point of banning binary drivers would be to leverage hardware
> > companies into either releasing open source drivers, or the specs for
> > someone else to write them.
> 
> IMHO, it's up to the users to decide if they want to keep buying hardware 
> which leads to inferior support, less reliability, decreased security and 
> all of the other ills associated with binary drivers.  Let them also 
> choose distributions which enact the binary driver policies they agree 
> with.
>...


Unfortunately, we are living in an economic system with the strong 
tendency to create oligopolys.

Situations with only 1-3 manufacturers you can choose from are quite 
common (consider e.g. the 3D graphics market).

If you aren't a big company with big market power but a simple costumer 
who needs such hardware you have zero choice if all manufactorers only 
offer binary-only drivers at best.


And there's also the common misconception all costumers had enough 
information when buying something. If you are a normal Linux user and 
buy some hardware labelled "runs under Linux", it could turn out that's 
with a Windows driver running under ndiswrapper...


> - James

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

RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[David Schwartz]

> And there's also the common misconception all costumers had enough
> information when buying something. If you are a normal Linux user and
> buy some hardware labelled "runs under Linux", it could turn out that's
> with a Windows driver running under ndiswrapper...

That is something that I think is well worth fixing. Doesn't Linus own the
trademark 'Linux'? How about some rules for use of that trademark and a
'Works with Linux' logo that can only be used if the hardware specifications
are provided?

Let them provide a closed-source driver if they want. Let them provide
user-space applications for which no source is provided if they want. But
don't let them use the logo unless they release sufficient information to
allow people to develop their own drivers and applications to interface with
the hardware.

That makes it clear that it's not about giving us the fruits of years of
your own work but that it's about enabling us to do our own work. (I would
have no objection to also requiring them to provide a minimal open-source
driver. I'm not trying to work out the exact terms here, just get the idea
out.)

DS

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Paolo Ornati]

On Thu, 14 Dec 2006 12:08:11 -0800
"David Schwartz" <davids@webmaster.com> wrote:

> 
> That is something that I think is well worth fixing. Doesn't Linus own the
> trademark 'Linux'? How about some rules for use of that trademark and a
> 'Works with Linux' logo that can only be used if the hardware specifications
> are provided?
> 
> Let them provide a closed-source driver if they want. Let them provide
> user-space applications for which no source is provided if they want. But
> don't let them use the logo unless they release sufficient information to
> allow people to develop their own drivers and applications to interface with
> the hardware.


This is the same I think, but not Linux specific:

http://wiki.duskglow.com/tiki-index.php?page=Open+Hardware+Foundation

------------------------------------------------------------------

P. Mc Namara 12 Jul 06: about the OHF foundation providing
"certificates" for hardware, I'd propose (...) levels.

    * First, any company that pledges full and complete interface and
behavioral documentation for a device, any docs necessary to make the
device do everything it is designed to do, and makes it publicly
available under nothing more cumbersome than the basic copyright that
exists on all written works receives one certificate. Somebody else
used "community friendly" or something similar. I don't know what to
call it. Perhaps just "Open Documentation" (...)

    * A company that contributes back to the community during the
development of a device get labeled "Community Supporter" or something
similar.

    * A company that enters into a legal agreement to release the
entire RTL and supporting information for a project at a given point in
the future (far enough ahead to protect the companies commercial
viability) can get the "Open Hardware" certificate. 

------------------------------------------------------------------

-- 
	Paolo Ornati
	Linux 2.6.18 on x86_64

RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Geert Uytterhoeven]

On Thu, 14 Dec 2006, David Schwartz wrote:
> > And there's also the common misconception all costumers had enough
> > information when buying something. If you are a normal Linux user and
> > buy some hardware labelled "runs under Linux", it could turn out that's
> > with a Windows driver running under ndiswrapper...
> 
> That is something that I think is well worth fixing. Doesn't Linus own the
> trademark 'Linux'? How about some rules for use of that trademark and a
> 'Works with Linux' logo that can only be used if the hardware specifications
> are provided?

Exactly my thoughts...

> Let them provide a closed-source driver if they want. Let them provide
> user-space applications for which no source is provided if they want. But
> don't let them use the logo unless they release sufficient information to
> allow people to develop their own drivers and applications to interface with
> the hardware.
> 
> That makes it clear that it's not about giving us the fruits of years of
> your own work but that it's about enabling us to do our own work. (I would
> have no objection to also requiring them to provide a minimal open-source
> driver. I'm not trying to work out the exact terms here, just get the idea
> out.)

Since `works with' may sound a bit too vague, something like
`LinuxFriendly(tm)', with a happy penguin logo?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Rafael J. Wysocki]

On Sunday, 17 December 2006 11:11, Geert Uytterhoeven wrote:
> On Thu, 14 Dec 2006, David Schwartz wrote:
> > > And there's also the common misconception all costumers had enough
> > > information when buying something. If you are a normal Linux user and
> > > buy some hardware labelled "runs under Linux", it could turn out that's
> > > with a Windows driver running under ndiswrapper...
> > 
> > That is something that I think is well worth fixing. Doesn't Linus own the
> > trademark 'Linux'? How about some rules for use of that trademark and a
> > 'Works with Linux' logo that can only be used if the hardware specifications
> > are provided?
> 
> Exactly my thoughts...
> 
> > Let them provide a closed-source driver if they want. Let them provide
> > user-space applications for which no source is provided if they want. But
> > don't let them use the logo unless they release sufficient information to
> > allow people to develop their own drivers and applications to interface with
> > the hardware.
> > 
> > That makes it clear that it's not about giving us the fruits of years of
> > your own work but that it's about enabling us to do our own work. (I would
> > have no objection to also requiring them to provide a minimal open-source
> > driver. I'm not trying to work out the exact terms here, just get the idea
> > out.)
> 
> Since `works with' may sound a bit too vague, something like
> `LinuxFriendly(tm)', with a happy penguin logo?

I like this idea.

Greetings,
Rafael


-- 
If you don't have the time to read,
you don't have the time or the tools to write.
		- Stephen King

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Marek Wawrzyczny]

On Sunday 17 December 2006 21:11, Geert Uytterhoeven wrote:
> Since `works with' may sound a bit too vague, something like
> `LinuxFriendly(tm)', with a happy penguin logo?

It would be really cool to see penguin logos on hardware :)

I had another, probably crazy idea. Would it be possible to utilize the 
current vendor/device PCI ID database to create Linux friendliness matrix 
site?

And if you let yourself get carried away, you can also imagine a little 
multi-platform utility. It would run on a test system collecting PCI IDs 
before submitting them to the site  to get the system's overall Linux 
friendliness rating.

In cases where the system contains devices which do not have entries in the 
database, the system could look up and use the vendor's Linux friendliness 
rating.

Something like that could really help end users to select the right system and 
would reward those who do the right thing.


Cheers,

Marek Wawrzyczny

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Diego Calleja]

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

El Tue, 19 Dec 2006 23:57:45 +1100, Marek Wawrzyczny <marekw1977@yahoo.com.au> escribió:

> I had another, probably crazy idea. Would it be possible to utilize the 
> current vendor/device PCI ID database to create Linux friendliness matrix 
> site?

I've a script (attached) that looks into /lib/modules/`uname -r`/modules.pcimap,
looks up the IDs in the pci id database and print the real name. At least it shows 
it's possible to know what devices are supported ...




[-- Attachment #2: list-kernel-hardware.py --]
[-- Type: text/x-python, Size: 2278 bytes --]

#!/usr/bin/python

def pciids_to_names(ids):
	# Only the last four numbers of the ids have useful info
	vendorid = ids[1][6:10]
	deviceid = ids[2][6:10]
	subvendorid = ids[3][6:10]
	subdeviceid = ids[4][6:10]

	result = [ids[0], "", "", "", "", ""]
	pciids = open('/usr/share/misc/pci.ids', 'r')

	# Search for vendor
	for line in pciids:
		if line[0] == "#" or line[0] == "C" or line[0] == "\t":
			continue
		if line[0:4] == vendorid:
			result[1] = line[6:].strip() # Vendor name
			break

	if result[1] == "": # Vendor not found
		return result

	# Search for a device
	for line in pciids:
		if line[0] != "\t":
			continue
		if line[1:5] == deviceid:
			result[2] = line[7:].strip() # Device name
			break

	# Search a subsystem name
	for line in pciids:
		if line[2:11] == subvendorid + " " + subdeviceid: # subsystem name
			result[3] = line[12:].strip() # The subvendor and subdevice ids point to a _single_ subsystem name
			break

	# Search a class name
	if ids[5][4:6] == "00" and ids[5][6:8] == "00" and ids[5][6:8] == "00":
		pass # void class ids
	else:
		pciids.seek(0)
		# Search a class name
		for line in pciids:
			if line[0] == "C":
				if line[2:4] ==  ids[5][4:6]: # found class
					result[4] = line[6:].strip() # appended class name
					break

		if result[4] == "": # class not found
			return result

		# Search subclass name
		for line in pciids:
			if line [1:3] == ids[5][6:8]:
				result[5] = line[5:].strip()
				break
	return result




### Start of the code flow ###
import platform
pcimap = open('/lib/modules/' + platform.uname()[2] + '/modules.pcimap', 'r')
previousmodule = "" 
for line in pcimap:
	if line[0] == "#" or line[0] == " ": continue
	data = line.split(None)
	ret = pciids_to_names(data)

	if ret[0] != previousmodule: 
		previousmodule = ret[0]
		print "Driver: " + previousmodule

	if ret[2] == "":
		output = "\tDevice NOT found in the pciid database: " + repr(data)
	else:
		output = "\tDevice: " + ret[2] + " (deviceid " + data[2][6:] + "); made by " + ret[1] + " (vendorid " + data[1][6:] + ")"
		if ret[3] != "": output += "; Subsystem: " + ret[3] + " (subsysid " + data[3][6:] + ":" + data[4][6:] + ")"
		if ret[4] != "": output += "; Class: " + ret[4]
		if ret[5] != "": output += "; Subclass: " + ret[5] 

	print output

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Gene Heskett]

On Tuesday 19 December 2006 08:56, Diego Calleja wrote:
>El Tue, 19 Dec 2006 23:57:45 +1100, Marek Wawrzyczny 
<marekw1977@yahoo.com.au> escribió:
>> I had another, probably crazy idea. Would it be possible to utilize
>> the current vendor/device PCI ID database to create Linux friendliness
>> matrix site?
>
>I've a script (attached) that looks into /lib/modules/`uname
> -r`/modules.pcimap, looks up the IDs in the pci id database and print
> the real name. At least it shows it's possible to know what devices are
> supported ...

FWIW:
[root@coyote src]# python list-kernel-hardware.py
Traceback (most recent call last):
  File "list-kernel-hardware.py", line 70, in ?
    ret = pciids_to_names(data)
  File "list-kernel-hardware.py", line 11, in pciids_to_names
    pciids = open('/usr/share/misc/pci.ids', 'r')
IOError: [Errno 2] No such file or directory: '/usr/share/misc/pci.ids'

That file apparently doesn't exist on an FC6 i686 system

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Bill Nottingham]

Gene Heskett (gene.heskett@verizon.net) said: 
> FWIW:
> [root@coyote src]# python list-kernel-hardware.py
> Traceback (most recent call last):
>   File "list-kernel-hardware.py", line 70, in ?
>     ret = pciids_to_names(data)
>   File "list-kernel-hardware.py", line 11, in pciids_to_names
>     pciids = open('/usr/share/misc/pci.ids', 'r')
> IOError: [Errno 2] No such file or directory: '/usr/share/misc/pci.ids'
> 
> That file apparently doesn't exist on an FC6 i686 system

s/misc/hwdata/ for FC and derivatives.

Bill

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Gene Heskett]

On Tuesday 19 December 2006 12:11, Bill Nottingham wrote:
>Gene Heskett (gene.heskett@verizon.net) said:
>> FWIW:
>> [root@coyote src]# python list-kernel-hardware.py
>> Traceback (most recent call last):
>>   File "list-kernel-hardware.py", line 70, in ?
>>     ret = pciids_to_names(data)
>>   File "list-kernel-hardware.py", line 11, in pciids_to_names
>>     pciids = open('/usr/share/misc/pci.ids', 'r')
>> IOError: [Errno 2] No such file or directory:
>> '/usr/share/misc/pci.ids'
>>
>> That file apparently doesn't exist on an FC6 i686 system
>
>s/misc/hwdata/ for FC and derivatives.
>
>Bill

Ah, thanks.  Verbose isn't it?

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Diego Calleja]

El Tue, 19 Dec 2006 11:46:30 -0500, Gene Heskett <gene.heskett@verizon.net> escribió:

> IOError: [Errno 2] No such file or directory: '/usr/share/misc/pci.ids'
> 
> That file apparently doesn't exist on an FC6 i686 system

Indeed, I forgot to document that. Ubuntu has it there (package pciutils), and
update-pciids updates the file from http://pciids.sourceforge.net/pci.ids. So you
can download that file and change the path in the script.

Anyway, you can find the output at http://www.terra.es/personal/diegocg/list.txt

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Valdis.Kletnieks]

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

On Tue, 19 Dec 2006 23:57:45 +1100, Marek Wawrzyczny said:
> On Sunday 17 December 2006 21:11, Geert Uytterhoeven wrote:
> > Since `works with' may sound a bit too vague, something like
> > `LinuxFriendly(tm)', with a happy penguin logo?
> 
> It would be really cool to see penguin logos on hardware :)

The little Microsoft flag sticker that was on my Dell Latitude got
replaced with a sticker that has a Tux and 'linux inside' on it. :)

> I had another, probably crazy idea. Would it be possible to utilize the 
> current vendor/device PCI ID database to create Linux friendliness matrix 
> site?
> 
> And if you let yourself get carried away, you can also imagine a little 
> multi-platform utility. It would run on a test system collecting PCI IDs 
> before submitting them to the site  to get the system's overall Linux 
> friendliness rating.

This is a can of worms, and then some.  For instance, let's consider this
Latitude.  *THIS* one has an NVidia Quadro NVS 110M in it.  However, that's
not the default graphics card on a Latitude D820.  So what number do you
put in?  Do you use:

a) the *default* graphics card
b) the one *I* have with the open-source driver
c) the same one, but with the NVidia binary driver?

(Remember that "users" have different criteria than "developers" - most
users would consider this entire thread "intellectual wanking", especially
since the patch that spawned it got withdrawn.  And 'Frames Per Second'
trumps that stupid little 'P' in the oops message.  Failure to understand
this mindset guarantees that your computation of a "friendliness rating"
is yet more intellectual wanking... ;)

Similar issues are involved with the wireless card - the Intel 3945 I
have isn't the default.  Repeat for several different disk options, and
at least 4 or 5 different CD/ROM/DVD options.  Add in the fact that Dell
often changes suppliers for disk and CD/DVD drives, and you have a nightmare
coming...

And then there's stuff on this machine that are *not* options, but don't
matter to me.  I see an 'O2 Micro' Firewire in the 'lspci' output.  I have
no idea how well it works.  I don't care what it contributes to the score.
On the other hand, somebody who uses external Firewire disk enclosures may
be *very* concerned about it, but not care in the slightest about the wireless
card.

Bonus points for figuring out what to do with systems that have some chip
that's a supported XYZ driver, but wired up behind a squirrely bridge with
some totally bizarre IRQ allocation, so you end up with something that's
visible on lspci but not actually *usable* in any real sense of the term...

> Something like that could really help end users to select the right system and 
> would reward those who do the right thing.

"You are trapped in a maze of twisty little configurations, all different..."



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

RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[David Schwartz]

> This is a can of worms, and then some.  For instance, let's consider this
> Latitude.  *THIS* one has an NVidia Quadro NVS 110M in it.
> However, that's
> not the default graphics card on a Latitude D820.  So what number do you
> put in?  Do you use:

> a) the *default* graphics card
> b) the one *I* have with the open-source driver
> c) the same one, but with the NVidia binary driver?


> Similar issues are involved with the wireless card - the Intel 3945 I
> have isn't the default.  Repeat for several different disk options, and
> at least 4 or 5 different CD/ROM/DVD options.  Add in the fact that Dell
> often changes suppliers for disk and CD/DVD drives, and you have
> a nightmare
> coming...

> And then there's stuff on this machine that are *not* options, but don't
> matter to me.  I see an 'O2 Micro' Firewire in the 'lspci' output.  I have
> no idea how well it works.  I don't care what it contributes to the score.
> On the other hand, somebody who uses external Firewire disk enclosures may
> be *very* concerned about it, but not care in the slightest about
> the wireless
> card.
>
> Bonus points for figuring out what to do with systems that have some chip
> that's a supported XYZ driver, but wired up behind a squirrely bridge with
> some totally bizarre IRQ allocation, so you end up with something that's
> visible on lspci but not actually *usable* in any real sense of
> the term...

Let's not let the perfect be the enemy of the good. Remember, the goal is to
allow consumers to know whether or not their system's hardware
specifications are available. It's not about driver availability -- if the
hardware specifications are available and a driver is not, that's not the
hardware manufacturer's fault.

Linux is about *allowing* people to do things.

DS

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Valdis.Kletnieks]

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

On Wed, 20 Dec 2006 11:29:00 PST, David Schwartz said:

> Let's not let the perfect be the enemy of the good. Remember, the goal is to
> allow consumers to know whether or not their system's hardware
> specifications are available. It's not about driver availability -- if the
> hardware specifications are available and a driver is not, that's not the
> hardware manufacturer's fault.

My point was "their system's hardware specifications" is, for some popular
vendors, a *very* fuzzy notion. You can't (for instance) say "specs are
available for a Dell Latitude D820" - there are configurations that specs are
available for, and configs that aren't.  My D820 has an NVidia card in it - we
know the answer there.  Do you give a different answer for a D820 that has the
Intel i950 graphics chipset instead?

Even more annoying, Dell often *changes* the vendor - the line item for the DVD
drive says "8X DVD+/-RW" (other choices include 24X CD-ROM and 24X CD-RW/DVD).
Mine showed up with a Philips SDVD8820 - but it's possible that some other D820
will get some other vendor's DVD (I've seen 2 C820's ordered at the same time,
they showed up with 2 different vendor's "24X CD-RW/DVD").  It's possible that
some poor guy is going to get a D820 that has a DVD that we have a known
buggy driver for - what do we tell *them*?

It's *easy* to do a "semi-good" that tells you if there's drivers for the
hardware config you're running the program on. But there's 2 problems:

a) You probably already know the answer
b) By the time you can run the program, it's often too late....

So given those 2 points, what actual value-added info does this *give*, over
and above 'lspci' and friends?  I suppose maybe for a install CD, it gives
a quick way to cleanly abort the install with a "Don't bother continuing
unless it's OK that your graphics/wireless/whatever won't work".  On the
other hand, the installer should have a grasp on this *already*....

Perfect may be the enemy of the good, but the good is also the enemy of
stuff claiming to be good but misses on an important design goal...

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

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[alan]

On Wed, 20 Dec 2006, Valdis.Kletnieks@vt.edu wrote:

> On Wed, 20 Dec 2006 11:29:00 PST, David Schwartz said:
>
>> Let's not let the perfect be the enemy of the good. Remember, the goal is to
>> allow consumers to know whether or not their system's hardware
>> specifications are available. It's not about driver availability -- if the
>> hardware specifications are available and a driver is not, that's not the
>> hardware manufacturer's fault.
>
> My point was "their system's hardware specifications" is, for some popular
> vendors, a *very* fuzzy notion. You can't (for instance) say "specs are
> available for a Dell Latitude D820" - there are configurations that specs are
> available for, and configs that aren't.  My D820 has an NVidia card in it - we
> know the answer there.  Do you give a different answer for a D820 that has the
> Intel i950 graphics chipset instead?
>
> Even more annoying, Dell often *changes* the vendor - the line item for the DVD
> drive says "8X DVD+/-RW" (other choices include 24X CD-ROM and 24X CD-RW/DVD).
> Mine showed up with a Philips SDVD8820 - but it's possible that some other D820
> will get some other vendor's DVD (I've seen 2 C820's ordered at the same time,
> they showed up with 2 different vendor's "24X CD-RW/DVD").  It's possible that
> some poor guy is going to get a D820 that has a DVD that we have a known
> buggy driver for - what do we tell *them*?
>
> It's *easy* to do a "semi-good" that tells you if there's drivers for the
> hardware config you're running the program on. But there's 2 problems:
>
> a) You probably already know the answer
> b) By the time you can run the program, it's often too late....
>
> So given those 2 points, what actual value-added info does this *give*, over
> and above 'lspci' and friends?  I suppose maybe for a install CD, it gives
> a quick way to cleanly abort the install with a "Don't bother continuing
> unless it's OK that your graphics/wireless/whatever won't work".  On the
> other hand, the installer should have a grasp on this *already*....
>
> Perfect may be the enemy of the good, but the good is also the enemy of
> stuff claiming to be good but misses on an important design goal...

Valid points, but they are almost more for the distribution than they are 
for the kernel.

I have considered designing a routine for use in Annaconda or some other 
installer that lists all the known hardware and how much of it will 
actually work with that particular distro.  I know some people will not 
care, but many will.  (Especially the people who ask "Will my machine work 
with Linux".)

Many people do not know what they have in the way of hardware.  They 
bought a machine.  What they were sold (or requested) and what they got 
are usually two different things.  They may know a few specifics, but they 
are probably missing important details.  (How many people know the model 
of PCI chip in their machine?  Or who made the IDE chipset?  Or the 
ethernet chipset on the motherboard?)  For those of us that deal with 
hardware every day, this is not as big of an issue as those who bought 
something from Dell or HP and it arrived in a big box pre-assembled.

Is there some way to look at a kernel and determine what drivers are 
"good" and those that are "less good"?  (Other than ordering Alan Cox's 
brain in a jar...)  What needs to be known is the state of the driver for 
kernel X where X maybe something current or woefully out of date.

Maybe instead of an EXPORT_GPL symbol we need a 
EXPORT_THIS_DRIVER_IS_CRAP symbol.

-- 
Q: Why do programmers confuse Halloween and Christmas?
A: Because OCT 31 == DEC 25

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Marek Wawrzyczny]

On Wednesday 20 December 2006 16:11, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 19 Dec 2006 23:57:45 +1100, Marek Wawrzyczny said:
> > On Sunday 17 December 2006 21:11, Geert Uytterhoeven wrote:
> > And if you let yourself get carried away, you can also imagine a little
> > multi-platform utility. It would run on a test system collecting PCI IDs
> > before submitting them to the site  to get the system's overall Linux
> > friendliness rating.
>
> This is a can of worms, and then some.  For instance, let's consider this
> Latitude.  *THIS* one has an NVidia Quadro NVS 110M in it.  However, that's
> not the default graphics card on a Latitude D820.  So what number do you
> put in?  Do you use:

No, no, no...  I was never proposing that. I was thinking of something more 
along the lines of reporting back on open-source friendliness of 
manufacturers of devices, and perhaps on the availability of open source 
drivers for the devices. I am talking only about "detected" devices. The 
database would never try and guess the vendor, model and variation of the 
system.

> (Remember that "users" have different criteria than "developers" - most
> users would consider this entire thread "intellectual wanking", especially
> since the patch that spawned it got withdrawn.  And 'Frames Per Second'
> trumps that stupid little 'P' in the oops message.  Failure to understand
> this mindset guarantees that your computation of a "friendliness rating"
> is yet more intellectual wanking... ;)

I actually find that trying to obtain information about what hardware is/isn't 
supported in Linux is actually quite difficult to obtain. The information 
that's on the internet is either outdated or has not yet been written.
I was hoping to analyze the system's device information together with 
driver/device information obtained from the kernel source itself to give 
users a better (but not perhaps not as authoritative as I'd like to) picture 
of what to expect.

> And then there's stuff on this machine that are *not* options, but don't
> matter to me.  I see an 'O2 Micro' Firewire in the 'lspci' output.  I have
> no idea how well it works.  I don't care what it contributes to the score.
> On the other hand, somebody who uses external Firewire disk enclosures may
> be *very* concerned about it, but not care in the slightest about the
> wireless card.

Perhaps we just report on the individual devices then... forget the system 
rating.

> Bonus points for figuring out what to do with systems that have some chip
> that's a supported XYZ driver, but wired up behind a squirrely bridge with
> some totally bizarre IRQ allocation, so you end up with something that's
> visible on lspci but not actually *usable* in any real sense of the term...

Hmmm... does this happen often? False results are definedly a show stopper.

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Horst H. von Brand]

Marek Wawrzyczny <marekw1977@yahoo.com.au> wrote:

[...]

> No, no, no...  I was never proposing that. I was thinking of something more 
> along the lines of reporting back on open-source friendliness of 
> manufacturers of devices, and perhaps on the availability of open source 
> drivers for the devices. I am talking only about "detected" devices. The 
> database would never try and guess the vendor, model and variation of the 
> system.

This is a /massive/ ammount of effort, and the data required is hard to
come by before buying, so it is rather useless. What chip is in NetworkCard
675? In 675a? (yes, I've seen dLink cards called <foo> and <foo>+ which
were /radically/ different!). Yes, here you go to the computer store and
ask them to build you a machine from parts you specify. But it is far from
the common way to get a PC (those stores mostly cater to heavy-weight
gamers, many pieces have to be special ordered), and building a machine
that works OK with Linux is a two or three day exercise in hunting down
specifications for compatible pieces. Most folks wander into the next
department store and buy a PC. Mostly terrible crap, BTW.

Where this makes sense (printers!) the data is there, mostly up to date,
and accurate.

[...]

> I actually find that trying to obtain information about what hardware
> is/isn't supported in Linux is actually quite difficult to obtain. The
> information that's on the internet is either outdated or has not yet been
> written.  I was hoping to analyze the system's device information
> together with driver/device information obtained from the kernel source
> itself to give users a better (but not perhaps not as authoritative as
> I'd like to) picture of what to expect.

There is just way too much hardware out there, and new pieces come out
every day. Then there are lots of integrators that buy chips and build PCI
cards. Sometimes cards with supported chips just don't work at all. Etc. It
is all over the map.

Besides, many times you don't find information on some piece of hardware it
is because it is dirt cheap stuff that has no chance of working, so nobody
even tried.

[...]

> > Bonus points for figuring out what to do with systems that have some chip
> > that's a supported XYZ driver, but wired up behind a squirrely bridge with
> > some totally bizarre IRQ allocation, so you end up with something that's
> > visible on lspci but not actually *usable* in any real sense of the term...

> Hmmm... does this happen often? False results are definedly a show
> stopper.

Not just for systems, even for individual cards.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Valdis.Kletnieks]

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

On Fri, 22 Dec 2006 02:34:54 +1100, Marek Wawrzyczny said:
>
> > And then there's stuff on this machine that are *not* options, but don't
> > matter to me.  I see an 'O2 Micro' Firewire in the 'lspci' output.  I have
> > no idea how well it works.  I don't care what it contributes to the score.
> > On the other hand, somebody who uses external Firewire disk enclosures may
> > be *very* concerned about it, but not care in the slightest about the
> > wireless card.
> 
> Perhaps we just report on the individual devices then... forget the system 
> rating.

OK, *that* I see as potentially useful - I frequently get handed older
boxen with strange gear in them, and need a way to figure out if I want to
install software, or cannibalize it for parts. Also helpful if a buddy has
a Frankintel box they build, and they want to know if they can install
something other than Windows.... 

Bonus points if it sees a card that has a known out-of-tree driver and
tells you where to find it and what its license status is (I just went
down that road with an Intel 3945)...

> > Bonus points for figuring out what to do with systems that have some chip
> > that's a supported XYZ driver, but wired up behind a squirrely bridge with
> > some totally bizarre IRQ allocation, so you end up with something that's
> > visible on lspci but not actually *usable* in any real sense of the term...
> 
> Hmmm... does this happen often? False results are definedly a show stopper.

Oh, we see reports of squirrelly or downright confused hardware all the time
on this list. :)

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

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Horst H. von Brand]

Valdis.Kletnieks@vt.edu wrote:
> On Fri, 22 Dec 2006 02:34:54 +1100, Marek Wawrzyczny said:

[...]

> > Perhaps we just report on the individual devices then... forget the system 
> > rating.

> OK, *that* I see as potentially useful - I frequently get handed older
> boxen with strange gear

== gear for which there is probably no documentation at all

>                         in them, and need a way to figure out if I want to
> install software,

LiveCD of your choice...

>                   or cannibalize it for parts. Also helpful if a buddy has
> a Frankintel box they build, and they want to know if they can install
> something other than Windows.... 

Same as above.

> Bonus points if it sees a card that has a known out-of-tree driver and
> tells you where to find it and what its license status is (I just went
> down that road with an Intel 3945)...

If in-tree driver is already a challange, out-of-tree is hopeless.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513

RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Steven Rostedt]

On Sun, 2006-12-17 at 11:11 +0100, Geert Uytterhoeven wrote:
> On Thu, 14 Dec 2006, David Schwartz wrote:

> > That makes it clear that it's not about giving us the fruits of years of
> > your own work but that it's about enabling us to do our own work. (I would
> > have no objection to also requiring them to provide a minimal open-source
> > driver. I'm not trying to work out the exact terms here, just get the idea
> > out.)
> 
> Since `works with' may sound a bit too vague, something like
> `LinuxFriendly(tm)', with a happy penguin logo?
> 

I've bought a couple of products lately that had the happy penguin logo
on it. Just to find out that they only applied a bare minimum
functionality of the device for Linux. If you want more, you need to
plug it into a Windows box.

Funny, if you own a Mac, it had the same problem. It had a little more
functionality than the Linux port, but still far from what they give for
Windows.

I like the Open Hardware thing that Paolo mentioned.

-- Steve

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Dave Jones]

On Wed, Dec 13, 2006 at 09:39:11PM -0800, Martin J. Bligh wrote:

 > The Ubuntu feisty fawn mess was a dangerous warning bell of where we're
 > going. If we don't stand up at some point, and ban binary drivers, we
 > will, I fear, end up with an unsustainable ecosystem for Linux when
 > binary drivers become pervasive. I don't want to see Linux destroyed
 > like that.

Thing is, if kernel.org kernels get patched to disallow binary modules,
whats to stop Ubuntu (or anyone else) reverting that change in the
kernels they distribute ?  The landscape doesn't really change much,
given that the majority of Linux end-users are probably running
distro kernels.

		Dave

-- 
http://www.codemonkey.org.uk

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Adrian Bunk]

On Thu, Dec 14, 2006 at 08:07:04AM -0500, Dave Jones wrote:
> On Wed, Dec 13, 2006 at 09:39:11PM -0800, Martin J. Bligh wrote:
> 
>  > The Ubuntu feisty fawn mess was a dangerous warning bell of where we're
>  > going. If we don't stand up at some point, and ban binary drivers, we
>  > will, I fear, end up with an unsustainable ecosystem for Linux when
>  > binary drivers become pervasive. I don't want to see Linux destroyed
>  > like that.
> 
> Thing is, if kernel.org kernels get patched to disallow binary modules,
> whats to stop Ubuntu (or anyone else) reverting that change in the
> kernels they distribute ?  The landscape doesn't really change much,
> given that the majority of Linux end-users are probably running
> distro kernels.

If a kernel developer or a competitor sends a cease&desist letter to 
such a distribution, the situation changes from a complicated "derived 
work" discussion to a relatively clear "They circumvented a technical 
measure to enforce the copyright.".

> 		Dave

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

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Dave Jones]

On Thu, Dec 14, 2006 at 04:05:14PM +0100, Adrian Bunk wrote:
 > On Thu, Dec 14, 2006 at 08:07:04AM -0500, Dave Jones wrote:
 > > On Wed, Dec 13, 2006 at 09:39:11PM -0800, Martin J. Bligh wrote:
 > > 
 > > Thing is, if kernel.org kernels get patched to disallow binary modules,
 > > whats to stop Ubuntu (or anyone else) reverting that change in the
 > > kernels they distribute ?  The landscape doesn't really change much,
 > > given that the majority of Linux end-users are probably running
 > > distro kernels.
 > 
 > If a kernel developer or a competitor sends a cease&desist letter to 
 > such a distribution, the situation changes from a complicated "derived 
 > work" discussion to a relatively clear "They circumvented a technical 
 > measure to enforce the copyright.".

C&D's don't work that way.  They can enforce "don't ship my code"
but not "ship my code, or else".  The modification would be just like
any other thats allowable by the GPL.

		Dave

-- 
http://www.codemonkey.org.uk

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Olivier Galibert]

On Thu, Dec 14, 2006 at 11:11:33AM -0500, Dave Jones wrote:
> On Thu, Dec 14, 2006 at 04:05:14PM +0100, Adrian Bunk wrote:
>  > If a kernel developer or a competitor sends a cease&desist letter to 
>  > such a distribution, the situation changes from a complicated "derived 
>  > work" discussion to a relatively clear "They circumvented a technical 
>  > measure to enforce the copyright.".
> 
> C&D's don't work that way.  They can enforce "don't ship my code"
> but not "ship my code, or else".  The modification would be just like
> any other thats allowable by the GPL.

Careful here.  The "technical measure" protection is something
unrelated to the copyright license itself.  Cf the streambox vcr
lawsuit for instance (settled though) where not implementing the
handling of one bit that said "don't save to disk" in original code
seemed to be illegal.

  OG.

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Martin J. Bligh]

Dave Jones wrote:
> On Wed, Dec 13, 2006 at 09:39:11PM -0800, Martin J. Bligh wrote:
> 
>  > The Ubuntu feisty fawn mess was a dangerous warning bell of where we're
>  > going. If we don't stand up at some point, and ban binary drivers, we
>  > will, I fear, end up with an unsustainable ecosystem for Linux when
>  > binary drivers become pervasive. I don't want to see Linux destroyed
>  > like that.
> 
> Thing is, if kernel.org kernels get patched to disallow binary modules,
> whats to stop Ubuntu (or anyone else) reverting that change in the
> kernels they distribute ?  The landscape doesn't really change much,
> given that the majority of Linux end-users are probably running
> distro kernels.

I don't think they'd dare spit in our faces quite that directly.
They think binary modules are permissible because we don't seem to have
consistently stated an intent contradicting that - some individual
developers have, but ultimately Linus hasn't.

I'm not talking about any legal issues to do with derived works,
copyrights or licenses - a clear statement of intent is probably all
it'd take to tip the balance.

M.

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jan Engelhardt]

> > The Ubuntu feisty fawn mess was a dangerous warning bell of where we're
> > going. If we don't stand up at some point, and ban binary drivers, we
> > will, I fear, end up with an unsustainable ecosystem for Linux when
> > binary drivers become pervasive. I don't want to see Linux destroyed
> > like that.
>
>Thing is, if kernel.org kernels get patched to disallow binary modules,
>whats to stop Ubuntu (or anyone else) reverting that change in the
>kernels they distribute ?  The landscape doesn't really change much,
>given that the majority of Linux end-users are probably running
>distro kernels.

And even if the distros don't change it (all legal issues aside), there's
probably some free user who repacks the distro kernel.

	/me eyeballs myself...


	-`J'
-- 

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Ben Collins]

On Wed, 2006-12-13 at 21:39 -0800, Martin J. Bligh wrote:
> The Ubuntu feisty fawn mess was a dangerous warning bell of where we're
> going. If we don't stand up at some point, and ban binary drivers, we
> will, I fear, end up with an unsustainable ecosystem for Linux when
> binary drivers become pervasive. I don't want to see Linux destroyed
> like that.

Yes, people have been worried about this for years, and to my knowledge,
it seems like things have been getting better with drivers, not worse
(look at Intel). And yet, people want to enforce more and more
restrictions against binary-only drivers, when it appears that we are
already winning.

You can't talk about drivers that don't exist for Linux. Things like
bcm43xx aren't effected by this new restriction for GPL-only drivers.
There's no binary-only driver for it (ndiswrapper doesn't count). If the
hardware vendor doesn't want to write a driver for linux, you can't make
them. You can buy other hardware, but that's about it.

Here's the list of proprietary drivers that are in Ubuntu's restricted
modules package:

	madwifi (closed hal implementation, being replaced in openhal)
	fritz
	ati
	nvidia
	ltmodem (does that even still work?)
	ipw3945d (not a kernel module, but just the daemon)

In over a year that list has only grown by ipw3945d. None of our users
are asking for new proprietary drivers. Believe me, if they needed them,
I'd hear about it. We have more cases of new unsupported hardware than
we do of new hardware with binary-only drivers. This proposed
restriction doesn't fix that.

You know what I think hurts us more than anything? You know what
probably keeps companies from writing drivers or releasing specs? It's
because they know some non-paid kernel hackers out there will eventually
reverse engineer it and write the drivers for them. Free development,
and they didn't even have to release their precious specs.

Don't get me wrong, I'm not bashing reverse engineering, or writing our
own drivers. It's how Linux got started. But the problem isn't as narrow
as people would like to think. And proprietary code isn't a growing
problem. At best, it's just a distraction that will eventually go away
on it's own.

The whole hardware vendor landscape is showing this, and it's not
because we locked down the kernel, it's because we've shown how well we
play with others, and how easy it is to get along with the whole
community. Do we want to destroy this good will?

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[James Courtier-Dutton]

Ben Collins wrote:
> 
> Here's the list of proprietary drivers that are in Ubuntu's restricted
> modules package:
> 
> 	madwifi (closed hal implementation, being replaced in openhal)
> 	fritz
> 	ati
> 	nvidia
> 	ltmodem (does that even still work?)
> 	ipw3945d (not a kernel module, but just the daemon)
> 

More items will be added to that list soon.
E.g. Linux Binary only, Creative X-Fi sound card drivers for Q2 2007.
http://opensource.creative.com/

> In over a year that list has only grown by ipw3945d. None of our users
> are asking for new proprietary drivers. Believe me, if they needed them,
> I'd hear about it. We have more cases of new unsupported hardware than
> we do of new hardware with binary-only drivers. This proposed
> restriction doesn't fix that.

Is there a list of "new unsupported hardware" ?
Reverse engineering or datasheets is the only way out of that.
As Linux becomes more and more popular on the desktop, manufacturers 
will start feeling the pain of Linux "unsupported hardware" and have to 
back down and release datasheets. Ubuntu is helping a lot in that direction.

> 
> You know what I think hurts us more than anything? You know what
> probably keeps companies from writing drivers or releasing specs? It's
> because they know some non-paid kernel hackers out there will eventually
> reverse engineer it and write the drivers for them. Free development,
> and they didn't even have to release their precious specs.

Well, once a device has been reverse engineered and GPLed, the specs are 
then in public domain and the IP does not exist any more. It actually 
helps the company release the specs once the information is already out 
there. The company then sees less reason to hold onto their specs in the 
first place, and tends to release them earlier next time.

> 
> Don't get me wrong, I'm not bashing reverse engineering, or writing our
> own drivers. It's how Linux got started. But the problem isn't as narrow
> as people would like to think. And proprietary code isn't a growing
> problem. At best, it's just a distraction that will eventually go away
> on it's own.
> 

I agree, as time goes by, more and more devices are reverse engineered 
or the manufacturer finally sees sense and releases the specs/datasheets.


James

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Dave Jones]

On Thu, Dec 14, 2006 at 03:10:57PM +0000, James Courtier-Dutton wrote:
 > More items will be added to that list soon.
 > E.g. Linux Binary only, Creative X-Fi sound card drivers for Q2 2007.
 > http://opensource.creative.com/

Wow. That wins 'most ironic hostname' award for 2006.
Thankfully onboard hardware is "good enough" for most end-users
these days, leaving just the high-end audio professionals in the lurch.

		Dave

-- 
http://www.codemonkey.org.uk

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Ben Collins]

On Thu, 2006-12-14 at 15:10 +0000, James Courtier-Dutton wrote:
> Ben Collins wrote:
> > 
> > Here's the list of proprietary drivers that are in Ubuntu's restricted
> > modules package:
> > 
> > 	madwifi (closed hal implementation, being replaced in openhal)
> > 	fritz
> > 	ati
> > 	nvidia
> > 	ltmodem (does that even still work?)
> > 	ipw3945d (not a kernel module, but just the daemon)
> > 
> 
> More items will be added to that list soon.
> E.g. Linux Binary only, Creative X-Fi sound card drivers for Q2 2007.
> http://opensource.creative.com/

I haven't even caught wind of this not being supported yet. No demand ==
no reason to include it when it does become available.

> > In over a year that list has only grown by ipw3945d. None of our users
> > are asking for new proprietary drivers. Believe me, if they needed them,
> > I'd hear about it. We have more cases of new unsupported hardware than
> > we do of new hardware with binary-only drivers. This proposed
> > restriction doesn't fix that.
> 
> Is there a list of "new unsupported hardware" ?
> Reverse engineering or datasheets is the only way out of that.
> As Linux becomes more and more popular on the desktop, manufacturers 
> will start feeling the pain of Linux "unsupported hardware" and have to 
> back down and release datasheets. Ubuntu is helping a lot in that direction.

I've not kept a list. Would be non-trivial to go through the bug tracker
to find this info. Mostly it's things like webcams, and wacky little
hardware that starts cropping up in laptops.

> > 
> > You know what I think hurts us more than anything? You know what
> > probably keeps companies from writing drivers or releasing specs? It's
> > because they know some non-paid kernel hackers out there will eventually
> > reverse engineer it and write the drivers for them. Free development,
> > and they didn't even have to release their precious specs.
> 
> Well, once a device has been reverse engineered and GPLed, the specs are 
> then in public domain and the IP does not exist any more. It actually 
> helps the company release the specs once the information is already out 
> there. The company then sees less reason to hold onto their specs in the 
> first place, and tends to release them earlier next time.

Right, I think reverse engineering does help in that aspect. The other
aspect is that they now have a driver that sort of works for their
hardware. Most of the work is done, and they decide to help things along
to make it stable. So laying ground work like this can have advantages.

I think hardware vendors are a lot like users. Once they see the
advantages to opening up their drivers, they wonder why they didn't do
it a long time ago. Sort of like how users need that one push to use
Linux, and they start to wonder why they should go back to Windows.

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jan Engelhardt]

>You know what I think hurts us more than anything? You know what
>probably keeps companies from writing drivers or releasing specs? It's
>because they know some non-paid kernel hackers out there will eventually
>reverse engineer it and write the drivers for them. Free development,
>and they didn't even have to release their precious specs.

I don't get them either. If reverse-engineering will release their
precious trade secrets they wanted to protect by making the thing
closed, they could have just asked someone to write a linux driver
for free if they don't have the guts to actually pay
qualified/experienced developers.


	-`J'
-- 

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Michael Buesch]

On Thursday 14 December 2006 15:12, Ben Collins wrote:
> You can't talk about drivers that don't exist for Linux. Things like
> bcm43xx aren't effected by this new restriction for GPL-only drivers.
> There's no binary-only driver for it (ndiswrapper doesn't count). If the
> hardware vendor doesn't want to write a driver for linux, you can't make
> them. You can buy other hardware, but that's about it.

Not that is matters in this discussion, but there are binary Broadcom
43xx drivers for linux available.

> Here's the list of proprietary drivers that are in Ubuntu's restricted
> modules package:
> 
> 	madwifi (closed hal implementation, being replaced in openhal)
> 	fritz

Well, that's not just one, right?
That's like, 10 or so for the different AVM cards.
I'm just estimating. Correct me, if I'm wrong.

(And if I didn't mention it yet; AVM binary drivers are
complete crap.)

> 	ati
> 	nvidia
> 	ltmodem (does that even still work?)
> 	ipw3945d (not a kernel module, but just the daemon)

> Don't get me wrong, I'm not bashing reverse engineering, or writing our
> own drivers. It's how Linux got started. But the problem isn't as narrow
> as people would like to think. And proprietary code isn't a growing
> problem. At best, it's just a distraction that will eventually go away
> on it's own.

Well, I _hope_ that, too.

-- 
Greetings Michael.

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Ben Collins]

On Thu, 2006-12-14 at 20:29 +0100, Michael Buesch wrote:
> On Thursday 14 December 2006 15:12, Ben Collins wrote:
> > You can't talk about drivers that don't exist for Linux. Things like
> > bcm43xx aren't effected by this new restriction for GPL-only drivers.
> > There's no binary-only driver for it (ndiswrapper doesn't count). If the
> > hardware vendor doesn't want to write a driver for linux, you can't make
> > them. You can buy other hardware, but that's about it.
> 
> Not that is matters in this discussion, but there are binary Broadcom
> 43xx drivers for linux available.
> 
> > Here's the list of proprietary drivers that are in Ubuntu's restricted
> > modules package:
> > 
> > 	madwifi (closed hal implementation, being replaced in openhal)
> > 	fritz
> 
> Well, that's not just one, right?
> That's like, 10 or so for the different AVM cards.
> I'm just estimating. Correct me, if I'm wrong.

One driver, many variations of the chipset. That's true of most drivers.

> (And if I didn't mention it yet; AVM binary drivers are
> complete crap.)

Wont disagree with you there.

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jeffrey V. Merkey]

Well said, and I agree with ALL of your statements contained in this 
post. About damn time this was addressed.

Jeff

Linus Torvalds wrote:

>On Wed, 13 Dec 2006, Greg KH wrote:
>  
>
>>Numerous kernel developers feel that loading non-GPL drivers into the
>>kernel violates the license of the kernel and their copyright.  Because
>>of this, a one year notice for everyone to address any non-GPL
>>compatible modules has been set.
>>    
>>
>
>Btw, I really think this is shortsighted.
>
>It will only result in _exactly_ the crap we were just trying to avoid, 
>namely stupid "shell game" drivers that don't actually help anything at 
>all, and move code into user space instead.
>
>What was the point again?
>
>Was the point to alienate people by showing how we're less about the 
>technology than about licenses?
>
>Was the point to show that we think we can extend our reach past derived 
>work boundaries by just saying so? 
>
>The silly thing is, the people who tend to push most for this are the 
>exact SAME people who say that the RIAA etc should not be able to tell 
>people what to do with the music copyrights that they own, and that the 
>DMCA is bad because it puts technical limits over the rights expressly 
>granted by copyright law.
>
>Doesn't anybody else see that as being hypocritical?
>
>So it's ok when we do it, but bad when other people do it? Somehow I'm not 
>surprised, but I still think it's sad how you guys are showing a marked 
>two-facedness about this.
>
>The fact is, the reason I don't think we should force the issue is very 
>simple: copyright law is simply _better_off_ when you honor the admittedly 
>gray issue of "derived work". It's gray. It's not black-and-white. But 
>being gray is _good_. Putting artificial black-and-white technical 
>counter-measures is actually bad. It's bad when the RIAA does it, it's bad 
>when anybody else does it.
>
>If a module arguably isn't a derived work, we simply shouldn't try to say 
>that its authors have to conform to our worldview.
>
>We should make decisions on TECHNICAL MERIT. And this one is clearly being 
>pushed on anything but.
>
>I happen to believe that there shouldn't be technical measures that keep 
>me from watching my DVD or listening to my music on whatever device I damn 
>well please. Fair use, man. But it should go the other way too: we should 
>not try to assert _our_ copyright rules on other peoples code that wasn't 
>derived from ours, or assert _our_ technical measures that keep people 
>from combining things their way.
>
>If people take our code, they'd better behave according to our rules. But 
>we shouldn't have to behave according to the RIAA rules just because we 
>_listen_ to their music. Similarly, nobody should be forced to behave 
>according to our rules just because they _use_ our system. 
>
>There's a big difference between "copy" and "use". It's exatcly the same 
>issue whether it's music or code. You can't re-distribute other peoples 
>music (becuase it's _their_ copyright), but they shouldn't put limits on 
>how you personally _use_ it (because it's _your_ life).
>
>Same goes for code. Copyright is about _distribution_, not about use. We 
>shouldn't limit how people use the code.
>
>Oh, well. I realize nobody is likely going to listen to me, and everybody 
>has their opinion set in stone. 
>
>That said, I'm going to suggest that you people talk to your COMPANY 
>LAWYERS on this, and I'm personally not going to merge that particular 
>code unless you can convince the people you work for to merge it first.
>
>In other words, you guys know my stance. I'll not fight the combined 
>opinion of other kernel developers, but I sure as hell won't be the first 
>to merge this, and I sure as hell won't have _my_ tree be the one that 
>causes this to happen.
>
>So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees 
>first. This is not something where we use my tree as a way to get it to 
>other trees. This is something where the push had better come from the 
>other direction.
>
>Because I think it's stupid. So use somebody else than me to push your 
>political agendas, please.
>
>		Linus
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[David Woodhouse]

On Wed, 2006-12-13 at 20:15 -0800, Linus Torvalds wrote:
> If a module arguably isn't a derived work, we simply shouldn't try to say 
> that its authors have to conform to our worldview.

I wouldn't argue that _anyone_ else should be exposed to my worldview; I
think the Geneva Convention has something to say about cruel and unusual
punishments.

But I would ask that they honour the licence on the code I release, and
perhaps more importantly on the code I import from other GPL sources.

If they fail to do that under the 'honour system' then I'm not averse to
'enforcing' it by technical measures. (For some value of 'enforcement'
which is easy for them to patch out if their lawyers are _really_ sure
they'll win when I sue them, that is.)

That's the big difference I see between this and the RIAA case you
mention -- in the case of Linux refusing to load non-GPL modules, if the
user _really_ thinks they'll win in court they can just hack it to load
the offending modules again. We are giving a _very_ strong indication of
our intent, but we aren't actually _forcing_ it on them in quite the
same way. With DRM-crippled players and hardware it's not so easy to get
around.

I'm very much in favour of Greg's approach. Give 12 months warning and
then just prevent loading of non-GPL modules.

That way, we get back from the current "binary modules are the status
quo even though some people are currently psyching themselves up to sue
for it" to "binary modules are possible if you're _very_ sure of your
legal position and willing to defend it". I think that's a very good
thing to do.

> We should make decisions on TECHNICAL MERIT. And this one is clearly being 
> pushed on anything but.

Not on my part. The thing that makes me _particularly_ vehement about
binary-only crap this week is a very much a technical issue -- in
particular, the fact that we had to do post-production board
modifications to shoot our wireless chip in the head when it goes AWOL,
because the code for it wasn't available to us.

It's come back time and time again -- closed code is undebuggable,
unportable, unimprovable, unworkable. It's a detriment to the whole
system. That's very much a _technical_ issue, to me.

For non-kernel code I'm happy enough to release what I write under a BSD
licence. I'll default to GPL but usually respond favourably to requests
to do otherwise. It _isn't_ a religious issue.

> Same goes for code. Copyright is about _distribution_, not about use.
> We shouldn't limit how people use the code.

And we don't need to. Aside from the fact that they can patch out the
check if they have a genuine need to, they can also mark their module as
GPL without consequences as long as they don't _distribute_ it. We still
don't limit their _use_ of it.

> Oh, well. I realize nobody is likely going to listen to me, and everybody 
> has their opinion set in stone. 

My opinion is fairly much set from all the times I've come up against
_technical_ issues, I'll admit. But I did listen, and I agree with what
you say about the RIAA 'enforcement'. But I do see that as _very_
different to our 'enforcement', because ours is so easy to patch out
it's more of a 'hint' than a lockdown.

> That said, I'm going to suggest that you people talk to your COMPANY 
> LAWYERS on this, and I'm personally not going to merge that particular 
> code unless you can convince the people you work for to merge it first.

We've already merged EXPORT_SYMBOL_GPL. Is there a difference other than
one of extent? What about just marking kmalloc as EXPORT_SYMBOL_GPL for
a start? :)

> In other words, you guys know my stance. I'll not fight the combined 
> opinion of other kernel developers, but I sure as hell won't be the first 
> to merge this, and I sure as hell won't have _my_ tree be the one that 
> causes this to happen.
> 
> So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees 
> first. This is not something where we use my tree as a way to get it to 
> other trees. This is something where the push had better come from the 
> other direction.

It's better to have a coherent approach, and for all of us to do it on
roughly the same timescale. Getting the distributions do so this is
going to be like herding cats -- having it upstream and letting it
trickle down is a much better approach, I think.

-- 
dwmw2

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Alan]

On Thu, 14 Dec 2006 08:21:20 +0000
David Woodhouse <dwmw2@infradead.org> wrote:

> If they fail to do that under the 'honour system' then I'm not averse to
> 'enforcing' it by technical measures. (For some value of 'enforcement'
> which is easy for them to patch out if their lawyers are _really_ sure
> they'll win when I sue them, that is.)

There are specific rules against removal of technical measures *even if
the result is legal*. It is an offence in many countries thanks to the
RIAA lobbyists and their corrupt pet politicians to remove technical
measures applied to a -public domain- work.

So your argument doesn't fly.

> Not on my part. The thing that makes me _particularly_ vehement about
> binary-only crap this week is a very much a technical issue -- in
> particular, the fact that we had to do post-production board
> modifications to shoot our wireless chip in the head when it goes AWOL,
> because the code for it wasn't available to us.

Consider it an education process. Hopefully the contracts for the
chips/docs were watertight enough you can sue the offending supplier for
the total cost of the rework. If not then you are really complaining
about getting contract negotiations wrong.

> It's better to have a coherent approach, and for all of us to do it on
> roughly the same timescale. Getting the distributions do so this is
> going to be like herding cats -- having it upstream and letting it
> trickle down is a much better approach, I think.

I doubt any distribution but the FSF "purified" Debian (the one that has
no firmware so doesn't work) would do it.

Alan

dfsg isn't fsf (Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19])

[Oleg Verych]

On 2006-12-14, Alan wrote:
[]
> I doubt any distribution but the FSF "purified" Debian (the one that has
> no firmware so doesn't work) would do it.

DFSG "purified" Debian[1], please.

[1] <http://www.debian.org/social_contract>

--
-o--=O C  info emacs : not found  /. .\ ( is there any reason to live? )
 #oo'L O  info make  : not found      o ( yes! -- R.I.P. FSF+RMS, viva )
<___=E M  man gcc    : not found    `-- ( Debian Free Operating System )

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Theodore Tso]

>But I would ask that they honour the licence on the code I release, and
>perhaps more importantly on the code I import from other GPL sources.

It's not a question of "honoring the license"; it's a matter of what
is the reach of the license, as it relates to derivitive works.  It's
a complicated subject, and very dependent on the local law; certainly
in the U.S., when I asked a Law Professor from the MIT Sloan School of
Management, who specialized in IP issues about the FSF theory of GPL
contamination by dynamic linking, after I explained all the details of
how dynamic linking work, she told me that it would be "laughed out of
the courtroom".  

Now, is that a legal opinion?  No, because the facts of every single
case are different, and it was an opinion from someone over a decade
ago, and case law may have changed (although as far as I know, there
has been no court ruling directly on this particular point since
then).

The bottom line though is that it is not _nearly_ so clear as some
people would like to believe.  There is a lot of gray --- and that's a
GOOD thing.  If copyright contamination via dynamic linking was the
settled law of the land, then all of the Macintosh extensions that
people wrote --- WHICH WORK BY PATCHING THE OPERATING SYSTEM --- would
be illegal.  And given how much Apple hated people implying that the
UI as handed down from the mountain by the great prophet Steve Jobs
wasn't good enough, would we really have wanted Apple hounding
developers with lawsuits just because "they weren't honoring the
license" by daring to patch MacOS, and extending the OS by linking in
their code?

And what about people who link in a debugger into the Microsoft HAL or
other Microsoft DLL's in order to reverse engineer USB drivers for
Linux or reverse engineer protocols for Samba --- that's dynamic
linking of a sort too --- should that be illegal as well?  Imagine the
power that Microsoft could put into their EULA if copyright
contamination could be as easily achieved by dynamic linking.

Please, let's try to have a little sanity here,

						- Ted

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Linus Torvalds]

On Thu, 14 Dec 2006, David Woodhouse wrote:
> 
> But I would ask that they honour the licence on the code I release, and
> perhaps more importantly on the code I import from other GPL sources.

This is a total non-argument, and it doesn't get any betetr by being 
mindlessly repeated over and over and over again.

The license on the code you released talked about "derived works".

Not "everything I want to".

If a module owner can argue successfully in a court of law that a binary 
driver isn't a derived work, then the GPL simply DOES NOT COVER IT!

In other words, people CAN "honor the license" and still not be required 
to put their code under the GPL.

And no, including one header file in order to compile against something 
does not automatically make something a "derived work". It may, or it may 
not. It really isn't up to you to decide whether it does (and notice how 
I'm not saying that it's up to _me_ either!).

For example, all the same people who clamor for free software get 
absolutely RABID about "fair use". Guess what "fair use" actually MEANS? 

Think about it for a moment. It expressly _limits_ the right of copyright 
authors to claim "derived work". So if you argue that anything that ever 
includes your header file (but none of your code) and compiles against it 
is a "derived work", then you are basically very close to arguing that 
"fair use" does not exist.

Do you really want to argue that "everything that has touched anything 
copyrighted AT ALL is a derived work"? Do you feel lucky, punk?

THAT is why I think this discussion is so hypocritical. Either you accept 
that "fair use" and copyrights aren't black-and-white, or you don't.

If you think this is a black-and-white "copyright owners have all the 
rights", then you're standing with the RIAA's and the MPAA's of the world.

Me, personally, I think the RIAA and the MPAA is a shithouse. They are 
immoral. But guess what? They are immoral exactly _because_ they think 
that they automatically own ALL the rights, just because they own the 
copyright.

That is what it boils down to: copyright doesn't really give you "absolute 
power". This is why I have been _consistently_ arguing that we're not 
about "black and white" or "good against evil". It simply isn't that 
simple.

I don't like binary modules. I refuse to support them, and if it turns out 
that the module was written using Linux code, and just for Linux, I htink 
that's a _clear_ copyright violation, and that binary module is obviously 
a license violation.

But if the module was written for other systems, and just ported to Linux, 
and not using our code, then it's very much debatable whether it's 
actually a "derived work". Interfaces don't make "derived works" per se. 

Now, is it something you could sue people over? Sure. I actually do 
believe that it's very possible that a judge _would_ consider such a 
module a derived work, and you can sue people. It probably depends on 
circumstances too. 

But don't you see the problem with a black-and-white technical measure?

Don't you see the problem with the DMCA and the DVD encryption? 

Those kinds of things REMOVE the "reasonable thought" from the equation, 
and turn a gradual process into a sharp "right or wrong" situation. AND 
THAT IS WRONG. We simply do not LIVE in a world that is black and white.

So if you think somebody violates your copyright, send them a C&D letter, 
and eventually take them to court. It's been done. Companies that mis-used 
the GPL have actually been sued, and THEY HAVE LOST. That's a GOOD thing. 
I'm not arguing against that at all. What I'm arguing against is the 
"blind belief" that you or I have the right to tell people what to do, 
just because we own copyrights.

It's not a blind belief that I'm willing to subscribe to. Exactly because 
I have _seen_ what that blind belief results in - crap like the DMCA and 
the RIAA lawsuits.

			Linus

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jeff V. Merkey]

Again, I agree with EVERY statement Linus made here. We operate exactly 
as Linus describes, and
legally, NO ONE can take us to task on GPL issues. We post patches of 
affected kernel code
(albiet the code resembles what Linus describes as a "skeleton driver") 
and our proprietary
non derived code we sell with our appliances. He is right, everyone else 
should just accept
it and get on with life or cry linus a river.

Jeff

Linus Torvalds wrote:

>On Thu, 14 Dec 2006, David Woodhouse wrote:
>  
>
>>But I would ask that they honour the licence on the code I release, and
>>perhaps more importantly on the code I import from other GPL sources.
>>    
>>
>
>This is a total non-argument, and it doesn't get any betetr by being 
>mindlessly repeated over and over and over again.
>
>The license on the code you released talked about "derived works".
>
>Not "everything I want to".
>
>If a module owner can argue successfully in a court of law that a binary 
>driver isn't a derived work, then the GPL simply DOES NOT COVER IT!
>
>In other words, people CAN "honor the license" and still not be required 
>to put their code under the GPL.
>
>And no, including one header file in order to compile against something 
>does not automatically make something a "derived work". It may, or it may 
>not. It really isn't up to you to decide whether it does (and notice how 
>I'm not saying that it's up to _me_ either!).
>
>For example, all the same people who clamor for free software get 
>absolutely RABID about "fair use". Guess what "fair use" actually MEANS? 
>
>Think about it for a moment. It expressly _limits_ the right of copyright 
>authors to claim "derived work". So if you argue that anything that ever 
>includes your header file (but none of your code) and compiles against it 
>is a "derived work", then you are basically very close to arguing that 
>"fair use" does not exist.
>
>Do you really want to argue that "everything that has touched anything 
>copyrighted AT ALL is a derived work"? Do you feel lucky, punk?
>
>THAT is why I think this discussion is so hypocritical. Either you accept 
>that "fair use" and copyrights aren't black-and-white, or you don't.
>
>If you think this is a black-and-white "copyright owners have all the 
>rights", then you're standing with the RIAA's and the MPAA's of the world.
>
>Me, personally, I think the RIAA and the MPAA is a shithouse. They are 
>immoral. But guess what? They are immoral exactly _because_ they think 
>that they automatically own ALL the rights, just because they own the 
>copyright.
>
>That is what it boils down to: copyright doesn't really give you "absolute 
>power". This is why I have been _consistently_ arguing that we're not 
>about "black and white" or "good against evil". It simply isn't that 
>simple.
>
>I don't like binary modules. I refuse to support them, and if it turns out 
>that the module was written using Linux code, and just for Linux, I htink 
>that's a _clear_ copyright violation, and that binary module is obviously 
>a license violation.
>
>But if the module was written for other systems, and just ported to Linux, 
>and not using our code, then it's very much debatable whether it's 
>actually a "derived work". Interfaces don't make "derived works" per se. 
>
>Now, is it something you could sue people over? Sure. I actually do 
>believe that it's very possible that a judge _would_ consider such a 
>module a derived work, and you can sue people. It probably depends on 
>circumstances too. 
>
>But don't you see the problem with a black-and-white technical measure?
>
>Don't you see the problem with the DMCA and the DVD encryption? 
>
>Those kinds of things REMOVE the "reasonable thought" from the equation, 
>and turn a gradual process into a sharp "right or wrong" situation. AND 
>THAT IS WRONG. We simply do not LIVE in a world that is black and white.
>
>So if you think somebody violates your copyright, send them a C&D letter, 
>and eventually take them to court. It's been done. Companies that mis-used 
>the GPL have actually been sued, and THEY HAVE LOST. That's a GOOD thing. 
>I'm not arguing against that at all. What I'm arguing against is the 
>"blind belief" that you or I have the right to tell people what to do, 
>just because we own copyrights.
>
>It's not a blind belief that I'm willing to subscribe to. Exactly because 
>I have _seen_ what that blind belief results in - crap like the DMCA and 
>the RIAA lawsuits.
>
>			Linus
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Martin J. Bligh]

Jeff V. Merkey wrote:
> 
> Again, I agree with EVERY statement Linus made here. We operate exactly 
> as Linus describes, and
> legally, NO ONE can take us to task on GPL issues. We post patches of 
> affected kernel code
> (albiet the code resembles what Linus describes as a "skeleton driver") 
> and our proprietary
> non derived code we sell with our appliances. 


Yeah, like this one?

ftp://ftp.soleranetworks.com/pub/solera/dsfs/FedoraCore6/datascout-only-2.6.18-11-13-06.patch

@@ -1316,8 +1316,8 @@

         mod->license_gplok = license_is_gpl_compatible(license);
         if (!mod->license_gplok && !(tainted & TAINT_PROPRIETARY_MODULE)) {
-               printk(KERN_WARNING "%s: module license '%s' taints 
kernel.\n",
-                      mod->name, license);
+//             printk(KERN_WARNING "%s: module license '%s' taints 
kernel.\n",
+//                    mod->name, license);
                 add_taint(TAINT_PROPRIETARY_MODULE);
         }
  }
@@ -1691,10 +1691,10 @@
         /* Set up license info based on the info section */
         set_license(mod, get_modinfo(sechdrs, infoindex, "license"));

-       if (strcmp(mod->name, "ndiswrapper") == 0)
-               add_taint(TAINT_PROPRIETARY_MODULE);
-       if (strcmp(mod->name, "driverloader") == 0)
-               add_taint(TAINT_PROPRIETARY_MODULE);
+//     if (strcmp(mod->name, "ndiswrapper") == 0)
+//             add_taint(TAINT_PROPRIETARY_MODULE);
+//     if (strcmp(mod->name, "driverloader") == 0)
+//             add_taint(TAINT_PROPRIETARY_MODULE);

         /* Set up MODINFO_ATTR fields */
         setup_modinfo(mod, sechdrs, infoindex);

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jeff V. Merkey]

Martin J. Bligh wrote:

> Jeff V. Merkey wrote:
>
>>
>> Again, I agree with EVERY statement Linus made here. We operate 
>> exactly as Linus describes, and
>> legally, NO ONE can take us to task on GPL issues. We post patches of 
>> affected kernel code
>> (albiet the code resembles what Linus describes as a "skeleton 
>> driver") and our proprietary
>> non derived code we sell with our appliances. 
>
>
>
> Yeah, like this one?


Yeah, like that one.  WITH THE POLITICAL AGENDA CODE REMOVED.

Jeff



>
> ftp://ftp.soleranetworks.com/pub/solera/dsfs/FedoraCore6/datascout-only-2.6.18-11-13-06.patch 
>
>
> @@ -1316,8 +1316,8 @@
>
>         mod->license_gplok = license_is_gpl_compatible(license);
>         if (!mod->license_gplok && !(tainted & 
> TAINT_PROPRIETARY_MODULE)) {
> -               printk(KERN_WARNING "%s: module license '%s' taints 
> kernel.\n",
> -                      mod->name, license);
> +//             printk(KERN_WARNING "%s: module license '%s' taints 
> kernel.\n",
> +//                    mod->name, license);
>                 add_taint(TAINT_PROPRIETARY_MODULE);
>         }
>  }
> @@ -1691,10 +1691,10 @@
>         /* Set up license info based on the info section */
>         set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
>
> -       if (strcmp(mod->name, "ndiswrapper") == 0)
> -               add_taint(TAINT_PROPRIETARY_MODULE);
> -       if (strcmp(mod->name, "driverloader") == 0)
> -               add_taint(TAINT_PROPRIETARY_MODULE);
> +//     if (strcmp(mod->name, "ndiswrapper") == 0)
> +//             add_taint(TAINT_PROPRIETARY_MODULE);
> +//     if (strcmp(mod->name, "driverloader") == 0)
> +//             add_taint(TAINT_PROPRIETARY_MODULE);
>
>         /* Set up MODINFO_ATTR fields */
>         setup_modinfo(mod, sechdrs, infoindex);
>
>

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Linus Torvalds]

On Thu, 14 Dec 2006, Jeff V. Merkey wrote:
>
> Yeah, like that one.  WITH THE POLITICAL AGENDA CODE REMOVED.

No. That's really a purely technical thing.

You can still do whatever you want, but people who support the resulting 
mess know that they shouldn't.

		Linus

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jeff V. Merkey]

Linus Torvalds wrote:

>On Thu, 14 Dec 2006, Jeff V. Merkey wrote:
>  
>
>>Yeah, like that one.  WITH THE POLITICAL AGENDA CODE REMOVED.
>>    
>>
>
>No. That's really a purely technical thing.
>
>
>  
>
I'm not certain I understand what you mean here. Nasty messages using 
the word "taint" is purely subjective.
(as is your opinion or anyone else's about the use of the word, 
including my opinion). Based upon the way the GPL is worded, "taint"
actually goes the other way in legal circles when corporate attorneys 
talk about using GPL code with non-GPL code.

i.e. "... If we use that linux code it will TAINT our development 
process and CONTAMINATE and POULLTE our proprietary
development efforts with GPL code and we do not know the IP sources of 
such code...".

You should change it to "non-GPL" rather than "tainted" since the use of 
this word is actionable and inaccruate of reality.
Free GPL code is what it is. The GPL is the only thing that "taints" IP. 
The use of the word is reversed. Also Linus, we do
open source and promote certain projects outside of the Linux Kernel -- 
and we fully support the GPL.

You can still do whatever you want, but people who support the resulting 
mess know that they shouldn't.


BULLSHIT. I diagree and you are talking out of both sides of your mouth.

:-)

Jeff

>		Linus
>
>  
>

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[James Courtier-Dutton]

Linus Torvalds wrote:
> 
> On Wed, 13 Dec 2006, Greg KH wrote:
>> Numerous kernel developers feel that loading non-GPL drivers into the
>> kernel violates the license of the kernel and their copyright.  Because
>> of this, a one year notice for everyone to address any non-GPL
>> compatible modules has been set.
> 
> Btw, I really think this is shortsighted.
> 
> It will only result in _exactly_ the crap we were just trying to avoid, 
> namely stupid "shell game" drivers that don't actually help anything at 
> all, and move code into user space instead.
> 
> What was the point again?
> 
> Was the point to alienate people by showing how we're less about the 
> technology than about licenses?
> 
> Was the point to show that we think we can extend our reach past derived 
> work boundaries by just saying so? 
> 
> The silly thing is, the people who tend to push most for this are the 
> exact SAME people who say that the RIAA etc should not be able to tell 
> people what to do with the music copyrights that they own, and that the 
> DMCA is bad because it puts technical limits over the rights expressly 
> granted by copyright law.
> 
> Doesn't anybody else see that as being hypocritical?
> 
> So it's ok when we do it, but bad when other people do it? Somehow I'm not 
> surprised, but I still think it's sad how you guys are showing a marked 
> two-facedness about this.
> 
> The fact is, the reason I don't think we should force the issue is very 
> simple: copyright law is simply _better_off_ when you honor the admittedly 
> gray issue of "derived work". It's gray. It's not black-and-white. But 
> being gray is _good_. Putting artificial black-and-white technical 
> counter-measures is actually bad. It's bad when the RIAA does it, it's bad 
> when anybody else does it.
> 
> If a module arguably isn't a derived work, we simply shouldn't try to say 
> that its authors have to conform to our worldview.
> 
> We should make decisions on TECHNICAL MERIT. And this one is clearly being 
> pushed on anything but.
> 

I agree with Linus on these points. The kernel should not be enforcing 
these issues. Leave the lawyers to do that bit. If companies want to 
play in the "Grey Area", then it is at their own risk. Binary drivers 
are already difficult and expensive for the companies because they have 
to keep updating them as we change the kernel versions. If they do open 
source drivers, we update them for them as we change the kernel 
versions, so it works out cheaper for the companies involved.

The open source community tends to be able to reverse engineer all 
drivers eventually anyway in order to ensure compatibility with all 
kernel versions and also ensure that the code is well reviewed and 
therefore contains fewer security loopholes, e.g. Atheros Wireless open 
source HAL. This also tends to make it rather pointless for companies to 
do binary drivers, because all it does is delay the open source version 
of the driver and increase the security risk to users. One other example 
I have, is that I reverse engineered a sound card driver so that we had 
an open source driver for it. Once I had manually documented the sound 
card, so we had details of all the registers and how to use them, the 
manufacturer finally sent the datasheet to me! A bit late really, but it 
certainly did encourage the manufacturer to pass datasheets to 
developers. I now have a large array of datasheets from this 
manufacturer that save me having to reverse engineer other sound cards 
in their range.
Making binary drivers is therefore not a viable way to protect IP. We 
are slowly removing the excuses that companies can hide behind as 
reasons for not releasing datasheets to open source driver developers.

James

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Mark Hounschell]

James Courtier-Dutton wrote:
> 
> I agree with Linus on these points. The kernel should not be enforcing
> these issues. Leave the lawyers to do that bit. If companies want to
> play in the "Grey Area", then it is at their own risk. Binary drivers
> are already difficult and expensive for the companies because they have
> to keep updating them as we change the kernel versions. If they do open
> source drivers, we update them for them as we change the kernel
> versions, so it works out cheaper for the companies involved.
> 

Hum. We open sourced our drivers 2 years ago. Now one is 'changing' them
for us. The only way that happens is if they can get in the official
tree. I know just from monitoring this list that our drivers would never
be acceptable for inclusion in any "functional form". We open sourced
them purely out of respect for the way we know the community feels about
it.

It would cost more for us to make them acceptable for inclusion than it
does for us to just maintain them ourselves. I suspect that is true for
most vendor created drivers open source or not.

So kernel developers making the required changes as the kernel changes
is NO real incentive for any vendor to open source their drivers. Sorry.

If it were knowingly less difficult to actually get your drivers
included, that would be an incentive and then you original point would
hold as an additional incentive.

My humble $.02 worth

Regards
Mark

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Sean]

On Sun, 24 Dec 2006 06:57:58 -0500
Mark Hounschell <dmarkh@cfl.rr.com> wrote:


> Hum. We open sourced our drivers 2 years ago. Now one is 'changing' them
> for us. The only way that happens is if they can get in the official
> tree. I know just from monitoring this list that our drivers would never
> be acceptable for inclusion in any "functional form". We open sourced
> them purely out of respect for the way we know the community feels about
> it.

That shows some class, thanks.

> It would cost more for us to make them acceptable for inclusion than it
> does for us to just maintain them ourselves. I suspect that is true for
> most vendor created drivers open source or not.
> 
> So kernel developers making the required changes as the kernel changes
> is NO real incentive for any vendor to open source their drivers. Sorry.
> 
> If it were knowingly less difficult to actually get your drivers
> included, that would be an incentive and then you original point would
> hold as an additional incentive.

Out of curiosity what specific technical issues in your driver code make
you think that it would be too expensive to whip them into shape for
inclusion?

Cheers,
Sean

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Mark Hounschell]

Sean wrote:
> On Sun, 24 Dec 2006 06:57:58 -0500
> Mark Hounschell <dmarkh@cfl.rr.com> wrote:
> 
> 
>> Hum. We open sourced our drivers 2 years ago. Now one is 'changing' them
>> for us. The only way that happens is if they can get in the official
>> tree. I know just from monitoring this list that our drivers would never
>> be acceptable for inclusion in any "functional form". We open sourced
>> them purely out of respect for the way we know the community feels about
>> it.
> 
> That shows some class, thanks.
> 
>> It would cost more for us to make them acceptable for inclusion than it
>> does for us to just maintain them ourselves. I suspect that is true for
>> most vendor created drivers open source or not.
>>
>> So kernel developers making the required changes as the kernel changes
>> is NO real incentive for any vendor to open source their drivers. Sorry.
>>
>> If it were knowingly less difficult to actually get your drivers
>> included, that would be an incentive and then you original point would
>> hold as an additional incentive.
> 
> Out of curiosity what specific technical issues in your driver code make
> you think that it would be too expensive to whip them into shape for
> inclusion?
> 
> Cheers,
> Sean
> 

Well just off the top of my head, one of our drivers directly mucks with
all the irq affinities (irq_desc) via a provided user land library call.
This single call forces all 'other' irqs to be serviced by all the
'other' processors. I know this would never fly in kernel. User land
/proc manipulation is not an option for us  here.

We have another that absolutely requires the Bigphysarea patch. We
refuse to use "MEM=xxxx" and use a fixed address. Every installation
would require a special configuration and our 'end users' would have to
have some understanding of all that. We are also maintaining that patch
internally also. So this product (for full functionality with our not so
open source application) requires a special kernel to begin with. Other
than that this one might have a chance of inclusion. It only requires
the bigphysarea when used with this application. It will actually build
and work (basically) with or without it.

Another is actually somewhat tied to the one mentioned above in that
this one has to facilitate the ability of its card being able to to PIO
reads and writes to 'special locations' in userspace and to the SRAM
memory of the above card. Even when on different pci busses. I've looked
at some of the V4L drivers that also do this sort of thing and I'm
confused by how they are doing it so I'm almost certain that what we are
doing would be considered 'wrong'.

Then there is probably the biggest one of all. The coding style issue.
Don't get me wrong I understand and agree with what I've read about it.
Our drivers were written by hardware people. Or I should say they were
written by OUR hardware people. I can offend them because I am among
them. No offense intended to any of you invaluable hardware guys.

I see 6 months of full time work before I could even sanely ask what I
needed to do for inclusion. It seems easier to just try to keep up with
the changes.

I'm certain our company is not the only one in this situation. I see
many GPL external kernel drivers. Why?

Mark

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Xavier Bestel]

On Wed, 2006-12-13 at 20:15 -0800, Linus Torvalds wrote:
> That said, I'm going to suggest that you people talk to your COMPANY 
> LAWYERS on this, and I'm personally not going to merge that particular 
> code unless you can convince the people you work for to merge it first.

That's quoting material :) Who's your master, by Linus.

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Dave Jones]

On Wed, Dec 13, 2006 at 08:15:59PM -0800, Linus Torvalds wrote:

 > So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees 
 > first.

You don't think I already get enough hatemail from binary-module users ? :)

		Dave

-- 
http://www.codemonkey.org.uk

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Ben Collins]

> So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees 
> first. This is not something where we use my tree as a way to get it to 
> other trees. This is something where the push had better come from the 
> other direction.

I can probably speak for Ubuntu in saying we wont include any sort of
patch like this unless it's forced on us.

I have to agree with your your whole statement. The gradual changes to
lock down kernel modules to a particular license(s) tends to mirror the
slow lock down of content (music/movies) that people complain about so
loudly. It's basically becoming DRM for code.

I don't think anyone ever expected technical mechanisms to be developed
to enforce the GPL. It's sort of counter intuitive to why the GPL
exists, which is to free the code.

Let the licenses and lawyers fight to protect the code. The code doesn't
need to do that itself. It's got better things to do.

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jan Engelhardt]

On Dec 14 2006 08:46, Ben Collins wrote:
>I have to agree with your your whole statement. The gradual changes to
>lock down kernel modules to a particular license(s) tends to mirror the
>slow lock down of content (music/movies) that people complain about so
>loudly. It's basically becoming DRM for code.
>
>I don't think anyone ever expected technical mechanisms to be developed
>to enforce the GPL. It's sort of counter intuitive to why the GPL
>exists, which is to free the code.

"""To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights"""

>Let the licenses and lawyers fight to protect the code. The code doesn't
>need to do that itself. It's got better things to do.


	-`J'
-- 

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Ben Collins]

On Thu, 2006-12-14 at 18:21 +0100, Jan Engelhardt wrote:
> On Dec 14 2006 08:46, Ben Collins wrote:
> >I have to agree with your your whole statement. The gradual changes to
> >lock down kernel modules to a particular license(s) tends to mirror the
> >slow lock down of content (music/movies) that people complain about so
> >loudly. It's basically becoming DRM for code.
> >
> >I don't think anyone ever expected technical mechanisms to be developed
> >to enforce the GPL. It's sort of counter intuitive to why the GPL
> >exists, which is to free the code.
> 
> """To protect your rights, we need to make restrictions that forbid
> anyone to deny you these rights"""
> 
> >Let the licenses and lawyers fight to protect the code. The code doesn't
> >need to do that itself. It's got better things to do.

And these restrictions are in the letter of the GPL, not the function
prototypes of my code. Anyone willing to write libgpl-enforcement?

I don't care if someone wants to take my code and blatantly make use of
it in their own projects. I encourage it. I wrote it so people could do
whatever the hell they wanted to with it. It's when that project is made
available to others where I expect the GPL to enforce my copyrights and
licenses. I don't expect my code to be self checking for it, and then
add conditions that this portion of the code cannot be removed, because
then it isn't really GPL anymore, because then it isn't really free
either.

Maybe people will be happy if it ends up like this:

Booting Linux...
Please insert your original GNU/Linux source CD...

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jeff Garzik]

Linus Torvalds wrote:
> Because I think it's stupid. So use somebody else than me to push your 
> political agendas, please.


ACK, I agree completely.  I think its a silly, political, non-technical 
decision being pushed here.

For the record, I also disagree with the sneaky backdoor way people want 
to add EXPORT_SYMBOL_GPL() to key subsystems that drivers will need. 
EXPORT_SYMBOL_GPL() is more to emphasize that certain symbols are more 
'internal' or frequently changed, and therefore use of them would imply 
you are using a derived work of the kernel.  EXPORT_SYMBOL_GPL() is 
/not/ a place for political activism either.

	Jeff

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Linus Torvalds]

On Thu, 14 Dec 2006, Jeff Garzik wrote:
> 
> For the record, I also disagree with the sneaky backdoor way people want to
> add EXPORT_SYMBOL_GPL() to key subsystems that drivers will need.

I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if done 
properly (and I think we use it fairly well).

I think we _can_ do things where we give clear hints to people that "we 
think this is such an internal Linux thing that you simply cannot use this 
without being considered a derived work".

It's really just a strong hint about what we consider to be internal. The 
fact is, "intent" actually does matter, and as such our _intent_ in saying 
"these are very deep and internal interfaces" is actually meaningful - 
even in a court of law.

So I personally don't see EXPORT_SYMBOL_GPL() to be a "technical measure", 
I see it as being "documentation".

That said, I think that some people seem to be a bit over-eager to use it. 
And I actually think that weakens the rest of them too (imagine a lawyer 
saying in front of a judge:

  "Look, they marked 'strcpy()' as a symbol that requires us to be GPL'd, 
   but look, it's a standard function available everywhere else too, and 
   you can implement it as one line of code, so a module that uses it 
   clearly is NOT a derived work, so EXPORT_SYMBOL_GPL is obviously not 
   something that means anything"

So this is why I've actually argued in the past for some 
EXPORT_SYMBOL_GPL's to be demoted to "normal" EXPORT_SYMBOL's. Exactly 
because over-using them actually _weakens_ them, and makes them pointless 
both from a documentation _and_ from a legal standpoint.

Btw, I've actually had a lawyer tell me that EXPORT_SYMBOL_GPL makes legal 
sense and has actually made people happier, for what its worth. Of course, 
you can get <n*2> different opinions from <n> lawyers, so that may not be 
all that meaningful ;)

				Linus

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Chris Wedgwood]

On Thu, Dec 14, 2006 at 09:03:57AM -0800, Linus Torvalds wrote:

> I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if
> done properly (and I think we use it fairly well).
>
> I think we _can_ do things where we give clear hints to people that
> "we think this is such an internal Linux thing that you simply
> cannot use this without being considered a derived work".

Then why not change the name to something more along those lines?

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Christoph Hellwig]

On Thu, Dec 14, 2006 at 09:08:41AM -0800, Chris Wedgwood wrote:
> On Thu, Dec 14, 2006 at 09:03:57AM -0800, Linus Torvalds wrote:
> 
> > I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if
> > done properly (and I think we use it fairly well).
> >
> > I think we _can_ do things where we give clear hints to people that
> > "we think this is such an internal Linux thing that you simply
> > cannot use this without being considered a derived work".
> 
> Then why not change the name to something more along those lines?

Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense.

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Chris Wedgwood]

On Thu, Dec 14, 2006 at 05:38:27PM +0000, Christoph Hellwig wrote:

> Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense.

A quick grep shows that changing this now would require updating
nearly 1900 instances, so patches to do this would be pretty large and
disruptive (though we could support both during a transition and
migrate them over time).

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jan Engelhardt]

On Dec 14 2006 09:52, Chris Wedgwood wrote:
>On Thu, Dec 14, 2006 at 05:38:27PM +0000, Christoph Hellwig wrote:
>
>> Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense.
>
>A quick grep shows that changing this now would require updating
>nearly 1900 instances, so patches to do this would be pretty large and
>disruptive (though we could support both during a transition and
>migrate them over time).

I'd prefer to do it at once. But that's not my decision so you anyway do what
you want.

That said, I would like to keep EXPORT_SYMBOL_GPL, because EXPORT and INTERNAL
is somehow contrary. Just a wording issue.

	-`J'
-- 

Re: GPL only modules

[Eric W. Biederman]

Jan Engelhardt <jengelh@linux01.gwdg.de> writes:

> On Dec 14 2006 09:52, Chris Wedgwood wrote:
>>On Thu, Dec 14, 2006 at 05:38:27PM +0000, Christoph Hellwig wrote:
>>
>>> Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense.
>>
>>A quick grep shows that changing this now would require updating
>>nearly 1900 instances, so patches to do this would be pretty large and
>>disruptive (though we could support both during a transition and
>>migrate them over time).
>
> I'd prefer to do it at once. But that's not my decision so you anyway do what
> you want.
>
> That said, I would like to keep EXPORT_SYMBOL_GPL, because EXPORT and INTERNAL
> is somehow contrary. Just a wording issue.

I would suggest that we make the prefix MODULE and not EXPORT.  It
more accurately conveys what we are trying to say, and it doesn't
have the conflicting problem with INTERNAL.

I don't know if it is actually worth doing a great rename for such
a simple clarification in language.  But it is worth considering
because it would more strongly convey that we don't expect these
symbols to be used by everything.

Eric

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Eric Sandeen]

Chris Wedgwood wrote:
> On Thu, Dec 14, 2006 at 05:38:27PM +0000, Christoph Hellwig wrote:
> 
>> Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense.
> 
> A quick grep shows that changing this now would require updating
> nearly 1900 instances, so patches to do this would be pretty large and
> disruptive (though we could support both during a transition and
> migrate them over time).

Please don't use that name, it strikes me as much more confusing than
EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite convey
what it means, either.

EXPORT_SYMBOL_RESTRICTED?  EXPORT_SYMBOL_DERIVED?  At least something
which is not internally inconsistent would be good (how is something
which is exported "internal?")

And, as long as EXPORT_SYMBOL_GPL continues to check that the module
using it has a GPL license, then it really -is- exactly descriptive of
what it's doing and probably shouldn't be changed.  IIMHO.

-Eric

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Chris Wedgwood]

On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote:

> Please don't use that name, it strikes me as much more confusing
> than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite
> convey what it means, either.

Calling internal symbols _INTERNAL is confusing?

> EXPORT_SYMBOL_RESTRICTED?  EXPORT_SYMBOL_DERIVED?  At least
> something which is not internally inconsistent would be good (how is
> something which is exported "internal?")

But those symbols aren't, they're about internal interfaces that might
change.

> And, as long as EXPORT_SYMBOL_GPL continues to check that the module
> using it has a GPL license, then it really -is- exactly descriptive
> of what it's doing and probably shouldn't be changed.  IIMHO.

Well, if EXPORT_SYMBOL_GPL / EXPORT_SYMBOL_INTERNAL is about
documenting things, why restrict who can use them based on the
license?

Surely the licence is more about tainting the kernel and debugging not
politics?

Do we even need to check the license at all in that case?  Maybe a
better idea would be to embed where the source code is located and use
the non-existence of that for a tainting?

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Linus Torvalds]

On Thu, 14 Dec 2006, Chris Wedgwood wrote:
> 
> Calling internal symbols _INTERNAL is confusing?

Well, I'm not sure the _INTERNAL name is all that much better than the 
_GPL one.

In many ways, the _GPL one describes the _effects_ better, and also points 
out the reason _why_ something is marked differently. Sure, it's marked 
becasue it's internal, but why is does that have to be pointed out at all? 
Why not use the same EXPORT_SYMBOL? The answer to that is the "GPL" part, 
ie the expectation that internal symbols are so internal that they have 
license effects.

And if you were an external vendor doing binary only modules, would you 
react to "internal"? It wouldn't have the same "oh, _that_ is what it is 
all about" thing, would it?

So I do agree that we have probably done a bad job of explaining why that 
_GPL thing makes sense, and what it means on a deeper level (the license 
thing is a very superficial thing, but its worth naming just because the 
superficial thing is also the biggest _impact_ - even if it may not be the 
underlying deeper _reason_ for it).

So which makes more sense from a naming standpoint: the superficial impact 
that is what _matters_ for people, or the more subtle issue that causes it 
to have that impact?

I think that question is what it boils down to, and at least personally, 
while I see both things as being worthwhile, I think the superficial thing 
is the one that needs pointing out, because it's the one that may change 
your behaviour (while the deeper _meaning_ is more of just an 
explanation).

But I don't personally care that deeply. I mostly care about the fact that 
changing the name now would just be inconvenient and unnecessary churn, 
and that's probably my biggest reason to not want to do it ;)

			Linus

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Scott Preece]

On 12/14/06, Chris Wedgwood <cw@f00f.org> wrote:
> On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote:
>
> > Please don't use that name, it strikes me as much more confusing
> > than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite
> > convey what it means, either.
>
> Calling internal symbols _INTERNAL is confusing?

I think it's the combination of "INTERNAL" and "EXPORT" that seems
contradictory - "If it's internal, why are you exporting it?"

I think "EXPORT_SYMBOL_GPL_ONLY" or "...ONLY UNDER_GPL" would make the
meaning clearer, but I don't really think the gain is worth the pain.
Anybody using kernel interfaces ought to be able to figure it out.

>
> But those symbols aren't, they're about internal interfaces that might
> change.

Folks who think this is likely to make a difference in court might
want to look at
<http:www.linuxworld.com/news/2006/120806-closed-modules2.html> for a
litany of court cases that have rejected infringement claims where a
much sterner effort had been made to hide or block use of interfaces.
The article claims that courts have increasingly found that
interfacing your code to an existing work is not infringement,
regardless of what you have to work around to do it.

Of course, that's one author's reading of the case law and I'm sure
there are others who disagree, but it's something you'd want to keep
in mind in calculating the expected value of a suit...

scott

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jeff V. Merkey]

This whole effort is pointless.  This is the same kind of crap MICROSOFT 
DOES to create incompatibilities
DELIBERATELY.  The code is either FREE or its NOT FREE.    If the code 
is FREE then let it be.  You can put whatever
you want in the code -- I will remove any such constructs, just like I 
remove them frm Red Hat's releases when they put
in the same kind of deliberate breakage for anti-competitive reasons.

You can go and yell at Novell too, since they do the SAME THING with 
their releases and mix their modules with Linux.

All someone has to do or say is.

"... I did not ever accept the GPL license with the FREE code I was 
given.  They said the code was FREE, and I took them
at their word. .."

FREE implies a transfer of ownsership and you also have to contend with 
the Doctrine of Estoppel.  i.e. if someone
has been using the code for over two years, and you have not brought a 
cause of action, you are BARRED from doing so
under the Doctrine of Estoppel and statute of limitations. 

Here's what that means so you can look it up:

http://en.wikigadugi.org/wiki/Estoppel

What Linus argued is that FREE means just that. 

Jeff


Scott Preece wrote:

> On 12/14/06, Chris Wedgwood <cw@f00f.org> wrote:
>
>> On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote:
>>
>> > Please don't use that name, it strikes me as much more confusing
>> > than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite
>> > convey what it means, either.
>>
>> Calling internal symbols _INTERNAL is confusing?
>
>
> I think it's the combination of "INTERNAL" and "EXPORT" that seems
> contradictory - "If it's internal, why are you exporting it?"
>
> I think "EXPORT_SYMBOL_GPL_ONLY" or "...ONLY UNDER_GPL" would make the
> meaning clearer, but I don't really think the gain is worth the pain.
> Anybody using kernel interfaces ought to be able to figure it out.
>
>>
>> But those symbols aren't, they're about internal interfaces that might
>> change.
>
>
> Folks who think this is likely to make a difference in court might
> want to look at
> <http:www.linuxworld.com/news/2006/120806-closed-modules2.html> for a
> litany of court cases that have rejected infringement claims where a
> much sterner effort had been made to hide or block use of interfaces.
> The article claims that courts have increasingly found that
> interfacing your code to an existing work is not infringement,
> regardless of what you have to work around to do it.
>
> Of course, that's one author's reading of the case law and I'm sure
> there are others who disagree, but it's something you'd want to keep
> in mind in calculating the expected value of a suit...
>
> scott
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: GPL only modules

[Alexandre Oliva]

On Dec 14, 2006, "Jeff V. Merkey" <jmerkey@wolfmountaingroup.com> wrote:

> FREE implies a transfer of ownsership

It's about freedom, not price.  And even then, it's the license that
has not cost, not the copyright.

> and you also have to contend with the Doctrine of Estoppel.  i.e. if
> someone has been using the code for over two years, and you have not
> brought a cause of action, you are BARRED from doing so under the
> Doctrine of Estoppel and statute of limitations.

Sure, but we're not necessarily talking about code that is two years
old.  We're talking about future releases.  Then, if someone
interfaces with code that was already there before, they might claim
they're still entitled to do so.  But if it's new code they interface
with, or new code they wrote after this clarification is published,
would they still be entitled to estoppel?  FWIW, IANAL.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Eduard Bloch]

#include <hallo.h>
* Jeff V. Merkey [Thu, Dec 14 2006, 12:34:52PM]:
> 
> This whole effort is pointless.  This is the same kind of crap MICROSOFT 
> DOES to create incompatibilities

Just my 0.02€ - one of the things I wonder about is why eg. class*
interfaces has been replaced with something "protected" by GPL enforcing
macros. What is the point? Nobody wins. The access to the new fine-grained
system has been restricted for users, and distributors (yes, I maintain
a such module) have to work around this in-kernel restriction
and create cludges.

Greg (and others from the "every touch of my bits is a derivation of it
and I need to protect it" party)  - what are you thinking? Do you
seriously think that such restrictions would help anyone? IMO protecting
the access to interfaces is an utterly stupid idea in the free software
world.

Eduard.

-- 
<Ref|ex> Geht 'n Mantafahrer zum Manta-Treffen.
         Fragt: Fährt hier wer Manta
		-- #Debian.DE

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Dave Neuer]

On 12/14/06, Jeff V. Merkey <jmerkey@wolfmountaingroup.com> wrote:
>
> This whole effort is pointless.  This is the same kind of crap MICROSOFT
> DOES to create incompatibilities
> DELIBERATELY.  The code is either FREE or its NOT FREE.
>
> All someone has to do or say is.
>
> "... I did not ever accept the GPL license with the FREE code I was
> given.  They said the code was FREE, and I took them
> at their word. .."

At which point, hopefully everyone in that courtroom besides the idiot
who says this knows the difference between a license and a contract.
If anyone doesn't, they can be referred to:

"5.  You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License."

The code is free, as in "redistributable at no charge as long as you
adhere to the terms of the license."

Your estoppel argument seems too confused between laches, promissory
estoppel and statutes of limitations to even make sense of, sorry.

Dave

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Eric W. Biederman]

Things we can say without being hypocrites and without getting into
legal theory:

Kernel modules without source, or that don't have a GPL compatible
license are inconsiderate and rude.

Please don't be rude.

Eric

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jeff V. Merkey]

Eric W. Biederman wrote:

>Things we can say without being hypocrites and without getting into
>legal theory:
>
>Kernel modules without source, or that don't have a GPL compatible
>license are inconsiderate and rude.
>  
>
??????

>Please don't be rude.
>  
>
???????

J

>Eric
>
>  
>

RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Hua Zhong]

I'd suggest putting a Documentation/GPL-Symbols to explain this.

Then in the "tainted" message, have a pointer to that documentation. 

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org 
> [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Scott Preece
> Sent: Thursday, December 14, 2006 11:43 AM
> To: Chris Wedgwood
> Cc: Eric Sandeen; Christoph Hellwig; Linus Torvalds; Jeff 
> Garzik; Greg KH; Jonathan Corbet; Andrew Morton; Martin 
> Bligh; Michael K. Edwards; linux-kernel@vger.kernel.org
> Subject: Re: GPL only modules [was Re: [GIT PATCH] more 
> Driver core patches for 2.6.19]
> 
> On 12/14/06, Chris Wedgwood <cw@f00f.org> wrote:
> > On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote:
> >
> > > Please don't use that name, it strikes me as much more confusing 
> > > than EXPORT_SYMBOL_GPL, even though I agree that _GPL 
> doesn't quite 
> > > convey what it means, either.
> >
> > Calling internal symbols _INTERNAL is confusing?
> 
> I think it's the combination of "INTERNAL" and "EXPORT" that 
> seems contradictory - "If it's internal, why are you exporting it?"
> 
> I think "EXPORT_SYMBOL_GPL_ONLY" or "...ONLY UNDER_GPL" would 
> make the meaning clearer, but I don't really think the gain 
> is worth the pain.
> Anybody using kernel interfaces ought to be able to figure it out.
> 
> >
> > But those symbols aren't, they're about internal interfaces 
> that might 
> > change.
> 
> Folks who think this is likely to make a difference in court 
> might want to look at 
> <http:www.linuxworld.com/news/2006/120806-closed-modules2.html
> > for a litany of court cases that have rejected infringement 
> claims where a much sterner effort had been made to hide or 
> block use of interfaces.
> The article claims that courts have increasingly found that 
> interfacing your code to an existing work is not 
> infringement, regardless of what you have to work around to do it.
> 
> Of course, that's one author's reading of the case law and 
> I'm sure there are others who disagree, but it's something 
> you'd want to keep in mind in calculating the expected value 
> of a suit...
> 
> scott
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in the body of a message to 
> majordomo@vger.kernel.org More majordomo info at  
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Geert Uytterhoeven]

On Thu, 14 Dec 2006, Christoph Hellwig wrote:
> On Thu, Dec 14, 2006 at 09:08:41AM -0800, Chris Wedgwood wrote:
> > On Thu, Dec 14, 2006 at 09:03:57AM -0800, Linus Torvalds wrote:
> > 
> > > I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if
> > > done properly (and I think we use it fairly well).
> > >
> > > I think we _can_ do things where we give clear hints to people that
> > > "we think this is such an internal Linux thing that you simply
> > > cannot use this without being considered a derived work".
> > 
> > Then why not change the name to something more along those lines?
> 
> Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense.

I find all those names confusing. If these special symbols are
GPL/INTERNAL/WHATEVER, what are the other exported symbols?

GPL -> Non-GPL?
INTERNAL -> External?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Adrian Bunk]

On Wed, Dec 13, 2006 at 08:15:59PM -0800, Linus Torvalds wrote:
>...
> The fact is, the reason I don't think we should force the issue is very 
> simple: copyright law is simply _better_off_ when you honor the admittedly 
> gray issue of "derived work". It's gray. It's not black-and-white. But 
> being gray is _good_. Putting artificial black-and-white technical 
> counter-measures is actually bad. It's bad when the RIAA does it, it's bad 
> when anybody else does it.
>...

One important question is:
Who gets in danger due to this grey area?

E.g. if I'd consider it important enough to stop Ubuntu from 
distributing kernels and binary-only modules, I wouldn't try the 
difficult task to take legal actions against a company located on the 
Isle of Man.

The trick is to let a lawyer send cease and desist letters to people 
distributing the infringing software for 1 Euro at Ebay.

The nice thing about cease and desist letters is that the one who 
accepts one has to pay the > 1000 Euro costs for the lawyer for this 
letter.

Another lucrative task for the lawer would be to send cease and desist 
letters to people running mirrors located in Germany distributing the 
infringing software.

> 		Linus

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

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Alan]

> The trick is to let a lawyer send cease and desist letters to people 
> distributing the infringing software for 1 Euro at Ebay.

Doesn't that sound even more like the music industry ? Pick on Grandma,
and people who've no clue about the issue. It's not the way to solve such
problems. The world does not need "The war on binary modules". Educate
people instead, and talk to vendors.

Save the atomic weapons for the people who are straight forward ripping
off work in routers, tvs and all sorts of appliances.

Alan

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Adrian Bunk]

On Thu, Dec 14, 2006 at 04:33:47PM +0000, Alan wrote:
> > The trick is to let a lawyer send cease and desist letters to people 
> > distributing the infringing software for 1 Euro at Ebay.
> 
> Doesn't that sound even more like the music industry ? Pick on Grandma,
> and people who've no clue about the issue. It's not the way to solve such
> problems. The world does not need "The war on binary modules". Educate
> people instead, and talk to vendors.
> 
> Save the atomic weapons for the people who are straight forward ripping
> off work in routers, tvs and all sorts of appliances.

I'm not saying that I would do it, but it's the way how it would be 
done if anyone would do it.

It's not about whether that would be good or bad, the point is that the 
ones that will most likely be affected if anyone will ever take legal 
actions will not be the big distributions but people selling their old 
distributions on Ebay or people operating mirrors.

Cease and desist letters are a lucrative business for lawyers here in 
Germany, and such grey areas are simply a timebomb waiting for lawyers 
and/or people wanting to harm Linux to (ab)use them.

> Alan

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

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Theodore Tso]

On Thu, Dec 14, 2006 at 04:33:47PM +0000, Alan wrote:
> > The trick is to let a lawyer send cease and desist letters to people 
> > distributing the infringing software for 1 Euro at Ebay.
> 
> Doesn't that sound even more like the music industry ? Pick on Grandma,
> and people who've no clue about the issue. It's not the way to solve such
> problems. The world does not need "The war on binary modules". Educate
> people instead, and talk to vendors.

.... or like Microsoft, who is threatening to make war on end-users
instead of settling things with vendors.  (One of the reasons why I
personally find the Microsoft promise not to sue _Novell_'s end users
so nasty.  Microsoft shouldn't be threatening anyone's users; if they
have a problem, they should be taking it up with the relevant vendor,
not sueing innocent and relatively shallow-pocketed end-users and
distributors.)

One of the things that I find so interesting about how rabid people
get about enforcing GPL-only modules is how they start acting more and
more like the RIAA, MPAA, and Microsoft every day....

						- Ted

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Alan]

> One of the things that I find so interesting about how rabid people
> get about enforcing GPL-only modules is how they start acting more and
> more like the RIAA, MPAA, and Microsoft every day....

There is a saying

	"That which you fight you become"

It's a warning that is well worth heeding in a lot of situations

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Adrian Bunk]

On Thu, Dec 14, 2006 at 12:17:49PM -0500, Theodore Tso wrote:
> On Thu, Dec 14, 2006 at 04:33:47PM +0000, Alan wrote:
> > > The trick is to let a lawyer send cease and desist letters to people 
> > > distributing the infringing software for 1 Euro at Ebay.
> > 
> > Doesn't that sound even more like the music industry ? Pick on Grandma,
> > and people who've no clue about the issue. It's not the way to solve such
> > problems. The world does not need "The war on binary modules". Educate
> > people instead, and talk to vendors.
> 
> .... or like Microsoft, who is threatening to make war on end-users
> instead of settling things with vendors.  (One of the reasons why I
> personally find the Microsoft promise not to sue _Novell_'s end users
> so nasty.  Microsoft shouldn't be threatening anyone's users; if they
> have a problem, they should be taking it up with the relevant vendor,
> not sueing innocent and relatively shallow-pocketed end-users and
> distributors.)
> 
> One of the things that I find so interesting about how rabid people
> get about enforcing GPL-only modules is how they start acting more and
> more like the RIAA, MPAA, and Microsoft every day....

Please don't think or imply I'd plan to do this, I'm only saying that 
there's a risk for users in such grey areas.

It could be that someone who wants to harm Linux starts suing people 
distributing Linux. If your goal is to harm Linux, suing users can 
simply be much more effective than suing vendors...

It could even be that people distributing Linux could receive cease and 
desist letters from people without any real interest in the issue
itself - "cease and desist letter"s are so frequent in Germany because 
the people who have to sign them have to pay the lawyers' costs that are 
usually > 1000 Euro, and that's a good business for the lawyers.

> 						- Ted

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

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Pavel Machek]

On Thu 14-12-06 20:51:36, Adrian Bunk wrote:
> On Thu, Dec 14, 2006 at 12:17:49PM -0500, Theodore Tso wrote:
> > On Thu, Dec 14, 2006 at 04:33:47PM +0000, Alan wrote:
> > > > The trick is to let a lawyer send cease and desist letters to people 
> > > > distributing the infringing software for 1 Euro at Ebay.
> > > 
> > > Doesn't that sound even more like the music industry ? Pick on Grandma,
> > > and people who've no clue about the issue. It's not the way to solve such
> > > problems. The world does not need "The war on binary modules". Educate
> > > people instead, and talk to vendors.
> > 
> > .... or like Microsoft, who is threatening to make war on end-users
> > instead of settling things with vendors.  (One of the reasons why I
> > personally find the Microsoft promise not to sue _Novell_'s end users
> > so nasty.  Microsoft shouldn't be threatening anyone's users; if they
> > have a problem, they should be taking it up with the relevant vendor,
> > not sueing innocent and relatively shallow-pocketed end-users and
> > distributors.)
> > 
> > One of the things that I find so interesting about how rabid people
> > get about enforcing GPL-only modules is how they start acting more and
> > more like the RIAA, MPAA, and Microsoft every day....
> 
> Please don't think or imply I'd plan to do this, I'm only saying that 
> there's a risk for users in such grey areas.
> 
> It could be that someone who wants to harm Linux starts suing people 
> distributing Linux. If your goal is to harm Linux, suing users can 
> simply be much more effective than suing vendors...
> 
> It could even be that people distributing Linux could receive cease and 
> desist letters from people without any real interest in the issue
> itself - "cease and desist letter"s are so frequent in Germany because 
> the people who have to sign them have to pay the lawyers' costs that are 
> usually > 1000 Euro, and that's a good business for the lawyers.

Something is very wrong with German legal system, I'm afraid.

							Pavel
-- 
Thanks for all the (sleeping) penguins.

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Adrian Bunk]

On Thu, Dec 21, 2006 at 03:38:29PM +0000, Pavel Machek wrote:
> On Thu 14-12-06 20:51:36, Adrian Bunk wrote:
> > On Thu, Dec 14, 2006 at 12:17:49PM -0500, Theodore Tso wrote:
> > > On Thu, Dec 14, 2006 at 04:33:47PM +0000, Alan wrote:
> > > > > The trick is to let a lawyer send cease and desist letters to people 
> > > > > distributing the infringing software for 1 Euro at Ebay.
> > > > 
> > > > Doesn't that sound even more like the music industry ? Pick on Grandma,
> > > > and people who've no clue about the issue. It's not the way to solve such
> > > > problems. The world does not need "The war on binary modules". Educate
> > > > people instead, and talk to vendors.
> > > 
> > > .... or like Microsoft, who is threatening to make war on end-users
> > > instead of settling things with vendors.  (One of the reasons why I
> > > personally find the Microsoft promise not to sue _Novell_'s end users
> > > so nasty.  Microsoft shouldn't be threatening anyone's users; if they
> > > have a problem, they should be taking it up with the relevant vendor,
> > > not sueing innocent and relatively shallow-pocketed end-users and
> > > distributors.)
> > > 
> > > One of the things that I find so interesting about how rabid people
> > > get about enforcing GPL-only modules is how they start acting more and
> > > more like the RIAA, MPAA, and Microsoft every day....
> > 
> > Please don't think or imply I'd plan to do this, I'm only saying that 
> > there's a risk for users in such grey areas.
> > 
> > It could be that someone who wants to harm Linux starts suing people 
> > distributing Linux. If your goal is to harm Linux, suing users can 
> > simply be much more effective than suing vendors...
> > 
> > It could even be that people distributing Linux could receive cease and 
> > desist letters from people without any real interest in the issue
> > itself - "cease and desist letter"s are so frequent in Germany because 
> > the people who have to sign them have to pay the lawyers' costs that are 
> > usually > 1000 Euro, and that's a good business for the lawyers.
> 
> Something is very wrong with German legal system, I'm afraid.

The point that you can take legal actions against anyone distributing 
something that violates your rights should be present in more or less 
all legal systems.

What might be special in Germany is only that you can demand your costs 
after successfully taking legal actions.

> 							Pavel

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

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Pavel Machek]

On Sat 2006-12-23 12:24:29, Adrian Bunk wrote:
> On Thu, Dec 21, 2006 at 03:38:29PM +0000, Pavel Machek wrote:
> > On Thu 14-12-06 20:51:36, Adrian Bunk wrote:
> > > On Thu, Dec 14, 2006 at 12:17:49PM -0500, Theodore Tso wrote:
> > > > On Thu, Dec 14, 2006 at 04:33:47PM +0000, Alan wrote:
> > > > > > The trick is to let a lawyer send cease and desist letters to people 
> > > > > > distributing the infringing software for 1 Euro at Ebay.
> > > > > 
> > > > > Doesn't that sound even more like the music industry ? Pick on Grandma,
> > > > > and people who've no clue about the issue. It's not the way to solve such
> > > > > problems. The world does not need "The war on binary modules". Educate
> > > > > people instead, and talk to vendors.
> > > > 
> > > > .... or like Microsoft, who is threatening to make war on end-users
> > > > instead of settling things with vendors.  (One of the reasons why I
> > > > personally find the Microsoft promise not to sue _Novell_'s end users
> > > > so nasty.  Microsoft shouldn't be threatening anyone's users; if they
> > > > have a problem, they should be taking it up with the relevant vendor,
> > > > not sueing innocent and relatively shallow-pocketed end-users and
> > > > distributors.)
> > > > 
> > > > One of the things that I find so interesting about how rabid people
> > > > get about enforcing GPL-only modules is how they start acting more and
> > > > more like the RIAA, MPAA, and Microsoft every day....
> > > 
> > > Please don't think or imply I'd plan to do this, I'm only saying that 
> > > there's a risk for users in such grey areas.
> > > 
> > > It could be that someone who wants to harm Linux starts suing people 
> > > distributing Linux. If your goal is to harm Linux, suing users can 
> > > simply be much more effective than suing vendors...
> > > 
> > > It could even be that people distributing Linux could receive cease and 
> > > desist letters from people without any real interest in the issue
> > > itself - "cease and desist letter"s are so frequent in Germany because 
> > > the people who have to sign them have to pay the lawyers' costs that are 
> > > usually > 1000 Euro, and that's a good business for the lawyers.
> > 
> > Something is very wrong with German legal system, I'm afraid.
> 
> The point that you can take legal actions against anyone distributing 
> something that violates your rights should be present in more or less 
> all legal systems.
> 
> What might be special in Germany is only that you can demand your costs 
> after successfully taking legal actions.

What is special in Germany is fact that any random lawyer can demand
$1000 (not his cost, his profit) if you distribute code that is not
his...
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Adrian Bunk]

On Sat, Dec 23, 2006 at 10:36:02PM +0100, Pavel Machek wrote:
> On Sat 2006-12-23 12:24:29, Adrian Bunk wrote:
> > On Thu, Dec 21, 2006 at 03:38:29PM +0000, Pavel Machek wrote:
> > > On Thu 14-12-06 20:51:36, Adrian Bunk wrote:
> > > > On Thu, Dec 14, 2006 at 12:17:49PM -0500, Theodore Tso wrote:
> > > > > On Thu, Dec 14, 2006 at 04:33:47PM +0000, Alan wrote:
> > > > > > > The trick is to let a lawyer send cease and desist letters to people 
> > > > > > > distributing the infringing software for 1 Euro at Ebay.
> > > > > > 
> > > > > > Doesn't that sound even more like the music industry ? Pick on Grandma,
> > > > > > and people who've no clue about the issue. It's not the way to solve such
> > > > > > problems. The world does not need "The war on binary modules". Educate
> > > > > > people instead, and talk to vendors.
> > > > > 
> > > > > .... or like Microsoft, who is threatening to make war on end-users
> > > > > instead of settling things with vendors.  (One of the reasons why I
> > > > > personally find the Microsoft promise not to sue _Novell_'s end users
> > > > > so nasty.  Microsoft shouldn't be threatening anyone's users; if they
> > > > > have a problem, they should be taking it up with the relevant vendor,
> > > > > not sueing innocent and relatively shallow-pocketed end-users and
> > > > > distributors.)
> > > > > 
> > > > > One of the things that I find so interesting about how rabid people
> > > > > get about enforcing GPL-only modules is how they start acting more and
> > > > > more like the RIAA, MPAA, and Microsoft every day....
> > > > 
> > > > Please don't think or imply I'd plan to do this, I'm only saying that 
> > > > there's a risk for users in such grey areas.
> > > > 
> > > > It could be that someone who wants to harm Linux starts suing people 
> > > > distributing Linux. If your goal is to harm Linux, suing users can 
> > > > simply be much more effective than suing vendors...
> > > > 
> > > > It could even be that people distributing Linux could receive cease and 
> > > > desist letters from people without any real interest in the issue
> > > > itself - "cease and desist letter"s are so frequent in Germany because 
> > > > the people who have to sign them have to pay the lawyers' costs that are 
> > > > usually > 1000 Euro, and that's a good business for the lawyers.
> > > 
> > > Something is very wrong with German legal system, I'm afraid.
> > 
> > The point that you can take legal actions against anyone distributing 
> > something that violates your rights should be present in more or less 
> > all legal systems.
> > 
> > What might be special in Germany is only that you can demand your costs 
> > after successfully taking legal actions.
> 
> What is special in Germany is fact that any random lawyer can demand
> $1000 (not his cost, his profit) if you distribute code that is not
> his...

This is a misunderstanding.

You can demand the costs for your lawyer.
The costs for your lawyer depend on the amount in controversy.

The one who tells his lawyer to take legal actions might be a copyright 
owner, but it's also possible based on competition law.

> 								Pavel

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

Re: free module selection

[Markus Elfring]

> Btw, I really think this is shortsighted.
> 
> It will only result in _exactly_ the crap we were just trying to avoid, 
> namely stupid "shell game" drivers that don't actually help anything at 
> all, and move code into user space instead.

I would like to contribute some more viewpoints to this hot discussion.

Greg Kroah-Hartman revoked a bit of his code suggestion to take time for second
thoughts on the topic.
http://article.gmane.org/gmane.linux.kernel/475890


> So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees 
> first. This is not something where we use my tree as a way to get it to 
> other trees. This is something where the push had better come from the 
> other direction.

I hope that people from such distributions will not create too much pressure to
"standardise" in licence limitations.

I imagine that there is the important matter of free choice and corresponding
fair use. Software techniques can help to choose between available alternatives
and possibilities.

1. How much can (kernel) modules be filtered for specific needs like it is
performed by class loaders for the Java programming languagge?
   Are any interceptors internally involved that might throw exceptions to
forward constraints handling to special signal handlers?
   http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern

2. Greg's design approach seems to be a nice option for testing purposes.
   http://www.kroah.com/log/2006/12/13#uio

   Are there any similarities with microkernels?
   In which "space" would you like to run your device drivers?

3. All interested parties can develop a Linux distribution for the specific
needs of the various users and customers. It may be a fun project as a hobby or
it would be something for production applications like IPCop or SELinux. They
can also distinguish the acceptable licences on their own. How much do they
really want a limited selection that will be enforced by tools for the discussed
use case?
   http://distrowatch.com/

Regards,
Markus

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Bill Nottingham]

Greg KH (gregkh@suse.de) said: 
> An updated version is below.

If you're adding this, you should probably schedule EXPORT_SYMBOL_GPL
for removal at the same time, as this essentially renders that irrelevant.

That being said...

First, this is adding the measure at module load time. Any copyright
infringment happens on distribution; module load isn't (necessarily)
that; if I write random code and load it, without ever sending it
to anyone, I'm not violating the license, and this would prevent that.
So it seems somewhat misplaced.

Secondly...

> Oh, and for those who have asked me how we would enforce this after this
> date if this decision is made, I'd like to go on record that I will be
> glad to take whatever legal means necessary to stop people from
> violating this.

There's nothing stopping you undertaking these means now. Addition of
this measure doesn't change the copyright status of any code - what was
a violation before would still be a violation. Copyright's not something
like trademark, where it's sue-or-lose - there's no requirement for
constant action, and there's no requirement for enforcement measures.
If I reproduce and start selling copies of the White album, it doesn't
matter that there wasn't a mechanism on the CD that prevented me doing
that - it's still a copyright violation.

Hence, the only purpose of a clause like this legally would seem to be
to *intentionally* go after people using the DMCA. Which seems... tacky.

Of course, I don't have significant code of note in the kernel, so I can't
really prevent you from doing this if you want...

Bill

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Greg KH]

On Thu, Dec 14, 2006 at 12:10:15AM -0500, Bill Nottingham wrote:
> 
> Greg KH (gregkh@suse.de) said: 
> > An updated version is below.
> 
> If you're adding this, you should probably schedule EXPORT_SYMBOL_GPL
> for removal at the same time, as this essentially renders that irrelevant.
> 
> That being said...
> 
> First, this is adding the measure at module load time. Any copyright
> infringment happens on distribution; module load isn't (necessarily)
> that; if I write random code and load it, without ever sending it
> to anyone, I'm not violating the license, and this would prevent that.
> So it seems somewhat misplaced.

Yes, as Linus points out, this is the main point here, my apologies.
GPL covers distribution, not usage, no matter how much the people
working on v3 want to change that :)

Even if we change the kernel this way, it prevents valid and legal
usages of the kernel.  So I am wrong, sorry.

> Secondly...
> 
> > Oh, and for those who have asked me how we would enforce this after this
> > date if this decision is made, I'd like to go on record that I will be
> > glad to take whatever legal means necessary to stop people from
> > violating this.
> 
> There's nothing stopping you undertaking these means now. Addition of
> this measure doesn't change the copyright status of any code - what was
> a violation before would still be a violation.

Agreed, and I have done this in the past.  I only stated this because it
seems that some people keep just wishing this whole issue would go away
if they ignore it.

> Hence, the only purpose of a clause like this legally would seem to be
> to *intentionally* go after people using the DMCA. Which seems... tacky.

Despite my wardrobe consisting mainly of old t-shirts and jeans, I still
never want to be called tacky :)

It's just that I'm so damn tired of this whole thing.  I'm tired of
people thinking they have a right to violate my copyright all the time.
I'm tired of people and companies somehow treating our license in ways
that are blatantly wrong and feeling fine about it.  Because we are a
loose band of a lot of individuals, and not a company or legal entity,
it seems to give companies the chutzpah to feel that they can get away
with violating our license.

So when someone like Andrew gives me the opportunity to put a stop to
all of the crap that I have to put up with each and every day with a
tiny 2 line patch, I jumped in and took it.  I need to sit back and
remember to see the bigger picture some times, so I apologize to
everyone here.

And yes, it is crap that I deal with every day due to the lovely grey
area that is Linux kernel module licensing these days.  I have customers
that demand we support them despite them mixing three and more different
closed source kernel modules at once and getting upset that I have no
way to help them out.  I have loony video tweakers that hand edit kernel
oopses to try to hide the fact that they are using a binary module
bigger than the sum of the whole kernel and demand that our group fix
their suspend/resume issue for them.  I see executives who say one thing
to the community and then turn around and overrule them just because
someone made a horrible purchasing decision on the brand of laptop wifi
card that they purchased.  I see lawyers who have their hands tied by
attorney-client rules and can not speak out in public for how they
really feel about licenses and how to interpret them.

And in the midst of all of that are the poor users who have no idea who
to listen to.  They don't know what is going on, they "just want to use
their hardware" and don't give a damm about anyone's license.  And then
there's the distros out there that listen to those users and give them
the working distro as they see a market for it, and again, as a company,
justify to themselves that it must be ok to violate those kernel
developers rights because no one seems to be stopping them so far.

[side diversion, it's not the video drivers that really matter here
everyone, those are just so obvious.  It's the hundreds of other
blatantly infringing binary kernel modules out there that really matter.
The ones that control filesystems, cluster interconnects, disk arrays,
media codecs, and a whole host of custom hardware.  That's the real
problem that Linux faces now and will only get worse in the future.
It's not two stupid little video drivers, I could honestly care less
about them...]

But it's all part of the process, and I can live with it, even if at
times it drives me crazy.

But I know we will succeed, it will just take us a little longer to get
there, so I might as well learn to enjoy the view more.

Even though I really think I can get that patch by the Novell lawyers
and convince management there that it is something we can do, it's not
something that I want to take on, as I think my time can be better spent
coding to advance Linux technically, not fight legal battles.

I'll go delete that module.c patch from my tree now.

thanks,

greg k-h

p.s. I still think the UIO interface is a valid and good one.  And yes,
it might cause people to move stuff to userspace that they really should
not be just to get around the GPL issues.  But like loots of tools, it
can be used in good and bad ways, we shouldn't prevent the good usages
of it.  I'll work to get more real examples using it before
resubmitting.

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Rik van Riel]

Greg KH wrote:

> It's just that I'm so damn tired of this whole thing.  I'm tired of
> people thinking they have a right to violate my copyright all the time.

Pretty much every license under the sun is getting violated,
and people are getting away with it. The GPL is not special
in this regard.

> And yes, it is crap that I deal with every day due to the lovely grey
> area that is Linux kernel module licensing these days.  I have customers
> that demand we support them despite them mixing three and more different
> closed source kernel modules at once and getting upset that I have no
> way to help them out.

However, users do not like running unsupportable software
when the shit hits the fan - which it will always do with
any piece of software, eventually :)

Maybe we should just educate users and teach them to
avoid crazy unsupportable configurations and simply buy
the hardware that has open drivers available?

In the laptop space, I already try to avoid everything
non-Centrino, because chances are a closed source video
or network driver would be needed with something else[1].

Judging from how much vendor drivers tend to get improved
when they get merged upstream, I don't see how vendors
think they can get away with not merging their code upstream.

I'm not talking about this from a legal standpoint (millions
of people get away with blatantly illegal stuff every day),
but from a technical and market point of view.

Why would users buy a piece of hardware that needs a binary
only driver that's unsupportable, when they can buy a similar
piece of hardware that has a driver that's upstream and is
supported by every single Linux distribution out there?

Sure, the process of getting drivers merged upstream[2] can
take some time and effort, but the resulting improvements in
driver performance and stability are often worth it.  It's
happened more than once that the Linux kernel community's
review process turned up some opportunities for a 30% performance
improvement in a submitted driver.

Hardware companies: can you afford to miss out on the stability
and performance improvements that merging a driver upstream tends
to get?

Can you afford to miss out when your competitors are getting these
benefits?

[1] other vendors: fix your stuff, so I can recommend your hardware too!
[2] http://kernelnewbies.org/UpstreamMerge
-- 
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Chris Friesen]

Rik van Riel wrote:

> Why would users buy a piece of hardware that needs a binary
> only driver that's unsupportable, when they can buy a similar
> piece of hardware that has a driver that's upstream and is
> supported by every single Linux distribution out there?

In my experience it falls into a number of categories:

1) The system that requires the binary driver has other hardware on it 
that is required for the app.

2) The system that requires the binary driver costs significantly less, 
enough that they decide to bite the bullet on the software support side.

3) The system that requires the binary driver is the *only* one 
available in the specified form factor with the specified cpu architecture.

4) The team that decides on the hardware is totally divorced from the OS 
guys, so they don't know/care what is supported by open source drivers 
in the first place.

Chris

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Alan]

> Pretty much every license under the sun is getting violated,
> and people are getting away with it. The GPL is not special
> in this regard.

That may begin to change in time. There are a lot of people getting very
angry at the political level about the way large companies in particular
flout copyright law and claim to "not know" because they just bought
something in, often from Taiwan or China, with stolen code in it.

There are proposals on the table in the EU to make commercial piracy a
criminal not a civil matter in the case of copyright. (The original
proposal also suggested for patents which would have been rather dumb but
that seems to have been killed off for now). So in a couple years a GPL
violating product in the EU may entail a walk down to the local police
station rather than a private court case. 

In the UK also trading standards whose remit right now is trademark abuse
will also be getting enforcement powers and funding for copyright stuff.
The powers that be are mostly thinking "pirate DVD in the local market
stall", but some of us have other ideas.

We do need to distinguish between the blatant violators and the
borderline people - there's a difference between the folks shipping Linux
rip-offs binary only in random unlabelled routers and people like Nvidia
and Novell who are on the edge of the license corner cases.

Another thing we should do more is aggressively merge prototype open
drivers for binary only hardware - lets get Nouveau's DRM bits into the
kernel ASAP for example.

Alan

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jeff Garzik]

Alan wrote:
> Another thing we should do more is aggressively merge prototype open
> drivers for binary only hardware - lets get Nouveau's DRM bits into the
> kernel ASAP for example.

ACK++  We should definitely push Nouveau[1] as hard as we can.

	Jeff


[1] http://nouveau.freedesktop.org/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Dave Airlie]

On 12/15/06, Jeff Garzik <jeff@garzik.org> wrote:
> Alan wrote:
> > Another thing we should do more is aggressively merge prototype open
> > drivers for binary only hardware - lets get Nouveau's DRM bits into the
> > kernel ASAP for example.
>
> ACK++  We should definitely push Nouveau[1] as hard as we can.
>
>         Jeff
>

It'll get in when the developers feel it is at a stage where it can be
supported, at the moment (I'm not speaking for all the nouveau team
only my own opinion) the API isn't stable and putting it into the
kernel only means we've declared the API supportable, I know in theory
marking it EXPERIMENTAL might work, in practice it will just cause us
headaches at this stage, there isn't enough knowledgeable developers
working on it both support users and continue development at a decent
rate, so mainly ppl are concentrating on development until it can at
least play Q3, and for me dualhead on my G5 :-)

Dave.

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Michael Buesch]

On Thursday 14 December 2006 23:21, Dave Airlie wrote:
> On 12/15/06, Jeff Garzik <jeff@garzik.org> wrote:
> > Alan wrote:
> > > Another thing we should do more is aggressively merge prototype open
> > > drivers for binary only hardware - lets get Nouveau's DRM bits into the
> > > kernel ASAP for example.
> >
> > ACK++  We should definitely push Nouveau[1] as hard as we can.
> >
> >         Jeff
> >
> 
> It'll get in when the developers feel it is at a stage where it can be
> supported, at the moment (I'm not speaking for all the nouveau team
> only my own opinion) the API isn't stable and putting it into the
> kernel only means we've declared the API supportable, I know in theory
> marking it EXPERIMENTAL might work, in practice it will just cause us
> headaches at this stage, there isn't enough knowledgeable developers
> working on it both support users and continue development at a decent
> rate, so mainly ppl are concentrating on development until it can at
> least play Q3, and for me dualhead on my G5 :-)

To what degree does it work on the G5?
Can we already drive a desktop system with it?
I'd like to play around with this on my Quad.

-- 
Greetings Michael.

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Dave Airlie]

> >
> > It'll get in when the developers feel it is at a stage where it can be
> > supported, at the moment (I'm not speaking for all the nouveau team
> > only my own opinion) the API isn't stable and putting it into the
> > kernel only means we've declared the API supportable, I know in theory
> > marking it EXPERIMENTAL might work, in practice it will just cause us
> > headaches at this stage, there isn't enough knowledgeable developers
> > working on it both support users and continue development at a decent
> > rate, so mainly ppl are concentrating on development until it can at
> > least play Q3, and for me dualhead on my G5 :-)
>
> To what degree does it work on the G5?
> Can we already drive a desktop system with it?
> I'd like to play around with this on my Quad.
>

2D worked the last time I tested it and fixed up all the problems, it
is slightly faster than nv, but may be more unstable, still only
single head... 3D even on x86 doesn't work yet without pre-loading
nvidia to set the hardware up correctly.. but it's coming along....
there are summary updates posted ~weekly on the nouveau wiki....

Dave.

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Michael Buesch]

On Thursday 14 December 2006 23:39, Dave Airlie wrote:
> > >
> > > It'll get in when the developers feel it is at a stage where it can be
> > > supported, at the moment (I'm not speaking for all the nouveau team
> > > only my own opinion) the API isn't stable and putting it into the
> > > kernel only means we've declared the API supportable, I know in theory
> > > marking it EXPERIMENTAL might work, in practice it will just cause us
> > > headaches at this stage, there isn't enough knowledgeable developers
> > > working on it both support users and continue development at a decent
> > > rate, so mainly ppl are concentrating on development until it can at
> > > least play Q3, and for me dualhead on my G5 :-)
> >
> > To what degree does it work on the G5?
> > Can we already drive a desktop system with it?
> > I'd like to play around with this on my Quad.
> >
> 
> 2D worked the last time I tested it and fixed up all the problems, it
> is slightly faster than nv, but may be more unstable, still only
> single head... 3D even on x86 doesn't work yet without pre-loading
> nvidia to set the hardware up correctly.. but it's coming along....
> there are summary updates posted ~weekly on the nouveau wiki....

Ok, that's nice to hear. :)
Can't be much more pain than nv, heh.
And as I only have singlehead, anyway, I'll give it a try.

-- 
Greetings Michael.

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Bill Nottingham]

Rik van Riel (riel@redhat.com) said: 
> Maybe we should just educate users and teach them to
> avoid crazy unsupportable configurations and simply buy
> the hardware that has open drivers available?

Educating the users may help, but it's hard to do the
education once they've already bought the hardware. Generally,
it would be 1) buy hardware 2) run whatever comes with it
3) try Linux. Hard to get the 'if you're ever thinking about
running Linux, don't buy XYZ' into that workflow.

> Sure, the process of getting drivers merged upstream[2] can
> take some time and effort, but the resulting improvements in
> driver performance and stability are often worth it.  It's
> happened more than once that the Linux kernel community's
> review process turned up some opportunities for a 30% performance
> improvement in a submitted driver.
> 
> Hardware companies: can you afford to miss out on the stability
> and performance improvements that merging a driver upstream tends
> to get?
> 
> Can you afford to miss out when your competitors are getting these
> benefits?

This is the big point - we need to show the vendors how getting
upstream helps them.

Compare costs of all-in-house development versus shared-with-community
development.

Compare how quickly issues are fixed, and how often drivers actually
regress with in-tree vs. out-of-tree drivers.

Get case studies of drivers that have been opened (qeth? lpfc? Others?)
and get other companies to *go on the record* on how opening their
drivers and getting them upstream has helped them to lower their development
costs and scale their sales.

Bill

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Nigel Cunningham]

Hi.

Good arguments have already been put against it, so I'll just keep it
short and sweet (FWIW)

Nacked-by: Nigel Cunningham <nigel@suspend2.net>

Regards,

Nigel

RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[David Schwartz]

> Someone also mentioned that we could just put a nice poem into the
> kernel module image in order to be able to enforce our copyright license
> in any court of law.
>
> 	Full bellies of fish
> 	Penguins sleep under the moon
> 	Dream of wings that fly
>
> thanks,

Whoever says that has no understanding of copyright law. Copyright law
*only* protects something when there are a large number of equally-good ways
to accomplish the same thing. If there is only one way to accomplish a
particular function, it cannot be protected by copyright.

The Lexmark v. Static Controls case made this pretty clear. Lexmark did
pretty much the same thing with their toner cartridges. You cannot copyright
a password to get the effect of a patent (ownership of every way to
accomplish a particular function).

By the way, the GPL seems to prohibit this. Why is this not an "additional
restriction"? Where does the GPL say that you cannot create and use a
derivative work unless you put a notice in it stating that it is licensed
under the GPL?

I agree with Linus that this is insane hypocrisy. To be totally blunt, the
want to do this -- to control the way other people use the works they own --
is the same evil impulse that drives the RIAA. Shame on you. It's supposed
to be about free as in freedom.

DS

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[David Woodhouse]

On Wed, 2006-12-13 at 16:55 -0800, Greg KH wrote:
> Oh, and for those who have asked me how we would enforce this after this
> date if this decision is made, I'd like to go on record that I will be
> glad to take whatever legal means necessary to stop people from
> violating this. 

I see no _overriding_ reason to wait. This is a technical measure which
they'd need to deliberately work around, and which might make the case
easier to win -- but I think I'm on record already as planning to sue
someone soon for binary-only modules, even without this particular
technical measure to prevent them.

The only reason it hasn't happened so far is because lawyers make me
itch.

-- 
dwmw2

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Alan]

> 2008?  I bet a lot of people would read the above to say that their
> system will just drop dead of a New Year's hangover, and they'll freak.
> I wouldn't want to be the one getting all the email at that point...

I wouldn't worry. Everyone will have patched it back out again by then,
or made their driver lie about the license. Both of which make the
problem worse not better when it comes to debugging.

Alan

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Adrian Bunk]

On Thu, Dec 14, 2006 at 10:36:13AM +0000, Alan wrote:
> > 2008?  I bet a lot of people would read the above to say that their
> > system will just drop dead of a New Year's hangover, and they'll freak.
> > I wouldn't want to be the one getting all the email at that point...
> 
> I wouldn't worry. Everyone will have patched it back out again by then,
> or made their driver lie about the license. Both of which make the
> problem worse not better when it comes to debugging.

But make it easier when it comes to court...

> Alan

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

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Pavel Machek]

Hi!

> > > > So let's come out and ban binary modules, rather than pussyfooting
> > > > around, if that's what we actually want to do.
> > > 
> > > Give people 12 months warning (time to work out what they're going to do,
> > > talk with the legal dept, etc) then make the kernel load only GPL-tagged
> > > modules.
> > > 
> > > I think I'd favour that.  It would aid those people who are trying to
> > > obtain device specs, and who are persuading organisations to GPL their drivers.
> > 
> > Ok, I have no objection to that at all.  I'll whip up such a patch in a
> > bit to spit out kernel log messages whenever such a module is loaded so
> > that people have some warning.
> 
> Here you go.  The wording for the feature-removal-schedule.txt file
> could probably be cleaned up.  Any suggestions would be welcome.
> 
> thanks,
> 
> greg k-h
> 
> -----------
> From: Greg Kroah-Hartmna <gregkh@suse.de>
> Subject: Notify non-GPL module loading will be going away in January 2008
> 
> Numerous kernel developers feel that loading non-GPL drivers into the
> kernel violates the license of the kernel and their copyright.  Because
> of this, a one year notice for everyone to address any non-GPL
> compatible modules has been set.
> 
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
> ---
>  Documentation/feature-removal-schedule.txt |    9 +++++++++
>  kernel/module.c                            |    6 +++++-
>  2 files changed, 14 insertions(+), 1 deletion(-)
> 
> --- gregkh-2.6.orig/Documentation/feature-removal-schedule.txt
> +++ gregkh-2.6/Documentation/feature-removal-schedule.txt
> @@ -281,3 +281,12 @@ Why:	Speedstep-centrino driver with ACPI
>  Who:	Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
>  
>  ---------------------------
> +
> +What:	non GPL licensed modules will able to be loaded successfully.
> +When:	January 2008
> +Why:	Numerous kernel developers feel that loading non-GPL drivers into the
> +	kernel violates the license of the kernel and their copyright.
> +
> +Who:	Greg Kroah-Hartman <greg@kroah.com> or <gregkh@suse.de>
> +
> +---------------------------
> --- gregkh-2.6.orig/kernel/module.c
> +++ gregkh-2.6/kernel/module.c
> @@ -1393,9 +1393,13 @@ static void set_license(struct module *m
>  		license = "unspecified";
>  
>  	if (!license_is_gpl_compatible(license)) {
> -		if (!(tainted & TAINT_PROPRIETARY_MODULE))
> +		if (!(tainted & TAINT_PROPRIETARY_MODULE)) {
>  			printk(KERN_WARNING "%s: module license '%s' taints "
>  				"kernel.\n", mod->name, license);
> +			printk(KERN_WARNING "%s: This module will not be able "
> +				"to be loaded after January 1, 2008 due to its "
> +				"license.\n", mod->name);
> +		}
>  		add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
>  	}
>  }

perhaps printk('Binary only modules are not allowed by kernel license,
but copyright law may still allow them in special cases. Be careful,
Greg is going tuo sue you at beggining of 2008 if you get it wrong.')
would be acceptable way to educate people?
							Pavel
-- 
Thanks for all the (sleeping) penguins.

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Dmitry Torokhov]

On Sunday 24 December 2006 09:27, Pavel Machek wrote:
> 
> perhaps printk('Binary only modules are not allowed by kernel license,
> but copyright law may still allow them in special cases. Be careful,

Come again?

> Greg is going tuo sue you at beggining of 2008 if you get it wrong.')
> would be acceptable way to educate people?

Since this message will be seen by an end-user who is likely does not
do any distribution he has nothing to fear from Greg ;)

-- 
Dmitry

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Michael K. Edwards]

On 12/13/06, Andrew Morton <akpm@osdl.org> wrote:
> On Wed, 13 Dec 2006 13:32:50 -0800
> Martin Bligh <mbligh@mbligh.org> wrote:
>
> > So let's come out and ban binary modules, rather than pussyfooting
> > around, if that's what we actually want to do.
>
> Give people 12 months warning (time to work out what they're going to do,
> talk with the legal dept, etc) then make the kernel load only GPL-tagged
> modules.

IIRC, Linus has deliberately and explicitly estopped himself from
claiming that loading a binary-only driver is a GPL violation.  Do you
really want to create an arbitrage opportunity for intermediaries who
undo technical measures that don't match Linus's declared policy or,
in many people's opinion, the law in at least some jurisdictions?
(I'm not going to go all amateur-lawyer on you, but the transcript of
oral argument at the Supreme Court level in Lotus v. Borland makes
really interesting reading no matter where you live or what your
stance is on GPL-and-linking.)

> I think I'd favour that.  It would aid those people who are trying to
> obtain device specs, and who are persuading organisations to GPL their drivers.

I don't think it would.  There is a strong argument that GPL drivers
in the mainline kernel are a good idea on technical and business
grounds.  Making a federal case out of it is a distraction at best.

There is a widespread delusion that closed driver code is an asset in
an accounting sense.  It costs a lot of money to create and even more
to maintain in any kind of usable condition.  As long as managers of
chip development projects get away with shifting some of the real cost
of creating yet another buggy undocumented one-off CPU interface onto
a "software" team in a different cost center, the pressure to label
the code base an intangible asset is overwhelming.  It usually takes a
reorg or two to diffuse the responsibility enough to call it a sunk
cost, at which point someone might be brave enough to argue that
opening it up would save money and/or sell more chips.

As things stand, there is a slippery slope (in a good way) from a
totally-closed, one-off, buggy vendor driver to a GPL'ed driver in the
mainline kernel.  Customers get impatient for drivers that work, the
vendor allows a customer or a mutually acceptable third party to work
on the code, the sky doesn't fall.  There are some situations where
the business strategy of keeping the driver closed is defensible on
both engineering and regulatory/barrier-to-entry grounds, but they're
fairly rare; and some fraction of vendors come around to that view in
time.

> (Whereas the patch which is proposed in this thread hinders those people)

There we agree.

Cheers,
- Michael

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Kyle Moffett]

On Dec 13, 2006, at 17:20:35, Michael K. Edwards wrote:
> On 12/13/06, Andrew Morton <akpm@osdl.org> wrote:
>> On Wed, 13 Dec 2006 13:32:50 -0800 Martin Bligh  
>> <mbligh@mbligh.org> wrote:
>>> So let's come out and ban binary modules, rather than  
>>> pussyfooting around, if that's what we actually want to do.
>>
>> Give people 12 months warning (time to work out what they're going  
>> to do, talk with the legal dept, etc) then make the kernel load  
>> only GPL-tagged modules.
>
> IIRC, Linus has deliberately and explicitly estopped himself from  
> claiming that loading a binary-only driver is a GPL violation.  Do  
> you really want to create an arbitrage opportunity for  
> intermediaries who undo technical measures that don't match Linus's  
> declared policy or, in many people's opinion, the law in at least  
> some jurisdictions? (I'm not going to go all amateur-lawyer on you,  
> but the transcript of oral argument at the Supreme Court level in  
> Lotus v. Borland makes really interesting reading no matter where  
> you live or what your stance is on GPL-and-linking.)

Ok, so what Linus said is true for any code that _Linus_ wrote up  
until this point.  It is perfectly fine for the iptables developers  
to say "I think linking with my GPL IPTables code for makes your code  
a derivative work of mine", although I don't really have the legal  
knowledge to argue technical points either way.

Corporations change their mind on licensing all the time; though you  
can never revoke privileges you already granted on existing  
materials. As soon as you start creating new material (in the Linux  
case at a rate of multiple megs per month) you can set new licensing  
requirements on that new code as long as it's compatible with the  
requirements on the old code which it's linked against.

Cheers,
Kyle Moffett

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Alan]

> IIRC, Linus has deliberately and explicitly estopped himself from
> claiming that loading a binary-only driver is a GPL violation.  Do you

He only owns a small amount of the code. Furthermore he imported third
party GPL code using the license as sole permission. So he may have dug a
personal hole but many of the rest of us have been repeatedly saying
whenever he said that - that we do not agree. The FSF has always said
binary modules are wrong and there is FSF code imported into the kernel
by Linus on license only grounds.

Whether it is a good idea is a different question.

Alan.

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Al Viro]

On Wed, Dec 13, 2006 at 11:55:00PM +0000, Alan wrote:
> > IIRC, Linus has deliberately and explicitly estopped himself from
> > claiming that loading a binary-only driver is a GPL violation.  Do you
> 
> He only owns a small amount of the code. Furthermore he imported third
> party GPL code using the license as sole permission. So he may have dug a
> personal hole but many of the rest of us have been repeatedly saying
> whenever he said that - that we do not agree. The FSF has always said
> binary modules are wrong and there is FSF code imported into the kernel
> by Linus on license only grounds.
> 
> Whether it is a good idea is a different question.

Wait a bloody minute - the only FSF code in the kernel I know of is from
libgcc, which does allow linking to non-GPL code.  Is there anything else?

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Linus Torvalds]

On Wed, 13 Dec 2006, Alan wrote:
> 
> He only owns a small amount of the code. Furthermore he imported third 
> party GPL code using the license as sole permission. So he may have dug 
> a personal hole but many of the rest of us have been repeatedly saying 
> whenever he said that - that we do not agree.

[ The "he" being me in the above ]

Btw, I'd like to make it clear in this discussion too (as I have in 
others), that I agree 100% with Alan here. 

The thing is, my opinion is really just _my_ opinion. People shouldn't see 
it as anything else. When I say "I don't think we should totally disallow 
binary modules", you should always keep in mind that:

 - the fact that I think that _some_ binary modules may be perfectly legal 
   does not mean that I think _all_ binary modules would be legal. I think 
   there are lots of ways to make such a binary module that is obviously 
   not ok.

 - I really _am_ just one of hundreds of copyright owners. The fact that 
   _I_ am not necessarily all that eager to take things to court should in 
   no way be seen as estoppel for _others_ who decide that they want to 
   flex their legal rights.

So when I "may have dug a personal hole", please realize that this is 
actually a personal - and conscious - choice. I've never wanted to do 
copyright assignments, for several reasons: I think they are nasty and 
wrong personally, and I'd hate all the paperwork, and I think it would 
actually detract from the development model.

But one of the reasons I've never wanted copyright assignments is that I'm 
personally actually _more_ comfortable with the system being co-owned. I 
_like_ having my hands bound, and being in that hole. Not because of any 
strange sexual hangups either, but simply because I think being personally 
limited is something that makes people trust me more in the end - or 
rather, it is something that means that people don't _have_ to trust me.

So people know that I can't unilaterally change the license. And they 
_know_ that they can actually take things to court on their own. AND THAT 
IS A GOOD THING. The last thing anybody _ever_ wants is to have me having 
absolute powers. Not you guys, and certainly not me.

So you guys should always be happy, realizing that Linus may have his 
quirks, but that my quirks can't ever really screw you guys up.

So I repeat: my opinions are _my_ opinions. Nobody else is legally bound 
by them. And I'm certainly willing to bend my behaviour in the presense of 
pressure (I think only mindless idiots can't change their mind - I 
personally change some of my opinions several times a day just to keep 
them fresh), but in somethign like this, where I _do_ have a fairly strong 
opinion, I really think that this kind of patch has to be merged in 
somebody elses tree than mine.

If, after a year, it turns out that my tree is the only one that doesn't 
have that clause, I think I'll either get the hint, or people will realize 
that I'm pointless and will just ignore me. It will have taken you long 
enough to realize that ;)

Because one of the great things about the GPL is that _nobody_ has the 
power to deny other peoples will. Not even me, not even for the kernel.

				Linus

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Rik van Riel]

Michael K. Edwards wrote:

> I don't think it would.  There is a strong argument that GPL drivers
> in the mainline kernel are a good idea on technical and business
> grounds.

Any volunteers to expand on that in the Kernelnewbies section
on this subject?  So far the "business ground" is only half a
page or so :)

http://kernelnewbies.org/UpstreamMerge

-- 
All Rights Reversed

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Michael K. Edwards]

On 12/13/06, Greg KH <gregkh@suse.de> wrote:
> On Wed, Dec 13, 2006 at 12:38:05PM -0800, Michael K. Edwards wrote:
> > Seriously, though, please please pretty please do not allow a facility
> > for "going through a simple interface to get accesses to irqs and
> > memory regions" into the mainline kernel, with or without toy ISA
> > examples.
>
> Why?  X does it today :)

Er, I rest my case?  Anyway, the history around X11 is completely
different from the present situation, and there were good arguments at
the time for structuring the problem so that the X server was
relatively kernel-neutral even if it was banging directly on a
framebuffer, and later on 2-D acceleration hardware.  As graphics
chips have become more sophisticated, pure-userspace X11 has become
less tenable.

> > Embedded systems integrators have enough trouble with chip vendors who
> > think that exposing the device registers to userspace constitutes a
> > "driver".
>
> Yes, and because of this, they create binary only drivers today.  Lots
> of them.  All over the place.  Doing crazy stupid crap in kernelspace.

It does not get less crazy and stupid because we open a big hole from
kernelspace to userspace and let them pretend that they have a GPL
"driver" when all of the chip init logic is peeked and poked from the
same closed code in userspace.  Most low-level drivers (the kind that
involve IRQs and registers local to the CPU; USB is different) cannot
be done right from userspace and we shouldn't encourage people to try.

> Then there are people who do irq stuff in userspace but get it wrong.
> I've seen that happen many times in lots of different research papers
> and presentations.

Their problems need not become our problems.

> This interface does it correctly, and it allows those people who for
> some reason feel they do want to keep their logic in non-gpl code, to do
> it.

People who want to keep their logic in non-GPL code do so by providing
binary-only drivers.  That's a sane compromise in certain sectors, and
occasionally results in the eventual opening of the driver (when the
illusion of competitive advantage in closed-ness wears off) in
integrable shape.  A customer with some leverage and technical skill
can negotiate for access to the source code so that he can fix the
bugs that are biting him, rebuild with a toolchain that isn't from the
Dark Ages, and so forth: a real-life demonstration to the vendor that
letting outsiders work on the code will sell more chips.  But if you
actively encourage a brain-damaged userspace driver strategy, that
opportunity is lost.

> It also allows code that needs floating point to not be in the kernel
> and in one instance using this interface actually sped up the device
> because of the lack of the need to go between kernel and userspace a
> bunch of times.

What instance is that?  Are you sure it wasn't a case of things being
done in the driver that should have been done in a library all along?

> > The correct description is more like "porting shim for MMU-less RTOS
> > tasks"; and if the BSP vendors of the world can make a nickel
> > supplying them, more power to them.  Just not in mainline, please.
>
> Again, X does this today, and does does lots of other applications.
> This is a way to do it in a sane manner, to keep people who want to do
> floating point out of the kernel, and to make some embedded people much
> happier to use Linux, gets them from being so mad at Linux because we
> keep changing the internal apis, and makes me happier as they stop
> violating my copyright by creating closed drivers in the kernel.

Today's problem is that too many chip suppliers' in-house software
people have neither the skills nor the schedule room nor the influence
to insist that drivers be written competently and maintainably,
whether or not they are maintained in the public view.  So chipmakers
turn to the BSP vendors, whose business model is built around being
the only people who can do incremental development on the code they
write.

I'm not at all hostile to BSP vendors or to chipmakers who wind up in
this position; that's the way most of the industry works nowadays.
But I do want to know when I'm dealing with that situation, because
the appropriate strategies for getting a product to market are
different when it costs the chip vendor real cash money each time they
commission a recompile to meet some customer's expectations.
Pretending that driver code doesn't need reviewing every few months as
the kernel's locking strategies, timer handling, internal APIs, etc.
evolve makes things worse.

Just like the only thing worse that a salesperson who's on commission
is a salesperson who isn't on commission, the only thing worse than a
closed device driver in kernelspace is a closed device driver in
userspace.

Cheers,
- Michael

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Linus Torvalds]

On Wed, 13 Dec 2006, Michael K. Edwards wrote:
>
> On 12/13/06, Linus Torvalds <torvalds@osdl.org> wrote:
> > Ok, what kind of ass-hat idiotic thing is this?
> 
> C'mon, Linus, tell us how you _really_ feel.

I'll try to be less subtle next time ;)

> Seriously, though, please please pretty please do not allow a facility
> for "going through a simple interface to get accesses to irqs and
> memory regions" into the mainline kernel, with or without toy ISA
> examples.

I do agree.

I'm not violently opposed to something like this in practice (we've 
already allowed it for USB devices), but there definitely needs to be a 
real reason that helps _us_, not just some ass-hat vendor that looks for a 
way to avoid open-sourcing their driver.

If there are real and valid uses (and as mentioned, I actually think that 
the whole graphics-3D-engine-thing is such a use) where a kernel driver 
simply doesn't work out well, or where there are serious tecnical reasons 
why it wants to be in user space (and "stability" is not one such thing: 
if you access hardware directly in user space, and your driver is buggy, 
the machine is equally deal, and a hell of a lot harder to control to 
boot).

Microkernel people have their heads up their arses, none of their 
arguments have actually ever made any real logical sense. So look 
elsewhere for real reasons to do it in user space.

		Linus

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Pavel Machek]

Hi!

> > Seriously, though, please please pretty please do not allow a facility
> > for "going through a simple interface to get accesses to irqs and
> > memory regions" into the mainline kernel, with or without toy ISA
> > examples.
> 
> I do agree.
> 
> I'm not violently opposed to something like this in practice (we've 
> already allowed it for USB devices), but there definitely needs to be a 
> real reason that helps _us_, not just some ass-hat vendor that looks for a 
> way to avoid open-sourcing their driver.
> 
> If there are real and valid uses (and as mentioned, I actually think that 
> the whole graphics-3D-engine-thing is such a use) where a kernel driver 
> simply doesn't work out well, or where there are serious tecnical reasons 
> why it wants to be in user space (and "stability" is not one such thing: 
> if you access hardware directly in user space, and your driver is buggy, 
> the machine is equally deal, and a hell of a lot harder to control to 
> boot).

Well.. it is easier to debug in userspace. While bad hw access can
still kill the box, bad free() will not, and most bugs in early
developent are actually of 2nd kind.
						Pavel
-- 
Thanks for all the (sleeping) penguins.

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Jörn Engel]

On Sat, 16 December 2006 09:05:32 +0000, Pavel Machek wrote:
> 
> Well.. it is easier to debug in userspace. While bad hw access can
> still kill the box, bad free() will not, and most bugs in early
> developent are actually of 2nd kind.

Isn't that what qemu is for?

Jörn

-- 
Happiness isn't having what you want, it's wanting what you have.
-- unknown

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Pavel Machek]

Hi!

> > Well.. it is easier to debug in userspace. While bad hw access can
> > still kill the box, bad free() will not, and most bugs in early
> > developent are actually of 2nd kind.
> 
> Isn't that what qemu is for?

I do not think you can reasonably debug driver for new hardware under
qemu.

Anyway, doing it in userspace is just convenient.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Benjamin Herrenschmidt]

> Ok, what kind of ass-hat idiotic thing is this?
> 
> 	irqreturn_t uio_irq_handler(int irq, void *dev_id)
> 	{
> 	        return IRQ_HANDLED;
> 	}
> 
> exactly what is the point here? No way will I pull this kind of crap. You 
> just seem to have guaranteed a dead machine if the irq is level-triggered, 
> since it will keep on happening forever.
> 
> Please remove.
> 
> YOU CANNOT DO IRQ'S BY LETTING USER SPACE SORT IT OUT!

Actually, you can... but wether you want is a different story :-)

You can simply mask it, have it handled by userspace and re-enable it
when that's done. Though say hello to horrible interrupt latencies and
hope you aren't sharing it with anything critical...

I don't mean I -like- the approach... I just say it can be made to
sort-of work. But I don't see the point.

Ben.

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Jan Engelhardt]

>You can simply mask it, have it handled by userspace and re-enable it
>when that's done. Though say hello to horrible interrupt latencies and
>hope you aren't sharing it with anything critical...

For the sharing case, some sort of softirq should be created. That is, when a
hard interrupt is generated and the irq handler is executed, set a flag that at
some other point in time, the irq is delivered to userspace. Like you do with
signals in userspace:

 void sighandler(int s) {
     exit_main_loop_soon = 1;
 }

something similar could be done in kernelspace without interrupting important
devices/irq_handlers sharing the same IRQ. 


	-`J'
-- 

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Linus Torvalds]

On Wed, 13 Dec 2006, Jan Engelhardt wrote:
> 
> For the sharing case, some sort of softirq should be created. That is, when a
> hard interrupt is generated and the irq handler is executed, set a flag that at
> some other point in time, the irq is delivered to userspace. Like you do with
> signals in userspace:

NO.

The whole point is, YOU CANNOT DO THIS.

You need to shut the device up. Otherwise it keeps screaming.

Please, people, don't confuse the issue any further. A hardware driver

	ABSOLUTELY POSITIVELY HAS TO

have an in-kernel irq handler that knows how to turn the irq off.

End of story. No ifs, buts, maybes about it.

You cannot have a generic kernel driver that doesn't know about the 
low-level hardware (not with current hardware - you could make the "shut 
the f*ck up" a generic thing if you designed hardware properly, but that 
simply does not exist in general right now).

In short: a user-space device driver has exactly TWO choices:

 - don't use interrupts at all, just polling

 - have an in-kernel irq handler that at a minimum knows how to test 
   whether the irq came from that device and knows how to shut it up.

This means NOT A GENERIC DRIVER. That simply isn't an option on the 
table, no matter how much people would like it to be.

			Linus

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Jan Engelhardt]

>> For the sharing case, some sort of softirq should be created. That is, when a
>> hard interrupt is generated and the irq handler is executed, set a flag that at
>> some other point in time, the irq is delivered to userspace. Like you do with
>> signals in userspace:
>
>NO.
>
>The whole point is, YOU CANNOT DO THIS.
>
>You need to shut the device up. Otherwise it keeps screaming.
>
>Please, people, don't confuse the issue any further. A hardware driver
>
>	ABSOLUTELY POSITIVELY HAS TO
>
>have an in-kernel irq handler that knows how to turn the irq off.
>
>End of story. No ifs, buts, maybes about it.

I don't get you. The rtc module does something similar (RTC generates
interrupts and notifies userspace about it)


  irqreturn_t uio_handler(...) {
      disable interrupts for this dev;
      set a flag that notifies userspace the next best time;
      seomstruct->flag |= IRQ_ARRIVED;
      return IRQ_HANDLED;
  }


  /* Userspace->kernel notification, e.g. by means of a device node
     /dev/uio or some ioctl. */
  int uio_write(...) {
      somestruct->flag &= ~IRQ_ARRIVED;
      enable interrupts for the device;
  }



> - have an in-kernel irq handler that at a minimum knows how to test 
>   whether the irq came from that device and knows how to shut it up.
>
>This means NOT A GENERIC DRIVER. That simply isn't an option on the 
>table, no matter how much people would like it to be.


	-`J'
-- 

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Jan Engelhardt]

>  irqreturn_t uio_handler(...) {
>      disable interrupts for this dev;
>      set a flag that notifies userspace the next best time;
>      seomstruct->flag |= IRQ_ARRIVED;
>      return IRQ_HANDLED;
>  }

Rather than IRQ_HANDLED, it should have been: remove this irq handler 
from the irq handlers for irq number N, so that it does not get called 
again until userspace has acked it.

See, maybe I don't have enough clue yet to exactly figure out why you 
say it does not work. However, this is how simple people see it 8)


	-`J'
-- 

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Linus Torvalds]

On Thu, 14 Dec 2006, Jan Engelhardt wrote:
> 
> Rather than IRQ_HANDLED, it should have been: remove this irq handler 
> from the irq handlers for irq number N, so that it does not get called 
> again until userspace has acked it.

Wrongo.

That just means that the _handler_ won't be called.

But the irq still stays active, and if it's shared, ALL THE OTHER HANDLERS 
FOR THAT INTERRUPT will be called. 

Over and over again. Forever. Because the machine won't be making any 
progress, and the user-level code (which might know how to shut it up) 
won't ever be called, because the machine is busy just doing interrupt 
delivery all the time.

> See, maybe I don't have enough clue yet to exactly figure out why you 
> say it does not work. However, this is how simple people see it 8)

You may be a bit simple. But I think it's more polite to call you 
"special". Or maybe just not very used to how hardware works.

Btw, this is not something theoretical. We used to have this particular 
problem _all_ the time with PCMCIA back when we weren't as good at 
interrupt routing. You'd insert a PCMCIA card, and the machine just hung. 
Hard.

And the reason was that it would send an irq, but we were expecting it on 
another interrupt. But if it showed up on something that was shared, you'd 
have a hung machine, because you'd just have the (say) ethernet driver 
saying "not for me", and returning. And obviously not able to actually 
shut it up, so when we returned from the interrupt handler, the interrupt 
happened immediately again.

So this really isn't theoretical. It's a very common failure schenario for 
mishandled interrupts. In fact, exactly because it's so common, these days 
we have all this special logic in the generic interrupt layer that 
notices, and shuts them up entirely (but does so by disabling _all_ the 
devices on that interrupt, so when this happens, you might well lose your 
disk driver or somethign else).

			Linus

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Jan Engelhardt]

On Dec 14 2006 09:32, Linus Torvalds wrote:
>On Thu, 14 Dec 2006, Jan Engelhardt wrote:
>> 
>> Rather than IRQ_HANDLED, it should have been: remove this irq
>> handler from the irq handlers for irq number N, so that it does
>> not get called again until userspace has acked it.
>
>That just means that the _handler_ won't be called. But the irq
>still stays active, and if it's shared, ALL THE OTHER HANDLERS FOR
>THAT INTERRUPT will be called.
>[...]
>And the reason was that it would send an irq, but we were expecting
>it on another interrupt. But if it showed up on something that was
>shared, you'd have a hung machine, because you'd just have the (say)
>ethernet driver saying "not for me", and returning. And obviously
>not able to actually shut it up, so when we returned from the
>interrupt handler, the interrupt happened immediately again.

Thanks for this explanation, I see the point. Removing the uio irq
handler will leave the irq chain only with "not for me" devices. In
that case, would it make sense to install a replacement uio handler
that says "yes, that's mine" [but ignoring it since userspace has not
yet finished with it]? (I think I've gotten into a loop since that
would be the IRQ_HANDLED case.) Mh, delicate problem.


	-`J'
-- 

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Linus Torvalds]

On Thu, 14 Dec 2006, Jan Engelhardt wrote:
> 
> I don't get you. The rtc module does something similar (RTC generates
> interrupts and notifies userspace about it)

The RTC module knows how to shut the interrupt up.

(And in many cases, timers are special. Timers, by design, are often "edge 
triggered" even in systems that have no other interrupts that work that 
way. Exactly because a timer is special. So the RTC module often knows 
that it doesn't need to do anything at all to shut it up, but even that 
is special per-device knowledge, that is NOT TRUE for any normal devices).


		Linus

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Thomas Gleixner]

On Thu, 2006-12-14 at 09:26 -0800, Linus Torvalds wrote:
> 
> On Thu, 14 Dec 2006, Jan Engelhardt wrote:
> > 
> > I don't get you. The rtc module does something similar (RTC generates
> > interrupts and notifies userspace about it)
> 
> The RTC module knows how to shut the interrupt up.

The kernel part of the UIO driver also knows how to shut the interrupt
up, so where is the difference ?

	tglx

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Linus Torvalds]

On Thu, 14 Dec 2006, Thomas Gleixner wrote:
> 
> The kernel part of the UIO driver also knows how to shut the interrupt
> up, so where is the difference ?

Thomas, you've been discussing some totally different and private 
Thomas-only thread than everybody else in this thread has been.

The point is NO, THE UIO DRIVER DID NOT KNOW THAT AT ALL. Go and read the 
post that STARTED this whole thread. Go and read the "example driver". 

The example driver was complete crap and drivel. 

		Linus

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Thomas Gleixner]

Linus,

On Thu, 2006-12-14 at 14:59 -0800, Linus Torvalds wrote:
> > The kernel part of the UIO driver also knows how to shut the interrupt
> > up, so where is the difference ?
> 
> Thomas, you've been discussing some totally different and private 
> Thomas-only thread than everybody else in this thread has been.

Yeah, I even looked at different code than others, until they noticed
that email before coffee is bad. :)

> The point is NO, THE UIO DRIVER DID NOT KNOW THAT AT ALL. Go and read the 
> post that STARTED this whole thread. Go and read the "example driver". 
> 
> The example driver was complete crap and drivel. 

Sigh, I accept and also Greg has done this before, that the example
driver based on the LPT port was not a fortunate choice. It was done to
provide some example which is reproducible on COTS hardware. 

Real world drivers like the sercos example I provided - and I do it
again - are aware of that problem:

/*
 * The chip specific portion of the interrupt handler. The framework code
 * takes care of userspace notification when we return IRQ_HANDLED
 */
static irqreturn_t sercos_handler(int irq, void *dev_id, struct pt_regs *reg)
{
        /* Check, if this interrupt is originated from the SERCOS chip */
        if (!(sercos_read(IRQ_STATUS) & SERCOS_INTERRUPT_MASK))
                return IRQ_NONE;

---------^ Makes it safe for IRQ sharing

        /* Acknowledge the chip interrupts */
        sercos_write(IRQ_ACK1, SERCOS_INTERRUPT_ACK1);
        sercos_write(IRQ_ACK2, SERCOS_INTERRUPT_ACK2);

----------^
	Actually prevents the box is dead scenario, as it disables the
interrupt from that device until it is reenabled from the user space
driver code. This covers also the case where the user space driver dies,
as the kernel still has the portion of code to shut this thing up for
ever.
        return IRQ_HANDLED;
}

The concept requires, that 
- the interrupt handling is in the kernel _AND_ open source
- the mapping of the device is done via the kernel controlled mapping
function rather than by poking in the PCI regs

I really regret that I ever came up with this LPT example, but cutting
the whole discussion down to that ugly example driver does not get us
anywhere.

	tglx

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Linus Torvalds]

On Thu, 14 Dec 2006, Benjamin Herrenschmidt wrote:
>
> Actually, you can... but wether you want is a different story :-)
> 
> You can simply mask it, have it handled by userspace and re-enable it
> when that's done.

Nope. Again, this whole mentality is WRONG.

It DOES NOT WORK. No architecture does per-device interrupts portably, 
which means that you'll always see sharing. 

And once you see sharing, you have small "details" like the harddisk 
interrupt or network interrupt that the user-land driver will depend on.

Oops. Instant deadlock.

> I don't mean I -like- the approach... I just say it can be made to
> sort-of work. But I don't see the point.

No. The point really is that it fundamentally _cannot_ work. Not in the 
real world.

It can only work in some alternate reality where you can always disable 
interrupts per-device, and even in that alternate reality it would be 
wrong to use that quoted interrupt handler: not only do you need to 
disable the irq, you need to have an "acknowledge" phase too

So you'd actually have to fix things _architecturally_, not just add some 
code to the irq handler.

		Linus

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Benjamin Herrenschmidt]

> No. The point really is that it fundamentally _cannot_ work. Not in the 
> real world.
> 
> It can only work in some alternate reality where you can always disable 
> interrupts per-device, and even in that alternate reality it would be 
> wrong to use that quoted interrupt handler: not only do you need to 
> disable the irq, you need to have an "acknowledge" phase too
> 
> So you'd actually have to fix things _architecturally_, not just add some 
> code to the irq handler.

Oh, it works well enough for non shared iqs if you are really anal about
it, but I agree that it sucks and I don't see the point of having it in
linux. The flow has to be different for level vs. edge and it's really
ugly but it works. I've seen people doing it in embedded space. But
again, I do agree it sucks big time :-)

the edge flow is easy. the level one is:

 - IRQ happens
 - kernel handler masks it and queue a msg for userland
 - later on, userland gets the message, talks to the device,
   (MMAP'ed mmio, acks the interrupt on the device itself) and
   does an ioctl/syscall/write/whatever to tell kernel it's done
 - kernel unmasks it.

But yeah, I hate it too, so let's not waste time talking about how to
make it work :-)

Ben.

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Thomas Gleixner]

On Thu, 2006-12-14 at 09:14 +1100, Benjamin Herrenschmidt wrote:
> the edge flow is easy. the level one is:
> 
>  - IRQ happens
>  - kernel handler masks it and queue a msg for userland
>  - later on, userland gets the message, talks to the device,
>    (MMAP'ed mmio, acks the interrupt on the device itself) and
>    does an ioctl/syscall/write/whatever to tell kernel it's done
>  - kernel unmasks it.

That's simply not true.

- IRQ happens
- kernel handler runs and masks the chip irq, which removes the IRQ
request
- user space message get queued or waiting reader woken
- kernel handler returns IRQ_HANDLED, which reenables the irq in the PIC
- user space handles the device
- user space reenables the device irq

No need for an ioctl. Neither for edge nor for level irqs.

	tglx

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Benjamin Herrenschmidt]

On Wed, 2006-12-13 at 23:30 +0100, Thomas Gleixner wrote:
> On Thu, 2006-12-14 at 09:14 +1100, Benjamin Herrenschmidt wrote:
> > the edge flow is easy. the level one is:
> > 
> >  - IRQ happens
> >  - kernel handler masks it and queue a msg for userland
> >  - later on, userland gets the message, talks to the device,
> >    (MMAP'ed mmio, acks the interrupt on the device itself) and
> >    does an ioctl/syscall/write/whatever to tell kernel it's done
> >  - kernel unmasks it.
> 
> That's simply not true.
> 
> - IRQ happens
> - kernel handler runs and masks the chip irq, which removes the IRQ
> request
> - user space message get queued or waiting reader woken
> - kernel handler returns IRQ_HANDLED, which reenables the irq in the PIC
> - user space handles the device
> - user space reenables the device irq
> 
> No need for an ioctl. Neither for edge nor for level irqs.

Wait wait wait... your scenario implies that the kernel has knowledge of
the chip to mask the irq in the chip in the first place.

If that is the case, then you have a chip specific kernel driver,
yadada, the whole story is moot :-)

We were talking about the idea of having some "generic" reflector of
irqs to userspace without device specific knowledge.

Ben.

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Thomas Gleixner]

On Thu, 2006-12-14 at 09:39 +1100, Benjamin Herrenschmidt wrote:
> > No need for an ioctl. Neither for edge nor for level irqs.
> 
> Wait wait wait... your scenario implies that the kernel has knowledge of
> the chip to mask the irq in the chip in the first place.
> 
> If that is the case, then you have a chip specific kernel driver,
> yadada, the whole story is moot :-)
> 
> We were talking about the idea of having some "generic" reflector of
> irqs to userspace without device specific knowledge.

Which simply is not possible, especially for shared irqs.

Can you please elaborate why this effort is moot, instead of throwing
the usual flamewar arguments around ?

The concept of UIO divides the problem in two spaces:

- kernel interface, which controls interrupts and mapping
- user space restricted interface

I don't see why the necessarity of a kernel stub driver is a killer
argument. The chip internals, which companies might want to protect are
certainly not in the interrupt registers.

Aside of that there are huge performance gains for certain application /
driver scenarios and I really don't see an advantage that people are
doing excactly the same thing in out of tree hackeries with a lot of
inconsistent user land interfaces.

	tglx

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Michael K. Edwards]

On 12/13/06, Thomas Gleixner <tglx@linutronix.de> wrote:
> Aside of that there are huge performance gains for certain application /
> driver scenarios and I really don't see an advantage that people are
> doing excactly the same thing in out of tree hackeries with a lot of
> inconsistent user land interfaces.

Greg's effort is noble but I think it is targeted at the wrong problem
and would actually make things worse.  Inconsistent interfaces from
one "driver" to another are the surface design flaw that obscures the
fundamental design flaw of exposing hardware to userland: abdication
of the driver writer's responsibility to choose and justify which
things belong in the driver and which belong in a hardware-agnostic
driver framework or a userspace library instead.

When you are talking about unique, one-off hardware, it doesn't really
matter whether the shim for a closed, out-of-tree, userspace driver
fits into a framework or not.  Who cares whether they use the
preferred MMIO reservation paths or just throw ioctl(POKE_ME_HARDER)
or mmap(/dev/mem) at the problem?  But I don't want to see ALSA or
iwconfig or i2c-core or any of the other competently designed and
implemented driver frameworks mangled into unusability by attempts to
facilitate this "design pattern".

Truth in advertising is an advantage even if it doesn't change the
underlying reality.  I can (and do) tell chip vendors, "that's not a
driver, that's a shim for some other customer's pre-existing eCos
task", and justify the cost of writing an actual driver to the client.
 I may or may not succeed in arguing that the new driver should be
designed to an existing API when that means rethinking the userspace
app, or that it should be implemented against a current kernel and
offered promptly up to the appropriate Linus lieutenant.  But at least
the project isn't crippled by confusion about whether or not the
existing blob constitutes a driver.

Cheers,
- Michael

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Alan]

> I don't see why the necessarity of a kernel stub driver is a killer
> argument. The chip internals, which companies might want to protect are
> certainly not in the interrupt registers.

So they can go off and write themselves a driver. Without putting junk in
the kernel "just in case", and if the driver and the user space code
using it are closely interdependant I'd suggest they look up the *legal*
definition of derivative work.

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Alan]

On Wed, 13 Dec 2006 23:30:55 +0100
Thomas Gleixner <tglx@linutronix.de> wrote:

> - IRQ happens
> - kernel handler runs and masks the chip irq, which removes the IRQ
> request

IRQ is shared with the disk driver, box dead. Plus if this is like the
uio crap in -mm its full of security holes.

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Greg KH]

On Wed, Dec 13, 2006 at 11:56:01PM +0000, Alan wrote:
> On Wed, 13 Dec 2006 23:30:55 +0100
> Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> > - IRQ happens
> > - kernel handler runs and masks the chip irq, which removes the IRQ
> > request
> 
> IRQ is shared with the disk driver, box dead. Plus if this is like the
> uio crap in -mm its full of security holes.

All of those security holes should now be taken care of, as all of the
nasty memory stuff has been either cleaned up or ripped out.

Please take a look at the most recent stuff (thomas just mentioned to me
on irc that he has a few more minor fixes for it) and let me know if you
still see any problems.

thanks,

greg k-h

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Thomas Gleixner]

On Wed, 2006-12-13 at 23:56 +0000, Alan wrote:
> On Wed, 13 Dec 2006 23:30:55 +0100
> Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> > - IRQ happens
> > - kernel handler runs and masks the chip irq, which removes the IRQ
> > request
> 
> IRQ is shared with the disk driver, box dead.

Err ? 

IRQ happens

IRQ is disabled by the generic handling code

Handler is invoked and checks, whether the irq is from the device or
not. 
 - If not, it returns IRQ_NONE, so the next driver (e.g. disk) is
invoked.
 - If yes, it masks the chip on the device, which disables the chip
interrupt line and returns IRQ_HANDLED.

In both cases the IRQ gets reenabled from the generic irq handling code
on return, so why is the box dead ?

	tglx

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Alan]

> > IRQ is shared with the disk driver, box dead.
> 
> Err ? 
> 
> IRQ happens
> 
> IRQ is disabled by the generic handling code
> 
> Handler is invoked and checks, whether the irq is from the device or
> not. 
>  - If not, it returns IRQ_NONE, so the next driver (e.g. disk) is
> invoked.
>  - If yes, it masks the chip on the device, which disables the chip
> interrupt line and returns IRQ_HANDLED.
> 
> In both cases the IRQ gets reenabled from the generic irq handling code
> on return, so why is the box dead ?

I wrote this before your "generic" layer was in fact explained further to
not be generic at all and involve a new driver for each device. Your
original explanation was not clear.

Alan

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Thomas Gleixner]

On Thu, 2006-12-14 at 09:14 +1100, Benjamin Herrenschmidt wrote:
> Oh, it works well enough for non shared iqs if you are really anal about

It works well for shared irqs. Thats the whole reason why you need an in
kernel part.

	tglx

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Benjamin Herrenschmidt]

On Wed, 2006-12-13 at 23:40 +0100, Thomas Gleixner wrote:
> On Thu, 2006-12-14 at 09:14 +1100, Benjamin Herrenschmidt wrote:
> > Oh, it works well enough for non shared iqs if you are really anal about
> 
> It works well for shared irqs. Thats the whole reason why you need an in
> kernel part.

As soon as you have an in-kernel part that is chip specific, yes, of
course it works, because essentially, what you have done is a kernel
driver for your chip and the whole discussion is moot :-) And I agree,
that's the right thing to do btw.

Ben.

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Thomas Gleixner]

On Thu, 2006-12-14 at 09:45 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2006-12-13 at 23:40 +0100, Thomas Gleixner wrote:
> > On Thu, 2006-12-14 at 09:14 +1100, Benjamin Herrenschmidt wrote:
> > > Oh, it works well enough for non shared iqs if you are really anal about
> > 
> > It works well for shared irqs. Thats the whole reason why you need an in
> > kernel part.
> 
> As soon as you have an in-kernel part that is chip specific, yes, of
> course it works, because essentially, what you have done is a kernel
> driver for your chip and the whole discussion is moot :-) And I agree,
> that's the right thing to do btw.

Still the framework has a benefit, as it removes the bunch of
incompatible out of tree attempts to achieve the same result.

	tglx

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Ricardo Galli]

> I think it would be a hell of a lot better idea if people just realized
> that they have "fair use" rights whether the authors give them or not, and
                 ^^^^^^^^^
> that the authors copyrights NEVER extend to anything but a "derived work"
...
> I find the RIAA's position and the DMCA distasteful, and in that I
> probably have a lot of things in common with a lot of people on this list.
> But by _exactly_ the same token, I also find the FSF's position and a lot
> of GPL zealots' position on this matter very distasteful.
...
> Because "fair use" is NOT somethng that should be specified in the
          ^^^^^^^^^
> license.

As you probably know, the GPL, the FSF, RMS or even GPL "zealots" never tried 
to change or restrict "fair use". GPL[23] covers only to "distibution" of the 
covered program. The freedom #0 says explicitly: "right to use the program 
for any purpose".

So, I don't see any clash here between GPL/FSF/RMS with "fair use"

And you probably know that any GPLed code can be linked and executed with any 
other program, whatever is its license if it's for personal use (is that 
worse than "fair use"?). 

And even if there is a function in linux that disables loading of non GPL 
modules, it's still allowed under the GPL to distribute a kernel with those 
functions removed. Any user can load any other module in this kernel without 
worrying about "fair use" or "derived work", GPL allows her to do it.

So, where's the freaking relationship between GPL (or its "zealots") and "fair 
use"? Who is trying to re-define it?

FUD, FUD, FUD.

-- 
  ricardo galli       GPG id C8114D34
  http://mnm.uib.es/gallir/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Linus Torvalds]

On Sat, 16 Dec 2006, Ricardo Galli wrote:

> As you probably know, the GPL, the FSF, RMS or even GPL "zealots" never tried 
> to change or restrict "fair use". GPL[23] covers only to "distibution" of the 
> covered program. The freedom #0 says explicitly: "right to use the program 
> for any purpose".

I'm sorry, but you're just rewriting history.

The FSF very much _has_ tried to make "fair use" a very restricted issue. 
The whole reason the LGPL exists is that people realized that if they 
don't do something like that, the GPL would have been tried in court, and 
the FSF's position that anything that touches GPL'd code would probably 
have been shown to be bogus.

In reality, if the FSF actually believed in "fair use", they would just 
have admitted that GNU libc could have continued to be under the GPL, and 
that any programs that link against it are obviously not "derived" from 
it.

But no. The FSF has very much tried to confuse and muddle the issue, and 
instead have claimed that projects like glibc should be done under the 
"Lesser" GPL.

That's just idiocy, but it works as a way to defuse the problem that the 
FSF has always had with admitting that not only _they_ have "fair use" 
rights, but others have them too.

Do you REALLY believe that a binary becomes a "derived work" of any random 
library that it gets linked against? If that's not "fair use" of a library 
that implements a standard library definition, I don't know what is.

And yes, the FSF really has tried to push that totally insane argument. 

So don't tell me that the FSF honors "fair use". They say they do, but 
they only seem to honor it when it helps _their_ argument, not when it 
helps "those evil people who try to take advantage of our hard work".

The fact is, if you accept fair use, you have to accept it for other 
people to take advantage of too. Fair use really isn't just a one-way 
street.

		Linus

Re: GPL only modules

[Alexandre Oliva]

On Dec 16, 2006, Linus Torvalds <torvalds@osdl.org> wrote:

> The whole reason the LGPL exists is that people realized that if they 
> don't do something like that, the GPL would have been tried in court, and 
> the FSF's position that anything that touches GPL'd code would probably 
> have been shown to be bogus.

Or that people would feel uncomfortable about the gray area and avoid
using the GPLed code in cases in which this would be perfectly legal
and advantageous to Free Software.  Sure enough, when people create
and distribute proprietary code by taking advantage of Free Software,
that's something to be avoided, but since there are other Free
Software licenses that are not compatible with the GNU GPL, it made
sense to enable software licensed under them to be combined with these
few libraries.  Letting concerns about copyright infringement, be such
acts permissible by law or not, scare Free Software developers away
from Free Software was not good for Free Software.

> Do you REALLY believe that a binary becomes a "derived work" of any random 
> library that it gets linked against? If that's not "fair use" of a library 
> that implements a standard library definition, I don't know what is.

There are many factors involved and you're oversimplifying the issue.

Some claim that, in the case of static linking, since there part of
the library copied to the binary, it is definitely a case of derived
work.

Some then take this notion that linking creates derived works and
further extend the claim that using dynamic linking is just a trick to
avoid making the binary a derived work, and thus it shouldn't be taken
into account, even if there still is *some* information from the
dynamic library that affects the linked binary.

Others then introduce exceptions such as the existence of another
implementation of the library that is binary- and license-compatible,
and that thus might make the license of the library actually used to
create the binary irrelevant.

Some disregard the fact that header files sometimes aren't just
interface definitions, but they also contain functional code, in the
form of preprocessor macros and inline functions, that, if used, do
make it to the binary.

All of these arguments have their strengths and weaknesses.  As you
and others point out, and it matches my personal knowledge, none of
them has been tried in court, and the outcome of a court dispute will
often depend on specifics anyway.

So calling these arguments idiocy is as presumptuous as FSF's alleged
behavior.  While at that, I feel you allegation is groundless, and I
hope this message makes it clear why, so I wish you'd take it back.


The gray area between what is clearly permitted by a license and the
murky lines that determine what constitutes a derived work, and what
is fair use even if it's a derived work, is not for any of us to
decide.  The best we can do is to offer interpretations on intent of
license authors and software authors, and of laws.  Even though we're
not lawyers or judges, such interpretations may be taken into account
in court disputes.

When the FSF says a license does not permit such and such behavior,
you apparently interpret that as a statement that the FSF thinks this
behavior wouldn't be permissible by fair use either.  This is an
incorrect interpretation.  As we've seen above, there *is* a gray area
beyond what is permitted by the license.  But the FSF must not give
anyone the impression that the *license* permits actions that would
make it less effective in fulfilling its intent, this would just
weaken the license.

Similarly, when you make an unqualified statement that some action is
permitted, because you mean it's permitted by fair use even if not by
the license, this might be mis-interpreted as something explicitly
permitted by the license.  So this weakens the license, one of our
most valuable tools to make the world a better place.  Is this what
you intend to do?  I hope not.

Thanks,

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: GPL only modules

[Ricardo Galli]

On Sunday 17 December 2006 14:54, Alexandre Oliva wrote:
> > The whole reason the LGPL exists is that people realized that if they
> > don't do something like that, the GPL would have been tried in court, and
> > the FSF's position that anything that touches GPL'd code would probably
> > have been shown to be bogus.
>
> Or that people would feel uncomfortable about the gray area and avoid
> using the GPLed code in cases in which this would be perfectly legal
> and advantageous to Free Software.  Sure enough, when people create
> and distribute proprietary code by taking advantage of Free Software,
> that's something to be avoided, but since there are other Free
> Software licenses that are not compatible with the GNU GPL, it made
> sense to enable software licensed under them to be combined with these
> few libraries.  Letting concerns about copyright infringement, be such
> acts permissible by law or not, scare Free Software developers away
> from Free Software was not good for Free Software.

LGPL somehow fixes this gray area to allow a wider and clear "fair use" by 
allowing people to easily[*] run proprietary programs in a free operating 
system.

[*] In the sense they don't need to compile/link the program themselves, which 
is clearly legal under the GPL and the FSF intentions (freedom #0).

So, people that just worries about "fair use" could interpret it --besides 
the "official" arguments- as a message that makes clear FSF is not trying to 
push his agenda into the gray areas of copyright laws.

But the very same evidence is used to loudly support an opposite 
interpretation of FSF [evil] intentions, to weaken the legal strength of the 
GPL, and to accuse FSF of pushing some hidden and insane arguments.

Presumptuous, to say the least.

-- 
  ricardo galli       GPG id C8114D34
  http://mnm.uib.es/gallir/

Re: GPL only modules

[Kyle Moffett]

On Dec 17, 2006, at 08:54:17, Alexandre Oliva wrote:
> On Dec 16, 2006, Linus Torvalds <torvalds@osdl.org> wrote:
>> Do you REALLY believe that a binary becomes a "derived work" of  
>> any random library that it gets linked against? If that's not  
>> "fair use" of a library that implements a standard library  
>> definition, I don't know what is.
>
> Some disregard the fact that header files sometimes aren't just  
> interface definitions, but they also contain functional code, in  
> the form of preprocessor macros and inline functions, that, if  
> used, do make it to the binary.

I would argue that this is _particularly_ pertinent with regards to  
Linux.  For example, if you look at many of our atomics or locking  
operations a good number of them (depending on architecture and  
version) are inline assembly that are directly output into the code  
which uses them.  As a result any binary module which uses those  
functions from the Linux headers is fairly directly a derivative work  
of the GPL headers because it contains machine code translated  
literally from GPLed assembly code found therein.  There are also a  
fair number of large perhaps-wrongly inline functions of which the  
use of any one would be likely to make the resulting binary  
"derivative".

On the other hand, certain projects like OpenAFS, while not license- 
compatible, are certainly not derivative works.  The project was  
created independently of Linux and operates on several different  
operating systems, so even though it uses the very-Linux-specific  
keyring interfaces under 2.6, no GPL licensing could possibly apply.

> The gray area between what is clearly permitted by a license and  
> the murky lines that determine what constitutes a derived work, and  
> what is fair use even if it's a derived work, is not for any of us  
> to decide. The best we can do is to offer interpretations on intent  
> of license authors and software authors, and of laws.  Even though  
> we're not lawyers or judges, such interpretations may be taken into  
> account in court disputes.

I agree, and I think that this thread has outlived its useful life.

Cheers,
Kyle Moffett

RE: GPL only modules

[David Schwartz]

> I would argue that this is _particularly_ pertinent with regards to
> Linux.  For example, if you look at many of our atomics or locking
> operations a good number of them (depending on architecture and
> version) are inline assembly that are directly output into the code
> which uses them.  As a result any binary module which uses those
> functions from the Linux headers is fairly directly a derivative work
> of the GPL headers because it contains machine code translated
> literally from GPLed assembly code found therein.  There are also a
> fair number of large perhaps-wrongly inline functions of which the
> use of any one would be likely to make the resulting binary
> "derivative".

That's not protectable expression under United States law. See Lexmark v.
Static Controls and the analogous case of the TLP (ignore the DMCA stuff in
that case, that's not relevant). If you want to make that kind of content
protectable, you have to get it out of the header files.

You cannot protect, by copyright, every reasonably practical way of
performing a function. Only a patent can do that. If taking something is
reasonably necessary to express a particular idea (and a Linux module for
the ATI X850 card is an idea), then that something cannot be protected by
copyright when it is used to express that idea. (Even if it would clearly be
protectably expression in another context.)

The premise of copyright is that there are millions of equally-good ways to
express the same idea or perform the same function, and you creatively pick
one, and that choice is protected. But if I'm developing a Linux module for
a particular network card, choosing to use the Linux kernel header files is
the only practical choice to perform that particular function. So their
content is not protectable when used in that context. (If you make another
way to do it, then the content becomes protectable in that context again.)

IANAL.

DS

Re: GPL only modules

[D. Hazelton]

On Sunday 17 December 2006 16:32, David Schwartz wrote:
> > I would argue that this is _particularly_ pertinent with regards to
> > Linux.  For example, if you look at many of our atomics or locking
> > operations a good number of them (depending on architecture and
> > version) are inline assembly that are directly output into the code
> > which uses them.  As a result any binary module which uses those
> > functions from the Linux headers is fairly directly a derivative work
> > of the GPL headers because it contains machine code translated
> > literally from GPLed assembly code found therein.  There are also a
> > fair number of large perhaps-wrongly inline functions of which the
> > use of any one would be likely to make the resulting binary
> > "derivative".
>
> That's not protectable expression under United States law. See Lexmark v.
> Static Controls and the analogous case of the TLP (ignore the DMCA stuff in
> that case, that's not relevant). If you want to make that kind of content
> protectable, you have to get it out of the header files.
>
> You cannot protect, by copyright, every reasonably practical way of
> performing a function. Only a patent can do that. If taking something is
> reasonably necessary to express a particular idea (and a Linux module for
> the ATI X850 card is an idea), then that something cannot be protected by
> copyright when it is used to express that idea. (Even if it would clearly
> be protectably expression in another context.)
>
> The premise of copyright is that there are millions of equally-good ways to
> express the same idea or perform the same function, and you creatively pick
> one, and that choice is protected. But if I'm developing a Linux module for
> a particular network card, choosing to use the Linux kernel header files is
> the only practical choice to perform that particular function. So their
> content is not protectable when used in that context. (If you make another
> way to do it, then the content becomes protectable in that context again.)
>
> IANAL.
>
> DS

Agreed. You missed the point. Since the Linux Kernel header files contain a 
chunk of the source code for the kernel in the form of the macros for locking 
et. al. then using the headers - including that code in your module - makes 
it a derivative work.

Actually, thinking about it, the way a Linux driver module works actually 
seems to make *ANY* driver a derivative work, because they are loaded into 
the kernels memory space and cannot function without having that done.

*IF* the "Usermode Driver" interface that is being worked on ever proves 
useful then, and only then, could you consider it *NOT* a derivative work. 
Because then the only thing it is using *IS* an interface, not complete 
chunks of the source as generated when the pre-processor finishes running 
through the file.

But as David said - IANAL

D. Hazelton

Re: GPL only modules

[Dave Neuer]

On 12/17/06, D. Hazelton <dhazelton@enter.net> wrote:
> On Sunday 17 December 2006 16:32, David Schwartz wrote:
> > > I would argue that this is _particularly_ pertinent with regards to
> > > Linux.  For example, if you look at many of our atomics or locking
> > > operations a good number of them (depending on architecture and
> > > version) are inline assembly that are directly output into the code
> > > which uses them.  As a result any binary module which uses those
> > > functions from the Linux headers is fairly directly a derivative work
> > > of the GPL headers because it contains machine code translated
> > > literally from GPLed assembly code found therein.  There are also a
> > > fair number of large perhaps-wrongly inline functions of which the
> > > use of any one would be likely to make the resulting binary
> > > "derivative".
> >
> > That's not protectable expression under United States law. See Lexmark v.
> > Static Controls and the analogous case of the TLP (ignore the DMCA stuff in
> > that case, that's not relevant). If you want to make that kind of content
> > protectable, you have to get it out of the header files.
> >
> > You cannot protect, by copyright, every reasonably practical way of
> > performing a function. Only a patent can do that. If taking something is
> > reasonably necessary to express a particular idea (and a Linux module for
> > the ATI X850 card is an idea), then that something cannot be protected by
> > copyright when it is used to express that idea. (Even if it would clearly
> > be protectably expression in another context.)
> >
> > The premise of copyright is that there are millions of equally-good ways to
> > express the same idea or perform the same function, and you creatively pick
> > one, and that choice is protected. But if I'm developing a Linux module for
> > a particular network card, choosing to use the Linux kernel header files is
> > the only practical choice to perform that particular function. So their
> > content is not protectable when used in that context. (If you make another
> > way to do it, then the content becomes protectable in that context again.)
> >
> > IANAL.
> >
> > DS
>
> Agreed. You missed the point. Since the Linux Kernel header files contain a
> chunk of the source code for the kernel in the form of the macros for locking
> et. al. then using the headers - including that code in your module - makes
> it a derivative work.

David didn't miss the point; Lexmark vs. Static Controls, however
unintuitively, ruled that even _verbatim_ copying is not always
copyright infringement in the case of software because of issues like
the doctrine of scenes a faire. In the case of spinlocks, if the only
way to accomplish atomic operations on an architecture is to use
something like the assembler that the inclusion of spinlock.h injects
into your binary, then according to Lexmark vs. Static Controls that
makes that included code unprotectable by copyright.

Where I disagree with David (as I have publicly before on this list),
is that he incorrectly applies the concept of "functional idea" to
"write a linux kernel module." I don't believe that is a "functional
idea" in the sense that is meaningful in the context of software
copyright or patents (at least until someone writes a piece of
software that writes kernel modules).

Dave

Re: GPL only modules

[D. Hazelton]

On Monday 18 December 2006 10:47, Dave Neuer wrote:
> On 12/17/06, D. Hazelton <dhazelton@enter.net> wrote:
> > On Sunday 17 December 2006 16:32, David Schwartz wrote:
> > > > I would argue that this is _particularly_ pertinent with regards to
> > > > Linux.  For example, if you look at many of our atomics or locking
> > > > operations a good number of them (depending on architecture and
> > > > version) are inline assembly that are directly output into the code
> > > > which uses them.  As a result any binary module which uses those
> > > > functions from the Linux headers is fairly directly a derivative work
> > > > of the GPL headers because it contains machine code translated
> > > > literally from GPLed assembly code found therein.  There are also a
> > > > fair number of large perhaps-wrongly inline functions of which the
> > > > use of any one would be likely to make the resulting binary
> > > > "derivative".
> > >
> > > That's not protectable expression under United States law. See Lexmark
> > > v. Static Controls and the analogous case of the TLP (ignore the DMCA
> > > stuff in that case, that's not relevant). If you want to make that kind
> > > of content protectable, you have to get it out of the header files.
> > >
> > > You cannot protect, by copyright, every reasonably practical way of
> > > performing a function. Only a patent can do that. If taking something
> > > is reasonably necessary to express a particular idea (and a Linux
> > > module for the ATI X850 card is an idea), then that something cannot be
> > > protected by copyright when it is used to express that idea. (Even if
> > > it would clearly be protectably expression in another context.)
> > >
> > > The premise of copyright is that there are millions of equally-good
> > > ways to express the same idea or perform the same function, and you
> > > creatively pick one, and that choice is protected. But if I'm
> > > developing a Linux module for a particular network card, choosing to
> > > use the Linux kernel header files is the only practical choice to
> > > perform that particular function. So their content is not protectable
> > > when used in that context. (If you make another way to do it, then the
> > > content becomes protectable in that context again.)
> > >
> > > IANAL.
> > >
> > > DS
> >
> > Agreed. You missed the point. Since the Linux Kernel header files contain
> > a chunk of the source code for the kernel in the form of the macros for
> > locking et. al. then using the headers - including that code in your
> > module - makes it a derivative work.
>
> David didn't miss the point; Lexmark vs. Static Controls, however
> unintuitively, ruled that even _verbatim_ copying is not always
> copyright infringement in the case of software because of issues like
> the doctrine of scenes a faire. In the case of spinlocks, if the only
> way to accomplish atomic operations on an architecture is to use
> something like the assembler that the inclusion of spinlock.h injects
> into your binary, then according to Lexmark vs. Static Controls that
> makes that included code unprotectable by copyright.

Ah, okay. However I'm quite sure that there are more ways to accomplish the 
tasks handled by the code in the header files (in most cases). 

> Where I disagree with David (as I have publicly before on this list),
> is that he incorrectly applies the concept of "functional idea" to
> "write a linux kernel module." I don't believe that is a "functional
> idea" in the sense that is meaningful in the context of software
> copyright or patents (at least until someone writes a piece of
> software that writes kernel modules).

Agreed. And thanks for clarifying that.

DRH

Re: GPL only modules

[Dave Neuer]

On 12/18/06, D. Hazelton <dhazelton@enter.net> wrote:
>
> Ah, okay. However I'm quite sure that there are more ways to accomplish the
> tasks handled by the code in the header files (in most cases).

Well, that may be so. Unfortunately, Lexmark vs. Static Controls
actually says that even if there are other ways, if those ways are far
less optimal, the result is as if there were only one way. I think the
decision is part of one big, giant mess that is US IP law as it
relates to software.

Dave

RE: GPL only modules

[David Schwartz]

Combined responses to save bandwidth and reduce the number of times people
have to press "d".

> Agreed. You missed the point.

I don't understand how you could lead with "agreed" and then proceed to
completely ignore the entire point I just made.

> Since the Linux Kernel header files
> contain a
> chunk of the source code for the kernel in the form of the macros
> for locking
> et. al. then using the headers - including that code in your
> module - makes
> it a derivative work.

No, it does not. The header files are purely function and not expressive in
this case. Copyright only protects one choice among many equally-practical
choices for expressing the same idea or performing the same function.

> Actually, thinking about it, the way a Linux driver module works actually
> seems to make *ANY* driver a derivative work, because they are
> loaded into
> the kernels memory space and cannot function without having that done.

If every practical way of expressing an idea contains something, then that
something is *not* protectable when used to express an idea of that kind.

> *IF* the "Usermode Driver" interface that is being worked on ever proves
> useful then, and only then, could you consider it *NOT* a
> derivative work.
> Because then the only thing it is using *IS* an interface, not complete
> chunks of the source as generated when the pre-processor finishes running
> through the file.

No, you have it completely backwards.

If a usermode driver interface was equally practical to develop a particular
type of driver, then using the kernel headers would make the driver a
derivative work. Because, in that case, the choice to use the kernel headers
would be a creative choice -- one chosen method among many equally practical
one.

Copyright only protects creative choices, not purely functional ones.

"A Linux 2.6 driver for the ATI X800 graphics chipset" is an idea. If the
only reasonably practical way to express that idea is with the Linux kernel
header files, then using the Linux kernel header files is scenes a fair, not
protected content.

For example, you cannot discuss the Napeleonic wars with using the word
"Napoleon", at least, not nearly as well. So nobody can claim copyright on
the word "Napoleon" when used to describe those wars because it is
deomnstrably *superior*. Only patents protect "best ways". Copyrights
protected "the way I choose among thousands of equally-good ways".

See Lexmark v. Static Controls and the Sega and Atari cases. This is clearly
a cases where "[w]hile, hypothetically, there might be a myriad of ways in
which a programmer may effectuate certain functions within a program . . .
efficiency concerns may so narrow the practical range of choice as to make
only one or two forms of expression workable options." "In order to
characterize a choice between alleged programming alternatives as
expressive, in short, the alternatives must be feasible within real-world
constraints."

The inclusion of the kernel header files in a kernel module is not
expressive, it's purely functional. The kernel header files are simply not
protectable expression when used in a kernel module.

-

>The difference - really - at least for static linking - is that "ln"
>makes modifications to each piece to make them work together, and in
>the case of a library, makes a selection of the parts of the library
>as needed by the rest of the program.  What ends up in the executable
>is not just a set of verbatim copies of the input files packed
>together, but rather a single program where the various parts have
>been modified so as to fit together and create a whole.  Thus it seems
>quite reasonable to me to say that a statically linked binary is a
>derived work of all of the object files and libraries that were linked
>together to form it.  IANAL, of course.

The linker makes no creative choices, so it does not produce a "work" for
copyright purposes. If it does not even produce a work, it cannot produce a
derivative work.

The question is not whether the combination is verbatim or transformative
but whether it is creative or mechanical. The linker combines things in a
mechanical and purely functional way.

A tar/gzip does the same thing. The compressed output for the third file may
be as dependent on the content of the second file as on the content of the
third file and in a very real sense will contain aspects of both of their
structures.

"Mere aggregation" does not mean a literal splicing of the raw code for two
or more files. It means a purely functional combination dictated completely
by technical concerns and lacking any creative input.

DS

Re: GPL only modules

[D. Hazelton]

On Monday 18 December 2006 12:16, David Schwartz wrote:
> Combined responses to save bandwidth and reduce the number of times people
> have to press "d".
>
> > Agreed. You missed the point.
>
> I don't understand how you could lead with "agreed" and then proceed to
> completely ignore the entire point I just made.

I *initially* thought you had missed the point. After your later post 
clarifying things I saw that my statement had been in error and that I did 
agree with you completely.

> > Since the Linux Kernel header files
> > contain a
> > chunk of the source code for the kernel in the form of the macros
> > for locking
> > et. al. then using the headers - including that code in your
> > module - makes
> > it a derivative work.
>
> No, it does not. The header files are purely function and not expressive in
> this case. Copyright only protects one choice among many equally-practical
> choices for expressing the same idea or performing the same function.

In this case, well. We aren't talking Copyright, but the license under which 
the software is distributed. According to the USPTO placing a statement such 
as (c) 2006 Pornrat Watanabe on a work you have created automatially places 
it under a copyright. The kernel source code, copyrighted as it is, is then 
distributed under the terms of the GNU GPL. 

Using the code from the header files may not make the module a derivative, but 
it is including parts of a copyrighted work. By *NOT* complying with the 
license under which said copyrighted work is distributed, you are giving up 
your rights under the license.

This doesn't negate any problems with people making Blob drivers, because, as 
you pointed out, under the same laws they aren't a derivative work, which 
means that that clause of the license doesn't apply. Now if the GPL contained 
a clause specifically defining what it considered a derivative work things 
would be different.

> > Actually, thinking about it, the way a Linux driver module works actually
> > seems to make *ANY* driver a derivative work, because they are
> > loaded into
> > the kernels memory space and cannot function without having that done.
>
> If every practical way of expressing an idea contains something, then that
> something is *not* protectable when used to express an idea of that kind.

Not what I was saying. There are any number of ways to make a driver 
function - the FUSE system has shown that clearly. But by making that driver 
one that is loaded directly into the kernels memory space...

It's that act that *I* *FEEL* makes it a derivative work.

> > *IF* the "Usermode Driver" interface that is being worked on ever proves
> > useful then, and only then, could you consider it *NOT* a
> > derivative work.
> > Because then the only thing it is using *IS* an interface, not complete
> > chunks of the source as generated when the pre-processor finishes running
> > through the file.
>
> No, you have it completely backwards.

No, you missed my point. I was saying that the Usermode Driver interface would 
make the current style of kernel modules fully derivative works. This being 
because they are using an open system interface and *NOT* including code 
distributed with the kernel.

> If a usermode driver interface was equally practical to develop a
> particular type of driver, then using the kernel headers would make the
> driver a derivative work. Because, in that case, the choice to use the
> kernel headers would be a creative choice -- one chosen method among many
> equally practical one.

And this is what I was saying. Perhaps I didn't state it in clear and concise 
english.

> Copyright only protects creative choices, not purely functional ones.
>
> "A Linux 2.6 driver for the ATI X800 graphics chipset" is an idea. If the
> only reasonably practical way to express that idea is with the Linux kernel
> header files, then using the Linux kernel header files is scenes a fair,
> not protected content.

Okay. I understood this back at the start of your reply.

<snip>
> DS

Okay, after a lot of thought and me realizing some mistakes I had made in 
interpreting the law and legal precedents I see we are on the same page.

DRH

Re: GPL only modules

[David Lang]

On Tue, 19 Dec 2006, D. Hazelton wrote:

> This doesn't negate any problems with people making Blob drivers, because, as
> you pointed out, under the same laws they aren't a derivative work, which
> means that that clause of the license doesn't apply. Now if the GPL contained
> a clause specifically defining what it considered a derivative work things
> would be different.

incorrect, the GPL (or any other license) cannot define what is a derived work, 
the law does that. they could have a clause in them that said that something 
that is a derived work under the law is not considered a derived work by the 
author (implicitly giving unrestricted permission to that something), but you 
cannot define something that the law doesn't consider a derived work to be one 
in the license.

David Lang

Re: GPL only modules

[Alexandre Oliva]

On Dec 17, 2006, Kyle Moffett <mrmacman_g4@mac.com> wrote:

> On the other hand, certain projects like OpenAFS, while not license- 
> compatible, are certainly not derivative works.

Certainly a big chunk of OpenAFS might not be, just like a big chunk
of other non-GPL drivers for Linux.

But what about the glue code?  Can that be defended as not a derived
work, such that it doesn't have to be GPL?

If not, can the whole containing both the non-derivative work and the
source code providing the glue without which the whole wouldn't
fulfill its intended purpose be regarded as a mere aggregate, and thus
not be subject to the requirement that the whole be released under the
GPL?

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: GPL only modules

[Christoph Hellwig]

On Mon, Dec 18, 2006 at 05:41:17PM -0200, Alexandre Oliva wrote:
> On Dec 17, 2006, Kyle Moffett <mrmacman_g4@mac.com> wrote:
> 
> > On the other hand, certain projects like OpenAFS, while not license- 
> > compatible, are certainly not derivative works.
> 
> Certainly a big chunk of OpenAFS might not be, just like a big chunk
> of other non-GPL drivers for Linux.
> 
> But what about the glue code?  Can that be defended as not a derived
> work, such that it doesn't have to be GPL?

Actually the OpenAFS kernel code almost 100% is a derived work of both
the original AFS codebase and Linux.  Just go and take a look at it,
there's shitloads of copy & paste and very deep poking into kernel internals.

Re: GPL only modules

[D. Hazelton]

On Monday 18 December 2006 14:41, Alexandre Oliva wrote:
> On Dec 17, 2006, Kyle Moffett <mrmacman_g4@mac.com> wrote:
> > On the other hand, certain projects like OpenAFS, while not license-
> > compatible, are certainly not derivative works.
>
> Certainly a big chunk of OpenAFS might not be, just like a big chunk
> of other non-GPL drivers for Linux.
>
> But what about the glue code?  Can that be defended as not a derived
> work, such that it doesn't have to be GPL?

That has never been an issue, really. Its what 99% of the binary drivers 
believe - hence the reason that there is the user-compiled component to all 
of them.

> If not, can the whole containing both the non-derivative work and the
> source code providing the glue without which the whole wouldn't
> fulfill its intended purpose be regarded as a mere aggregate, and thus
> not be subject to the requirement that the whole be released under the
> GPL?

The view that binary vendors take is "Linking does not create a derived 
work" - regardless of the fact that you cannot have a complete compiled 
program or module *WITHOUT* that linking. However I have a feeling that the 
lawyers in the employ of the companies that ship BLOB drivers say that all 
they need to do to comply with the GPL is to ship the glue-code in source 
form.

And I have to admit that this does seem to comply with the GPL - to the 
letter, if not the spirit.

DRH

Re: GPL only modules

[Alexandre Oliva]

On Dec 19, 2006, "D. Hazelton" <dhazelton@enter.net> wrote:

> However I have a feeling that the lawyers in the employ of the
> companies that ship BLOB drivers say that all they need to do to
> comply with the GPL is to ship the glue-code in source form.

> And I have to admit that this does seem to comply with the GPL - to the 
> letter, if not the spirit.

I don't see that it does comply even with the letter.  Consider this:

  These requirements apply to the modified work as a whole.  If
  identifiable sections of that work are not derived from the Program,
  and can be reasonably considered independent and separate works in
  themselves, then this License, and its terms, do not apply to those
  sections when you distribute them as separate works.  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, whose permissions for other licensees extend
  to the entire whole, and thus to each and every part regardless of
  who wrote it.

The work, in this case, is the GPLed glue code, in source form, and
the binary blob, without sources.  See that, even though the binary
blob is an independent and separate work in itself, and so it can
indeed be distributed separaly under a different license, when it's
distributed as part of a whole, then the whole must be on the terms of
the GPL.

So the question becomes whether the copyright holder of the glue code
bound by these GPL terms.

(a) If the glue code can be shown to be a derived work from Linux,
even in source form, then the copyright holder *is* bound by these
terms, and thus the whole could only be distributed under the GPL, so
including the binary blob would be in violation of the license.

(b) Now, if the glue code is *not* a derived work from Linux, then the
copyright holder is entitled to use whatever terms she likes.  It
could be any license whatsoever, that permits the distribution of the
whole or of the parts with whatever constraints copyright law
permitted.  Why would they choose the GPL in this case, then?


Let's assume they're not intentionally violating the GPL, but rather
that they believe they're entitled to do what they're doing, i.e.,
that they believe (a) their glue code is not a derived work from
Linux.

In this case, they *can* distribute the glue source code under the GPL
along with their binary blob.  But can anyone else?

Methinks anyone else would be entitled to pass the same whole along
under the GPL, per section 1, but wouldn't be entitled to distribute
modified versions, because this would require the derived work to be
licensed under the GPL, and nobody else is able to provide the source
code to the binary blob.

And then, who'd be entitled to complain?  Only the copyright holder of
the glue code and the binary blob.

Would you like to be on the wrong end of a copyright infringement
lawsuit by one of these binary blob distributors for distributing a
patched version of their glue code + binary blob?  More to the point,
do you think they would actually bring suit, just to make it clear
that the whole point is for them to keep a monopoly on the rights to
modify and then distribute the combined work, in spite of using the
GPL for (part of) the work?


It gets trickier for binaries, since they are quite possibly derived
works from the kernel, licensed under the GPL.  If they are, they
can't be distributed at all, not even by the copyright holder of the
glue code + binary blob.  If they aren't, then the copyright holder
can distribute them, but nobody else can because that would be a
violation of the GPL, as in the discussion above.  So, the copyright
holder would be keeping a monopoly on the rights to distribute
binaries, and anyone else could be sued by them.


Sure enough, one might think of praising them for distributing the
glue code under the GPL.  Then others could take this glue code and
use it for something else that is useful, right?

Well...  Not quite.  For one, even if enabling others to distribute
glue code + binary blobs were a good thing, using somebody else's glue
code means you're bound by the GPL requirements, so you can't ship the
combination of the glue code with your binary blob.

And then, if you intend to use the glue code to plug in some other
code that is GPL-compatible in the kernel, perhaps you'd be better off
not using the glue code at all, but rather modifying the
GPL-compatible code to fit.

So, even if condoning binary blobs were morally acceptable, we still
wouldn't be gaining anything from this relationship, we'd only be
enabling vendors to sell us their undocumented hardware while denying
us our freedoms.

Why should we do this?

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: GPL only modules

[Scott Preece]

On 12/19/06, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Dec 19, 2006, "D. Hazelton" <dhazelton@enter.net> wrote:
>
> > However I have a feeling that the lawyers in the employ of the
> > companies that ship BLOB drivers say that all they need to do to
> > comply with the GPL is to ship the glue-code in source form.
>
> > And I have to admit that this does seem to comply with the GPL - to the
> > letter, if not the spirit.
>
> I don't see that it does comply even with the letter.  Consider this:
>
>   These requirements apply to the modified work as a whole.  If
>   identifiable sections of that work are not derived from the Program,
>   and can be reasonably considered independent and separate works in
>   themselves, then this License, and its terms, do not apply to those
>   sections when you distribute them as separate works.  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, whose permissions for other licensees extend
>   to the entire whole, and thus to each and every part regardless of
>   who wrote it.
>
> The work, in this case, is the GPLed glue code, in source form, and
> the binary blob, without sources.  See that, even though the binary
> blob is an independent and separate work in itself, and so it can
> indeed be distributed separaly under a different license, when it's
> distributed as part of a whole, then the whole must be on the terms of
> the GPL.
---

The question is what "the whole work" is. If the binary is not a
derived work, and is not prelinked with the work, then it seems likely
to be considered merely an aggregation, not requiring GPL licensing.
Note that there's some difficulty in the language, in that the GPL
uses "work based on the work" to mean something that it defines
specifically, while the Copyright Act defines "derived work" as "work
based on the work". THere is no equivalence there - The GPL's "work
based on the work" includes cases that do not fit the Act's
definition.

So, the GPL's requirement for licensing under the GPL clearly applies
to prelinked binaries, but it is not at all clear that it would apply
to a binary object, not derived from the kernel, shipped on the same
media. That is, the aggregation is NOT a modification of the original
work, it's just an aggregation (work of colective authorship).

---
> ...
> Let's assume they're not intentionally violating the GPL, but rather
> that they believe they're entitled to do what they're doing, i.e.,
> that they believe (a) their glue code is not a derived work from
> Linux.
>
> In this case, they *can* distribute the glue source code under the GPL
> along with their binary blob.  But can anyone else?
>
> Methinks anyone else would be entitled to pass the same whole along
> under the GPL, per section 1, but wouldn't be entitled to distribute
> modified versions, because this would require the derived work to be
> licensed under the GPL, and nobody else is able to provide the source
> code to the binary blob.
---

I'm confused here.  If the glue code is not a derived work, then they
don't need to use the GPL at all. If they DO ue the GPL, then (as you
note) if they didn't include the source code, nobody else could
redistribute it because nobody else would be able to meet the license
terms. I would expect that if they were going to GPL the glue code,
they would also provide the source for it.

---
>...
> Well...  Not quite.  For one, even if enabling others to distribute
> glue code + binary blobs were a good thing, using somebody else's glue
> code means you're bound by the GPL requirements, so you can't ship the
> combination of the glue code with your binary blob.
---

Only if you assume that using the glue code would make your blob a
derived work of the glue code. In many cases the point of the glue
code is to be an adapter between Linux and an existing interface. In
such a case, any binary blob using that interface would not be a
derived work of the glue code.

As before, though, if you linked the binary blob with the glue code
object, then the combined object probably would be a derived work and
have to conform to the GPL.

---
> ...
> So, even if condoning binary blobs were morally acceptable, we still
> wouldn't be gaining anything from this relationship, we'd only be
> enabling vendors to sell us their undocumented hardware while denying
> us our freedoms.
>
> Why should we do this?
---

To enable the use of the hardware in Linux systems? Most people would
prefer well-documented hardware with free drivers, but when that isn't
available, many people might still like to be able to use the
hardware. It's less than ideal, but so is having no way at all to use
the hardware.

scott

Re: GPL only modules

[Linus Torvalds]

On Sun, 17 Dec 2006, Alexandre Oliva wrote:

> On Dec 16, 2006, Linus Torvalds <torvalds@osdl.org> wrote:
> > 
> > The whole reason the LGPL exists is that people realized that if they 
> > don't do something like that, the GPL would have been tried in court, and 
> > the FSF's position that anything that touches GPL'd code would probably 
> > have been shown to be bogus.
> 
> Or that people would feel uncomfortable about the gray area and avoid
> using the GPLed code in cases in which this would be perfectly legal
> and advantageous to Free Software. 

I agree. A lot of it is about "comfort". But you can _easily_ handle that 
comfort level in other ways.

For example, many programs already do have clarifications that certain 
uses do not introduce any GPL dependency what-so-ever. The kernel COPYING 
makes it clear that user space is not a derived work of the kernel, for 
example. You don't actually need to use a different license for this case: 
if all you're looking for is "comfort", then you really can comfort people 
other ways.

For example, glibc could easily have just come out and said the thing that 
is obvious to any sane person: "using this library as just a standard 
library does not make your program a derived work". 

There really wassn't much need for the LGPL, I think. 

> There are many factors involved and you're oversimplifying the issue.

Sure. It's never clear-cut. It's never black and white. 

> Some claim that, in the case of static linking, since there part of
> the library copied to the binary, it is definitely a case of derived
> work.

No, the sane way to think about it is that linking just creates an 
"aggregate" work. It's no less "aggregate" than creating a CD-ROM that 
contains the library and some random program: you "link" them together 
with "mkisofs".

Why do people think that using "ln" is _any_ different from using 
"mkisofs". Both create one file that contains multiple pieces. What's the 
difference - really?

Of course, the _aggregate_ still needs permission from all the copyright 
holders in order to be distributed, that goes without saying. But the 
GPLv2 clearly allows aggregation.

And don't get me wrong: I do not say that "linking" _never_ creates 
derived works. I'm just saying that "linking" is just a technical step, 
and as such is not the answer to whether something is derived or not. 
Things can be derived works of each other _without_ being linked, and they 
may not be derived works even if they _are_ linked.

So "linking" basically has very little to do with "derived" per se.

Linking does have one thing that it implies: it's maybe a bit "closer" 
relationship between the parts than "mkisofs" implies. So there is 
definitely a higher _correlation_ between "derived work" and "linking", 
but it's really a correlation, not a causal relationship.

For example, if you link two object files together where neither is a 
"library" with standard interfaces, then the result is most likely a 
derived work from both. But it wasn't the "act of linking" that caused 
that to happen, but simply the fact that they were part of a bigger whole, 
and were meaningless apart from each other.

Think of this in the sense of a book. Does binding pages together create a 
"derived work"? Not always: you can have anthologies (which are 
*aggregations* of works with *independent* copyright), and the binding of 
pages together didn't really do anything to the independent pieces. But 
clearly, if you're talking about individual pages in one story, then each 
individual page is not an independent work in itself.

Linking is the same way. Are the two pieces you link "independent works" 
on their own? If so, the end result is really just an aggregate, no 
different from using "mkisofs". They are still clearly separable: you 
could have built either piece AGAINST SOMETHING ELSE.

> Some then take this notion that linking creates derived works and
> further extend the claim that using dynamic linking is just a trick to
> avoid making the binary a derived work, and thus it shouldn't be taken
> into account, even if there still is *some* information from the
> dynamic library that affects the linked binary.

See how this whole "trick" discussion becomes a totally moot point once 
you realize that "mkisofs" and "ld" aren't really all that different.

Does "mkisofs" create a derived work, or an aggregate? Does "ld" create a 
derived work or an aggregate? The answer in BOTH cases is the same: it's 
not about the name of the command, or some technical detail about how the 
pieces are bound together. Copyright law doesn't concern itself with 
"mkisofs" vs "ld". It would be totally INSANE if it did, wouldn't you say?

So if it isn't about "mkisofs" vs "ld", then _what_ is it about?

I gave you one answer above. Feel free to make your own judgements. I'm 
just saying that anybody who thinks that copyright law cares about 
"mkisofs" vs "ld" is just obviously misguided.

So I think the "dynamic vs static" linking argument is a red herring. It 
_is_ meaningful in two ways:

 - static linking obviously means that even at a MINIMUM, the result will 
   _contain_ both things, so at a minimum, you do need the permission to 
   distribute the pieces as parts of an aggregate work.

   In contrast,  in dynamic linking, since you're not _actually_ 
   distributing the thing you linked against, you don't need to have the 
   license to distribute it as an aggregate work.

   This particular thing is a non-issue wrt the GPLv2, since you always 
   have the right to do distribution of aggregates, but it does come up in 
   some OTHER licenses.

 - you can (quite validly, in my opinion) argue that dynamic linking is a 
   sign of separation, and as such if you're able to do dynamic linking 
   against an unmodified second work, you have a much stronger argument 
   that they really can be seen as two independent works. But notice how 
   this was not a technical argument about the _linking_ per se: this 
   comes back to a much more important (and much more fundamental) issue 
   of whether things are independent (and being independent is certainly 
   one _requirement_ for them not being derived works)

   In other words: the _ability_ to do dynamic linking is certainly 
   meaningful, not because of the linking itself, but because of what it 
   implies from a perspective of "independence".

So to get back to the example of glibc: if a program _could_ have been 
linked against some other library, then that pretty clearly shows that 
it's really independent of glibc, and the linking is "mere aggregation" 
exactly the same way "mkisofs" is generally considered "mere aggregation".

And that is actually true whether you link dynamically or statically. 
Since the GPLv2 allows aggregation, I think you can very much argue in 
front of a judge that you could have linked statically against even a 
GPL'd glibc.

But notice how the thing changes if you talk about a specialized library 
like libqt - and notice how it again doesn't really matter whether you do 
dynamic or static linking. Libqt is still a work in its own right, but 
what about the program that links _to_ it? You can't generally really 
claim that it could equally well have been built against some other 
library, so now that program - whether linked dynamically or statically - 
obviously cannot stand on its own independently of libqt.

As a result, something that links against libqt is very different from 
something that links against glibc. 

But note how it wasn't "static" vs "dynamic" that mattered AT ALL. What 
mattered was whether they had independent lives.

And finally, in case it's not clear: I'm not a lawyer, and I don't play 
one on TV, and if I did, I'd be better looking and wouldn't spend my time 
on some technical discussion forum. So I'm not claiming that my viewpoint 
is "Right(tm)".

But I _am_ claiming that it makes a hell of a lot more sense as a 
viewpoint than the "linking is magic" argument does.

			Linus

Re: GPL only modules

[Paul Mackerras]

Linus Torvalds writes:

> Why do people think that using "ln" is _any_ different from using 
> "mkisofs". Both create one file that contains multiple pieces. What's the 
> difference - really?

The difference - really - at least for static linking - is that "ln"
makes modifications to each piece to make them work together, and in
the case of a library, makes a selection of the parts of the library
as needed by the rest of the program.  What ends up in the executable
is not just a set of verbatim copies of the input files packed
together, but rather a single program where the various parts have
been modified so as to fit together and create a whole.  Thus it seems
quite reasonable to me to say that a statically linked binary is a
derived work of all of the object files and libraries that were linked
together to form it.  IANAL, of course.

Dynamic linking is different, of course, if only because the final
runnable program is never distributed, but only formed in memory
during execution.  Also, the shared libraries are not modified and
incorporated during linking.

Paul.

Re: GPL only modules

[Junio C Hamano]

Paul Mackerras <paulus@samba.org> writes:

> Linus Torvalds writes:
>
>> Why do people think that using "ln" is _any_ different from using 
>> "mkisofs". Both create one file that contains multiple pieces. What's the 
>> difference - really?
>
> The difference - really - at least for static linking - is that "ln"
> makes modifications to each piece to make them work together, and in
> the case of a library, makes a selection of the parts of the library
> as needed by the rest of the program.

Excuse me, but are you two discussing "ld"? ;-)

Re: GPL only modules

[Paul Mackerras]

Junio C Hamano writes:

> Excuse me, but are you two discussing "ld"? ;-)

Oops.  Yes. :)

Paul.

Re: GPL only modules

[Dave Neuer]

On 12/17/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
> Linking does have one thing that it implies: it's maybe a bit "closer"
> relationship between the parts than "mkisofs" implies. So there is
> definitely a higher _correlation_ between "derived work" and "linking",
> but it's really a correlation, not a causal relationship.
>
> But it wasn't the "act of linking" that caused
> that to happen, but simply the fact that they were part of a bigger whole,
> and were meaningless apart from each other.

I think this is the key, both with libraries and w/ your book example
below; the concept of independant "meaning." If your code doesn't do
whatever it is supposed to do _unless_ it is linked with _my_ code,
then it seems fairly clear that your code is derivative of mine, just
as your sequel to my novel (or your pages added onto my book) don't
"mean" anything if someone hasn't read mine.

>
> Think of this in the sense of a book. Does binding pages together create a
> "derived work"? Not always: you can have anthologies (which are
> *aggregations* of works with *independent* copyright), and the binding of
> pages together didn't really do anything to the independent pieces. But
> clearly, if you're talking about individual pages in one story, then each
> individual page is not an independent work in itself.

Dave

Re: GPL only modules

[Theodore Tso]

On Mon, Dec 18, 2006 at 10:38:38AM -0500, Dave Neuer wrote:
> I think this is the key, both with libraries and w/ your book example
> below; the concept of independant "meaning." If your code doesn't do
> whatever it is supposed to do _unless_ it is linked with _my_ code,
> then it seems fairly clear that your code is derivative of mine, just
> as your sequel to my novel (or your pages added onto my book) don't
> "mean" anything if someone hasn't read mine.

That's a wonderful theory, but I don't believe it's recognized by the
courts.  I'm also pretty sure you don't want to go there.  Consider
folks who create add-ons to Tivo player, or extensions to MacOS.  They
don't _do_ anything unless they are used with the Tivo player.  Or a
game meant for a Playstation 3; it won't _do_ anything unless it's
calls the BIOS and system functions provided by the PS3.  Does that
automatically make them derived works?

What about a GPL'ed program which interfaces with the iTunes server?
It won't _do_ anything unless it can connect across the network and
talks to iTunes code.  Does that make it a derived work?

If the answer is no --- or should be no --- then maybe you should be
more careful before making such statements.

For myself, I believe we actually get the largest amount of
programming freedom if we use a very tightly defined definition of
derived code, and not try to create new expansive definitions and try
to ram them through the court system or through legislatures.  In the
end, we may end up regretting it.

						- Ted

Re: GPL only modules

[Dave Neuer]

On 12/18/06, Theodore Tso <tytso@mit.edu> wrote:
> On Mon, Dec 18, 2006 at 10:38:38AM -0500, Dave Neuer wrote:
> > I think this is the key, both with libraries and w/ your book example
> > below; the concept of independant "meaning." If your code doesn't do
> > whatever it is supposed to do _unless_ it is linked with _my_ code,
> > then it seems fairly clear that your code is derivative of mine, just
> > as your sequel to my novel (or your pages added onto my book) don't
> > "mean" anything if someone hasn't read mine.
>
> For myself, I believe we actually get the largest amount of
> programming freedom if we use a very tightly defined definition of
> derived code, and not try to create new expansive definitions and try
> to ram them through the court system or through legislatures.  In the
> end, we may end up regretting it.

To be sure, we as programmers will have the most freedom if there is
no form of intellectual property protection for software at all
(imagine all of those Renaissance publishers whose sensibilities would
have been quite shocked by the suggestion that their distribution of
some author's work for a small fee was somehow "theft").

It's less clear to me that a more expansive "we" will be equally well
served, freedom-wise, by less protection though I'm very sympathetic
to the argument.

>                                                 - Ted
>

Dave

Re: GPL only modules

[Alexandre Oliva]

On Dec 17, 2006, Linus Torvalds <torvalds@osdl.org> wrote:

> For example, glibc could easily have just come out and said the thing that 
> is obvious to any sane person: "using this library as just a standard 
> library does not make your program a derived work". 

> There really wassn't much need for the LGPL, I think. 

So I guess you approve of the reformulation of LGPL as an additional
permission on top of GPL, as in its draft at gplv3.fsf.org, right?

>> Some claim that, in the case of static linking, since there part of
>> the library copied to the binary, it is definitely a case of derived
>> work.

> No, the sane way to think about it is that linking just creates an 
> "aggregate" work.

That's your take on it.  It does make sense, but claiming it's *the*
sane way to think about it is making the mistake you accused the FSF
of making.


> Why do people think that using "ln" is _any_ different from using 
> "mkisofs".

Maybe because mkisofs will create a functional filesystem image out of
whatever you could possibly throw at it, while ld will perform a
number of cross-checks between the inputs it is given which indicates
a much closer relationship between the inputs?

You said so yourself, so I guess we agree.


> Does "mkisofs" create a derived work, or an aggregate?

I'd say both.  I understand it's a derived work, but one that happens
to be a mere aggregate of works that might or might not be based on a
GPLed program included in the aggregate.  Now, does this mean that a
court would be pretty much forced to admit the aggregate as a derived
work, and thus that the copyright holder (or the license author) gets
a say on what 'mere aggregate' means in the license chosen by the
copyright holder?

ld creates works that perhaps can be construed as not being mere
aggregates or even derived works, since ld doesn't always copy the
contents of its inputs to the output.  But it does extract some
information that makes to the output, and there is a closer
relationship between the works than in the mere aggregation case of
mkisofs, so there is still room for claiming that the output is a
derived work, and that it's not a mere aggregate.

In fact, it can't possibly be exempt by this paragraph in clause 2 of
the GPL:

  In addition, 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.

because we're not talking about mere aggregation of the work (or a
work based on it) with another work not based on the program, but
rather about whether the linker output is based on the program or not.
A court gets to decide whether it is a derived work, but since in the
dynamic linking case you're not aggregating (because you're not
copying the entire library) the program with other works not based on
the program, then this exception doesn't apply, methinks.

>    This particular thing is a non-issue wrt the GPLv2, since you always 
>    have the right to do distribution of aggregates, but it does come up in 
>    some OTHER licenses.

Make it *mere* aggregates.  That *might* turn out to be a relevant
distinction.  E.g., if there's functional dependence of one of the
elements of the aggregate on another, is the aggregate work still the
result of mere aggregation?

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: GPL only modules

[Linus Torvalds]

On Mon, 18 Dec 2006, Alexandre Oliva wrote:
> 
> So I guess you approve of the reformulation of LGPL as an additional
> permission on top of GPL, as in its draft at gplv3.fsf.org, right?

Yes. I think that part of the GPLv3 is a good idea.

That said, I think they are still pushing the "you don't have any rights 
unless we give you additional rights explicitly" angle a bit too hard.

The fact is, people DO have rights, regardless of what the license says. 
We have them when it comes to music, and we have them when it comes to 
software. Copyright law only gives _limited_ rights to copyright holders, 
and we should actually fight those rights being expanded, instead of 
trying to expand on them ourselves.

> > No, the sane way to think about it is that linking just creates an 
> > "aggregate" work.
> 
> That's your take on it.  It does make sense, but claiming it's *the*
> sane way to think about it is making the mistake you accused the FSF
> of making.

I did point that out at the end of the email you quote. I said it's not 
necessarily the only way to look at things. But I GUARANTEE you that it 
makes more sense than the "no rights" approach, and I GUARANTEE you that 
it makes more sense than thinking that "ld is magic, and makes a derived 
work" approach.

> In fact, it can't possibly be exempt by this paragraph in clause 2 of
> the GPL:
> 
>   In addition, 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.

This is actually a red herring. The way the GPLv2 _defines_ "work" and 
"Program" is by derived "derived work". 

You're confused by _your_ interpretation of "work" and "Program". You 
think that "Program" means "binary", because that's you think normally.

But the GPLv2 actually defines that "Program" is just the "derivative work 
under copyright law".

Really. Go look. It's right there at the very top, in section 0.

In other words, in the GPL, "Program" does NOT mean "binary". Never has.

And in fact, it wouldn't make sense if it did, since you can use the GPL 
for other things than just programs (and people have).

So you _always_ get back to the question: what is "derivative"? And the 
GPLv2 doesn't actually even say anything about that, but EXPLICITLY says 
that it is left to copyright law.

			Linus

Re: GPL only modules

[Alexandre Oliva]

On Dec 18, 2006, Linus Torvalds <torvalds@osdl.org> wrote:

> That said, I think they are still pushing the "you don't have any rights 
> unless we give you additional rights explicitly" angle a bit too hard.

Maybe it's just a matter of perception.  I don't see it that way from
the inside.

How about
http://gplv3.fsf.org/comments/rt/readsay.html?filename=gplv3-draft-2&id=2238

Would it help address your mis-perception?

> But I GUARANTEE you that it makes more sense than the "no rights"
> approach

Yeah, but that's a Straw Man.

> and I GUARANTEE you that it makes more sense than thinking that "ld
> is magic, and makes a derived work" approach.

I believe you and I have already shot down the 'ld-is-like-mkisofs'
argument.

>> In fact, it can't possibly be exempt by this paragraph in clause 2 of
>> the GPL:

>> In addition, 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.

> This is actually a red herring. The way the GPLv2 _defines_ "work" and 
> "Program" is by derived "derived work". 

No, that's how it defines 'work based on the Program', see the quoted
portion below.

> You're confused by _your_ interpretation of "work" and "Program". You 
> think that "Program" means "binary", because that's you think normally.

I can't see where you drew that conclusion from, but it's an incorrect
conclusion.  Program can denote the sources as much as the binaries.

> But the GPLv2 actually defines that "Program" is just the "derivative work 
> under copyright law".

> Really. Go look. It's right there at the very top, in section 0.

/me looks again

  0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License.  The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language.  (Hereinafter, translation is included without limitation in
the term "modification".)

> In other words, in the GPL, "Program" does NOT mean "binary". Never has.

Agreed.  So what?  How does this relate with the point above?

The binary is a Program, as much as the sources are a Program.  Both
forms are subject to copyright law and to the license, in spite of
http://www.fsfla.org/?q=en/node/128#1

> And in fact, it wouldn't make sense if it did, since you can use the GPL 
> for other things than just programs (and people have).

People do many odd things.  How do you define source code and object
code to other things that are not programs.

> So you _always_ get back to the question: what is "derivative"? And the 
> GPLv2 doesn't actually even say anything about that, but EXPLICITLY says 
> that it is left to copyright law.

Exactly.  No disagreement here.

I'm not disputing this fact.

In the point you quoted above, I was only disputing your argument of
"mere aggregation" in the context of dynamic linking.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: GPL only modules

[Linus Torvalds]

On Mon, 18 Dec 2006, Alexandre Oliva wrote:
>
> > In other words, in the GPL, "Program" does NOT mean "binary". Never has.
> 
> Agreed.  So what?  How does this relate with the point above?
> 
> The binary is a Program, as much as the sources are a Program.  Both
> forms are subject to copyright law and to the license, in spite of
> http://www.fsfla.org/?q=en/node/128#1

Here's how it relates:
 - if a program is not a "derived work" of the C library, then it's not 
   "the program" as defined by the GPLv2 AT ALL.

In other words, it doesn't matter ONE WHIT whether you use "ld --static" 
or "ld" or "mkisofs" - if the program isn't (by copyright law) derived 
from glibc, then EVEN IF glibc was under the GPLv2, it would IN NO WAY 
AFFECT THE RESULTING BINARY.

And I'm simply claiming that a binary doesn't become "derived from" by any 
action of linking.

Even if you link using "ld", even if it's static, the binary is not 
"derived from". It's an aggregate.

"Derivation" has nothing to do with "linking". Either it's derived or it 
is not, and "linking" simply doesn't matter. It doesn't matter whether 
it's static or dynamic. That's a detail that simply doesn't have anythign 
at all to do with "derivative work".

THAT is my point. 

Static vs dynamic matters for whether it's an AGGREGATE work. Clearly, 
static linking aggregates the library with the other program in the same 
binary. There's no question about that. And that _does_ have meaning from 
a copyright law angle, since if you don't have permission to ship 
aggregate works under the license, then you can't ship said binary. It's 
just a non-issue in the specific case of the GPLv2.

In the presense of dynamic linking the binary isn't even an aggregate 
work.

THAT is the difference between static and dynamic. A simple command line 
flag to the linker shouldn't really reasonably be considered to change 
"derivation" status.

Either something is derived, or it's not. If it's derived, "ld", 
"mkisofs", "putting them close together" or "shipping them on totally 
separate CD's" doesn't matter. It's still derived.

		Linus

RE: GPL only modules

[David Schwartz]

> Static vs dynamic matters for whether it's an AGGREGATE work. Clearly,
> static linking aggregates the library with the other program in the same
> binary. There's no question about that. And that _does_ have meaning from
> a copyright law angle, since if you don't have permission to ship
> aggregate works under the license, then you can't ship said binary. It's
> just a non-issue in the specific case of the GPLv2.

The right to ship aggregate works is not one specifically reserved by law to
the copyright holder. It's also not clear that an aggregate work is in fact
a single work for any legal purpose other than the aggregator's claim to
copyright. All you need to ship an aggregated work is the right to ship each
of the individual works aggregated in it. For GPL'd works, you get that
right from first sale, assuming you lawfully acquired the GPL'd work in the
first place.

If the aggregation is performed in an automated and mechanized way, the
aggregate is not a single work. It's still multiple works aggregated
together. For copyright law purposes, it is not a work because no creative
input was needed to produce it beyond what was used to create the works from
which it was formed.

I recently bought two DVDs as a present for a friend of mine. I put the two
DVDs in one box and shipped them to him. Just because the two DVDs are in
one box does not make them a derivative work for copyright purposes because
no creative input went in to them. I can even staple the two DVDs together
if I want. I also don't need any special permission to ship the two of them
together to my friend, first sale covers that. The right to ship each
individual work is all that's needed to ship the aggregate.

Now, if I wanted to write my own story with elements from the content of
both DVDs, that would be a derivative work because the combination itself is
done in a creative way.

No automated, mechanical process can create a derivative work of software.
(With a few exceptions not relevant here.)

DS

Re: GPL only modules

[Scott Preece]

On 12/18/06, David Schwartz <davids@webmaster.com> wrote:
>
> > Static vs dynamic matters for whether it's an AGGREGATE work. Clearly,
> > static linking aggregates the library with the other program in the same
> > binary. There's no question about that. And that _does_ have meaning from
> > a copyright law angle, since if you don't have permission to ship
> > aggregate works under the license, then you can't ship said binary. It's
> > just a non-issue in the specific case of the GPLv2.
>
> The right to ship aggregate works is not one specifically reserved by law to
> the copyright holder.
---
Well, it's reserved to the authors of all the works in the aggregate,
possibly including the person doing the aggregation. And the author of
each of those works does have the right to limit your permission to
distribute in ways that might bar use in aggregations.
---
> It's also not clear that an aggregate work is in fact
> a single work for any legal purpose other than the aggregator's claim to
> copyright.
---

Not sure what you're trying to say there - what are we talking about
here other than the copyright?

---
> All you need to ship an aggregated work is the right to ship each
> of the individual works aggregated in it. For GPL'd works, you get that
> right from first sale, assuming you lawfully acquired the GPL'd work in the
> first place.
---

An aggregate work (the word used in the Copyright Act is either
"Compilation" or "Collective work", depending on the level of
creativity involved in forming it). In either case it is an
independent work. The person creating a Compilation has, at the least,
copyright in the organization of the material, plus copyright in any
original material she contributes. I agree, however, that all you need
to distribute tthe compilation is permission to distribute each of the
pieces in the given form (the author could have given you the right to
distribute only in conjunction with other specified works, for
instance) or placed other restrictions on the license.

First sale has nothing to do with this. First sale applies to the
redistribution or resale of copies you have purchased, not with the
right to make additional copies.

---
> ... For copyright law purposes, it is not a work because no creative
> input was needed to produce it beyond what was used to create the works from
> which it was formed.
---

Selection and organization are potentially creative. The Act
distinguishes between derivative works, compilations, and collective
works. A derivative work is a work "based on" the original work; a
compilation is a work formed by "collecting and assembling"
preexisting works "in such a way that the resulting work as a whole
constitutes an original work of authorship. A "collective work" is any
work formed by assembling independent works into a whole. All
compilations are collective works, but not all collective works are
compilations. Derivative works have nothing to do with aggregation.

---
> I recently bought two DVDs as a present for a friend of mine. I put the two
> DVDs in one box and shipped them to him. Just because the two DVDs are in
> one box does not make them a derivative work for copyright purposes because
> no creative input went in to them. I can even staple the two DVDs together
> if I want. I also don't need any special permission to ship the two of them
> together to my friend, first sale covers that. The right to ship each
> individual work is all that's needed to ship the aggregate.
---

First sale is separate from Copyright. You have the right to ship
them, but not to make copies of them. You can't for instance, ship
your friend a single DVD that combines the contents of the two you
bought. That's not unlike the distinction GPLv3 makes between
"propagating" and "conveying".

---
>
> Now, if I wanted to write my own story with elements from the content of
> both DVDs, that would be a derivative work because the combination itself is
> done in a creative way.
---

If it just rearranged the pieces, it would not be a derivative work,
it would be a compilation. If you transformed the pieces, it might be
a derivative work (depending on the nature of the transformation).

---
>
> No automated, mechanical process can create a derivative work of software.
> (With a few exceptions not relevant here.)
---

The truth of that statement depends on exactly what you mean by "an
automated, mechanical process". There are mechanical processs that
would simply produce the original work itself, not a derivative (e.g.,
changing the type from Courier to Times). There are other mechanical
proceses that would produce a collective work (e.g., inserting after
each line of the program a statement indicating whether or not it was
valid C). There are other mechanical processes that would create a
derivative work (e.g., a paraphrasing tool). It depends on the nature
of the mechanical process; that is, the decision, by you, to apply a
particular mechanical process is itself creative. But, perhaps that's
what you meant by your "few exceptions".

As always, IANAL,
scott

RE: GPL only modules

[David Schwartz]

> > It's also not clear that an aggregate work is in fact
> > a single work for any legal purpose other than the aggregator's claim to
> > copyright.

> Not sure what you're trying to say there - what are we talking about
> here other than the copyright?

We are talking about two different possible copyright claims. One is the
person who aggregates the works who may try to claim a "compilation
copyright" in the aggregate. The other is the authors of the original works
who may try to claim that the aggregate is a derivative work.

> First sale has nothing to do with this. First sale applies to the
> redistribution or resale of copies you have purchased, not with the
> right to make additional copies.

First sale is exactly what this is about. Nobody needs to make "additional
copies" of the Linux kernel because I can download a thousand of them from a
computer operated by the guy in the office down the hall from me.


> > ... For copyright law purposes, it is not a work because no creative
> > input was needed to produce it beyond what was used to create
> > the works from
> > which it was formed.

> Selection and organization are potentially creative. The Act
> distinguishes between derivative works, compilations, and collective
> works. A derivative work is a work "based on" the original work; a
> compilation is a work formed by "collecting and assembling"
> preexisting works "in such a way that the resulting work as a whole
> constitutes an original work of authorship. A "collective work" is any
> work formed by assembling independent works into a whole. All
> compilations are collective works, but not all collective works are
> compilations. Derivative works have nothing to do with aggregation.

Good, so we agree that aggregate is not a derivative work. That means it
doesn't have to be GPL'd even if some of its component works are GPL'd.

> > I recently bought two DVDs as a present for a friend of mine. I
> > put the two
> > DVDs in one box and shipped them to him. Just because the two
> > DVDs are in
> > one box does not make them a derivative work for copyright
> > purposes because
> > no creative input went in to them. I can even staple the two
> > DVDs together
> > if I want. I also don't need any special permission to ship the
> > two of them
> > together to my friend, first sale covers that. The right to ship each
> > individual work is all that's needed to ship the aggregate.

> First sale is separate from Copyright. You have the right to ship
> them, but not to make copies of them. You can't for instance, ship
> your friend a single DVD that combines the contents of the two you
> bought. That's not unlike the distinction GPLv3 makes between
> "propagating" and "conveying".

I don't see why you can't distribute a single DVD that combines the contents
of the two you bought, so long as you destroy the originals. There is no
issue about the number of copies with the GPL because you can download any
number of copies of a GPL'd work from someone else who provides you with
source.

> > Now, if I wanted to write my own story with elements from the content of
> > both DVDs, that would be a derivative work because the
> > combination itself is
> > done in a creative way.

> If it just rearranged the pieces, it would not be a derivative work,
> it would be a compilation. If you transformed the pieces, it might be
> a derivative work (depending on the nature of the transformation).

I think it depends upon how small the pieces are. If you rearranged them
creatively, and the result was in effect a single work, I think it would be
a derivative work.

> > No automated, mechanical process can create a derivative work
> > of software.
> > (With a few exceptions not relevant here.)

> The truth of that statement depends on exactly what you mean by "an
> automated, mechanical process". There are mechanical processs that
> would simply produce the original work itself, not a derivative (e.g.,
> changing the type from Courier to Times). There are other mechanical
> proceses that would produce a collective work (e.g., inserting after
> each line of the program a statement indicating whether or not it was
> valid C). There are other mechanical processes that would create a
> derivative work (e.g., a paraphrasing tool). It depends on the nature
> of the mechanical process; that is, the decision, by you, to apply a
> particular mechanical process is itself creative. But, perhaps that's
> what you meant by your "few exceptions".

I mean that you can't link together a bunch of works that would otherwise be
independent and get a derivative work as a result. Linking combines
mechanistically, not creatively, so it aggregates.

DS

Re: GPL only modules

[Scott Preece]

On 12/18/06, David Schwartz <davids@webmaster.com> wrote:
>
>
> > First sale has nothing to do with this. First sale applies to the
> > redistribution or resale of copies you have purchased, not with the
> > right to make additional copies.
>
> First sale is exactly what this is about. Nobody needs to make "additional
> copies" of the Linux kernel because I can download a thousand of them from a
> computer operated by the guy in the office down the hall from me.
---

This is an interesting argument that was new to me. However, it is not
clear at all that First Sale applies to intangible copies. And it's
not clear that there is a sale involved, legally. Again, IANAL, but I
think this is seriously untested ground.

scott

Re: GPL only modules

[Alexandre Oliva]

On Dec 18, 2006, "David Schwartz" <davids@webmaster.com> wrote:

> I don't see why you can't distribute a single DVD that combines the contents
> of the two you bought, so long as you destroy the originals.

Because, for example, per Brazilian law since 1998, fair use only
grants you the right to copy small portions of copyrighted works for
personal use.   http://www.petitiononline.com/netlivre

Remember that the GPL is not only about US copyright law or US
courts.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: GPL only modules

[Alexandre Oliva]

On Dec 18, 2006, "David Schwartz" <davids@webmaster.com> wrote:

> No automated, mechanical process can create a derivative work of software.
> (With a few exceptions not relevant here.)

Can you explain what mechanisms are involved in copyright monopolies
over object code, then?
(there's a hint at http://www.fsfla.org/?q=en/node/128#1 )

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: GPL only modules

[Jeff V. Merkey]

Linus Torvalds wrote:

>On Mon, 18 Dec 2006, Alexandre Oliva wrote:
>  
>
>>>In other words, in the GPL, "Program" does NOT mean "binary". Never has.
>>>      
>>>
>>Agreed.  So what?  How does this relate with the point above?
>>
>>The binary is a Program, as much as the sources are a Program.  Both
>>forms are subject to copyright law and to the license, in spite of
>>http://www.fsfla.org/?q=en/node/128#1
>>    
>>
>
>Here's how it relates:
> - if a program is not a "derived work" of the C library, then it's not 
>   "the program" as defined by the GPLv2 AT ALL.
>
>In other words, it doesn't matter ONE WHIT whether you use "ld --static" 
>or "ld" or "mkisofs" - if the program isn't (by copyright law) derived 
>from glibc, then EVEN IF glibc was under the GPLv2, it would IN NO WAY 
>AFFECT THE RESULTING BINARY.
>
>And I'm simply claiming that a binary doesn't become "derived from" by any 
>action of linking.
>
>Even if you link using "ld", even if it's static, the binary is not 
>"derived from". It's an aggregate.
>
>"Derivation" has nothing to do with "linking". Either it's derived or it 
>is not, and "linking" simply doesn't matter. It doesn't matter whether 
>it's static or dynamic. That's a detail that simply doesn't have anythign 
>at all to do with "derivative work".
>
>THAT is my point. 
>
>Static vs dynamic matters for whether it's an AGGREGATE work. Clearly, 
>static linking aggregates the library with the other program in the same 
>binary. There's no question about that. And that _does_ have meaning from 
>a copyright law angle, since if you don't have permission to ship 
>aggregate works under the license, then you can't ship said binary. It's 
>just a non-issue in the specific case of the GPLv2.
>
>In the presense of dynamic linking the binary isn't even an aggregate 
>work.
>
>THAT is the difference between static and dynamic. A simple command line 
>flag to the linker shouldn't really reasonably be considered to change 
>"derivation" status.
>
>Either something is derived, or it's not. If it's derived, "ld", 
>"mkisofs", "putting them close together" or "shipping them on totally 
>separate CD's" doesn't matter. It's still derived.
>
>		Linus
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>
Yep. We love you linus, keep going.

Also, we are taking over SCO's office space after the first of the year, 
since they have no one left. We will try to get that annoying eyesore of 
a sign taken off the building as soon as possible. They moved to 
Holliday, UT (or are moving there at present).

:-)

Jeff

Re: GPL only modules

[Alexandre Oliva]

On Dec 18, 2006, Linus Torvalds <torvalds@osdl.org> wrote:

> On Mon, 18 Dec 2006, Alexandre Oliva wrote:

>> > In other words, in the GPL, "Program" does NOT mean "binary". Never has.

>> Agreed.  So what?  How does this relate with the point above?

> Here's how it relates:
>  - if a program is not a "derived work" of the C library, then it's not 
>    "the program" as defined by the GPLv2 AT ALL.

In the case I'm talking about, libgpl (make it a GPLed libc) is the
program, and a binary produced by linking anything else with the
program (libgpl) is what you claim to be an aggregate (a term not
defined in the GPL; is it defined in US law?).

For both static and dynamic linking, you might claim the output is an
aggregate, but that doesn't matter.  What matters is whether or not
the output is a work based on the program, and whether the "mere
aggregation" paragraph kicks in.

If the output is not an aggregate, which is quite likely to be
the case for dynamic linking, and quite possibly also for many static
linking cases, then the "mere aggregation" paragraph of clause 2 does
not kick in.

If the output is indeed an aggregate, as it may quite likely be in the
case of static linking, then the "mere aggregation" considerations of
clause 2 may kick in and enable the 'anything else' to not be brought
under the scope of the license.  You still need permission to
distribute the whole.  The GPL asserts its non-interference with your
ability to distribute the separate portion separately, under whatever
license you can, as long as it's not a derived work from the GPL
portion.

But what about the whole?  If you can't separate the whole into, well,
the separate components, is it still a mere aggregate?  mkisofs will
create an image in which the components are all there, easily
extractable individually in their original form.  This is *clearly*
mere aggregation, even if some components turn out to be works based
on other GPL programs.

But even in the case of static linking, this is not how it works.
Say, if the portions of the static libgpl to be copied to the output
are selected based on the contents of the 'anything else', could you
legitimately claim that the output is not a derived work of both
libgpl and this 'anything else', but rather a mere aggregation of
unrelated works?

In either case, if you distribute the linker output, and it happens to
be found to be a derived work of the program (libgpl), aggregate or
not, then you must license the whole of the linker output under the
GPL, and this means to me that you have to be able to provide the
source code of every portion thereof under the GPL, except for
portions explicitly excluded by the GPL itself.

So whether it's an aggregate or not is completely irrelevant.  What
matters is whether it's a derived work of a GPLed program (and if
there is copying, it probably is) and whether the mere aggregation
clause kicks in to grant an exception.

> THAT is the difference between static and dynamic. A simple command line 
> flag to the linker shouldn't really reasonably be considered to change 
> "derivation" status.

If in one case there is extraction, copying and transformation of the
GPLed intput, and in the other there is something much simpler (does
it still qualify as extraction, copying and transformation?), then
derivation becomes more or less obvious to prove, but you're right in
that the status of the output probably won't change.  The status of
the inputs certainly doesn't.

> Either something is derived, or it's not. If it's derived, "ld", 
> "mkisofs", "putting them close together" or "shipping them on totally 
> separate CD's" doesn't matter. It's still derived.

But the important questions at hand, I think, are what makes it
derived, and whether it qualifies for any of the exceptions in the
GPL.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

RE: GPL only modules

[David Schwartz]

> For both static and dynamic linking, you might claim the output is an
> aggregate, but that doesn't matter.  What matters is whether or not
> the output is a work based on the program, and whether the "mere
> aggregation" paragraph kicks in.
>
> If the output is not an aggregate, which is quite likely to be
> the case for dynamic linking, and quite possibly also for many static
> linking cases, then the "mere aggregation" paragraph of clause 2 does
> not kick in.
>
> If the output is indeed an aggregate, as it may quite likely be in the
> case of static linking, then the "mere aggregation" considerations of
> clause 2 may kick in and enable the 'anything else' to not be brought
> under the scope of the license.  You still need permission to
> distribute the whole.  The GPL asserts its non-interference with your
> ability to distribute the separate portion separately, under whatever
> license you can, as long as it's not a derived work from the GPL
> portion.

No!

It makes no difference whether the "mere aggregation" paragraph kicks in
because the "mere aggregation" paragraph is *explaining* the *law*. What
matters is what the law actually *says*.

We are talking about what works are within the GPL's scope. The text of the
GPL does not matter because the GPL does not set its own scope, copyright
law does.

The GPL could say that if you ever see the source code to a GPL'd work,
every work you ever write must be placed under the GPL. But that wouldn't
make it true, because that would be a requirement outside the GPL's scope.

We are talking about works are inside the GPL's legal scope, and in that
case, nothing the GPL says can enlarge the scope.

DS

Re: GPL only modules

[D. Hazelton]

On Monday 18 December 2006 20:35, David Schwartz wrote:
> > For both static and dynamic linking, you might claim the output is an
> > aggregate, but that doesn't matter.  What matters is whether or not
> > the output is a work based on the program, and whether the "mere
> > aggregation" paragraph kicks in.
> >
> > If the output is not an aggregate, which is quite likely to be
> > the case for dynamic linking, and quite possibly also for many static
> > linking cases, then the "mere aggregation" paragraph of clause 2 does
> > not kick in.
> >
> > If the output is indeed an aggregate, as it may quite likely be in the
> > case of static linking, then the "mere aggregation" considerations of
> > clause 2 may kick in and enable the 'anything else' to not be brought
> > under the scope of the license.  You still need permission to
> > distribute the whole.  The GPL asserts its non-interference with your
> > ability to distribute the separate portion separately, under whatever
> > license you can, as long as it's not a derived work from the GPL
> > portion.
>
> No!
>
> It makes no difference whether the "mere aggregation" paragraph kicks in
> because the "mere aggregation" paragraph is *explaining* the *law*. What
> matters is what the law actually *says*.
>
> We are talking about what works are within the GPL's scope. The text of the
> GPL does not matter because the GPL does not set its own scope, copyright
> law does.
>
> The GPL could say that if you ever see the source code to a GPL'd work,
> every work you ever write must be placed under the GPL. But that wouldn't
> make it true, because that would be a requirement outside the GPL's scope.
>
> We are talking about works are inside the GPL's legal scope, and in that
> case, nothing the GPL says can enlarge the scope.
>
> DS


Actually, after rereading the GPLv2 because of this discussion I came to a 
most surprising conclusion. While there are *IMPLICIT* and *EXPLICIT* 
copyrights on the code, they have no bearing on the text of the GPL.

The GPL is a License that covers how the code may be used, modified and 
distributed. This is the reason that the FSF people had to make the big 
exception for Bison, because the parser skeleton is such an integral part of 
Bison (Bison itself, IIRC, uses the same skeleton, modified, as part of the 
program) that truthfully, any parser built using Bison is a derivative work 
of code released under the GPL.

That said, since there is a distribution, use and modification license on the 
Linux Kernel - the GPLv2 - there are those extra restrictions on the code 
*OUTSIDE* the copyright rules.

DRH

Re: GPL only modules

[Horst H. von Brand]

D. Hazelton <dhazelton@enter.net> wrote:

[...]

> The GPL is a License that covers how the code may be used, modified and 
> distributed. This is the reason that the FSF people had to make the big 
> exception for Bison, because the parser skeleton is such an integral part of 
> Bison (Bison itself, IIRC, uses the same skeleton, modified, as part of the 
> program) that truthfully, any parser built using Bison is a derivative work 
> of code released under the GPL.

They didn't "have to make the big exception", if Linus' view is correct:
The parser is built mechanically from the skeleton and the user's input, so
it is just an aggregation. Sure, it is best to make this clear (by the
exception), even if not needed.

> That said, since there is a distribution, use and modification license on
> the Linux Kernel - the GPLv2 - there are those extra restrictions on the
> code *OUTSIDE* the copyright rules.

A license like GPL works /inside/ copyright law, by allowing you to do
things the law prohibits unless the owner of the right agrees. What the law
allows explicitly, regardless of the owner's wishes, can't be taken away.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513

Re: GPL only modules

[Alexandre Oliva]

On Dec 18, 2006, "David Schwartz" <davids@webmaster.com> wrote:

> It makes no difference whether the "mere aggregation" paragraph kicks in
> because the "mere aggregation" paragraph is *explaining* the *law*. What
> matters is what the law actually *says*.

You mean "mere aggregation" is defined in copyright law?  I don't
think so, otherwise the term 'aggregate' probably wouldn't have
been used in GPLv3.

AFAIK it's perfectly legitimate (even if immoral) for a copyright
license to prohibit the distribution of the software governed by the
license with anything else the author establishes.  E.g., some Java
virtual machine's license used to establish that you couldn't ship it
along with other implementations of Java that didn't pass some
comformance test.

Now, the GPL doesn't do this.  It doesn't say you can't distribute
GPLed software along with any other software.  It only says that, when
you distribute together works that don't constitute mere aggregation
(providing its own definition of mere aggregation), then the whole
must be licensed under the GPL.

> The GPL could say that if you ever see the source code to a GPL'd work,
> every work you ever write must be placed under the GPL. But that wouldn't
> make it true, because that would be a requirement outside the GPL's scope.

It is indeed possible that this would fall outside the scope of
copyright law in the US, and it would not be morally acceptable for
the GPL to impose such a condition.  But then, since nobody can be
forced to see the source code of a GPLed work, or any work for that
matter, acceptance is voluntary, and one shouldn't enter an agreement
one's not willing to abide by.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: GPL only modules

[Paul Mackerras]

Linus Torvalds writes:

> "Derivation" has nothing to do with "linking". Either it's derived or it 
> is not, and "linking" simply doesn't matter. It doesn't matter whether 
> it's static or dynamic. That's a detail that simply doesn't have anythign 
> at all to do with "derivative work".

There is in fact a pretty substantial non-technical difference between
static and dynamic linking.  If I create a binary by static linking
and I include some library, and I distribute that binary to someone
else, the recipient doesn't need to have a separate copy of the
library, because they get one in the binary.

If on the other hand the binary is dynamically linked, then the
recipient needs to get hold of a copy of the library from somewhere,
implying that they need to have satisfied whatever license conditions
the copyright owner of the library places on it, in order to have
obtained their copy of the library legally.

In other words, static linking gives the recipient a "free" copy of
the library, but dynamic linking doesn't.  That is why some companies'
legal guidelines have quite different rules about the distribution of
binaries, depending on whether they are statically or dynamically
linked.

If the library was a proprietary library, for which the copyright
owner wanted to charge a per-copy fee, the owner would no doubt object
to me distributing statically-linked binaries containing his library,
but could conceivably be perfectly happy with me distributing binaries
that have been dynamically linked against his library, since then
anyone who wants to use my binary has to purchase a copy of his
library from him.

So therefore I don't think you can reasonably claim that static
vs. dynamic linking is only a technical difference.  There are clearly
other differences when it comes to distribution of the resulting
binaries.

Paul.

Re: GPL only modules

[Linus Torvalds]

On Tue, 19 Dec 2006, Paul Mackerras wrote:
>
> There is in fact a pretty substantial non-technical difference between
> static and dynamic linking.  If I create a binary by static linking
> and I include some library, and I distribute that binary to someone
> else, the recipient doesn't need to have a separate copy of the
> library, because they get one in the binary.

I agree, and I do agree that it's a real difference. 

I personally think that it's the "aggregation" issue, not a "derivation" 
issue, but I'll freely admit that it's just my personal view of the 
situation.

> In other words, static linking gives the recipient a "free" copy of
> the library, but dynamic linking doesn't.  That is why some companies'
> legal guidelines have quite different rules about the distribution of
> binaries, depending on whether they are statically or dynamically
> linked.

Yes. There is not doubt at all that regardless of anything else, if you 
link statically, you at the VERY LEAST need to have the right to 
distribute the library as part of an "aggregate work". 

> So therefore I don't think you can reasonably claim that static
> vs. dynamic linking is only a technical difference.  There are clearly
> other differences when it comes to distribution of the resulting
> binaries.

Yes. And I have actually talked about this exact issue - even in the 
absense of any "derivation" from the library, the fact that static linking 
includes a _copy_ of the library does mean that you have to have the right 
to distribute that particular copy. 

Now, under the GPL, aggregate distribution is allowed, but you still do 
need to follow the other GPL rules (ie you would need to distributed 
sources for the library - even if you don't necessarily distribute sources 
to the binary you linked _with_).

So there's no question that "dynamic linking" simplifies issues, by virtue 
of not even distributing any library code at all. I absolutely agree about 
that part.

		Linus

Re: GPL only modules

[Paul Mackerras]

Linus Torvalds writes:
> 
> 
> On Tue, 19 Dec 2006, Paul Mackerras wrote:
> >
> > There is in fact a pretty substantial non-technical difference between
> > static and dynamic linking.  If I create a binary by static linking
> > and I include some library, and I distribute that binary to someone
> > else, the recipient doesn't need to have a separate copy of the
> > library, because they get one in the binary.
> 
> I agree, and I do agree that it's a real difference. 
> 
> I personally think that it's the "aggregation" issue, not a "derivation" 
> issue, but I'll freely admit that it's just my personal view of the 
> situation.

I think the critical issue is whether any human creativity is required
to establish derivation.

Clearly there is some modification and adaptation that ld does to a
library in the process of linking it into a binary, and ld is unlike
mkisofs or gzip in that you can't extract the library in its original
form (or any form suitable for linking with another program) from the
output of ld --static.

The question is whether it matters that the process that ld does is
mechanical in nature.  This is possibly an area where you'll get a
different answer in different jurisdictions.  I believe that in the
US, some creative input is required to establish copyright, whereas in
Australia, only "effort" is needed.  I don't know whether that affects
the definition of "derived work".

I personally would think that a mechanical process of modification
*does* create a derived work, but it would take a court of law or a
legislature to make an authoritative decision, I guess.

Paul.

RE: GPL only modules

[David Schwartz]

Combined responses:

> So therefore I don't think you can reasonably claim that static
> vs. dynamic linking is only a technical difference.  There are clearly
> other differences when it comes to distribution of the resulting
> binaries.

We're only talking about the special case of GPL'd works. You can download a
million copies of a GPL'd work from a server run by a family member across
the room. You can then delete one copy for each copy you distribute in the
form of a statically linked work.

Issues of copying don't apply to GPL'd works unless you have no access to
the source code. Otherwise, someone else can copy you as many works as you
want with the source code, and you can use first sale to transfer every one
of them.

> I personally would think that a mechanical process of modification
> *does* create a derived work, but it would take a court of law or a
> legislature to make an authoritative decision, I guess.

Under at least United States law, copyright protected creative expression
and only creative expression. In other jurisdictions, there are other types
of rights similar to copyright that one can obtain by means of hard work,
for example database compilation rights. They are usually legally distinct
from copyright and grant different rights with different rules.

DS

Re: GPL only modules

[Daniel Barkalow]

On Mon, 18 Dec 2006, Linus Torvalds wrote:

> Static vs dynamic matters for whether it's an AGGREGATE work. Clearly, 
> static linking aggregates the library with the other program in the same 
> binary. There's no question about that. And that _does_ have meaning from 
> a copyright law angle, since if you don't have permission to ship 
> aggregate works under the license, then you can't ship said binary. It's 
> just a non-issue in the specific case of the GPLv2.

Under US law, the distinction is between works that are copyrightable 
themselves as "derivative works" and works that are derived from others, 
but aren't copyrightable. Provided you're allowed to ship aggregate works, 
the question is whether the output of "ld" is a copyrightable work 
distinct from the inputs.

I'd agree that "ar", like "mkisofs", doesn't create a derived work, but I 
think that "objcopy" does create a derived work, and "ld" does too, by 
virtue of modifying the objects it takes to resolve symbols. Now, you 
could distribute to somebody an ar archive of your program, and the 
recipient (given fair use rights to the copy of the program they received) 
could do "gcc program.a -o program" to link it. But I don't think you 
automatically get the right (under the "mere aggregation" permission) to 
distribute the result of relocating the symbols of gnutls around those of 
your program and vice versa, along with modifying the references to 
external symbols from each of these to point to specific locations.

	-Daniel
*This .sig left intentionally blank*

RE: GPL only modules

[David Schwartz]

Note: Combined responses.

> I'd agree that "ar", like "mkisofs", doesn't create a derived work, but I
> think that "objcopy" does create a derived work, and "ld" does too, by
> virtue of modifying the objects it takes to resolve symbols. Now, you
> could distribute to somebody an ar archive of your program, and the
> recipient (given fair use rights to the copy of the program they
> received)
> could do "gcc program.a -o program" to link it. But I don't think you
> automatically get the right (under the "mere aggregation" permission) to
> distribute the result of relocating the symbols of gnutls around those of
> your program and vice versa, along with modifying the references to
> external symbols from each of these to point to specific locations.

The question is, as a matter of copyright law, what right do you need to
distribute the aggregate? As I understand the law, the answer is that you
need the right to distribute each of the individual works in the aggregate.
Fortunately, you can trivially get the right to distribute any GPL'd work
under first sale. (Simply download as many copies as you plan to
distribute.)

To argue otherwise would be to argue that you can't buy a DVD and a Hallmark
card and ship the two of them together to your mother.

--

>This is an interesting argument that was new to me. However, it is not
>clear at all that First Sale applies to intangible copies. And it's
>not clear that there is a sale involved, legally. Again, IANAL, but I
>think this is seriously untested ground.

First sale has nothing do with a sale. 17 USC 109(a) says, "Notwithstanding
the provisions of section 106 (3), the owner of a particular copy or
phonorecord lawfully made under this title, or any person authorized by such
owner, is entitled, without the authority of the copyright owner, to sell or
otherwise dispose of the possession of that copy or phonorecord."

I think it's well settled law that everyone who lawfully acquires a copy of
a copyrighted work has the right to its normal expected use and may transfer
that right along with their copy to another without needing any special
permission from the copyright holder. Exceptions would include cases where
there was specific assent to a license, such as shrink-wrap, click-through,
or EULA.

I'm not really qualified to respond to the argument that first sale doesn't
apply to an intangible copy. As the law is written, it simply refers to the
owner of a "a particular copy". Sometimes "a copy" only means tangible
copies and sometimes it simply means the result of copying. It seems bizarre
to me, however, to argue that if I lawfully download a program, I need
special permission from the copyright holder to put it on CD but not a hard
drive. What is the *legal* difference? And if I put it no a hard drive, I
can't sell it? Seems crazy to me.

--

>AFAIK it's perfectly legitimate (even if immoral) for a copyright
>license to prohibit the distribution of the software governed by the
>license with anything else the author establishes.  E.g., some Java
>virtual machine's license used to establish that you couldn't ship it
>along with other implementations of Java that didn't pass some
>comformance test.

Nobody ever said a copyright holder couldn't restrict the distribution of
his software when such distribution is not authorized by things like fair
use, first sale, or other things. Of course a copyright holder can set any
rules he want for those distributions not authorized by law.

However, those restrictions do not affect those who did not agree to them.
For example, if I buy such a JVM and don't agree to the license (assuming I
don't have to agree to the license to lawfully acquire the JVM), I can give
it to a friend along with any other software I want.

--

>A bare license probably cannot take them away, since you haven't
>agreed to anything.  But (1) that may not be true in all legal
>systems, and (2) a contract-based license can take it away (e.g. an
>NDA).  So the GPL's clarification is worthwhile.  For the same reason,
>I'm guessing, the Creative Commons licenses have (also in section 2,
>at least in v2.5):

The clarification serves another important purpose as well. If some
provision is ambiguous and admits of two readins, one which conflicts with
fair use and would not be enforceable and one which doesn't that is, these
disclaimers make clear that the latter interpretation is the one that should
be chosen. So they may actually *increase* the scope of the license.

DS

Re: GPL only modules

[Scott Preece]

On 12/20/06, David Schwartz <davids@webmaster.com> wrote:

> > I'd agree that "ar", like "mkisofs", doesn't create a derived work, but I
> > think that "objcopy" does create a derived work, and "ld" does too, by
> > virtue of modifying the objects it takes to resolve symbols. ...
>
> The question is, as a matter of copyright law, what right do you need to
> distribute the aggregate? As I understand the law, the answer is that you
> need the right to distribute each of the individual works in the aggregate.
> Fortunately, you can trivially get the right to distribute any GPL'd work
> under first sale. (Simply download as many copies as you plan to
> distribute.)
>
> To argue otherwise would be to argue that you can't buy a DVD and a Hallmark
> card and ship the two of them together to your mother.
---

If the aggregate is not a derived work, then you only need the
separate permissions for the original works. If the aggregate is a
derived work, then you need permissions relative to the derived work,
not just the original work - essenitlally, permission to modify the
work. And, the permissions would all have to allow the specific form
of distribution and aggregation involved. [Don't give me back the
example of breaking the DVD in half - "the work" is not the medium;
your purchase of a DVD does not give you the right to modify the movie
it carries and redistribute the modified version, even under first
sale.]

---
>
> >This is an interesting argument that was new to me. However, it is not
> >clear at all that First Sale applies to intangible copies. And it's
> >not clear that there is a sale involved, legally. Again, IANAL, but I
> >think this is seriously untested ground.
>
> First sale has nothing do with a sale. 17 USC 109(a) says, "Notwithstanding
> the provisions of section 106 (3), the owner of a particular copy or
> phonorecord lawfully made under this title, or any person authorized by such
> owner, is entitled, without the authority of the copyright owner, to sell or
> otherwise dispose of the possession of that copy or phonorecord."
---

While I generally agree with you that first sale can occur without an
actual sale, the GPL (and distribution by free download in general) is
an odd situation (the law wasn't designed for works that could be
freely copied) and I would not suggest anyone depend on a court to
interpret that clause the way you are.

---
> I'm not really qualified to respond to the argument that first sale doesn't
> apply to an intangible copy. As the law is written, it simply refers to the
> owner of a "a particular copy". Sometimes "a copy" only means tangible
> copies and sometimes it simply means the result of copying. It seems bizarre
> to me, however, to argue that if I lawfully download a program, I need
> special permission from the copyright holder to put it on CD but not a hard
> drive. What is the *legal* difference? And if I put it no a hard drive, I
> can't sell it? Seems crazy to me.
---

Nevertheless, the only decided cases I could find in the area went the
other way - saying that intangible copies did not exhaust the author's
distribution rights. Note that your example is misleading - you don't
need different permission to put it on a CD than to put it on a hard
drive, but you might not have permission to distribute it (depending
on the terms under which you received it). There is case law finding
that, in at least some cases, the author's rights in particular copies
(even tangible copies) was not exhausted.

---
>
> Nobody ever said a copyright holder couldn't restrict the distribution of
> his software when such distribution is not authorized by things like fair
> use, first sale, or other things. Of course a copyright holder can set any
> rules he want for those distributions not authorized by law.
>
> However, those restrictions do not affect those who did not agree to them.
> For example, if I buy such a JVM and don't agree to the license (assuming I
> don't have to agree to the license to lawfully acquire the JVM), I can give
> it to a friend along with any other software I want.
---

No, as with the language in the GPL, your right to distribute is
provided by the license you received with the JVM, so if you don't
accept it, you can't distribute. However, the first sale doctrine
provides a limited exception; if you got the JVM through an
unrestricted sale, then you would normally have the right to sell that
particular copy without any further license (though possibly not to
someone in a different part of the world).

scott

RE: GPL only modules

[David Schwartz]

> > However, those restrictions do not affect those who did not
> > agree to them.
> > For example, if I buy such a JVM and don't agree to the license
> > (assuming I
> > don't have to agree to the license to lawfully acquire the
> > JVM), I can give
> > it to a friend along with any other software I want.

> No

Yes.

> as with the language in the GPL, your right to distribute is
> provided by the license you received with the JVM, so if you don't
> accept it, you can't distribute.

This is flat out self-contradiction. If my right is provided by the license,
then I can distribute. If I don't accept the license, then how is my right
to distribute provided by it?

The paragraph you are saying "No" to is completely correct and your response
is complete double-speak.

> However, the first sale doctrine
> provides a limited exception;

Exactly. So the idea that you can't distribute a work unless you agree to
its license is nonsense. With a license like the GPL, that is something that
is not a shrink-wrap, click-through, or EULA, the license does not apply to
anyone who does not agree to it. The GPL makes this totally clear in section
5.

If you don't accept the license, you simply don't get the additional rights
the license offers. You still have all the rights you originally had.

> if you got the JVM through an
> unrestricted sale, then you would normally have the right to sell that
> particular copy without any further license (though possibly not to
> someone in a different part of the world).

Your license to distribute is provided by the license if and only if you
agree to the license. Otherwise, it's as if the license doesn't exist. You
can get the right to distribute the work any other way that may be available
to you. First sale is just one example.

DS

Re: GPL only modules

[Giacomo A. Catenazzi]

Linus Torvalds wrote:
> 
> On Mon, 18 Dec 2006, Alexandre Oliva wrote:
>>> In other words, in the GPL, "Program" does NOT mean "binary". Never has.
>> Agreed.  So what?  How does this relate with the point above?
>>
>> The binary is a Program, as much as the sources are a Program.  Both
>> forms are subject to copyright law and to the license, in spite of
>> http://www.fsfla.org/?q=en/node/128#1
> 
> Here's how it relates:
>  - if a program is not a "derived work" of the C library, then it's not 
>    "the program" as defined by the GPLv2 AT ALL.
> 
> In other words, it doesn't matter ONE WHIT whether you use "ld --static" 
> or "ld" or "mkisofs" - if the program isn't (by copyright law) derived 
> from glibc, then EVEN IF glibc was under the GPLv2, it would IN NO WAY 
> AFFECT THE RESULTING BINARY.

I really don't agree.  It seems you confuse source and binary application.

The source surelly is not derived, you can link *any* libc to your
program.

But a binary is different.

Let start with your example about books: you write a book, you have
the copyright of the text, but if you publish it with X publiher, he
may use a own font.  You can read the book, scan it to extract text
(I hope fair use allows it), but not copy the book pages: there is
your text, but also copyrighted font.  Publisher should check
that the two license are compatible, as the user that links
with a new library.

For binary, it is the same. You can extract libraries and rest of
programs (better doing with sources), but until it is one binary,
it is a new mixed entity.

It is not only linking, it is mixing bytes! Some part of library is
linked statically, there are some references in the static part of
program. It is a mix and until the two part are mixed (not only linked)
you should follow both licenses for copying!

Choose any dynamic program in your machine, try to link glibc with an
other (not directly derived libc) library... you see how it is hard,
and it is very different to an "aggregation".  And dynamic links is
only the latest step of "merging" the two binaries.

Other libraries tend to be more "dynamic", but glibc mixes to much

In other word, source A, library B: the binary C is derived both from A
and B, but surelly A is not derived by B.  So IMHO IANAL, in arguments
we should not confuse the sources and the binary in the arguments, so
not calling simply "the program".


ciao
	cate


> 
> And I'm simply claiming that a binary doesn't become "derived from" by any 
> action of linking.
> 
> Even if you link using "ld", even if it's static, the binary is not 
> "derived from". It's an aggregate.
> 
> "Derivation" has nothing to do with "linking". Either it's derived or it 
> is not, and "linking" simply doesn't matter. It doesn't matter whether 
> it's static or dynamic. That's a detail that simply doesn't have anythign 
> at all to do with "derivative work".
> 
> THAT is my point. 
> 
> Static vs dynamic matters for whether it's an AGGREGATE work. Clearly, 
> static linking aggregates the library with the other program in the same 
> binary. There's no question about that. And that _does_ have meaning from 
> a copyright law angle, since if you don't have permission to ship 
> aggregate works under the license, then you can't ship said binary. It's 
> just a non-issue in the specific case of the GPLv2.
> 
> In the presense of dynamic linking the binary isn't even an aggregate 
> work.
> 
> THAT is the difference between static and dynamic. A simple command line 
> flag to the linker shouldn't really reasonably be considered to change 
> "derivation" status.
> 
> Either something is derived, or it's not. If it's derived, "ld", 
> "mkisofs", "putting them close together" or "shipping them on totally 
> separate CD's" doesn't matter. It's still derived.
> 
> 		Linus

Re: GPL only modules

[Giacomo A. Catenazzi]

Linus Torvalds wrote:
> 
> On Mon, 18 Dec 2006, Alexandre Oliva wrote:
>>> In other words, in the GPL, "Program" does NOT mean "binary". Never has.
>> Agreed.  So what?  How does this relate with the point above?
>>
>> The binary is a Program, as much as the sources are a Program.  Both
>> forms are subject to copyright law and to the license, in spite of
>> http://www.fsfla.org/?q=en/node/128#1
> 
> Here's how it relates:
>  - if a program is not a "derived work" of the C library, then it's not 
>    "the program" as defined by the GPLv2 AT ALL.
> 
> In other words, it doesn't matter ONE WHIT whether you use "ld --static" 
> or "ld" or "mkisofs" - if the program isn't (by copyright law) derived 
> from glibc, then EVEN IF glibc was under the GPLv2, it would IN NO WAY 
> AFFECT THE RESULTING BINARY.

I really don't agree.  It seems you confuse source and binary application.

The source surelly is not derived, you can link *any* libc to your
program.

But a binary is different.

Let start with your example about books: you write a book, you have
the copyright of the text, but if you publish it with X publiher, he
may use a own font.  You can read the book, scan it to extract text
(I hope fair use allows it), but not copy the book pages: there is
your text, but also copyrighted font.  Publisher should check
that the two license are compatible, as the user that links
with a new library.

For binary, it is the same. You can extract libraries and rest of
programs (better doing with sources), but until it is one binary,
it is a new mixed entity.

It is not only linking, it is mixing bytes! Some part of library is
linked statically, there are some references in the static part of
program. It is a mix and until the two part are mixed (not only linked)
you should follow both licenses for copying!

Choose any dynamic program in your machine, try to link glibc with an
other (not directly derived libc) library... you see how it is hard,
and it is very different to an "aggregation".  And dynamic links is
only the latest step of "merging" the two binaries.

Other libraries tend to be more "dynamic", but glibc mixes to much

In other word, source A, library B: the binary C is derived both from A
and B, but surelly A is not derived by B.  So IMHO IANAL, in arguments
we should not confuse the sources and the binary in the arguments, so
not calling simply "the program".


ciao
	cate


> 
> And I'm simply claiming that a binary doesn't become "derived from" by any 
> action of linking.
> 
> Even if you link using "ld", even if it's static, the binary is not 
> "derived from". It's an aggregate.
> 
> "Derivation" has nothing to do with "linking". Either it's derived or it 
> is not, and "linking" simply doesn't matter. It doesn't matter whether 
> it's static or dynamic. That's a detail that simply doesn't have anythign 
> at all to do with "derivative work".
> 
> THAT is my point. 
> 
> Static vs dynamic matters for whether it's an AGGREGATE work. Clearly, 
> static linking aggregates the library with the other program in the same 
> binary. There's no question about that. And that _does_ have meaning from 
> a copyright law angle, since if you don't have permission to ship 
> aggregate works under the license, then you can't ship said binary. It's 
> just a non-issue in the specific case of the GPLv2.
> 
> In the presense of dynamic linking the binary isn't even an aggregate 
> work.
> 
> THAT is the difference between static and dynamic. A simple command line 
> flag to the linker shouldn't really reasonably be considered to change 
> "derivation" status.
> 
> Either something is derived, or it's not. If it's derived, "ld", 
> "mkisofs", "putting them close together" or "shipping them on totally 
> separate CD's" doesn't matter. It's still derived.
> 
> 		Linus

Re: GPL only modules

[Sanjoy Mahajan]

Linus Torvalds wrote:
> That said, I think they are still pushing the "you don't have any
> rights unless we give you additional rights explicitly" angle a bit
> too hard.

>From section 2 (GPLv3, draft 2):

 This License acknowledges your rights of "fair use" or other
 equivalent, as provided by copyright law. 

By choosing 'acknowledges' as the verb, the licensee says explicitly
that fair-use rights are already yours, not that they are being given
to you.

-Sanjoy

`Never underestimate the evil of which men of power are capable.'
         --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.

Re: GPL only modules

[Horst H. von Brand]

Sanjoy Mahajan <sanjoy@mrao.cam.ac.uk> wrote:
> Linus Torvalds wrote:
> > That said, I think they are still pushing the "you don't have any
> > rights unless we give you additional rights explicitly" angle a bit
> > too hard.
> 
> From section 2 (GPLv3, draft 2):
> 
>  This License acknowledges your rights of "fair use" or other
>  equivalent, as provided by copyright law. 
> 
> By choosing 'acknowledges' as the verb, the licensee says explicitly
> that fair-use rights are already yours, not that they are being given
> to you.

Pure noise, a license can't take them away in any case.

[That is my pet pevee with GPL: It has a bit of legally binding text, and
 lots of "explanation" and "philosophy" that don't add anything but
 confusion. A clear-cut license plus an explanation/comment would have been
 better. IMHO, IANAL. HAND.]
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513

Re: GPL only modules

[Sanjoy Mahajan]

>> [GPL acknowledging fair-use rights]

> Pure noise, a license can't take them away in any case.

A bare license probably cannot take them away, since you haven't
agreed to anything.  But (1) that may not be true in all legal
systems, and (2) a contract-based license can take it away (e.g. an
NDA).  So the GPL's clarification is worthwhile.  For the same reason,
I'm guessing, the Creative Commons licenses have (also in section 2,
at least in v2.5):

   2. Fair Use Rights. Nothing in this license is intended to reduce,
   limit, or restrict any rights arising from fair use, first sale or
   other limitations on the exclusive rights of the copyright owner
   under copyright law or other applicable laws.

-Sanjoy

`Never underestimate the evil of which men of power are capable.'
         --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.

Re: GPL only modules

[Alexandre Oliva]

On Dec 19, 2006, "Horst H. von Brand" <vonbrand@inf.utfsm.cl> wrote:

> Sanjoy Mahajan <sanjoy@mrao.cam.ac.uk> wrote:

>> This License acknowledges your rights of "fair use" or other
>> equivalent, as provided by copyright law. 

>> By choosing 'acknowledges' as the verb, the licensee says explicitly
>> that fair-use rights are already yours, not that they are being given
>> to you.

> Pure noise, a license can't take them away in any case.

Yeah, that's merely informative, indeed.  Point is to ensure people
know their rights, while at the same time avoiding giving impressions
such the one Linus somehow got.

> [That is my pet pevee with GPL: It has a bit of legally binding text, and
>  lots of "explanation" and "philosophy" that don't add anything but
>  confusion. A clear-cut license plus an explanation/comment would have been
>  better. IMHO, IANAL. HAND.]

This bit would probably fit better in the spirit (preamble) than in
the letter.  That's why I filed the comment about it in the preamble.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}