From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S968133AbeE2W7i (ORCPT ); Tue, 29 May 2018 18:59:38 -0400 Received: from mail-pl0-f68.google.com ([209.85.160.68]:35484 "EHLO mail-pl0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S967991AbeE2W7d (ORCPT ); Tue, 29 May 2018 18:59:33 -0400 X-Google-Smtp-Source: ADUXVKIbF6G3WX8gbQX7drEXSI1+rGqd0D3APCTg5bJ4oFMANwdId3wVoCMyckcUd04i69k2SnY37A== Date: Tue, 29 May 2018 15:59:28 -0700 From: "Luis R. Rodriguez" To: Kent Overstreet Cc: "Theodore Y. Ts'o" , Coly Li , Ciaran Farrell , One Thousand Gnomes , linux-bcache@vger.kernel.org, "linux-kernel@vger.kernel.org" , Greg Kroah-Hartman , Linus Torvalds , Thomas Gleixner , Philippe Ombredanne , Kate Stewart , Jonas Oberg Subject: Re: PostgreSQL licensed code on Linux Message-ID: <20180529225928.GI31712@garbanzo.do-not-panic.com> References: <20180529192643.GA3487@kmo-pixel> <20180529205143.GB7381@thunk.org> <20180529210025.GB3487@kmo-pixel> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180529210025.GB3487@kmo-pixel> User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 29, 2018 at 05:00:25PM -0400, Kent Overstreet wrote: > On Tue, May 29, 2018 at 04:51:44PM -0400, Theodore Y. Ts'o wrote: > > On Tue, May 29, 2018 at 03:26:43PM -0400, Kent Overstreet wrote: > > > > That seems to indicate that we've had already PostgreSQL licensed code on > > > > Linux since Kent's addition of bcache to Linux in 2013. The portion of code > > > > is rather small though, to me it seems to cover only crc_table[], > > > > bch_crc64_update(), and bch_crc64(). > > > > > > > As silly as it may be we should split out the PostgreSQL licensed code from > > > > drivers/md/bcache/util.c into its own file and while at it clarify the > > > > license. > > > > While we're at it maybe we should move the crc-64 code to lib and/or > > crypto, alongside our support for crc-8, crc-16, and crc-32 > > algorithms? That way if there are other potential users for crc-64, > > they will be less likely to re-invent the wheel.... > > Yeah, this came up because Coly wanted to do that, but needed to know what to > put in MODULE_LICENSE(). At run time its GPL, so MODULE_LICENSE("GPL") would make sense. I had sent a patch to help clarify this in 2012, I'll resend now [0]. [0] https://lkml.org/lkml/2012/4/8/75 Luis