similar to: LGPL relicense port of rsync

... > 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

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

Hi, from my point of view: On Sat, 9 Jan 2016 14:48:09 +0100 Per Lundqvist <perlundq at gmail.com> wrote: > ... > > 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 >

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

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

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 the license of 'hash'. We'd therefore like to request that

> > > > > > > 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

Hi, I realise that the GPL license question has been discussed in 2003 and in 2007, extensively. Back then, the conclusion seem to have been that in-process usage is not possible for most use-cases and that instead, a network layer/IPC mechanism is required to use Xapian with any non-GPL software. I think the project is severely undermining its own potential success. I see that there are even

Found this code: ftp://ftp.samba.org/pub/unpacked/ntdb/lib/ccan/ilog/ilog.c Tests show that it's faster to use the following code in FLAC__bitmath_ilog2_wide(): static const unsigned char DEBRUIJN_IDX32[32]={ 0, 1,28, 2,29,14,24, 3,30,22,20,15,25,17, 4, 8, 31,27,13,23,21,19,16, 7,26,12,18, 6,11, 5,10, 9 }; FLAC__uint32 v; int m;

> 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 contributor agreement wouldn't work. Care to send the URL? Here are some quick points that come to mind: 1. It raises the bar to contribution, because something must be “signed” before a

> 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

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

This has already been discussed extensively in the public. The threads are available in the archives. -Chris > On Aug 10, 2017, at 1:05 PM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > > Sorry, but I really don't think a private conversation is appropriate > for such discussions. > > If the motive cannot be explained in public I have no choice

Hi all, Now that we’ve settled on the license legalese to get to, we need to start the process of relicensing. We’re still sorting through all of the details of what this will take, but the first step is clear: new contributions to LLVM will need to be under both the old license structure and the new one (until the old structure is completely phased out). From a mechanical perspective, this is

I manage the audio-video section of the GNU web site http://audio-video.gnu.org/. I have tried the Theora codec and am very impressed by the level of integration with free desktops and the bit rate/quality combinations. I intend to move all video content to the Theora codec partly for technical reasons but mainly to promote free and open formats. I do have longer term worries, projecting

Hi Rafael, We’ve discussed why a license change is preferable over the span of several years now. I’m happy to explain over the phone, contact me off list and we can talk. -Chris > On Aug 10, 2017, at 8:33 AM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > > Hi, > > I still don't see any justification in the text why a license change is >

Bcc'd to everyone who have sent me patches to dovecot-auth or related code. Once in a while people ask me if Dovecot's authentication server code could be relicensed to BSD so they could use it for their project. Usually they have been other BSD-licensed open source projects which just prefer not to use LGPL code. Now there's again this company asking me to give them a bit less

Hi, I'm confused about my licensing obligation with respect to the Xapian SWIG bindings. I've got a python wrapper that sits above the standard Xapian Python/SWIG bindings, and I wasn't sure if the *intent* of the Xapian team is that my python wrapper - and any code that also uses my wrapper also falls under GPLv2. It seems unclear if the FSF's position on dynamic linking in

I can't understand what version of the LGPL you are using for the Wine source code. > Wine is free software. The licensing terms are the GNU Lesser General Public License. There are 2 links in your main page: the first links to the official LGPL v3 page http://www.gnu.org/copyleft/lesser.html the second links to a page of the WineHQ site, showing the LGPL v2.1

Hello, I am new to Cortado and I am very interested in playing video in some of my Java applets using the Theora decoder. I would like to write a LGPL library to use the decoders in Processing (see processing.org). I prefer LGPL over GPL because it allows a wider usage of the library. The core libraries of Processing are released under LGPL as well. I would like to use com.fluendo.plugin and