Hi everybody,
>Over two years ago, the Linux USB developers stated that they believed
>there was no way to create a USB kernel driver that was not under the
>GPL. This patch moves the USB apis to enforce that decision.
>There are no known closed source USB drivers in the wild, so this patch
>should cause no problems.
hm, I'm not sure, but will your patch make Samsung's Unified Linux
Driver for printing & scanning stop working?
http://org.downloadcenter.samsung.com/downloadfile/ContentsFile.aspx?CDSite=DE&CttFileID=801111&CDCttType=DR&ModelType=N&ModelName=SCX-4521F&VPath=DR/200707/20070720165133984_UnifiedLinuxDriver.tar.gz
another Manufacturer / Candidate I'm worrying about is Brother:
http://solutions.brother.com/linux/en_us/index.html
Brother is providing opensource cups drivers (kudos to the developers
@ Brother for that!), the sane-drivers however seem to be closed
source, will those work ?
I'm no developer, just a heavy user ;) so unfortunately I can't tell
whether those drivers are dependent on being NOT GPL,
if your patch will find its inclusion into Linus' mainline-tree,
there's still the possibility to revert that patch, right ? (freedom
of doing with the code what I need to)
Many thanks in advance & thanks a lot for your work :)
Mat
On Mon, Feb 04, 2008 at 12:43:11PM +0100, Matthew wrote:
> Hi everybody,
>
> >Over two years ago, the Linux USB developers stated that they believed
> >there was no way to create a USB kernel driver that was not under the
> >GPL. This patch moves the USB apis to enforce that decision.
>
> >There are no known closed source USB drivers in the wild, so this patch
> >should cause no problems.
>
> hm, I'm not sure, but will your patch make Samsung's Unified Linux
> Driver for printing & scanning stop working?
> http://org.downloadcenter.samsung.com/downloadfile/ContentsFile.aspx?CDSite=DE&CttFileID=801111&CDCttType=DR&ModelType=N&ModelName=SCX-4521F&VPath=DR/200707/20070720165133984_UnifiedLinuxDriver.tar.gz
No, in looking at that package, I do not see any kernel modules, just
userspace programs. They must be using the usbfs interface to the
kernel from userspace, a perfict example of how a vendor can control USB
device from userspace, without needing a kernel driver :)
So it should continue to work just fine.
> another Manufacturer / Candidate I'm worrying about is Brother:
> http://solutions.brother.com/linux/en_us/index.html
> Brother is providing opensource cups drivers (kudos to the developers
> @ Brother for that!), the sane-drivers however seem to be closed
> source, will those work ?
Both sane and cups are userspace programs, using usbfs and the kernel
usblp driver respectively, and should not see anything change at all.
> I'm no developer, just a heavy user ;) so unfortunately I can't tell
> whether those drivers are dependent on being NOT GPL,
You would be seeing some warnings in the kernel log for the past 2 years
when using these products, about how the symbols were going to be
changed in the future. If not, you are fine.
thanks,
greg k-h
----- Original Message -----
From: "Jan Engelhardt" <[email protected]>
To: "Gilles Espinasse" <[email protected]>
Cc: <[email protected]>; <[email protected]>
Sent: Wednesday, February 06, 2008 10:14 PM
Subject: RE: [PATCH] USB: mark USB drivers as being GPL only
>
> On Feb 1 2008 15:45, Gilles Espinasse wrote:
> >..
...
> >
> >There is the unicorn usb adsl modem driver (STM unicorn chip).
> >http://www.bewan.com/bewan/drivers/A1012-A1006-A904-A888-A983-0.9.3.tgz
> >There is some sources and a binary blob to be linked.
> >
> >The only things I know from the binary blob is that sources should be 150
000
> >lines of C++.
>
> It's 63 C++ files actually (wow, that even beats the blob-iness of
nvidia!)
> and a few files look rather empty. Their source would rather benefit
> from getting a review on LKML.
>
Just for curiosity, how could you know the number of sources files without
the sources of the blob?
Or you have them...?
Gilles
On Fri, Feb 08, 2008 at 12:51:22AM +0200, Hannu Savolainen wrote:
> Alan Cox kirjoitti:
>>> doesn't mean it's derived from Linux. In the case of user-space code
>>> it's widely understood that no licence restrictions are conferred. The
>>>
>>
>> Actually that is also questionable. The only reason it is fairly certain
>> in Linux is Linus went to the trouble of stating that interpretation was
>> intended in the COPYING file and saying he sees it that way.
>>
>>
>>> No. Holders of Linux copyrights would have to prove that the
>>> proprietary code is derived from the kernel. They have the burden of
>>> proof, and defence needs merely show that their arguments are wrong.
>>>
>>
>> Wrong again. In civil law in the USA and most of europe the test is
>> "balance of probability".
>>
> What is the "propability" that drivers using the interfaces now declared as
> "EXPORT_SYMBOL_GPL" are derived from the Linux kernel source code instead
> of some definitive documentation?
>
> As you all (should) know there is a book called "Linux Device Drivers, 3rd
> Edition" published by O'Reilly (ISBN 0-596-00590-3)". All the USB kernel
> interfaces are documented there. One of the authors is Greg Kroah-Hartman
> which makes this book "definite" source of information on Linux USB driver
> programming. I assume Greg is the author of the USB related sections.
Yes, I wrote that, and if you look at that chapter, it states it is
based on the GPL licensed documentation that comes from the kernel
itself, which was written by a lot of other people as well.
> The "legal" question is what is that which one is license the one that
> applies? Is it the licecense of the kernel (GPL) or is it the license of
> the documentation (no restrictions on usage)?
There is no such license on that documentation.
> The "moral" question is that why did Greg author a book that declares these
> USB interfaces as "free to use" and soon after that made a decision that
> they are no longer "free to use"?
Where did I ever declare these interfaces as "free to use in violation
of the GPL" anywhere? If you look at the examples that I wrote for that
book, they are all licensed under the GPLv2 only.
Same goes for the Windows Driver book. You can use the Windows driver
development kit and API, as long as you follow their license. And that
license explicitly forbids using it in code that is under an open source
license. Is describing those interfaces in a book somehow also
"immoral"?
geesh, this thread is just insane, time to just ignore it...
greg k-h