On Mon, 22 Mar 2004 01:29:34 +0100, Pavel Machek <[email protected]> wrote:
>
> +/*
> + * Copyright (c) 2000-2002 Marc Alexander Lehmann <[email protected]>
> + *
> + * Redistribution and use in source and binary forms, with or without modifica-
> + * tion, are permitted provided that the following conditions are met:
> + *
> + * 1. Redistributions of source code must retain the above copyright notice,
> + * this list of conditions and the following disclaimer.
> + *
> + * 2. Redistributions in binary form must reproduce the above copyright
> + * notice, this list of conditions and the following disclaimer in the
> + * documentation and/or other materials provided with the distribution.
> + *
> + * 3. The name of the author may not be used to endorse or promote products
> + * derived from this software without specific prior written permission.
>
> lzf compression should go under /lib, not under kernel/power, and
> probably should go in separately.
>
> This looks like BSD with advertising clause. I do not think you are
> allowed to link this with kernel. It does not follow kernel coding style.
Hello Marc,
As you will be aware, everone using swsusp2 loves to use your LZF functionality
which yields effective suspend/resume transfer rates of well above 100MB/s.
With inclusion of swsusp2 into kernel mainline drawing nearer, one _major_
issue was raised, which is the BSD license you released LZF under.
As said, BSD-only licensed code is _invalid_ to be linked with kernel code,
therefor swsusp2 will have to drop LZF alltogether unless you relicense it.
Would you please consider to relicense under GPL2, or GPL2 + BSD.
Intel does something like GPL2 + BSD this with ACPI btw. Please have a look
at their license.
This means in practice that GPL2 allows inclusion into the kernel, which
being opensource credits you, and other proprietary apps using the BSD
license will credit you in their documentation.
Also, as Pavel mentioned, LZF code should be put in /lib and cleaned up. This
is a chance to get LZF into the kernel and it would be much appreciated if you
please would take care of this. Thank you!
Regards
Michael
Hi all,
Michael Frank wrote:
| >+ * 3. The name of the author may not be used to endorse or promote products
| >+ * derived from this software without specific prior written permission.
[...]
| >This looks like BSD with advertising clause. I do not think you are
| >allowed to link this with kernel. It does not follow kernel coding style.
[...]
| As said, BSD-only licensed code is _invalid_ to be linked with kernel code,
| therefor swsusp2 will have to drop LZF alltogether unless you relicense it.
The licence above looks like BSD /without/ advertising clause, which
is GPL compatible. Note that the (GPL-incompatible) advertising
clause is the one that says "mention me in your advertising materials"
whereas the above licence only requires mention in accompanying
documentation and says /not/ to use the name of the author to promote
derived works.
See also http://www.gnu.org/philosophy/license-list.html, under "The
modified BSD license":
This is the original BSD license, modified by removal of the
advertising clause. It is a simple, permissive non-copyleft free
software license, compatible with the GNU GPL.
The licence so described looks to me the same as LZF's licence.
Cheers,
Cameron.
On Mon, 2004-03-22 at 10:40, Cameron Patrick wrote:
> The licence so described looks to me the same as LZF's licence.
however at least I would prefer the author to dual license it ANYWAY,
because compression stuff generally is riddled with patents; the author
GPL licensing it at least gives all users a license of the authors
patents (if any).
On Mon, 22 Mar 2004 10:49:48 +0100, Arjan van de Ven <[email protected]> wrote:
> On Mon, 2004-03-22 at 10:40, Cameron Patrick wrote:
>
>> The licence so described looks to me the same as LZF's licence.
>
> however at least I would prefer the author to dual license it ANYWAY,
> because compression stuff generally is riddled with patents; the author
> GPL licensing it at least gives all users a license of the authors
> patents (if any).
>
Right, for kernel side the BSD license is too "simplistic".
I like to see a ACPI style license.
Regards
Michael
Hi!
> | >+ * 3. The name of the author may not be used to endorse or promote products
> | >+ * derived from this software without specific prior written permission.
> [...]
> | >This looks like BSD with advertising clause. I do not think you are
> | >allowed to link this with kernel. It does not follow kernel coding style.
> [...]
> | As said, BSD-only licensed code is _invalid_ to be linked with kernel code,
> | therefor swsusp2 will have to drop LZF alltogether unless you relicense it.
>
> The licence above looks like BSD /without/ advertising clause, which
> is GPL compatible. Note that the (GPL-incompatible) advertising
Yes, I was wrong. It indeed looks like BSD _without_
advertising.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
On Mon, Mar 22, 2004 at 10:49:48AM +0100, Arjan van de Ven <[email protected]> wrote:
> > The licence so described looks to me the same as LZF's licence.
>
> however at least I would prefer the author to dual license it ANYWAY,
> because compression stuff generally is riddled with patents; the author
> GPL licensing it at least gives all users a license of the authors
> patents (if any).
I would like to avoid dual-licensing and instead change the existing
license to suit any needs, if at all possible. (Note that relicensing
should be possible, at least this was my original goal).
If patents are an issue, how about adding this:
4. The author is unaware of any existing patents and disclaims any
patents, or other restrictions, on the LZF algorithm or this
implementation.
I would add this clause to both future lzf distributions as well as the
file that is part of the lzf patch.
If there are unavoidable reasons why the GPL is required, then I'd bite
the bullet and dual-license it, in the hope that further bugfixes or
modifications will be contributed under both licenses.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [email protected] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
On Mon, Mar 22, 2004 at 07:21:21PM +0100, Marc Lehmann wrote:
> If there are unavoidable reasons why the GPL is required, then I'd bite
> the bullet and dual-license it, in the hope that further bugfixes or
> modifications will be contributed under both licenses.
dual licensing is a LOT easier. Really; esp since it becomes GPL anyway sort
of when it's distributed as part of the kernel..
About bugfixes; I'd recommend using something like:
Alternatively, the contents of this file may be used under the
terms of the GNU General Public License version 2 (the "GPL"), in which
case the provisions of the GPL are applicable instead of the
above. If you wish to allow the use of your version of this file
only under the terms of the GPL and not to allow others to use
your version of this file under the BSD license, indicate your decision
by deleting the provisions above and replace them with the notice
and other provisions required by the GPL. If you do not delete
the provisions above, a recipient may use your version of this
file under either the BSD or the GPL.
like the pcmcia code does; eg you say "if you send me stuff I assume it's
dual licensed too unless you indicate otherwise".
Hi.
I'm not sure what the verdict is in the end. Do we need changes to the
license? If so, could you send me a patch, Marc?
Regards,
Nigel
On Tue, 2004-03-23 at 06:21, Marc Lehmann wrote:
> On Mon, Mar 22, 2004 at 10:49:48AM +0100, Arjan van de Ven <[email protected]> wrote:
> > > The licence so described looks to me the same as LZF's licence.
> >
> > however at least I would prefer the author to dual license it ANYWAY,
> > because compression stuff generally is riddled with patents; the author
> > GPL licensing it at least gives all users a license of the authors
> > patents (if any).
>
> I would like to avoid dual-licensing and instead change the existing
> license to suit any needs, if at all possible. (Note that relicensing
> should be possible, at least this was my original goal).
>
> If patents are an issue, how about adding this:
>
> 4. The author is unaware of any existing patents and disclaims any
> patents, or other restrictions, on the LZF algorithm or this
> implementation.
>
> I would add this clause to both future lzf distributions as well as the
> file that is part of the lzf patch.
>
> If there are unavoidable reasons why the GPL is required, then I'd bite
> the bullet and dual-license it, in the hope that further bugfixes or
> modifications will be contributed under both licenses.
--
Nigel Cunningham
C/- Westminster Presbyterian Church Belconnen
61 Templeton Street, Cook, ACT 2614.
+61 (2) 6251 7727(wk); +61 (2) 6253 0250 (home)
Evolution (n): A hypothetical process whereby infinitely improbable events occur
with alarming frequency, order arises from chaos, and no one is given credit.
On Tue, Mar 23, 2004 at 12:47:26PM +0100, Arjan van de Ven <[email protected]> wrote:
> About bugfixes; I'd recommend using something like:
That sounds reasonable. Sorry for the delay, but I didn't receive your
mail earlier (not being on the cc:).
I have added this notice to all core files of the distribution and
released it as 1.3, assuming that this solves all the problems. It can
temporarily be found here: http://data.plan9.de/liblzf-1.3.tar.gz
The files in the kernel diverge a tiny bit (being a slight subset), and I
think it's easiest to just add the additional notice to the files:
kernel/power/lzf/lzf_c.c
kernel/power/lzf/lzf_d.c
The following should be applied to both files:
diff -u -p
@@ -24,6 +24,16 @@
* WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTH-
* ERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
* OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * Alternatively, the contents of this file may be used under the terms of
+ * the GNU General Public License version 2 (the "GPL"), in which case the
+ * provisions of the GPL are applicable instead of the above. If you wish to
+ * allow the use of your version of this file only under the terms of the
+ * GPL and not to allow others to use your version of this file under the
+ * BSD license, indicate your decision by deleting the provisions above and
+ * replace them with the notice and other provisions required by the GPL. If
+ * you do not delete the provisions above, a recipient may use your version
+ * of this file under either the BSD or the GPL.
*/
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [email protected] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
On Mon, Mar 22, 2004 at 05:18:57PM +0800, Michael Frank <[email protected]> wrote:
> Also, as Pavel mentioned, LZF code should be put in /lib and cleaned up.
I fully agree. Unfortunately, I have about zero time for any such project
in the foreseeable future (It'd need more time since my knowledge about
integration issues is extremely scarce, and I am swamped with other work).
The code in the kernel required a few features not available with earlier
lzf releases (e.g. passing the the hash table via args instead of
allocating it on the stack).
The standard 1.3 release is configurable via defines in this respect
(-DAVOID_ERRNO -DLZF_STATE_ARG), and would be better suited for inclusion
in the kernel (the code would be byte-identical in the userspace and
kernel version), but making a patch would require some testing, to make
sure the new code compiles etc.
Also, as used in software-suspend2, the user must #define symbols (see
the beginning of kernel/power/lzfcompress.c) and include the c files
directly. When making them library functions one would need to choose
a reasonable default. Copying lzfP.h into include/linux and editing it
should be enough, though.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [email protected] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|