Choice of language server and license
ghisvail opened this issue · comments
Thanks @laughedelic for working on a Atom-IDE package for Scala.
I was wondering what motivated your choice for the underlying language server over other choices. In VSCode, we have language packages for Scala backed by sbt, ensime and dotty respectively. None uses scalameta, hence my surprise.
On a separate topic, I am not sure of the benefits of the LGPL-3 license for Atom packages. Especially when the underlying backend (scalameta) is permissively licensed.
Hello @ghisvail!
I was wondering what motivated your choice for the underlying language server over other choices. In VSCode, we have language packages for Scala backed by sbt, ensime and dotty respectively. None uses scalameta, hence my surprise.
I also made an Atom plugin for the sbt server: atom-sbt-client, but I think it's completely independent and non-conflicting with other servers: it only compiles your project on save (and shows errors). There are some other features for it in development, but we'll see later how to deal with different servers coexistence. I think that sbt-server is special and other Scala language servers should communicate with it, not the editor client directly. I'm not sure about this yet 🤔 it needs more research.
I tried ENSIME several times and it never worked for me well enough, so I am very excited now about the active development of the Scalameta-based language server: scalameta/language-server. They keep the VS Code extension in the same repo, so you can try it out (see the contributing guide for the setup instructions). So you do have a language package using Scalameta, it's just not published yet 😊
I'm also curious about Dotty and thought of trying some pet project with it and making an Atom client for its language server. Just didn't have time yet. And while I'm dealing with Scala 2.x in my daily work, I'm more interested in supporting it first (also, obviously I'm using Atom and not planning to switch to VS Code so far).
On a separate topic, I am not sure of the benefits of the LGPL-3 license for Atom packages. Especially when the underlying backend (scalameta) is permissively licensed.
Actually, they added their Apache v2.0 license after I already published this plugin with LGPL-3 😄 I chose it just because it's the default license I use in my personal projects (or GPL/AGPL). IANAL but I think that this plugin's license is (legally) completely independent from the server's license, so I hope there is no conflict. I'm also not sure about benefits of using another license here, if you have something in mind, please speak it out. I don't have a hard opinion on this, but I think that in general the free-er the license is from the beginning, the better. I think this doesn't impose any restrictions on the users of the Atom plugin.
Oh yes, and you gave me an idea! 🌟
I saw that the ENSIME-based server is launched in a similar way as this one, so I could support both of them in one plugin. Assuming that they both use LSP properly, the rest of the plugin's code will be the same. Users could switch which server they want to use in the plugin settings. Some autodetection is also possible: ENSIME has some configs lying around, so when they are present, plugin would launch ENSIME server, if not — Scalameta.
This is just an idea, I saw that @vovapolu is going to make an Atom plugin for the ENSIME server: https://github.com/ensime/ensime-server/issues/1780#issuecomment-340413247. So let's see what he thinks about it.
@laughedelic I can see the appeal of having a generic IDE plugin which could potentially talk to different implementations of a Scala language server. I asked just out of curiosity really.
Regarding the licensing, I really don't see the point of copyleft for Atom plugins, but your opinion may vary. In particular, the LGPL-3 weak copyleft terms are only motivated for dynamically-linked shared libraries, and their applicability for source-only software is left for interpretation.
Should you insist on using copyleft terms for this plugin, just use plain GPL-3. For weak copyleft terms, MPL-2.0 is suitable for source-only software. I would strongly encourage to follow the rest of the Atom community, and release the plugin under MIT.
@ghisvail Thanks for telling me about MPL! I wasn't aware of it and it does seem like a better fit for this case. I'd like to stick to a copyleft license for now unless there are any good reasons to choose MIT (if you want to elaborate on why I really should use MIT here, please do).
I noticed that the majority of Atom plugins use MIT license, but to be honest, I believe that this is because it's set as a default in the plugin generator. I also found this comment:
There isn't any technical restriction on licenses for Atom packages. There is the practical limitation that in order for it to show up in the packages list on https://atom.io and in the apm tool, it currently needs to be in a public repository on GitHub.
From what I've seen most packages employ the default MIT license, though I haven't polled people for their actual preferences ... maybe people are just taking the default?
Thanks for telling me about MPL!
You're welcome. Surprised you had not heard of it.
you want to elaborate on why I really should use MIT here
Considering the small size and limited feature-set of this plugin, I fail to picture how copyleft is going to serve your users. The features of the plugin could be easily re-implemented under permissive terms.
I believe that this is because it's set as a default in the plugin generator.
The web community is known to be large adopters of MIT. I don't think the fact it is set as default is the main factor for it.
Meanwhile, you have not built much of a case for using a copyleft license, especially after proving to yourself that LGPL-3 was rather unfit for an Atom plugin. No offense.
No offence taken 😅 I easily admit that I'm quite uneducated about licensing and legal concerns in general, so I'm open to learn more and get convinced in a better choice. My naïve simple view is that default choice should be a copyleft license that obligates/encourages contributing back. I'm not a hardcore copyleft believer (again, because I don't know enough to defend it), so if the community would profit more from the project being licensed differently, I'm fine with it. In this case I just don't see why MIT would be a better choice and how MPL would restrict anybody from doing anything with this little plugin.
default choice should be a copyleft license that obligates/encourages contributing back
And this view is still shared by others, don't get me wrong. Sadly not by the community targeted by this plugin.
I just don't see why MIT would be a better choice and how MPL would restrict anybody from doing anything with this little plugin.
I am not saying MPL is wrong, but choosing copyleft can potentially have the opposite effect of replling contributors rather than attracting them as you would expect it to do. The web community were early adopters of the "opensource as default" mentality, so the incentives behind copyleft do not resonate with it and their redundancy may even irritate.
OK. Thanks for explaining yourself. I understand the situation better now. I wanted to stick with MPL, thinking that this project is more oriented to the Scala community than to Atom, but then I saw that all Scala.js projects are also licensed under MIT or Apache-2.0. So I decided to change to MIT for simplicity.