search for: relicensing

This is an update on the current status of the relicensing, but also an opportunity to give feedback. Sorry it's rather long, but I think it's necessary to summarise the situation - there are probably list members who weren't even born at the start of the history of this! Xapian is currently licensed as GPLv2+, but isn't something we actu...

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

...4 and i386 was just changed to clang: https://marc.info/?l=openbsd-cvs&m=150109829003860 OpenBSD developers have previously made their position clear during this discussion: http://lists.llvm.org/pipermail/llvm-dev/2017-April/112300.html That said, Chris and others have made it clear that the relicensing process will proceed as planned. LLVM will most likely be forked.

...them to agree to this and also verify their identity. I do however suspect > this to be an almost impossible task... > > Is this as futile as it seems? ;) > > And is there a complete list of contributors available somewhere? > > thanks, > -- > Per Lundqvist > Hi Per, relicensing the yajsync library with LGPL might be a precondition for the longterm awareness and survivability of the yajsync project. So it's really worth the attempt to relicense. I saw that librsync is as well LGPL'ed. In my view it would have never gotten the attention and usage/linkage it has toda...

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,

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

...encies are all LGPLv2+ The fact that Bruno has been notably silent on this list for several months may be a problem; we have several outstanding requests for a looser license on these and other modules where Bruno has made non-trivial contributions. It may be time to ask rms if the FSF can do the relicensing, rather than our current policy of tracking down all contributors and asking them to use their grant-back clause of their FSF copyright assignment as our backdoor of not having to involve the FSF. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.o...

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

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

...gt;>> >>>>> Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> writes: >>>>> >>>>>> 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 pretty sim...

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

...t; 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 Tobias, and his general > feeling is that relicensing isl again would be doable if necessary (we > already did this once, to an MIT license, in order to enable better LLVM > integration). > > > Does adding polly expose any additional legal risks? Some people from > Reservoir labs have explicitly stated to me that some of their patent...

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

...t;>> Cheers, >>> Rafael >>> >>> Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> writes: >>> >>>> 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 pretty sim...

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

...we want. > > As such, I don't agree with it. > > Cheers, > Rafael > > Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> 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 pretty sim...

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 > > discuss such a case in an organization that contributed source code...

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