The question over future possible PostgreSQL licensed code on Linux came up
to me recently. While doing some quick of digging around I found code
already under such license it seems:
The file drivers/md/bcache/util.c has:
cafe563591446 (Kent Overstreet 2013-03-23 16:11:31 -0700 318) /*
cafe563591446 (Kent Overstreet 2013-03-23 16:11:31 -0700 319) * Portions
Copyright (c) 1996-2001, PostgreSQL Global Development Group (Any
cafe563591446 (Kent Overstreet 2013-03-23 16:11:31 -0700 320) * use
permitted, subject to terms of PostgreSQL license; see.)
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(). Four things:
a) This is the only code on Linux which seems to use PostgreSQL
b) The language for license seem to be cut off, 'see.' seems incomplete,
whereas typically it would point to a file with the full language text.
c) We can only infer what portions of the file are under this license
d) Even though some licenses claim to be GPL-Compatible, if possible we
should dual license such with the GPL if possible (*)
If some folks are considering adding yet more code to Linux which is
currently under a PostgreSQL license I figured reviewing the existing
PostgreSQL code's use may be a good start to set precedent for future work.
Since we already have at least one file with a PostgreSQL-sort-of boiler
plate it at least sets the precedent we have already sort of dealt with
PostgreSQL.
My recommendations:
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.
If possible, if we can dual license this code with GPL it would be good as
it would do two things:
1) Removes any ambiguity in case of questions over GPL Compatibility in the
future about the PostgreSQL license
2) Other folks considering using PostgreSQL licensed code on Linux have a
template they can use
Other thoughts?
* Although some websites / organizations may state a license is GPL
compatible we have to be careful in the kernel as some companies or
organizations may disagree with some of these views (example is FSF's
website and position -- an example was one of the old BSD licenses which
some folks questioned its GPL compatibility with); despite the ambiguity
possible with dual licensing language [0], if one chooses a clear language
it can be extremely useful and cautious on the kernel community's part.
[0]
https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
Luis
On Tue, May 29, 2018 at 12:14:01PM -0700, Luis R. Rodriguez wrote:
> The question over future possible PostgreSQL licensed code on Linux came up
> to me recently. While doing some quick of digging around I found code
> already under such license it seems:
>
> The file drivers/md/bcache/util.c has:
>
> cafe563591446 (Kent Overstreet 2013-03-23 16:11:31 -0700 318) /*
> cafe563591446 (Kent Overstreet 2013-03-23 16:11:31 -0700 319) * Portions
> Copyright (c) 1996-2001, PostgreSQL Global Development Group (Any
> cafe563591446 (Kent Overstreet 2013-03-23 16:11:31 -0700 320) * use
> permitted, subject to terms of PostgreSQL license; see.)
>
> 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(). Four things:
Yep, it's just that code.
>
> a) This is the only code on Linux which seems to use PostgreSQL
> b) The language for license seem to be cut off, 'see.' seems incomplete,
> whereas typically it would point to a file with the full language text.
> c) We can only infer what portions of the file are under this license
> d) Even though some licenses claim to be GPL-Compatible, if possible we
> should dual license such with the GPL if possible (*)
>
> If some folks are considering adding yet more code to Linux which is
> currently under a PostgreSQL license I figured reviewing the existing
> PostgreSQL code's use may be a good start to set precedent for future work.
> Since we already have at least one file with a PostgreSQL-sort-of boiler
> plate it at least sets the precedent we have already sort of dealt with
> PostgreSQL.
>
> My recommendations:
>
> 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.
>
> If possible, if we can dual license this code with GPL it would be good as
> it would do two things:
>
> 1) Removes any ambiguity in case of questions over GPL Compatibility in the
> future about the PostgreSQL license
>
> 2) Other folks considering using PostgreSQL licensed code on Linux have a
> template they can use
Sounds good to me, I'll defer to your judgement since you have more experience
with these things than me :) Let me know if there's anything you need from me. I
never modified that code besides renaming the functions, but dual licensing
would be fine by me.
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....
- Ted
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().
On Tue, May 29, 2018 at 03:26:43PM -0400, Kent Overstreet wrote:
> On Tue, May 29, 2018 at 12:14:01PM -0700, Luis R. Rodriguez wrote:
> > The question over future possible PostgreSQL licensed code on Linux came up
> > to me recently. While doing some quick of digging around I found code
> > already under such license it seems:
> >
> > The file drivers/md/bcache/util.c has:
> >
> > cafe563591446 (Kent Overstreet 2013-03-23 16:11:31 -0700 318) /*
> > cafe563591446 (Kent Overstreet 2013-03-23 16:11:31 -0700 319) * Portions
> > Copyright (c) 1996-2001, PostgreSQL Global Development Group (Any
> > cafe563591446 (Kent Overstreet 2013-03-23 16:11:31 -0700 320) * use
> > permitted, subject to terms of PostgreSQL license; see.)
> >
> > 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(). Four things:
>
> Yep, it's just that code.
Great, thanks for the confirmation.
> > a) This is the only code on Linux which seems to use PostgreSQL
> > b) The language for license seem to be cut off, 'see.' seems incomplete,
> > whereas typically it would point to a file with the full language text.
> > c) We can only infer what portions of the file are under this license
> > d) Even though some licenses claim to be GPL-Compatible, if possible we
> > should dual license such with the GPL if possible (*)
> >
> > If some folks are considering adding yet more code to Linux which is
> > currently under a PostgreSQL license I figured reviewing the existing
> > PostgreSQL code's use may be a good start to set precedent for future work.
> > Since we already have at least one file with a PostgreSQL-sort-of boiler
> > plate it at least sets the precedent we have already sort of dealt with
> > PostgreSQL.
> >
> > My recommendations:
> >
> > 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.
> >
> > If possible, if we can dual license this code with GPL it would be good as
> > it would do two things:
> >
> > 1) Removes any ambiguity in case of questions over GPL Compatibility in the
> > future about the PostgreSQL license
> >
> > 2) Other folks considering using PostgreSQL licensed code on Linux have a
> > template they can use
>
> Sounds good to me, I'll defer to your judgement since you have more experience
> with these things than me :) Let me know if there's anything you need from me. I
> never modified that code besides renaming the functions, but dual licensing
> would be fine by me.
IANAL, but my recommendations below.
Trying to get all interested parties on Linux to agree PostgreSQL is
indeed GPL-Compatible is certainly possible but may require a bit of
legal billable hours on quite a bit of parts in the community. It takes
a long time...
Dual licensing would be preferred to avoid adding yet-another-license
and possibile ambiguities over compatibility, however, that would
require the original copyright holder's permission.
You can poke if you'd like, however there are two other alternatives.
a) License new code to GPL and add provenance notice for PostgreSQL
- Useful if we know upstream PostgreSQL does not care for our
own changes
b) Dual license GPL/PostgreSQL with provenance notice for the original
PostgreSQL code.
- Useful if we know PostgreSQL may be interested in reaping
benefit of our own changes on Linux as well.
a) and b) are possible if you made changes to the code (even space and
style changes count). If you opt for a) our code on Linux and evolutions of it
remains GPL, but would annotate provenance from the PostgreSQL license.
It'd include language such as:
-------------------------------------------------------------------------------
<GPL header>
* This file incorporates work covered by the following copyright and
* permission notice:
<Original PostgreSQL header and copyrght notice>
-------------------------------------------------------------------------------
So for instance this strategy was done on the carl9170 device driver rewrite
where Johannes took ISC licensed otus device driver from staging and
rewrote the driver based on it, an example file with the notice:
drivers/net/wireless/ath/carl9170/phy.c
This followed the guidence previously provided by SFLC on dealing with
this [0].
But since there may be other code coming up we have to consider what the
goals are.
- Is the plan to consider incorporating more PostgreSQL
licensed code on Linux?
- Is the goal to also let the PostgreSQL reap benefit of our own
enhancements?
If so for both then, and we if we really dont' want to get a good set of
company attorneys to say "PostgreSQL is GPL compatible", then b)
should work. It would be something like:
-------------------------------------------------------------------------------
<GPL header>
etc... later version; or, when distributed separately from the Linux kernel or
when incorporated into other software packages, subject to the license:
<latest PostgreSQL header and copyrght notice with your name>
* This file incorporates work covered by the following copyright and
* permission notice:
<Original PostgreSQL header and copyrght notice>
-------------------------------------------------------------------------------
[0] https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
Luis
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
It would seem I did follow up with a v3 patch and Rusty noted that although
I may be right, its hard to care [0]. But of relevance here is again if one
of the MODULE_LICENSE() dual tags should be used or the GPL tag. I'll
continue to side recommending with the MODULE_LICENSE("GPL") tag even on
files with permissive licenses, and even if it we haven't clarified this in
documentation as I think scaling these tags further is just silly.
[0] http://lkml.kernel.org/r/[email protected]
Luis
On Wed, May 30, 2018 at 2:12 AM, Luis R. Rodriguez <[email protected]> wrote:
> It would seem I did follow up with a v3 patch and Rusty noted that although
> I may be right, its hard to care [0]. But of relevance here is again if one
> of the MODULE_LICENSE() dual tags should be used or the GPL tag. I'll
> continue to side recommending with the MODULE_LICENSE("GPL") tag even on
> files with permissive licenses, and even if it we haven't clarified this in
> documentation as I think scaling these tags further is just silly.
>
> [0] http://lkml.kernel.org/r/[email protected]
https://www.spinics.net/lists/linux-bcache/msg06048.html
https://www.spinics.net/lists/linux-bcache/msg06058.html
--
With Best Regards,
Andy Shevchenko
On Wed, May 30, 2018 at 02:22:14AM +0300, Andy Shevchenko wrote:
> On Wed, May 30, 2018 at 2:12 AM, Luis R. Rodriguez <[email protected]> wrote:
> > It would seem I did follow up with a v3 patch and Rusty noted that although
> > I may be right, its hard to care [0]. But of relevance here is again if one
> > of the MODULE_LICENSE() dual tags should be used or the GPL tag. I'll
> > continue to side recommending with the MODULE_LICENSE("GPL") tag even on
> > files with permissive licenses, and even if it we haven't clarified this in
> > documentation as I think scaling these tags further is just silly.
> >
> > [0] http://lkml.kernel.org/r/[email protected]
>
> https://www.spinics.net/lists/linux-bcache/msg06048.html
>
> https://www.spinics.net/lists/linux-bcache/msg06058.html
For those that are not developers:
The proposed changes referenced in the above URLs take old portions PostgreSQL
C code which were previously on a larger C file and move them to a new module
which has the PostgreSQL header. Modules need to have a MODULE_LICENSE() tag,
and if one is not used the kernel assumes the module is proprietary. The above
code lacks a MODULE_LICENSE() tag as such currently the driver is proprietary.
Clearly that needs to be fixed before upstreaming.
Luis
On Wed, May 30, 2018 at 3:03 AM, Luis R. Rodriguez <[email protected]> wrote:
> On Wed, May 30, 2018 at 02:22:14AM +0300, Andy Shevchenko wrote:
>> On Wed, May 30, 2018 at 2:12 AM, Luis R. Rodriguez <[email protected]> wrote:
>> > It would seem I did follow up with a v3 patch and Rusty noted that although
>> > I may be right, its hard to care [0]. But of relevance here is again if one
>> > of the MODULE_LICENSE() dual tags should be used or the GPL tag. I'll
>> > continue to side recommending with the MODULE_LICENSE("GPL") tag even on
>> > files with permissive licenses, and even if it we haven't clarified this in
>> > documentation as I think scaling these tags further is just silly.
>> >
>> > [0] http://lkml.kernel.org/r/[email protected]
>>
>> https://www.spinics.net/lists/linux-bcache/msg06048.html
>>
>> https://www.spinics.net/lists/linux-bcache/msg06058.html
>
> For those that are not developers:
>
> The proposed changes referenced in the above URLs take old portions PostgreSQL
> C code which were previously on a larger C file and move them to a new module
> which has the PostgreSQL header. Modules need to have a MODULE_LICENSE() tag,
> and if one is not used the kernel assumes the module is proprietary. The above
> code lacks a MODULE_LICENSE() tag as such currently the driver is proprietary.
Thanks for explaining this for audience.
> Clearly that needs to be fixed before upstreaming.
Yes, that's why Coly deferred the change for getting clear with licenses.
--
With Best Regards,
Andy Shevchenko