similar to: Request to relicense hash gnulib module to LGPLv2+

On Tue, Nov 5, 2013 at 7:51 AM, Richard W.M. Jones <rjones@redhat.com> wrote: > On Wed, Aug 28, 2013 at 06:51:11PM +0100, Richard W.M. Jones wrote: >> libguestfs (an LGPLv2+ library) uses the 'hash' module, which turns >> out to be "GPL". >> >> Actually this happened because we started to use it in a separate >> GPL'd utility program,

On 08/28/2013 11:51 AM, Richard W.M. Jones wrote: > libguestfs (an LGPLv2+ library) uses the 'hash' module, which turns > out to be "GPL". > > Actually this happened because we started to use it in a separate > GPL'd utility program, but later on included this functionality in the > core library, copying the same code from the utility but not checking >

On Wed, Aug 28, 2013 at 06:51:11PM +0100, Richard W.M. Jones wrote: > libguestfs (an LGPLv2+ library) uses the 'hash' module, which turns > out to be "GPL". > > Actually this happened because we started to use it in a separate > GPL'd utility program, but later on included this functionality in the > core library, copying the same code from the utility but

This merely enforces (wrt gnulib) the existing convention that libguestfs is covered by LGPLv2+ . >From 99a8fab0fa0474b4ab3959a5bd5867779a1d08d6 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering at redhat.com> Date: Mon, 26 Oct 2009 16:01:06 +0100 Subject: [PATCH libguestfs] build: tell gnulib-tool that this is an lgplv2+ library * bootstrap: Invoke gnulib-tool with --lgpl=2. ---

Hi Andrey, 2016-01-23 4:02 GMT+01:00 Andrey Gursky <andrey.gursky at e-mail.ua>: ... > If they don't want to bother with just discussing, why would they take a > big effort to claim? And your proposition for LGPL is not very > different in opposite to BSD or public domain. Yes, I agree. The risk of having a future lawsuit against my project would be pretty small if I

gettime hash human memcpy openat-die openat-safer quote quotearg readlinkat save-cwd symlinkat timespec utimens xstrtol xstrtoll xstrtoumax xvasprintf I didnt track where they are uses, some of them arent used directly.

... > Getting the approval for a relicensing I think the contributions to > rsync have to be analyzed in detail to approach a reasonable number of > contributors. > > I experienced that finding a responsible person that is willing to > discuss such a case in an organization that contributed source code is > nearly impossible. > > Looking at the source code (my short

I haven't run CentOS on a machine of my own for several years; but my domain (NOT the address I post from) is hosted on a machine running CentOS. The list for the mailer I run recommends using aspell, which is not installed (according to rpm -q) on the remote host, as a spellchecker. Does anybody here know offhand if CentOS supports it? Or how do I check? -- Beartooth Staffwright, Not

Hi, I am maintaining a port of rsync (https://github.com/perlundq/yajsync) which is GPL:ed of course. The main purpose of the project is to provide a Java API library for the rsync protocol. It would therefore be really nice to be able to use LGPL as the license. But in order to do so I would first have to get a list of all the individual contributors to rsync and then be able to contact them

Hello, I would like to see Xapian used more widely in the PHP community. The major obstacle is that binaries of the PHP extension cannot be distributed. I've been reading earlier discussions on this and wonder if there's now an option. My starting points were https://trac.xapian.org/wiki/FAQ/PHP%20Bindings%20Package and the discussion at https://trac.xapian.org/ticket/191. One comment

Hi Everyone, I’d like to start a discussion about how to improve some important issues we have in the LLVM community, regarding our license and patent policy. Before we get started, I’d like to emphasize that *this is an RFC*, intended for discussion. There is no time pressure to do something fast here -- we want to do the right long-term thing for the community (though we also don’t want

Hi, The Perl module Search::Xapian's README file ends with these lines: ===================================================================== This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. ===================================================================== (http://cpansearch.perl.org/src/OLLY/Search-Xapian-1.2.4.0/README) But

On Fri, Nov 26, 2010 at 10:03:05AM -0800, Yandell, Henri wrote: > We?re looking into using Hivex and came across something odd. While > the license of hivex.c is LGPL 2.1, it appears to require the GPL > 3.0 licensed gnulib package for a few minor functions ( full_read, > full_write and c_toupper ). There are also a few GPL 3.0 build > files. It has always been our intention to

> On Nov 1, 2016, at 12:21 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, Sep 12, 2016 at 09:16:47AM -0700, Chris Lattner via llvm-dev wrote: >> The goals of this effort are outlined in the previous email but, in short, we aim to: >> - encourage ongoing contributions to LLVM by preserving low barrier to entry for contributors.

Our README file claims that license info is in LICENSE, but we did not have a file by that name in the tarball. At least we did correctly ship COPYING.LIB since the library is LGPLv2+. --- The LGPL requires that the user also receive a copy of the GPL, since anyone can upgrade their copy from LGPL to GPL. Does that mean we should ship a copy of COPYING alongside COPYING.LIB? README | 3 ++- 1

> It is my interest to see my code used. In particular I am really excited > to see llvm/clang/lld/lldb/etc replacing more and more of the previous > components on these systems. I really don't want to harm that change. > > If FreeBSD and OpenBSD are OK with license X, I am OK with license X. Rafael, It is my understanding that Apache 2.0 licensed code will not be integrated

> > > > > > > I guess I could write an initial protocol specification - but it would > > > not be complete and I wouldn't be able to relicense my library to > > > LGPL anyway. > > > > > > So I guess I have convinced myself that it is not worth the effort > > > trying. Time is probably better spent coding ;) And that's OK

On Aug 10, 2017, at 3:08 PM, Rafael Avila de Espindola via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Chris Lattner <clattner at llvm.org> writes: > >>> On Aug 10, 2017, at 2:59 PM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: >>> >>> I can find old threads about it, but nothing saying why it was decided >>> that

Hi Martin, 2016-01-23 18:41 GMT+01:00 Martin Pool <mbp at sourcefrog.net>: > It seems like yajsync is a reimplementation of rsync's protocol by looking > at the GPL'd C rsync source, but it doesn't actually include any code from > rsync. Is that right? Yes correct, it is a complete rewrite in Java. Most of it is completely different, only some small parts of the actual

Am 07.01.2016 um 23:26 schrieb Per Lundqvist: > Hi, > > I am maintaining a port of rsync (https://github.com/perlundq/yajsync) > which is GPL:ed of course. The main purpose of the project is to > provide a Java API library for the rsync protocol. It would > therefore be really nice to be able to use LGPL as the license. > > But in order to do so I would first have to get a