Replies: 10 comments 8 replies
-
I would just stay with MIT. Let them make money of it. So what? |
Beta Was this translation helpful? Give feedback.
-
There may not be a problem with it. But I understand that more companies are trying to protect their work with dual licensing. Maybe it's not something that we should worry about (indeed: so what?). But it might not hurt to think about it a bit I guess |
Beta Was this translation helpful? Give feedback.
-
I checked godot/godot and they are using MIT as well. It this project gains any traction at all, you will be fine with that license, as there is much opportunity to still start a foundation and make money from it to support development. Even if large corps would use the code in that project, that would make it even easier to get them on board as they could easily contribute to upstream without worrying about the license, and every project using Gosub is contributing indirectly to it, because the engine being used needs to be supported by the visited websites, so devs get aware of it |
Beta Was this translation helpful? Give feedback.
-
look for MongoDB approach, i think you need to create costume licenses like MongoDB with Server Side Public License |
Beta Was this translation helpful? Give feedback.
-
Hello cool initiative. The problem if you choose to prohibit commercial use of the product it stops being a Open Source license by the definition of the OSI and that would probably decrement the usage of the tool at large. The Server Side Public License is also not recognized as strictly open source (lot of controversy came from that) and I think it only adds to infrastructure related code (I may be wrong) and wouldn't apply for a desktop application. If you want to stick to open source can either keep the mit license or change it to a gpl license, if you want to avoid a more competitive situation in the future in which a huge company steals your code, adds improvements as closed source and you don't get the source code of said improvements, that may however reduce the amount of contributions on the project. I would in this case go forth with the MIT, as it won't be a saas company that is the most common case of this being a problem, but you should weigh what you want to do with the solution in the future and choose acordingly based on those requirements. PD: the official github webpage to help choosing a license may be useful for you if you haven't already check it out https://choosealicense.com/ |
Beta Was this translation helpful? Give feedback.
-
You could also instead of aiming for one license for all the project, separate it in multiple packages/repositories and decide the licensing that feels most appropiate for each component, also allowing easier distribution and source management for people who just want to use/contribute to a certain functionality |
Beta Was this translation helpful? Give feedback.
-
From your blog post, it sounds like the bigger issue is companies taking one's work under a permissive license and creating or distributing a proprietary version, not necessarily whether or not one profits from it. I think the GPL offers an option closest to your goals, at least to my understanding. While the GPL doesn't prohibit anyone to profit from it, it does state that no one can create derivatives that turn it into a proprietary app, where the source code isn't available.
The GPL allows anyone to sell copies of the software. While many OSS project opt to provide the software at gratis, it is a misconception many people make. The "free" refers to "freedom", not "free beer"; sometimes "libre" is used to describe this to avoid this double meaning. There is potentially the situation where a distributor can provide binaries of the software without the source code by default. However, users have the right to request the source code after being provided the binary (e.g. the source code doesn't necessarily need to be public but does need to be provided at a user's request).
There seems to be a misconception that equates the GPL as a Contributor License Agreement, or CLA, when that is not the case. |
Beta Was this translation helpful? Give feedback.
-
It seems like the GPL best fits your requirements. The only downside of it, as already mentioned, is that it may curb adoption of and contributions to your project (especially by commercial parties) as others would be required to license their works using your projects as GPL as well (and so they might decide against using and becoming involved in your project in the first place). You may instead consider the LGPL, which allows your libraries to be used in otherwise closed source applications as long as direct modifications to your code are open sourced and these applications relying on your software can be used/recompiled with a modified version of your code. Of course, as open source enthusiasts we shall never give proprietary software developers any advantages they don't already have ;) (see https://www.gnu.org/licenses/why-not-lgpl.html) You should also note that as long as the rights granted to you by contributors concerning their contributions to your project allow it (this is why you should have a CLA), you may freely switch licenses later. All contributors retain their copyright (which includes the right to choose a license) when choosing for example GPL, LGPL, MIT or Apache. A counterexample would be CC0 (releasing the works into public domain). Note that I am no lawyer and this is not legal advice. If you want more to read, I recommend the license recommendations maintained by the Free Software Foundation https://www.gnu.org/licenses/license-recommendations.html Personally, I believe free and open source software is the future and we should work towards making it advantageous to become part of this "movement" (so: choose GPL!) :) |
Beta Was this translation helpful? Give feedback.
-
I like the spirit and aim of the GPL licenses, personally. In my experience, though, working on the private side of things, the GPL licenses are radioactive when it comes to adoption in companies. I suspect businesses will in general avoid GPL-licensed libraries if possible if it requires linking to them with their own code, unless, perhaps, they have a big open-source group already up and running. That seems like a significant pool of potential contributors to shut out should this project gain traction. For my own personal projects I use MIT. Much of the software I see and interact with in the Rust space is MIT or Apache 2 or dual licensed. |
Beta Was this translation helpful? Give feedback.
-
The most popular license which aligns to your requirements the most is GPLv3+. And I really hopes we get a browser written in GPL rather than permissive license. We have seen this with chromium which is primarily open source but many polular derivative browsers like google chrome and edge are proprietary |
Beta Was this translation helpful? Give feedback.
-
Basically, because I have no idea's about the legal stuff, I pretty much always use MIT license for all projects I create. I'm wondering if this would be the right license, or if there are things to consider?
My goals for this project:
The problem with the last part I guess is that it would be difficult to establish this without restricting things too much goal 1 and 2. What about an (paid) application that uses the gosub-engine for displaying html markup?
I'm curious what would be the best way to deal with this, as I can image it would be much harder to do changes in the licensing later on if the project gets a lot bigger.
Beta Was this translation helpful? Give feedback.
All reactions