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
