Re: [dev] [license] gpl issues

2023-05-08 Thread NRK
On Sun, May 07, 2023 at 11:31:04AM +0200, Страхиња Радић wrote:
> but the arguments presented in it leave me unconvinced.

The "maneuverings" argument in specific was entirely misdiagnosed. Even
in his own example (redhat trying to remove /etc) you can clearly see it
has nothing to do with GPL and everything to do with _adoption_.

Let's imagine a world where the linux ecosystem (including the GNU
tools) were permissively licensed. And now redhat wants to remove
`/etc`. Of course, if redhat was the only distro that did this, most
applications wouldn't adopt their policy - leaving them with an insane
amount of packages which will be broken on their distro - making this
plan infeasible.

According to that article's logic:

This kind of "hijacking" and political maneuverings never happen
with a permissive license like the BSD or MIT licenses.

in this imaginary universe, redhat would just go, "Hmm, we didn't get
what we wanted, but since linux is BSD licensed, we'll just give up."
Does that sound realistic? Of course not. They would've done exactly
what they're doing right now - trying to push their policies unto every
(or at least most) distros via the virus that is systemd so that their
policies gain _adoption_ among applications/libraries. Linux being
GPL/BSD makes zero difference when you need adoption from a massive
amount of third party applications.

If you want a real world example, just look at wayland-protocol, which
is MIT licensed. According to that articles logic, Valve can just fork
it and add their custom-protocol and implement it in their compositor.

But if Valve's compositor is the only compositor that implement's a
protocol, then most applications won't follow/adopt it and thus the
protocol will be useless.

So the reality of the situation is that Valve is still "maneuvering" and
trying to get what they want into the upstream wayland-protocol so that
it gains adoption. The MIT license made zero difference.

- NRK



Re: [dev] Servers with TLS support

2023-05-08 Thread Sagar Acharya
Thanks. althttpd looks great. Since I'm hosting on NetBSD, I found that there 
is a packaged mini_httpd which I'm trying initially.

In configuration which cert do I use, fullchain or designman.org.key?
Also, how does linking work in /www directory?

Earlier, since I used flask of python, I used to have ahref="foo/bar.html" 
within html templates which used to be processed automatically as 
"https://designman.org/foo/bar.html;

However, this is not working for mini_httpd static setup.
Thanking you
Sagar Acharya
https://designman.org



8 May 2023, 14:15 by maxschillin...@web.de:

>
> >I checked out the recommended webservers under rocks subpage but all of them 
> >lack TLS support. Merecat does have it's support but it needs systemd which 
> >my host system does not have. mini_httpd doesn't compile. Are there other 
> >minimal webservers with https support?
>
> Hi Sagar,
>
> althttpd [1] might be interesting for you.
>
> Best regards,
> Max
>
> [1] https://sqlite.org/althttpd/
>



Re: [dev] Servers with TLS support

2023-05-08 Thread Max Schillinger


>I checked out the recommended webservers under rocks subpage but all of them 
>lack TLS support. Merecat does have it's support but it needs systemd which my 
>host system does not have. mini_httpd doesn't compile. Are there other minimal 
>webservers with https support?

Hi Sagar,

althttpd [1] might be interesting for you.

Best regards,
Max

[1] https://sqlite.org/althttpd/