Embedding your project within mine… how best to license?

[SamuelMarks]

Hey @r-lyeh just found your projects and now might be a good time to embed it in my libacquire.

The plan is to use your codebase as the fallback when a more optimised shared library isn't found (no zlib or libarchive, for example)

I'm not anti CC0/Unlicense/WTFPL, but some files in my project are taken from OpenBSD and FreeBSD codebases so I don't think they can be licensed as such.

Do I just /* SPDX-License-Identifier: (Apache-2.0 OR MIT) */ the various files that can't be other, and /* SPDX-License-Identifier: CC0 */ the rest?

Thanks and again great work with these libraries,

PS: Oh, and give me a few days but contributions welcome… especially interested in what other APIs you think are useful for a libacquire

[r-lyeh]

Hello @SamuelMarks ,

First of all, you don't need to relicense your existing OpenBSD/FreeBSD to a newer license. Those files can be licensed as-is, and you just incorporate newly licensed items to your codebase. Usually, by doing so, you would have to modify your LICENSE and Copyright files and adjust to the new licensing clauses, but since CC0/Unlicense/WTFPL is basically "copyleft without clauses" you need actually to do nothing. Just include the source files and be happy with that. No need to acknowledge or attribute the original authors either. Totally free as beer.

If you are still concerned that the licenses do not fit your codebase, you can relicense them as BSD, MIT, ZLIB, L/GPL or whatever other more-restrictive license you would like to. What you cant never do is to relicense from a more restrictive license to a permissive one (top to bottom is forbidden). Ie, you can't relicense GPL to MIT-0, but you could like relicense MIT-0 as GPL. If it helps, consider my sources 0-BSD or MIT-0 licensed as well, so you dont have to think that much :D

PS: You could also benefit from @mattiasgustavsson 's https single-header library, which worked out great for me. I can't find the link right now. But poking him now so he can hopefully share the right link :D

[mattiasgustavsson]

Ah, my https.h lib was never finished, I just think I shared a WIP version on twitter at some point.

It was basically a merged single header of libtomcrypt, https://github.com/libtom/libtomcrypt, TLSe, https://github.com/eduardsui/tlse, and my own http.h, https://github.com/mattiasgustavsson/libs/blob/main/http.h.
I guess I could dig it out if someone wants to use it as a starting point, but I think it will take some work to get it fully working and secure

[r-lyeh]

Do I just /* SPDX-License-Identifier: (Apache-2.0 OR MIT) / the various files that can't be other, and / SPDX-License-Identifier: CC0 */ the rest?
@SamuelMarks : Forgot to answer that. That's totally fine too.

I guess I could dig it out if someone wants to use it as a starting point
@mattiasgustavsson : I think you should, in fact, upload it to your libs repo and let/accept any potential PRs! I have some compilation fixes for it already (tcc/linux/osx fixes iirc) :D

[mattiasgustavsson]

I think I’d much rather someone else did that, I don’t want to have to maintain or oversee it myself 😝

[SamuelMarks]

In terms of licensing, thanks for your comments, I kind of understood it that way already, the thing is I like to contribute fixes back. So if I just take your code and relicense it (Apache-2.0 OR MIT) then I can't contribute added features and bug fixes back to your project. I hate AGPL which forces contributions back, but when I find Unlicense I want to contribute back! 🎊

---

In terms of abstracting out a new HTTPS client from low level sockets, I did modify this codebase + elsewhere rewrote this in C:
https://github.com/SamuelMarks/oauth2/blob/master/cpp/src/tiny_web_client.cpp

Also modified:
https://github.com/SamuelMarks/netw/tree/cmake
https://github.com/SamuelMarks/Hands-On-Network-Programming-with-C/tree/cmake

Having a single binary that would work in Docker's FROM scratch is certainly an interesting plan. Three things:

• Sockets would still need to be linked dynamically with whatever the system provides (again, see tiny_web_client.cpp & web_get.c), i.e., <io.h> & <winsock2.h> or <unistd.h>, <sys/socket.h>, <netinet/in.h> & <netdb.h>)
• SSL certificates would still need to be downloaded (so can't do a 2 line Dockerfile as I don't want to embed the certs in my binary and extract it…)
• Bugs in my own TLS implementation would need to be fixed by me, rather than the big advantage of linking with system provided shared libraries where a Windows Update / apt upgrade would bring in the fix

So I'd much rather bring in a libcurl archive with ADD and use the system provided HTTPS library on other operating systems.

(also there are probably efficiency gains to using their prepackaged solution)

(though happy to hear your argument to the contrary)

[r-lyeh]

I'm losing the track about what we're discussing in here :D
Feel free to relicense or to embed all my source code as much as needed.
If you ever contribute back, I'll take your contributions and PRs as Unlicensed still.
Absolutely no worries there!

PS: FWIW, I'm attaching the (modified) https header from Mattias that I was referring to earlier. No objections about using OS utilities (or even curl or wget) for that tool you're crafting :)
https.zip