Kyle Mitchell

Those are really good thoughts! Here are a few answers and thoughts.

* No, it won't stay AGPL. It will be just my license once a lawyer approves that license. And I have actually four licenses; it will start on the most restrictive, but I will move it to the most permissive over time as this repo becomes established and recognized. In essence, I will explicitly follow the process in [1] that tends to happen over time.

* Yay!

* Double yay! Thank you!

* Yes. This is necessary to implement DSL's in it. (My build system will use a DSL.) Also, it will have better error messages.

* Great! This is one thing that Rust is right on: mutation should not be default.

* I'm not the biggest fan of it either; that syntax will change to something better. Maybe just `push <expr>: <stack>`. I don't know. Any suggestions?

* Technically, they are not built-in; they are a part of the standard library, but point taken: there needs to be a better namespace for those standard library ones. (By the way, this means that yes, your own libraries can add context stacks for client code.)

* Function suffixes are weird, yes. I don't know what to do about that. I've waffled a bit between them and having implicit name mangling (as in C++), but that leads to ABI and interoperability issues. But I acknowledge the issue. What can I say? Language design is hard!

And to answer, your claim that you're not a language guy, you are. As a user, you are more right than me as to what is good; actual users matter…

In terms of "antithetical values", the machine learning project ml5js.org actually did something about this. They bound their open-source license to a Code of Conduct¹, which forbids the use of their ML software for (1) discriminating against marginalized communities, (2) building tools that disingenuously manipulate public opinion, (3) building tools of mass surveillance and prediction to repress the rights of people, and (4) building tools that control weapons, including tools that automate the deployment, operation, and targeting of weapons.

Reported violations of the Code of Conduct are sent to a Steering Committee, made up of members of the community, who determine if the reported project is in violation of the Code of Conduct. If so, the Committee takes steps to remedy the situation (e.g. realigning project with the Code of Conduct, or removing ml5.js from the project) — and if no resolution is found, the project falls out of compliance with the terms of the software license.

It's an interesting experiment.² Software is a tool to help us solve problems and reach desired outcomes. Licenses are also a tool to help us solve problems and reach desired outcomes. When desired outcomes exclude certain things (e.g. discrimination of marginalized communities, manipulation of public opinion, autonomous weapons, values antithetical to that of a community), it seems a Code of Conduct can also be a worthwhile tool to solve problems and support the outcomes that the community…

I agree that Open Source (and Free Software, so let's go with FOSS) works as designed. However, charging is not an option FOSS supports. At best it's accepting and no one's paying. OpenSSL, for instance, had accepted money for a long time yet the whole internet had to be scared for the money to actually start trickling in and still laughable amounts.

Where I don't agree is that FOSS is not to blame. It absolutely is. FOSS is the entrenched default. And FOSS is incompatible with requiring a payment. To require a payment one has to run a tangential business (provide support, integration services, etc.) and all the options are in conflict with the quality of the main FOSS product one way or another. FOSS makes it hard to switch to any other model and it's harder the longer the project lives.

The issue of funding is not going to be solved by FOSS because it is not the foal. We need to look past FOSS to find a solution. A good start would be to chose a different license when one starts a project. Like one of PolyForm Licenses [1] or BTPL [2]. These are not FOSS compatible but they align much better with the funding goal. And if one figures it doesn't work for the project it's easy to switch to FOSS. Much easier than the other way around, anyway.

[1]: https://polyformproject.org/licenses/
[2]: https://writing.kemitchell.com/2022/01/26/Big-Time-2.0.0

Yes, that's the MongoDB variant which codifies it directly, and SF Conservancy and other legal entities promotion FOSS licenses states that the network stack contagion concern does not actually apply for the AGPL. But because AGPL doesn’t dig into the definition of "access", simply defining it as “users interacting with it remotely through a computer network”, nor define clear boundaries for how the "contagious" part of GPLv3 interacts with the rest of the network stack of this clause, it has meant that some lawyers think that a court may overly broadly interpret the definition.

So far this contagion concern hasn't actually played out, and big corporations/hyperscalers are often using AGPL software somewhere in their stack if they're using common Linux distros - and nothing thus far has been compelled to be open sourced that isn't AGPL software.

This might be insightful about the concerns as well as why lawyers still think it's straightforward: https://www.opencoreventures.com/blog/agpl-license-is-a-non-starter-for-most-companies

https://discuss.logseq.com/t/on-the-agpl-license-and-the-idea-to-move-away-from-it/14716

https://writing.kemitchell.com/2021/01/24/Reading-AGPL

(not a lawyer): https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html

You ask a very good question. I'm afraid the very strong rules about confidentiality that apply to me as a California attorney prevent me from answering as I'd like.

I can say that I think your experience is typical of large software firms. Most still ban AGPLv3, if not all GPLs or all copyleft licenses, by policy.

Even when there are exploitable loopholes, they're typically narrow enough to require very close collaboration between legal and engineering, in the context of a very specific project, especially the first time. It's possible to exploit those loopholes, but not possible to prescribe how to do so by general policy. That used to be true of private changes to GPLv2 and GPLv3 code. We've seen exercises of those intentional gaps in copyleft operationalized as policy in firms that rely on them daily.

If you see posts on https://writing.kemitchell.com that you like, you may also find https://blog.licensezero.com worth the candle.

I didn't say a trademark isn't a form of IP. I said their application for a trademark was rejected due to "open source" being too generic/descriptive, not due to the reason you directly asserted above ("They don't hold the IP, I don't really see any way they could be granted a trademark on it").

You can read more about this at https://opensource.org/pressreleases/certified-open-source.php or https://www.techmonitor.ai/technology/open_source_initiative_gives_up_on_trademark/ among many other sources. Or a much longer blog post from a lawyer who is active on HN: https://writing.kemitchell.com/2020/05/11/Open-Source-Property

fwiw, a non-OSI attempt to trademark "open source hardware" was also rejected for the exact same reason. https://opensource.com/law/13/5/os-hardware-trademark-rejected