Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider using a copyleft license #10

Closed
aylamz opened this issue Apr 18, 2024 · 8 comments
Closed

Consider using a copyleft license #10

aylamz opened this issue Apr 18, 2024 · 8 comments
Labels
meta About the project but unrelated to code

Comments

@aylamz
Copy link

aylamz commented Apr 18, 2024

Hello! This seems like a really cool project and I like your vision for it! However I noticed it uses MIT license which is a 'permissive' license. I suggest using a copyleft license, such as GPL-v3 instead. Or if that's too 'strong' copyleft, there also options such as LGPL or MPL

Why

Copyleft means that others who use this code have to give back. Currently this project is MIT licensed, meaning anyone can just take this code and use it in their proprietary software or just sell it and not make their changes public.

Permissive license would make more sense for project meant to included in other software such as libraries. I don't see much reason for a game to be MIT-licensed.

I am interested in contributing to this project as I really want there to be a decent open source voxel game as an alternative to Minecraft but I don't feel comfortable contributing to a permissively licensed project.

This is a suggestion, the choice whether to change the license is up to you of course. Feel free to close this issue if you do not want to change the license. :)

@nerdachse
Copy link
Contributor

Hey there!

Copyleft means that others who use this code have to give back.

If you can enforce it in court. Never forget that.
It's nice that there are rules, but remember how many companies didn't care about GPL and still just "copied" code.

On the other hand it also means that the project could get less contributions, because for many people GPL software is a nogo and they may want to upstream a fix here, but use it for their own project, which may be proprietary AND it makes for a dilemma: If you had a look at GPL code and got inspired (like really, inspired, not copying), what is yours and do you have to give back?

Even though this is not a library, it can be used as one in the sense that you go in, pick a book, read it and be smarter afterwards. That's not so easy with copyleft-licenses.

I think there is merits to be found in both directions.

I personally like that this project is MIT licensed because I have a similar, but not the same vision and can see how some problems I also face are tackled here. If I can no longer do that, that would be sad, but of course that's the decision for @Inspirateur to make :)

@Inspirateur Inspirateur added the meta About the project but unrelated to code label Apr 18, 2024
@Inspirateur
Copy link
Owner

Inspirateur commented Apr 18, 2024

Thanks for raising the issue, it's a good time to think on this and make a choice for the future !
(also, I didn't know about MPL, thanks for telling me about it 🙂)

I'm hesitating between MPL and MIT, it doesn't make any difference for personal uses (playing the game, making a non-commercial fork, learning from it), so let's discuss the commercial case:

With a MIT license, people will be able to re-use parts of the code in commercial projects, I'm aware that not many people will choose to give back but some will.

one interesting thing to note is the less value they add on top of the project, the less interesting their project become compared to the open source and free version; so I'm not too scared by the scenario of someone selling the game as is and profiting of it.

With a MPL license, many will choose not to use any part of the code at all, and those people will definitely not give anything back to the project. Those that still decide to use parts of the code will indeed be forced to contribute back with their modifications per the license, which is good for the project (but I'm kinda wondering if these users would not have contributed back anyway)

And then there's you! It's definitely not good for the project if the license (MIT or MPL) drive potential contributors away.

Which is why I'm looking for feedback for a compromise: switching Riverbed to MPL but keeping MIT for the general purpose crates that I extract from the code (which I try to do as much as possible). What do you all think about this :) ? @aylamz @nerdachse

@aylamz
Copy link
Author

aylamz commented Apr 18, 2024

switching Riverbed to MPL but keeping MIT for the general purpose crates that I extract from the code (which I try to do as much as possible).

I'm not necessarily against this idea but I'm not sure how you would do this? Because you can't take MPL-licensed code and extract it into a crate and release that under MIT? Am I missing or misunderstanding something here? :)

And if going with the MIT/MPL split license approach, wouldn't it make more sense to use a stronger copyleft such as GPL instead of MPL? If the re-usable parts are published with MIT license anyway then the rest could be more stronger copyleft without much issues?

Another thing: Apache license might be a better choice for a permissive license than MIT. It is more explicit about certain things and also protects against patent trolls. Or maybe a dual-license like Bevy itself? bevyengine/bevy#2373 (though now things are getting maybe a bit needlessly complicated)

Also just wanted to point out that you seem to be using "commercial" when you mean "proprietary"? No FOSS license, by definition, prohibits commercial use and there is commercial FOSS software as well as non-commercial proprietary software out there. So using "commercial" and "proprietary" to mean the same thing is a bit confusing :)

@Inspirateur
Copy link
Owner

Good points, for the extracting into crates part you're correct but I do think it's possible if every authors agree to it ?
But yeah it's kinda bothersome.

Also sorry for using "commercial" instead of "proprietary", as you correctly pointed out these are separate concepts, but I do think they are correlated enough that my point remain mostly unchanged :)

I'm not sold on having a license less permissive than MPL, because even though the project is not a library I mean to help other people build their own voxel game with it (it already has helped some), so it kinda shares this same purpose :)

Apache license seems good to me too 👍

@aylamz
Copy link
Author

aylamz commented Apr 18, 2024

for the extracting into crates part you're correct but I do think it's possible if every authors agree to it ?

Yes but at this point you're basically just dual licensing under a permissive and a (weak) copyleft license, which there is not much reason to do as then the copyleft kind of loses its purpose :)

@Inspirateur
Copy link
Owner

Yes but at this point you're basically just dual licensing under a permissive and a (weak) copyleft license, which there is not much reason to do as then the copyleft kind of loses its purpose :)

Mh idk, for a game like this i'd say more than 50% of the code is too specific and not crate-able, so that would still be some protection...

I've asked around and this approach seem to make sense for other people too, but maybe I'm trying to find a compromise that doesn't exist 😅

And would you be ok with the Apache license you suggested or would that still be too permissive for you to consider contributing ? (not that there'll be any obligation to haha)

@aylamz
Copy link
Author

aylamz commented Apr 19, 2024

Mh idk, for a game like this i'd say more than 50% of the code is too specific and not crate-able, so that would still be some protection...

The only viable way I see to implement this approach that you've proposed would be to ask every contributor before their contribution is merged, effectively dual-licensing the project under MIT (or Apache) and MPL (or whatever). If you ask them after, well then you might not be able to contact them or they might not agree to their contribution's license being changed.

And would you be ok with the Apache license you suggested or would that still be too permissive for you to consider contributing ? (not that there'll be any obligation to haha)

Apache license isn't any more copyleft than MIT, is it? It's just more explicit about some things. :) It is a better permissive license than MIT in my opinion but it's still a permissive license.

Anyway if you don't want to change the license to be copyleft, that's fine. I'll just use this project to learn from then. And I might use parts of it in my own project maybe (if or when I make one) :)

@Inspirateur
Copy link
Owner

Inspirateur commented Apr 19, 2024

Ok after quite some discussion I've come to this conclusion for the project:

For now Riverbed is in a very early stage where the code is generic enough to be used in any voxel game, and since many Bevy user struggle to build their own voxel game and I want to help the Bevy (and Rust) community I'm going to keep a very permissive license such as MIT or Apache while Riverbed is in this early stage (which is arbitrarily defined by me :p)

When the voxel engine gets far enough that I can start implementing specific Riverbed gameplay (or assets), I will consider switching to a MLP license (or similar) to protect the project👍

I will always encourage people to learn from the code however, I didn't invent any algorithm used in the game and I think we're all better off if we can learn from each other's work :)

Anyway, thanks for bringing this up, I'll close this issue for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta About the project but unrelated to code
Projects
None yet
Development

No branches or pull requests

3 participants