On 06/02/2018 11:18 AM, Daniel Stenberg wrote:
> On Sat, 2 Jun 2018, Patrick Monnerat wrote:
>
>> IMHO this should be examined on a case by case basis like Daniel does
>> for axTLS, and not be limited by a "checklist".
>
> Relatedly, I could add that in private emails with some people I've
> already been "highly skeptical" of proposals wanting to merge code
> adapted to work with proprietary (non-FOSS licensed) TLS libraries.
> The reasoning then is similar but with a slightly different angle:
>

As you know me, I would'nt advocate for proprietary software, but:

> 1 - we can't easily test/debug curl against such libraries. And by
> "we" I then mean anyone in the curl community who can build and run
> curl, I don't consider "but we can send a few people a copy of the
> software" a sustainable model.
>

Some of these target proprietary libraries are rather to be considered
as a part of the OS and are well documented: this is the case with
GSKit, OS/400 ldap, W$ sockets and crypto, W$ ldap and maybe more. As
such, they are alive and the OS publishers assume their maintenance.
If we do not trust/accept these, we should also stop support for
proprietary C compilers/libs and even closed-source OSes.

> 2 - I find it odd that we would take on maintainance of code used
> solely to benefit a single commercial entity, for free!
>

This is true for third party libraries, not for those provided as a part
of the OS. Is cURL a benefit to commercial platforms for free ? If yes,
by following your above statement, we should stop supporting them.

Don't take these words too strictly: I have been absurdly extremist only
for the purpose of demonstration ;-) All this stuff is a matter of
compromises.
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-06-02