picviz license (generated images as derivative work ?)
Hi, Since a few versions, the picviz [1] license has changed for the following: ---8 Describes the terms under which Picviz is distributed. A copy of the GPL is appended after the specific Picviz license terms. * *** Specific Picviz license terms *** * BEGIN Picviz means: Picviz parsers, Picviz library (libpicviz), Picviz command line interface (CLI) and Picviz graphical user interface (GUI). Note that the GPL places important restrictions on derived works, yet it does not provide a detailed definition of that term. To avoid misunderstandings, we consider an application to constitute a derivative work for the purpose of this license if it does any of the following: o Integrates source code from Picviz o Integrates images generated by Picviz o Executes Picviz and parses the results (as opposed to typical shell or execution-menu apps, which simply display raw Picviz output and so are not derivative works.) o Integrates/includes/aggregates Picviz into a proprietary executable installer, such as those produced by InstallShield. o Links to a library or executes a program that does any of the above The term Picviz should be taken to also include any portions or derived works of Picviz. This list is not exclusive, but is meant to clarify our interpretation of derived works with some common examples. Our interpretation applies only to Picviz--we don't speak for other people's· GPL works. /END GNU GENERAL PUBLIC LICENSE Version 3, 29 June 2007 [... text of GPLv3 ...] ---8 Note: picviz is a parallel coordinates plotter which takes data (text) as input and creates an image (png, jpeg, etc.). As the maintainer of the picviz Debian package, my question is the following: Are the clarifications added to the license, and especially the fact that generated images by picviz, considered to be additional restrictions, and do they cause problems with respect to the DFSG ? Thanks, Pierre [1] http://www.picviz.com -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120225144540.ga6...@mail.wzdftpd.net
Re: picviz license (generated images as derivative work ?)
Note that the GPL places important restrictions on derived works, yet it does not provide a detailed definition of that term. It's so on purpose: it's copyright law that says what is a derived work. Authors can't extend the reach of their rights at will. At least when they don't sell devices that implement effective technological means /alessandro, not a lawyer, not a DD -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120225151844.ga22...@mail.gnudd.com
windows video capture card driver source contains LGPLv2 header file - can I port?
Hi all, I am writing because I have a video capture card based on the MV9200 chip, which currently does not have a Linux driver, and I would like to remedy that situation. I'll bet you can guess how responsive the company behind the MV9200 has been when asked for Linux drivers or hardware documentation. I googled for a Windows driver, and the archive I found contained the binary Windows driver AND its source code! I couldn't believe my luck. Now I'm not sure how to proceed because I'm not sure of the copyright status of the code, and I don't know if that even matters. I grepped through the source code for 'copyright' and found three instances: 1. The .rc file for the accompanying windows application (as distinct from the driver) contains a Copyright (C) 2007 string. 2. The .inf file for the driver contains a Copyright (c) 1991-2004 VastVision Corporation string. 3. The header file Command.h in the driver source code contains a Copyright (C) 2000 - 2002 by Eduardo Jos?Tagle string. The final one intrigued me. The beginning of that file contains the following comment: /* Command.hpp: Part of the WDM Video Capture Driver for Bt848 based video capture cards Copyright (C) 2000 - 2002 by Eduardo Jos?Tagle. This library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more details. You should have received a copy of the GNU Library General Public License along with this library; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ What are my options for creating a Linux driver for this hardware? Thank you, Eric Anopolsky -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPQXdDT23=e0lnmmmqo752fqhptpnbkirn3izk9fzoy1c8e...@mail.gmail.com
Re: windows video capture card driver source contains LGPLv2 header file - can I port?
On Feb 25, 2012, at 10:46 AM, erp...@gmail.com wrote: What are my options for creating a Linux driver for this hardware? What you've reported doesn't really provide enough information for us to opine (even with 'non-legal advice' opinions). You say the Windows application is distinct from the driver, but is that distinction maintained in the copyright notices? Etc. The Command.h file -- was it built/provided by the driver manufacturer, or did the author of the Windows driver/software use LGPL code? Etc. But it may not matter. Recall that (at least in the U.S., where arguably the biggest threat of litigation exists), copyright does not extend to functional elements; Lotus v. Borland, 516 U.S. 233 (1996). To the extent code is required to interoperate with the hardware, you can reuse/derive from it safely. (You might also want to familiarize yourself with the Abstraction / Filtration / Comparison test from Computer Associates v. Altai 982 F.2d 693 (6th Cir. 2003): http://en.wikipedia.org/wiki/Abstraction-Filtration-Comparison_test ). In short, I personally would not take a clean-room approach to that code. I'd look at it, learn from it, and write my own Linux driver, personally. Anything specific to the hardware I'd copy more or less verbatim. Anything else, if there's really only the one way of doing it, it's not copyright protected; if there's more than one way, I'd be creative. :) This is not legal advice; if you want that, contact me directly (and pay me =)).
Re: windows video capture card driver source contains LGPLv2 header file - can I port?
On Sat, Feb 25, 2012 at 12:52 PM, Chris Harshman r...@packetlaw.com wrote: On Feb 25, 2012, at 10:46 AM, erp...@gmail.com wrote: What are my options for creating a Linux driver for this hardware? What you've reported doesn't really provide enough information for us to opine (even with 'non-legal advice' opinions). You say the Windows application is distinct from the driver, but is that distinction maintained in the copyright notices? Etc. By distinct, I mean that there are three separate components inside the archive I downloaded. There is a Drv directory that contains the .h and .cpp files necessary to build a WDM device driver that is loaded into the Windows kernel. The only copyright notice found inside this set of files is the LGPLv2 notice in Command.h. The file that contains most of the code, main.cpp, does not have a copyright notice. Additionally, there are some (Chinese?) comments I can't read. There is also an App directory containing a Microsoft Visual C++ project that builds an exe file that runs in userspace. I haven't run it yet, but I think it talks to the device driver to extract frames from the video capture card and perhaps display or save them. None of the files that are used to build this executable have any type of copyright notice except for a resource script (.rc file). It does not identify the copyright holder or the license under which it is distributed--only that the copyright date is 2007. Finally, there is a Bin directory, containing the compiled driver and the compiled userspace executable. In the same directory there is an inf file used to install the driver in Windows. It contains the notice: Copyright (c) 1991-2004 VastVision Corporation. Those are all of the copyright notices. Is that useful information? The Command.h file -- was it built/provided by the driver manufacturer, or did the author of the Windows driver/software use LGPL code? Etc. I believe the Command.h file was originally written for the Windows bt878 capture card driver, released under the LGPLv2 and then it was borrowed for use in this driver. I suspect that the binary .sys WDM kernel driver provided in the Bin directory was compiled using this header by the driver manufacturer. But it may not matter. Recall that (at least in the U.S., where arguably the biggest threat of litigation exists), copyright does not extend to functional elements; Lotus v. Borland, 516 U.S. 233 (1996). To the extent code is required to interoperate with the hardware, you can reuse/derive from it safely. (You might also want to familiarize yourself with the Abstraction / Filtration / Comparison test from Computer Associates v. Altai 982 F.2d 693 (6th Cir. 2003): http://en.wikipedia.org/wiki/Abstraction-Filtration-Comparison_test ). In short, I personally would not take a clean-room approach to that code. I'd look at it, learn from it, and write my own Linux driver, personally. Anything specific to the hardware I'd copy more or less verbatim. Anything else, if there's really only the one way of doing it, it's not copyright protected; if there's more than one way, I'd be creative. :) I like this answer. :) This is not legal advice; if you want that, contact me directly (and pay me =)). I really appreciate the portion of your Saturday that you put into this free response to my question, but I don't think I need actual legal advice right now. Based on my interactions with the company that made the chip, I seriously doubt they would care even if I copied and pasted all of their code into a Linux driver. They just don't seem to care. I'm more concerned about what the Linux kernel maintainers will think and whether or not they will reject any driver I write for copyright reasons. Thanks, Eric -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capqxddrqe3hn-61dguxygp6-uwojb8pbsvtfdxpkdrqppeq...@mail.gmail.com
Re: picviz license (generated images as derivative work ?)
On Sat, 25 Feb 2012 15:45:40 +0100 Pierre Chifflier wrote:
Hi,
Hi!
[...]
*
*** Specific Picviz license terms ***
*
[...]
Note that the GPL places important restrictions on derived works, yet
it does not provide a detailed definition of that term.
Well, actually, the GNU GPL v3 does never talk about derivative
works: it talks about works based on other works...
But anyway...
To avoid
misunderstandings, we consider an application to constitute a
derivative work for the purpose of this license if it does any of the
following:
o Integrates source code from Picviz
o Integrates images generated by Picviz
Anything that incorporates any output of Picviz is considered as a
derivative work of Picviz ?!?
I am not a lawyer, but, as far as I can tell, this is inconsistent with
the actual definition of the concept of derivative work, as found in
existing copyright laws in various jurisdictions, *unless* the output
of Picviz includes substantial portions of Picviz itself.
o Executes Picviz and parses the results (as opposed to typical shell or
execution-menu apps, which simply display raw Picviz output and so are
not derivative works.)
According to this interpretation any script that does something like
VERS=`env LC_ALL=C apt-cache policy $PACKAGE | awk '/Installed/ { print $2;
}'`
should be considered as a derivative work of apt-cache?!?
Again, I am not a lawyer, but this seems to be a bit overreaching...
o Integrates/includes/aggregates Picviz into a proprietary executable
installer, such as those produced by InstallShield.
o Links to a library or executes a program that does any of the above
[...]
As the maintainer of the picviz Debian package, my question is the
following:
Are the clarifications added to the license, and especially the fact
that generated images by picviz, considered to be additional
restrictions, and do they cause problems with respect to the DFSG ?
I am under the impression that those clarifications are a bit
overreaching and thus constitute further restrictions with respect to
the GNU GPL v3.
They could cause problems with respect to DFSG #9, at least.
However, please note that the GNU GPL v3 has a clause that states that
any further restriction may be removed (see Section 7):
[...]
| All other non-permissive additional terms are considered further
| restrictions within the meaning of section 10. If the Program as you
| received it, or any part of it, contains a notice stating that it is
| governed by this License along with a term that is a further
| restriction, you may remove that term.
[...]
I think you should try to persuade upstream to drop the above-quoted
clarifications and adopt the GNU GPL, without any further restriction
or attempt to change definitions found relevant laws.
I hope this helps a bit.
Bye and thanks for taking this issue seriously.
--
http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
New GnuPG key, see the transition document!
. Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpNgd3KcU0uJ.pgp
Description: PGP signature
Re: windows video capture card driver source contains LGPLv2 header file - can I port?
On Sun, Feb 26, 2012 at 6:43 AM, erp...@gmail.com wrote: I'm more concerned about what the Linux kernel maintainers will think and whether or not they will reject any driver I write for copyright reasons. I would suggest that a cleanroom implementation would be the way to go if you care about mainlining the driver. As it is, the origin, copyright and license of the code is unclear at best. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6GXV=BbgT4wa_ZdkeEiAwe7HSBgmkY=t1w0agatx96...@mail.gmail.com
Re: windows video capture card driver source contains LGPLv2 header file - can I port?
On Feb 25, 2012, at 5:14 PM, Paul Wise wrote: I would suggest that a cleanroom implementation would be the way to go if you care about mainlining the driver. Out of curiosity - why? (Especially given the driver may never get ported with the cleanroom approach.) No license / copyright is needed for functional elements... -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/80f86089-e659-4e9f-9e24-f5bd9195e...@packetlaw.com
