Thread: contrib/fuzzystrmatch/dmetaphone.c license
contrib/fuzzystrmatch/dmetaphone.c says this: > /***************************** COPYRIGHT NOTICES *********************** > > Most of this code is directly from the Text::DoubleMetaphone perl module > version 0.05 available from http://www.cpan.org. > It bears this copyright notice: > > > Copyright 2000, Maurice Aubrey <maurice@hevanet.com>. > All rights reserved. > > This code is based heavily on the C++ implementation by > Lawrence Philips and incorporates several bug fixes courtesy > of Kevin Atkinson <kevina@users.sourceforge.net>. > > This module is free software; you may redistribute it and/or > modify it under the same terms as Perl itself. Is that OK? Perl is dual-licensed under the GPL and the "Artistic License", so the question is whether the Artistic License is compatible with the PostgreSQL license. IANAL, but I couldn't immediately figure out what the Artistic License requires, when you pick a piece of code and modify and embed it in another project. - Heikki
On Tue, Feb 24, 2015 at 12:24 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > contrib/fuzzystrmatch/dmetaphone.c says this: > >> /***************************** COPYRIGHT NOTICES *********************** >> >> Most of this code is directly from the Text::DoubleMetaphone perl module >> version 0.05 available from http://www.cpan.org. >> It bears this copyright notice: >> >> >> Copyright 2000, Maurice Aubrey <maurice@hevanet.com>. >> All rights reserved. >> >> This code is based heavily on the C++ implementation by >> Lawrence Philips and incorporates several bug fixes courtesy >> of Kevin Atkinson <kevina@users.sourceforge.net>. >> >> This module is free software; you may redistribute it and/or >> modify it under the same terms as Perl itself. > > > Is that OK? Perl is dual-licensed under the GPL and the "Artistic License", > so the question is whether the Artistic License is compatible with the > PostgreSQL license. IANAL, but I couldn't immediately figure out what the > Artistic License requires, when you pick a piece of code and modify and > embed it in another project. My belief (as someone who is not a lawyer, but has spent a fair bit of time working with them on such issues) is that it is not compatible. The licence requires derivative works to retain the licence properties, which have requirements that go well beyond those of our licence, however, as you point out it's far from clear whether lifting a piece of code would be subject to those restrictions, or be covered by clause 8/9 (do we expose a direct interface to this functionality?) which potentially allow the original licence to be dropped from derivative works. It's largely because of such uncertainties that I have been advised in the past (by those with appropriate letters after their names) to stop using the Artistic licence. This is why I spent nearly a year working on changing pgAdmin to the PostgreSQL licence. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/24/2015 04:47 AM, Dave Page wrote: > On Tue, Feb 24, 2015 at 12:24 PM, Heikki Linnakangas > <hlinnakangas@vmware.com> wrote: >> contrib/fuzzystrmatch/dmetaphone.c says this: >> >>> /***************************** COPYRIGHT NOTICES >>> *********************** >>> >>> Most of this code is directly from the Text::DoubleMetaphone >>> perl module version 0.05 available from http://www.cpan.org. It >>> bears this copyright notice: >>> >>> >>> Copyright 2000, Maurice Aubrey <maurice@hevanet.com>. All >>> rights reserved. >>> >>> This code is based heavily on the C++ implementation by >>> Lawrence Philips and incorporates several bug fixes courtesy of >>> Kevin Atkinson <kevina@users.sourceforge.net>. >>> >>> This module is free software; you may redistribute it and/or >>> modify it under the same terms as Perl itself. >> >> >> Is that OK? Perl is dual-licensed under the GPL and the "Artistic >> License", so the question is whether the Artistic License is >> compatible with the PostgreSQL license. IANAL, but I couldn't >> immediately figure out what the Artistic License requires, when >> you pick a piece of code and modify and embed it in another >> project. > > My belief (as someone who is not a lawyer, but has spent a fair bit > of time working with them on such issues) is that it is not > compatible. The licence requires derivative works to retain the > licence properties, which have requirements that go well beyond > those of our licence, however, as you point out it's far from clear > whether lifting a piece of code would be subject to those > restrictions, or be covered by clause 8/9 (do we expose a direct > interface to this functionality?) which potentially allow the > original licence to be dropped from derivative works. > > It's largely because of such uncertainties that I have been advised > in the past (by those with appropriate letters after their names) > to stop using the Artistic licence. This is why I spent nearly a > year working on changing pgAdmin to the PostgreSQL licence. I committed this (1 July 2004), but cannot remember any details about a license discussion. And I searched the list archives and curiously cannot find any email at all about it either. Maybe Andrew remembers something. I doubt we want to rip it out without some suitable replacement -- do we? Joe - -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, & 24x7 Support -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJU7f+PAAoJEDfy90M199hlMiYP/0TAVa1Jif8yn6Xv4fxm+Ycs eYxucdUO5GoHzWRluB7E3AFGw+cabC+BWKrTqUwvF/KhYGpvW+L8eEn67gNXQs0f Da5GmTbiql0EEamSNRX4IdzEGjnl5q5ngSwJWPDN71taoNjLWW1bFgVQam0wxbQ/ YGQTMujM2ZQS7yEJsszIw+wH7/3Yoh8keDb+ceYIPfhMXX/cshYehLkjhBEIrY45 lKYVL8fYzUfqV0OHGVak6GfguyK82+kabW8nFQteIS8cdgwFJpzNmU5bIKldQu8p nFr/67hh/kpSBHYlSziwK64CmVj2x0dGZB6I0cLnV+Y290DDT/oaXfvaTpWtGQ75 tz/QH4pNF3wbOvZnqv/QQXo3VU1mpmWraAyghy+bS6gspZ2cJSEs58gnK84LzY8H fOMzqz1YaiViJ+oCIPHU5kjoMiuMsRGDdOx+MIFCe97hRl0eQ60euDlR34gPsWLU rGtFrm/YeW4jBkYnKoi7WtvPBRbUv8VVR7W1pfooElPeou3iaqVL5ImYDvQ1cli2 LRLz5ERBmwfRAQZis2kFbWVCknrCaNZ3JKTuNF+ad8P1lUajmvNkXQ/1nqAiGpvI engjVzxAJbm8ckuKnkK6zA67BU4ylrVOZRypPfBhGzQJj1KkCeT6UIq7245owUoA 7OvQa1lQIDqGPqycEp3U =Em7c -----END PGP SIGNATURE-----
On 02/25/2015 06:59 PM, Joe Conway wrote: > I doubt we want to rip it out without some suitable replacement -- do we? No, probably not. I think there are a few options: 0. Find out that the current situation is OK, and the Artistic license is not a problem the way the code is used. 1. Ask Maurice Aubrey and the other upstream authors if they would like to re-license it under the PostgreSQL license (or another compatible license or public domain) 2. Rip it out. 3. Rewrite it in a cleanroom fashion. - Heikki
On 02/25/2015 11:59 AM, Joe Conway wrote: >> >> It's largely because of such uncertainties that I have been advised >> in the past (by those with appropriate letters after their names) >> to stop using the Artistic licence. This is why I spent nearly a >> year working on changing pgAdmin to the PostgreSQL licence. > I committed this (1 July 2004), but cannot remember any details about > a license discussion. And I searched the list archives and curiously > cannot find any email at all about it either. Maybe Andrew remembers > something. > > I doubt we want to rip it out without some suitable replacement -- do we? > > That's more than 10 years ago. I remember creating this for my then work at the North Carolina State Highway Patrol and sending it to Joe, but that's about the extent of my recollection. If the Artistic License isn't acceptable. I guess we'd have to try to get the code relicensed, or reimplement the function ourselves. There are numerous implementations out there we could copy from or use as a basis for reimplementation, including several licensed under the Apache 2.0 license - is that compatible with ours? cheers andrew
On 2/25/15 4:10 PM, Andrew Dunstan wrote: > > On 02/25/2015 11:59 AM, Joe Conway wrote: >>> >>> It's largely because of such uncertainties that I have been advised >>> in the past (by those with appropriate letters after their names) >>> to stop using the Artistic licence. This is why I spent nearly a >>> year working on changing pgAdmin to the PostgreSQL licence. >> I committed this (1 July 2004), but cannot remember any details about >> a license discussion. And I searched the list archives and curiously >> cannot find any email at all about it either. Maybe Andrew remembers >> something. >> >> I doubt we want to rip it out without some suitable replacement -- do we? >> >> > > That's more than 10 years ago. I remember creating this for my then work > at the North Carolina State Highway Patrol and sending it to Joe, but > that's about the extent of my recollection. > > If the Artistic License isn't acceptable. I guess we'd have to try to > get the code relicensed, or reimplement the function ourselves. There > are numerous implementations out there we could copy from or use as a > basis for reimplementation, including several licensed under the Apache > 2.0 license - is that compatible with ours? Perhaps a company large enough to have in-house counsel (EnterpriseDB?) could get a quick legal opinion on the license before we start pursuing other things? Perhaps this is just a non-issue... -- Jim Nasby, Data Architect, Blue Treble Consulting Data in Trouble? Get it in Treble! http://BlueTreble.com
* Jim Nasby (Jim.Nasby@BlueTreble.com) wrote:
> On 2/25/15 4:10 PM, Andrew Dunstan wrote:
> >
> >On 02/25/2015 11:59 AM, Joe Conway wrote:
> >>>
> >>>It's largely because of such uncertainties that I have been advised
> >>>in the past (by those with appropriate letters after their names)
> >>>to stop using the Artistic licence. This is why I spent nearly a
> >>>year working on changing pgAdmin to the PostgreSQL licence.
> >>I committed this (1 July 2004), but cannot remember any details about
> >>a license discussion. And I searched the list archives and curiously
> >>cannot find any email at all about it either. Maybe Andrew remembers
> >>something.
> >>
> >>I doubt we want to rip it out without some suitable replacement -- do we?
> >>
> >>
> >
> >That's more than 10 years ago. I remember creating this for my then work
> >at the North Carolina State Highway Patrol and sending it to Joe, but
> >that's about the extent of my recollection.
> >
> >If the Artistic License isn't acceptable. I guess we'd have to try to
> >get the code relicensed, or reimplement the function ourselves. There
> >are numerous implementations out there we could copy from or use as a
> >basis for reimplementation, including several licensed under the Apache
> >2.0 license - is that compatible with ours?
>
> Perhaps a company large enough to have in-house counsel
> (EnterpriseDB?) could get a quick legal opinion on the license
> before we start pursuing other things? Perhaps this is just a
> non-issue...
For my 2c (IANAL), I'm not convinced that it's an issue either.. I've
certainly not heard of anyone complaining about it either, so..
That said, we could also through SPI which might get us a bit of
pro-bono work, if we really wanted to pursue this. Just a hunch, but as
they tend to be conservative (lawyers in general), I expect the answer
we'd get is "yes, it might conflict and if you want to avoid any issues
you wouldn't include it."
To that end, I'd suggest -core simply formally ask the authors about it.
Once we have that answer, we can figure out what to do. In my
experience, at least, it's a lot better to go that route and figure out
what the original authors really *intended* than to go get a lawyer to
weigh in on it. One of those approaches is both free and gives a clear
answer, while the other is expensive and doesn't provide any real
certainty. :)
Thanks,
Stephen
On 02/25/2015 06:44 PM, Jim Nasby wrote: > On 2/25/15 4:10 PM, Andrew Dunstan wrote: >> >> On 02/25/2015 11:59 AM, Joe Conway wrote: >>>> >>>> It's largely because of such uncertainties that I have been advised >>>> in the past (by those with appropriate letters after their names) >>>> to stop using the Artistic licence. This is why I spent nearly a >>>> year working on changing pgAdmin to the PostgreSQL licence. >>> I committed this (1 July 2004), but cannot remember any details about >>> a license discussion. And I searched the list archives and curiously >>> cannot find any email at all about it either. Maybe Andrew remembers >>> something. >>> >>> I doubt we want to rip it out without some suitable replacement -- >>> do we? >>> >>> >> >> That's more than 10 years ago. I remember creating this for my then work >> at the North Carolina State Highway Patrol and sending it to Joe, but >> that's about the extent of my recollection. >> >> If the Artistic License isn't acceptable. I guess we'd have to try to >> get the code relicensed, or reimplement the function ourselves. There >> are numerous implementations out there we could copy from or use as a >> basis for reimplementation, including several licensed under the Apache >> 2.0 license - is that compatible with ours? > > Perhaps a company large enough to have in-house counsel > (EnterpriseDB?) could get a quick legal opinion on the license before > we start pursuing other things? Perhaps this is just a non-issue... The first para above was written by Dave Page, who works for EDB .... cheers andrew
On Thu, Feb 26, 2015 at 8:56 AM, Stephen Frost <sfrost@snowman.net> wrote: > * Jim Nasby (Jim.Nasby@BlueTreble.com) wrote: >> On 2/25/15 4:10 PM, Andrew Dunstan wrote: >> > >> >On 02/25/2015 11:59 AM, Joe Conway wrote: >> >>> >> >>>It's largely because of such uncertainties that I have been advised >> >>>in the past (by those with appropriate letters after their names) >> >>>to stop using the Artistic licence. This is why I spent nearly a >> >>>year working on changing pgAdmin to the PostgreSQL licence. >> >>I committed this (1 July 2004), but cannot remember any details about >> >>a license discussion. And I searched the list archives and curiously >> >>cannot find any email at all about it either. Maybe Andrew remembers >> >>something. >> >> >> >>I doubt we want to rip it out without some suitable replacement -- do we? >> >> >> >> >> > >> >That's more than 10 years ago. I remember creating this for my then work >> >at the North Carolina State Highway Patrol and sending it to Joe, but >> >that's about the extent of my recollection. >> > >> >If the Artistic License isn't acceptable. I guess we'd have to try to >> >get the code relicensed, or reimplement the function ourselves. There >> >are numerous implementations out there we could copy from or use as a >> >basis for reimplementation, including several licensed under the Apache >> >2.0 license - is that compatible with ours? >> >> Perhaps a company large enough to have in-house counsel >> (EnterpriseDB?) could get a quick legal opinion on the license >> before we start pursuing other things? Perhaps this is just a >> non-issue... > > For my 2c (IANAL), I'm not convinced that it's an issue either.. I've > certainly not heard of anyone complaining about it either, so.. > > That said, we could also through SPI which might get us a bit of > pro-bono work, if we really wanted to pursue this. Just a hunch, but as > they tend to be conservative (lawyers in general), I expect the answer > we'd get is "yes, it might conflict and if you want to avoid any issues > you wouldn't include it." Exactly :), and I just had a discussion with some legal folks about that because it has been an issue raised internally. So the boring stuff being... The Perl License has two meanings: GPL v2.0 or Artistic License 1.0, and there can be problems if fuzzystrmatch.so links with something that has portions licensed as Apache v2 because Apache v2 and GPL v2.0 are incompatible, or anything who-know-what incompatible with Apache v2. By choosing the Artistic license there are no problems visibly, at least for the case I have been pinged about. > To that end, I'd suggest -core simply formally ask the authors about it. > Once we have that answer, we can figure out what to do. In my > experience, at least, it's a lot better to go that route and figure out > what the original authors really *intended* than to go get a lawyer to > weigh in on it. One of those approaches is both free and gives a clear > answer, while the other is expensive and doesn't provide any real > certainty. :) I would go this way as well, aka ask the authors and see if it is possible to remove the license notice and keep everything licensed under PostgreSQL license to avoid any future problems... -- Michael
On Wed, Feb 25, 2015 at 08:36:49PM -0500, Andrew Dunstan wrote: > >>>I doubt we want to rip it out without some suitable > >>>replacement -- do we? > >>> > >>> > >> > >>That's more than 10 years ago. I remember creating this for my then work > >>at the North Carolina State Highway Patrol and sending it to Joe, but > >>that's about the extent of my recollection. > >> > >>If the Artistic License isn't acceptable. I guess we'd have to try to > >>get the code relicensed, or reimplement the function ourselves. There > >>are numerous implementations out there we could copy from or use as a > >>basis for reimplementation, including several licensed under the Apache > >>2.0 license - is that compatible with ours? > > > >Perhaps a company large enough to have in-house counsel > >(EnterpriseDB?) could get a quick legal opinion on the license > >before we start pursuing other things? Perhaps this is just a > >non-issue... > > > The first para above was written by Dave Page, who works for EDB .... Where are we on this? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +