similar to: Relicensing alloc.h

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

> 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

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 actually chose for Xapian, but rather due to 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

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

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

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

i'm trying to build ices0.4 and vorbis-tools 1.0.1 with flac 1.1.1. Neither seems happy, hence the crossposting (sorry). ICES0.4 --- ices refuses to see the libFLAC library, even if i specify --with-flac=/usr/local/lib (or even just --with-flac=/usr/local/, as the configure script seems to look in the lib and include subdirectories of the specified path?). i get a configure error:

i'm trying to build ices0.4 and vorbis-tools 1.0.1 with flac 1.1.1. Neither seems happy, hence the crossposting (sorry). ICES0.4 --- ices refuses to see the libFLAC library, even if i specify --with-flac=/usr/local/lib (or even just --with-flac=/usr/local/, as the configure script seems to look in the lib and include subdirectories of the specified path?). i get a configure error:

On Oct 19, 2015, at 10:53 AM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: >>>> 2) We could require new contributors to sign the Apache CLA. >>> >>> To me, this is the most acceptable option of the listed terms. >> >> Please explain: why? > > First part for me is that switching the code to a different license > doesn't

On Wed, Oct 21, 2015 at 5:16 AM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Tue, Oct 20, 2015 at 09:54:30PM -0700, Chris Lattner wrote: >> On Oct 19, 2015, at 10:53 AM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: >> >>>> 2) We could require new contributors to sign the Apache CLA. >> >>> >>

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

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

Hello, I need flac bug, which is already in cvs (1328191) fixed, so I was wondering first is cvs safe for everyday use? I can understand a crash, but corrupt files aren't common right? Also, when trying to 'make install' to prefix=/home/sbh I get: /bin/sh ../../libtool --mode=install /usr/bin/install -c 'libFLAC++.la' '/home/sbh//lib/libFLAC++.la' libtool: install:

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

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

I really really do not like armchair lawyer discussions and this is just flamebait if I've ever seen it... --------------- #1 Is the submarine patent risk really that bad? (What's driving this) #2 Pragmatically have "you" even considered how to execute on this relicense plan? a. What if one of the copyright holders doesn't agree? b. What audit procedure do you plan to use c.

/usr/bin/ld: bad -rpath option collect2: ld returned 1 exit status make[4]: *** [libFLAC.la] Error 1 --- flac-1.1.2/src/libFLAC/Makefile.in.orig 2005-02-04 21:23:37.000000000 -0500 +++ flac-1.1.2/src/libFLAC/Makefile.in 2006-04-30 20:30:00.000000000 -0400 @@ -399,7 +399,7 @@ rm -f "$${dir}/so_locations"; \ done libFLAC.la: $(libFLAC_la_OBJECTS)