Licensing claims (fnmatch)

[William A Rowe Jr <wr...@rowe-clan.net>]

On Wed, Feb 21, 2018 at 10:27 AM, Stefan Sperling <st...@stsp.name> wrote:
> On Tue, Feb 20, 2018 at 03:27:57PM -0600, William A Rowe Jr wrote:
>> I ran into the same headache with my complete rewrite of
>> the fnmatch.c logic of BSD that we ship in APR, and delivered
>> my rewrite of the file under both licenses.
>
> For which OpenBSD is still grateful, by the way :)

https://www.apache.org/legal/src-headers.html now offers an
option that I wish I had pursued for the fnmatch.c component;

https://www.apache.org/legal/src-headers.html#3party

In short, had we retained (and I assigned) simply the BSD license to
that file, following this caviet;

4. Minor modifications/additions to third-party source files should
typically be licensed under the same terms as the rest of the rest of
the third-party source for convenience.

then all further patches to apr_fnmatch.c would still be licensed in
BSD terms and consumable upstream, provided the PMC is agreeable;

5. Major modifications/additions to third-party should be dealt with
on a case-by-case basis by the PMC.

This would make the synchronization of POSIX [:class:] and other bug
fixes and extensions to apr_fnmatch much simpler.

Would this be acceptable to APR PMC?

Re: Licensing claims (fnmatch)

[Stefan Sperling <st...@apache.org>]

On Thu, Feb 22, 2018 at 01:31:34PM -0600, William A Rowe Jr wrote:
> Nick is right, I needed to pursue this with all apr_fnmatch.c committers
> for this specific change, once that first question is resolved. Thanks for
> the confirmation, Ryan! Small fixes were also suggested by several
> committers, including stsp, jailletc36, and trawick. I trust there are
> no objections to stsp and applying these suggestions under BSD-3
> license?

No objections from me. I don't even remember what I contributed exactly.
All I remember is talking to you about this code at an Apache Retreat
in Ireland some years ago, and that I (later on?) ported it to OpenBSD with
a BSD licence granted by you, because we needed a fix for the recursive
fnmatch issue like everyone did at the time.
In this porting process, millert's charclass extension, which had been added
to OpenBSD before this event, was retained in OpenBSD's implementation.

Re: Licensing claims (fnmatch)

[William A Rowe Jr <wr...@rowe-clan.net>]

I am first asking in the general case, where we adopt a functionality
wholesale from a BSD or MIT licensed project, whether we are willing
to keep the code under the original license, fnmatch as one example?

Nick is right, I needed to pursue this with all apr_fnmatch.c committers
for this specific change, once that first question is resolved. Thanks for
the confirmation, Ryan! Small fixes were also suggested by several
committers, including stsp, jailletc36, and trawick. I trust there are
no objections to stsp and applying these suggestions under BSD-3
license?

millert authored the POSIX [:class:] handling schema for this fnmatch
implementation, folks can see the current openbsd iteration here;

https://github.com/openbsd/src/blob/master/lib/libc/gen/fnmatch.c

Note his use of ISC license; as I'm no longer at VMware itself, any
simplification beyond one of BSD 3-clause and AL 2.0 is no longer
simple.

If we want to adopt this extension... keeping to POLS - adding POSIX
charclass support without a new flag seems to push this to apr 2.0?

Anyways, I'm not pushing hard to relicense, and will keep offering
my changes under either language. This just jumped out at me as
a way to license and change code we want upstream to adopt.


On Thu, Feb 22, 2018 at 5:20 AM, Ryan Bloom <rb...@gmail.com> wrote:
> I still monitor the list, I just don’t post.  If I remember correctly, this
> code came from httpd 1.3.  I might have made some small changes, but I am
> pretty sure this code’s lineage could be traced all the way back to when it
> was BSD licensed.  I say go ahead for my part.
>
> Ryan
>
> On Thu, Feb 22, 2018 at 3:36 AM Nick Kew <ni...@apache.org> wrote:
>>
>> On Wed, 2018-02-21 at 11:30 -0600, William A Rowe Jr wrote:
>> > then all further patches to apr_fnmatch.c would still be licensed in
>> > BSD terms and consumable upstream, provided the PMC is agreeable;
>> >
>> > 5. Major modifications/additions to third-party should be dealt with
>> > on a case-by-case basis by the PMC.
>> >
>> > This would make the synchronization of POSIX [:class:] and other bug
>> > fixes and extensions to apr_fnmatch much simpler.
>> >
>> > Would this be acceptable to APR PMC?
>>
>> As far as I'm concerned, that's fine provided we have no objections
>> from any significant contributors.  A quick look at svn suggests
>> that's basically yourself, with some early commits from Ryan.
>> I don't think Ryan is active here any more, so perhaps he should
>> be pinged as a matter of courtesy?
>>
>> Or is his name there a mere technicality, perhaps a legacy
>> of an initial code drop into svn?
>>
>> --
>> Nick Kew
>>
> --
> Ryan Bloom
> rbloom@gmail.com

Re: Licensing claims (fnmatch)

[Ryan Bloom <rb...@gmail.com>]

I still monitor the list, I just don’t post.  If I remember correctly, this
code came from httpd 1.3.  I might have made some small changes, but I am
pretty sure this code’s lineage could be traced all the way back to when it
was BSD licensed.  I say go ahead for my part.

Ryan

On Thu, Feb 22, 2018 at 3:36 AM Nick Kew <ni...@apache.org> wrote:

> On Wed, 2018-02-21 at 11:30 -0600, William A Rowe Jr wrote:
> > then all further patches to apr_fnmatch.c would still be licensed in
> > BSD terms and consumable upstream, provided the PMC is agreeable;
> >
> > 5. Major modifications/additions to third-party should be dealt with
> > on a case-by-case basis by the PMC.
> >
> > This would make the synchronization of POSIX [:class:] and other bug
> > fixes and extensions to apr_fnmatch much simpler.
> >
> > Would this be acceptable to APR PMC?
>
> As far as I'm concerned, that's fine provided we have no objections
> from any significant contributors.  A quick look at svn suggests
> that's basically yourself, with some early commits from Ryan.
> I don't think Ryan is active here any more, so perhaps he should
> be pinged as a matter of courtesy?
>
> Or is his name there a mere technicality, perhaps a legacy
> of an initial code drop into svn?
>
> --
> Nick Kew
>
> --
Ryan Bloom
rbloom@gmail.com

Re: Licensing claims (fnmatch)

[Nick Kew <ni...@apache.org>]

On Wed, 2018-02-21 at 11:30 -0600, William A Rowe Jr wrote:
> then all further patches to apr_fnmatch.c would still be licensed in
> BSD terms and consumable upstream, provided the PMC is agreeable;
> 
> 5. Major modifications/additions to third-party should be dealt with
> on a case-by-case basis by the PMC.
> 
> This would make the synchronization of POSIX [:class:] and other bug
> fixes and extensions to apr_fnmatch much simpler.
> 
> Would this be acceptable to APR PMC?

As far as I'm concerned, that's fine provided we have no objections
from any significant contributors.  A quick look at svn suggests
that's basically yourself, with some early commits from Ryan.
I don't think Ryan is active here any more, so perhaps he should
be pinged as a matter of courtesy?

Or is his name there a mere technicality, perhaps a legacy
of an initial code drop into svn?

-- 
Nick Kew

Re: Licensing claims (fnmatch)

[Yann Ylavic <yl...@gmail.com>]

On Wed, Feb 21, 2018 at 6:30 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> Would this be acceptable to APR PMC?

+1