similar to: Relicensing: Revised Developer Policy

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

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 >

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

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

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

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

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

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

Greetings all! # Summary - We will put the new LLVM license and developer policy in place for all subsequent commits next Friday (2019-01-18). - Commit access will be stopped while this is done (starting 3pm PST, hopefully under 3 hours). - We will restore commit access for everyone covered by relevant corporate and/or individual agreements. - Others will need to take some steps to restore commit

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

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

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

Hi all, Some history. Samba has historically only accepted code with personal, not corporate copyright attached. There were a couple of good reasons for this in the past, one of which was that we preferred GPL enforcement decisions to be made by individuals, not by corporations. Under GPLv2, a license violator loses all rights under the license and these have to be reinstated by the copyright

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

We're getting the last things in place, and expect in roughly one hour we will pause all commit access while we put in place the various mechanical pieces of this. I will send a somewhat detailed email reminding people of what has changed when everything opens back up. If this takes us more than 1-2 hours, I'll send an update with a rough time estimate. Details in case you missed the

The original intent of the virtio header relicensing from 2008 was to make sure anyone can implement compatible devices/drivers. The virtio-ccw was omitted by mistake. We have an ack from the only contributor as well as the maintainer from IBM, so it's not too late to fix that. Make it dual-licensed with GPLv2, as the whole kernel is GPL2. Acked-by: Christian Borntraeger <borntraeger at

On Fri, Jun 1, 2012 at 12:49 PM, Benjamin Kramer <benny.kra at googlemail.com>wrote: > > On 01.06.2012, at 08:14, Kostya Serebryany wrote: > > > > > > > On Fri, Jun 1, 2012 at 7:13 AM, Chris Lattner <clattner at apple.com> > wrote: > > On May 31, 2012, at 6:48 PM, Chandler Carruth wrote: > >> I'm not sure that this solves the problem.