I haven't looked into detail in it, but just giving my first reaction: a license of your own makes no one happy.

If you want to create a new Open Source license, fine, if you want to do a new Open Source project, fine, but doing both at the same time will be more than double painful.

Also calling it OS but have a no OSI approved license... /shrug/

(But I don't want to derail from the technical achievements, sorry! And feel free to ignore this, just saying the first thing I noticed)

Hi Denny and thanks for your feedback!

I'm glad you took a note of the license :-)

I understand your point very well and I agree on the notion of challenge. In essence the Operon-license terms and conditions only become a concern when one wants to modify the source or binary -form of the program (Operon in this case) for their own use. This is a marginal use-case and I do not see it as a problem for adopting the software. I might be wrong of course and the public sentiment could be very different.

I grepped the site and license and found no OS mentioned (?), however the license implies that. Going through the OSF process takes some time and more preparation.

Current OS-licenses are disappointing to me, and if I were to offer a license to choose from (e.g. ASF2.0 / Operon) it would be equally disappointing when one of those were later removed. I'm not urged to push my language to the world while sacrificing the core-values the license holds. If someone takes a deeper look into the language and likes it, they might also want to take a deeper look into the license. If there were deep law-technical problems with the license, then I'm willing to remove it and replace it with an existing OSF-approved license. Until this happens someone has to point out the flaws.

What I find fun is that there are quite many language specific licenses (PHP, Python, Eiffel, Erlang). Why is that? :-D

Rationale for Operon-license:

• promote ethical use of the software by clearly defining the cases when the software may not be used

• clearly state that software under this license may be used as linked library, or other kind of dependency, without making the host-application subject to the same license

• make the license readable for technical people by explicitly and verbosely stating the terms and conditions

Hi @OperonGuy, and thank you for your answer. For some reason - probably bias - I just assumed it was saying that Operon is Open Source, but you say it is not, and that takes away my whole argument. Accordingly, I striked away those comments.

Yes, you are absolutely right that you have all the right in the world to publish your project in any way you feel most comfortable with, and I support that. Thank you for your clarification, and I wish you and your project all the best!

Regarding "why do many language implementations have a bespoke license?", I think the reason is that for the languages you have listed, they are all older than the OSI, and certainly older than the best practice of not proliferating new licenses. Newer programming language implementations seem to usually have standard licenses (Go, F#, Scala).

Thank you for your response and clarification, that resolves my remark.

Names are hard too. I was certain it was a spin on Oberon, based on the name. REBOL had the same problem, where people thought it was a new COBOL.

@Gregg Irwin True. It took quite a lot of time to think up that name and I still didn't realize that there was a language over 30 years old called Oberon 😄 I realized this few years ago, but guess it's not that much of a problem.

That lisp syntax - I have built something quite similar and I am calling it p-expressions / r-expressions / f-expressions … is this a completely a new lisp ? My approach is to build a transpiler over hylang and I have written an app with this dialect. I am trying to move towards the direction of newtonscript where I want to introduce more “natural language” primitives over lisp especially for setv.

Yeah, it's a new concoction. You can read more about it at https://github.com/akkartik/mu/tree/main/shell#readme. I spent a few years noodling on Lisp variants like Readable s-expressions a few years ago when I worked on https://github.com/akkartik/wart So I reused some of those ideas here. But I don't care too much about these syntax issues anymore. These days the first thing I evaluate a language on is how many languages it takes to build it, starting from machine code.

I will add a reference to it. Lunar is the only implementation I know that supports an alternate syntax. My conclusion with respect to the syntax of lisp is .. lisp has an inflexible space-based lexer. I am not particularly interested in supporting infix notation as much as I am interested in getting rid of scope related parens.

Yeah, that's fair. Do you care about having Lisp macros?

S-expressions are completely supported as I will be parsing them as is. Parens begin s-expression parsing. Additionally I am getting rid of reader macros in favour of general preprocessing and template based code generation. Another goal is to build a two way syntax parsers that will take s-expressions syntax and translate it freely to and from the new syntax so that you can use an editor to read and port code.