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 <rbl...@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 <n...@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
> rbl...@gmail.com

Reply via email to