search for: relicensed

...mission for the relicensing, please let us know right away. The current status is that if you configure git master with --disable-gpl-libxapian then you'll get a build with some features disabled which only contains code that we should be able to relicense (NB the code hasn't actually been relicensed yet). This option currently disables the following: * glass backend * inmemory backend * remote backend * replication The only backend you get is the new "honey" backend which currently only supports reading. To create a honey database, you currently need to use a full build of xapian...

...ctually 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 'hash' is relicensed as LGPLv2+. If this is not possible, we will have to rewrite the code, probably implementing our own hash table, which would be a shame because hash works well for our needs. Notes: - the code doesn't appear to call exit (it does call abort), and so seems to be suitable for a library - has...

> 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

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

...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 'hash' is relicensed as LGPLv2+. >> If this is not possible, we will have to rewrite the code, probably >> implementing our own hash table, which would be a shame because hash >> works well for our needs. >> >> Notes: >> >> - the code doesn't appear to call exit (it does ca...

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

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

Seeing how http://flac.sourceforge.net/license.html stresses that libflac and libflac++ are licensed under the New BSD License, would it be possible to relicense include/share/alloc.h from GPL 2.1+ to the New BSD License so that all of libflac and libflac++ become licensed under the New BSD License as intended? Best Regards Magnus Blomfelt

...ause 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 'hash' is relicensed as LGPLv2+. > If this is not possible, we will have to rewrite the code, probably > implementing our own hash table, which would be a shame because hash > works well for our needs. > > Notes: > > - the code doesn't appear to call exit (it does call abort), and so > s...

...ause 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 'hash' is relicensed as LGPLv2+. > If this is not possible, we will have to rewrite the code, probably > implementing our own hash table, which would be a shame because hash > works well for our needs. > > Notes: > > - the code doesn't appear to call exit (it does call abort), and so > s...

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

hi, I would like to use the module spawn-pipe in a library called libguestfs to make it compileable under mingw. currently the library is using the fork/exec combination which doesnt compile under mingw (mingw doesnt support fork). spawn-pipe looks like a good replacement, however it is licensed GPL which is a problem for an LGPL library. Is it possible to relicense that module (and its

On Wed, Sep 13, 2017 at 7:43 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 09/13/2017 02:16 AM, C Bergström wrote: > > A completely non-technical point, but what's the current "polly" license? > Does integrating that code conflict in any way with the work being done to > relicense llvm? > > > Good question. I discussed this explicitly with

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

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

...> 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 relicensed it as LGPL. It is such a small project and it is the LGPL license we're talking about. But I would like to do this the right way (TM). And if rsync itself could be split into a LGPL licensed library + GPL application others could benefit from this too (and possible rsync also with an increased...

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 >

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 >

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