Some ideas for a sublanguage #92
Replies: 8 comments
-
|
The objection I have in this proposal is Linus has some concerns with 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. |
Beta Was this translation helpful? Give feedback.
-
No.
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. |
Beta Was this translation helpful? Give feedback.
-
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:
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? |
Beta Was this translation helpful? Give feedback.
-
|
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:
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. |
Beta Was this translation helpful? Give feedback.
-
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 So, yes, you can link against LGPL-licensed libraries with the Expat (MIT) license.
Optimizations are not limited, as far as I know, by any linkage. In Rust/Crab, when you add a crate to a project,
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.
It is exactly that :) |
Beta Was this translation helpful? Give feedback.
-
Ah that makes more sense thanks! And yes I am one of those people :)
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! :) |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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:
main()provideargv, andio::Error; this could be implemented by allowingmain()to return astd::io::Result<(), String>or something else.LGPL-3.0-or-later-licensed standard/core library,AGPL-3.0-or-later-licensed compiler toolchain. ** 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 :)
Beta Was this translation helpful? Give feedback.
All reactions