Some ideas for a sublanguage

[emmatebibyte]

Here, a sublanguage that implements breaking changes to crab is being discussed. I decided to create a list of the things I would like to see in such a sublanguage:

• A C-style entry point. I would like to see main() provide argv, and
• a simpler io::Error; this could be implemented by allowing main() to return a std::io::Result<(), String> or something else.
• A stable ABI
• LGPL-3.0-or-later-licensed standard/core library, AGPL-3.0-or-later-licensed compiler toolchain. *
• Proper source file license and copyright notices **

* The LGPL would preserve the freedom of the library without implicitly licensing anything linked against it as copyleft, therefore allowing crab to be used in permissively-licensed projects as well as nonfree ones. Changes to the library itself would be copylefted, though. The AGPL would specifically apply in any case where the compiler is used over a network, requiring any forks of crab to provide ways to access its source code. Otherwise, it’s the same as the GPL.

** License notices are an important part of software licensing that goes mostly ignored by even the likes of the upstream project, and they don’t just apply for the GPL family of licenses.

Please add anything more here that you’d like to see in crab :)

[TCROC]

The objection I have in this proposal is LGPL-3.0-or-later. I personally prefer MIT because I just like to use / develop the software without having to worry about enforcing ideologies inside the software I develop. Granted its a personal preference in the projects I like to take part in.

Linus has some concerns with GPL-3.0-or-later licenses in particular: https://www.youtube.com/watch?v=PaKIZ7gJlRU

Some questions that I have are:

Does LGPL allow me to use the source code directly inside an MIT project? Do I have to compile against DLLs? If it is the ladder, this would have some serious negative impacts against compiler time optimizations.

It may also hurt adoption as there are many people (such as myself) and businesses that get wary when seeing GPL based licenses.

[emmatebibyte]

Does LGPL allow me to use the source code directly inside an MIT project?

No.

Do I have to compile against DLLs?

Also no. Linking of any kind is allowed with the LGPL.

I think that some of Linus’ concerns with the GPLv3 are valid, but the AGPLv3, to me, is still the best license that has been made for software to this day.

The reason many people dislike the GPL family of licenses is misunderstanding, but these same people have never sat down and read the licenses they do use, either. Just try reading the Expat (MIT) license.

Overall, the GPL licenses are a hack, and being a hack in the legal system, they are long and confusing. Legalese is a bitch. But being a hack, it has to be that complex to do what it needs to do.

[TCROC]

Also no. Linking of any kind is allowed with the LGPL.

Ok cool. So I've never worked on a compiler before, but I feel that I have a high level understanding.

Basically, (for Crab at least) Crab gets translated to an intermediate language. Then optimizations are performed. Then it is compiled to machine code. Many of those same optimizations are not going to be possible and / or extremely limited when linking of any kind correct? By extension, limiting the performance of MIT projects. The only 2 I'm aware of are dynamic and static.

And this brings into question a few additional things:

1. If users want to use this new language in their project, does that project have to be LGPL or have an LGPL compatible license? Or in simpler terms, can I use an LGPL language to build an MIT project?

2. Regarding dynamic and static linking, this would bring limitations on the standard library right? The only projects that would be able to make use of function inlining for example would have to be LGPL compatible? (I'm aware this question might get rendered moot if any of the above scenarios do in fact allow MIT).

and then 3,

If we are in fact limited to linking and MIT projects (and especially proprietary projects) cannot make use of inlining, would it be possible to carve out exceptions in the LGPL license?

For example, explicit carve outs where something like this is allowed:

// LGPL licensed function (for simplicity sake, lets pretend addition is LGPL licensed)
fn add(arg1: i32, arg2: i32) -> i32 {
  arg1 + arg2
}

// MIT licensed function. Or maybe even on the other extreme, a proprietary function
// at Grapefruit Inc.
fn find_the_answer_to_everything(arg1: i32, arg2: i32) -> i32 {
  let mut someVal = arg1 + arg2 // here we made use of LGPL code.  Didn't change it, just used it
  someVal = someVal - 42
  someVal
}

If we would have changed that LGPL code somehow, then we have to contribute back. Otherwise we can use it like that?

[TCROC]

I skimmed the article you linked. Will take a night to sit down and actually digest it as it looks really interesting! :)

They do have a nice summary at the bottom that concludes with what I was expecting them to conclude with:

All these quibbles are a bit like spitting out gum on the way into church.

I'm not familiar with that statement, but I expect that all of the criticisms of MIT are also speculative and overly critical. A non issue until somebody decides to make it an issue one day. Kinda like worrying about the sky falling (although Chicken Little's concerns did end up being valid 😅). So I don't think nit picking at MIT is a good argument in favor of LGPL. But if the goal is to maintain the freedom initiative that FSF has presented the world with while still allowing incompatible codebases to link, I can see LGPL being useful there.

[emmatebibyte]

If users want to use this new language in their project, does that project have to be LGPL or have an LGPL compatible license? Or in simpler terms, can I use an LGPL language to build an MIT project?

When you write standard library functions in your code, you’re using linked code from the standard library. The LGPL was designed to allow a copyleft library to exist while allowing other, permissive projects to link (statically or dynamically) against the library. The GNU libc is LGPL-licensed.

So, yes, you can link against LGPL-licensed libraries with the Expat (MIT) license.

Many of those same optimizations are not going to be possible and / or extremely limited when linking of any kind correct? By extension, limiting the performance of MIT projects.

Optimizations are not limited, as far as I know, by any linkage. In Rust/Crab, when you add a crate to a project, rustc will link that crate into your project when you use it.

So I don't think nit picking at MIT is a good argument in favor of LGPL.

The purpose of linking the article was more to outline how many people are scared of the GPL family of licenses because of their density but have never really considered their conception of the permissive licenses they do use.

But if the goal is to maintain the freedom initiative that FSF has presented the world with while still allowing incompatible codebases to link, I can see LGPL being useful there.

It is exactly that :)

[TCROC]

The purpose of linking the article was more to outline how many people are scared of the GPL family of licenses because of their density but have never really considered their conception of the permissive licenses they do use.

Ah that makes more sense thanks! And yes I am one of those people :)

It is exactly that :)

Nice! I personally don't share those same values that the FSF has. I'm more of the mindset:

Here's my code. Do with it as you please :) (Just don't sue me).

I like to have the flexibility to do with it literally whatever I want. Even if that means taking it apart, rearranging the pieces, and not sharing because its a Monday and I haven't had my coffee yet lol. Ironically feels more "free" to me.

BUT

I feel I've made my thoughts towards LGPL sufficiently known so I'll avoid muddying your proposal any further with a debate on licenses.

I look forward to seeing what other thoughts people have regarding the proposal and thanks for answering my questions! :)

[emmatebibyte]

not sharing because its a Monday and I haven't had my coffee yet lol.

Just a note: I don’t know if this is your impression of it, but the GPL family of licenses doesn’t mandate you sharing the source of something publically. All you must do is make the source available in some way to the user. A couple decades ago, that often meant buying a CD with GPL-licensed software on it which also contained the source.

This means you’re free to make changes on your machine that you don’t share at all.

[JoaoVictorVP]

The GPL family of licenses tends to have similar, fundamental problems to other licenses, it's just an "inversion" of what is normally conceived. As long as there are licenses that allow people to be prosecuted through the force of law for [using, copying, modifying, opening and/or refusing to do any of these things] we will not see a real world of free software, but a brick wall being built by over loopholes and loopholes in the bureaucracy and a relentless quest for power and for the promotion of certain ideological points of view about how software should be.