search

SethBling / cbscript

CBScript for Minecraft
1.13k stars 28 forks source link

Add License to Repository #3

Open jly02 opened 4 months ago

jly02 commented 4 months ago

I'm aware it was stated that the project is open source, but including a license would make it explicit :)

jly02 commented 4 months ago

misclick

Florke64 commented 4 months ago

SethBling should decide on a license. Even WTF You Want if decision is hard.

However, I would suggest MIT. Something should be done, before project starts to be used, and forked widely (because, it will be for sure)

jaco-L8 commented 4 months ago

I would always advocate for GNU, but this project seems very suited for MIT

RustoMCSpit commented 4 months ago

I would always advocate for GNU, but this project seems very suited for MIT

AGPL3 if he wants it to be open source and only used in 100% open source projects too, MPL if he wants it to be able to be used in closed source apps but any modifications anyone makes to this would be open source (so Minecraft could take it for free without open sourcing Minecraft but if they make this code better they have to open source that and that only), MIT if he wants no control over it whatsoever. In my opinion, MIT licenses are pointless when you can just use MPL, there are no use cases for why MPL isn't better than MIT unless you want to be like FreeBSD and get screwed by some multi-billion dollar corp like Sony.

nfitzen commented 4 months ago

@RustoMCSpit note that the GNU GPL is a fine license in its own right and might be considered if this won't be used in server-side code.

If using the (A)GPL, it might be worth considering, if applicable, a license exception for linking with Minecraft, such as that in the GPL FAQ. A compiler exception where there are libraries put into it is also a consideration, such as the GCC runtime library exception. I'm not sure how much these might be necessary if at all, but it's worth mentioning.

(Obligatory disclaimer: I'm not a lawyer. These are commonly acknowledged situations that could arise under GPL'd code for interacting with non-free programs, and is not advice as to a course of action or an exhaustive list of options.)

Florke64 commented 4 months ago

unless you want to be like FreeBSD and get screwed by some multi-billion dollar corp like Sony

I would like to make an argument, that this project is indeed very well suited to the MIT licence as it is educational in its nature. Also, it is unlikely that the project will be taken over by a corporation for profit. At most, big networks like Hypixel* might abuse it in that way. At the end of the day, it ~recompiles~ transcompiles to just command blocks. Usage and profiting from this project is also limited by Mojang's EULA.

* or some pay-to-win servers

Makonede commented 4 months ago

I'm aware it was stated that the project is open source, but including a license would make it explicit :)

the project isn't actually open source at all without an open source license. in its current state, redistribution, for example, is still a violation of copyright, since it is unlicensed and therefore is under exclusive copyright. see No License.

a common misconception is that "open source" means "you can view the code." it actually means a lot more than that, and the proper term for this is "source-available."

@RustoMCSpit note that the GNU GPL is a fine license in its own right and might be considered if this won't be used in server-side code.

why would this be used in server-side code?

If using the (A)GPL, it might be worth considering, if applicable, a license exception for linking with Minecraft, such as that in the GPL FAQ. A compiler exception where there are libraries put into it is also a consideration, such as the GCC runtime library exception. I'm not sure how much these might be necessary if at all, but it's worth mentioning.

this project doesn't link with minecraft at all. read the readme

Also, it is unlikely that the project will be taken over by a corporation for profit.

the GNU GPL says nothing about the project being "taken over." yes, it does restrict use of the software in a closed-source project, but that's a phrase with a much clearer meaning and less dramatic tone to it compared to being "taken over by a corporation."

Usage and profiting from this project is also limited by Mojang's EULA.

no. this project doesn't touch minecraft at all so mojang can't do anything about it, and EULAs aren't legally binding like this.

my suggestion: GNU GPLv3 if you want the project's source code to be disclosed when used in a closed-source protect, otherwise MIT. if you decide on something else, make sure it's a free license.

as like most others here, IANAL. everything i said is a product of personal research and my own experience with open source projects. please let me know if you disagree with anything i said.

SethBling commented 4 months ago

I appreciate the thoughtful comments here. What I'd like is for this project to be usable by anyone to produce datapacks (or videos about datapacks etc) that they can monetize, but for the code itself not to be monetizeable. I also want credit to remain in any derivative codebases. Does anyone have thoughts as to the best route for that?

RustoMCSpit commented 4 months ago

I appreciate the thoughtful comments here. What I'd like is for this project to be usable by anyone to produce datapacks (or videos about datapacks etc) that they can monetize, but for the code itself not to be monetizeable. I also want credit to remain in any derivative codebases. Does anyone have thoughts as to the best route for that?

https://choosealicense.com/licenses/mpl-2.0/ If I'm understanding this right, the MPLv2 sounds best. It lets people include your work in closed source applications as long as they keep your work in a separate folder and publish any changes made within that folder. I'm not really sure what you mean by 'monetizable' as you want people to be able to make money with their data packs but not with your code - how could people make money with their data packs but not your code if your code is within that data pack? Surely they'd be monetising both of them as they share the codebase? Doesn't that defeat the point or could you clarify?

RustoMCSpit commented 4 months ago

@SethBling If you want everyone to use it only as an open source codebase, AGPLv3 is best. That still can be monetised but typically when we say 'monetised' we mean closed source as open source things are freely available to clone or build yourself, making any sort of paywall pointless. The only way I've seen an open source app be monetised is something like Asesprite where the majority of users would rather buy it on Steam than build from source (and also, most people don't even know what open source means so the concept of building from source is unknown to them). The thing is, this is a coding related project, everyone knows how to build from source.

RustoMCSpit commented 4 months ago

or videos about datapacks etc

that just falls under fair use, no license is needed there.

RustoMCSpit commented 4 months ago

. I also want credit to remain in any derivative codebases.

most licenses require this so don't worry. unless youre picking something like public domain or the 'buy me a beer' license this will be fine. the three most popular licenses are (in order of how copyleft they are) AGPLv3, MPLv2, MIT. AGPLv3 means everything has to be FOSS (free and open source), MPLv2 is explained above, MIT is the 'use this however just don't sue me if it breaks your computer and give me credit' license.

dhozou commented 4 months ago

IANAL

All licenses mentioned except the WTFPL require credit be included in any distribution of the software, modified or otherwise. The MIT license is the most permissive, only requiring attribution and allowing derivative code to be distributed as closed source. The Mozilla Public License 2.0 requires any derivative work make the licensed source files (your code), modified or otherwise, also available under the MPL but does not require new source files to be under the same license. The GPL is more restrictive, requiring any derivative work be distributed under the same license or a similar, compatible license with the goal of ensuring all source code remains open source. The AGPL additionally requires any derivative work to distribute its source code under a compatible license even if the work is only accessible as a service over the internet and not directly distributed; an example would be a website providing compilation of CBScript in the browser. Such a project would be required to release any modifications to your code under similar terms.

The MPL, GPL, and AGPL (from least to most strict) all fit the goal of ensuring your code and derivative modifications remain public. None explicitly ban commercializing derivative works, but any customer would have the same rights under the license to redistribute the code freely.

As an aside, it's important to understand that should you accept code contributions from other people, they will own the rights to their contributions and you will be bound by the conditions of the license as well. Changing the license at a later date would require permission from all rights holders.

RustoMCSpit commented 4 months ago

As an aside, it's important to understand that should you accept code contributions from other people, they will own the rights to their contributions and you will be bound by the conditions of the license as well. Changing the license at a later date would require permission from all rights holders.

(unless you make them agree to a CLA like musescore does)

Makonede commented 4 months ago

I appreciate the thoughtful comments here. What I'd like is for this project to be usable by anyone to produce datapacks (or videos about datapacks etc) that they can monetize, but for the code itself not to be monetizeable. I also want credit to remain in any derivative codebases. Does anyone have thoughts as to the best route for that?

use the GNU GPLv3

I'm not really sure what you mean by 'monetizable' as you want people to be able to make money with their data packs but not with your code - how could people make money with their data packs but not your code if your code is within that data pack? Surely they'd be monetising both of them as they share the codebase? Doesn't that defeat the point or could you clarify?

the code is not within the data packs

RustoMCSpit commented 4 months ago

why GPLv3 and not AGPLv3?

Makonede commented 4 months ago

why GPLv3 and not AGPLv3?

because this code is not used on the network

Perksey commented 3 months ago

I appreciate the thoughtful comments here. What I'd like is for this project to be usable by anyone to produce datapacks (or videos about datapacks etc) that they can monetize, but for the code itself not to be monetizeable. I also want credit to remain in any derivative codebases. Does anyone have thoughts as to the best route for that?

This would be MPL-2.0. This requires that any file containing the compiler's code itself be licensed as MPL-2.0 i.e. also be open-source, but files building on top of or as a result of CBScript are free to be licensed however, provided that a copy of the MPL-2.0 is included with the derivative works.

4wincode commented 3 months ago

why GPLv3 and not AGPLv3?

because this code is not used on the network

It's not intended to be and it isn't currently, but the point of using AGPL rather than GPL is to stop others from doing so without releasing the source. I'm still an advocate for MIT (or MPL) in this case but just pointing this out.

Doomsdayrs commented 3 months ago

Let's consider a company wants to make a web based CBScript editor (Software as a Service).

If my memory and understanding serves me correctly, the company does not have to release the source code or any modifications they do as they are not "distributing" the software, merely hosting it on their back-end servers.

This is why software such as Mastodon are under AGPLv3, to prevent SaaS exploits.

T/r/u/t/h social (censored to prevent dog piling) has come under legal fire from the Free Software Foundation in the past primarily because of this, as they did not abide by the requirements of AGPLv3 (releasing modifications, acknowledging source, etc).

AGPLv3 is the safest license currently for this type of project. Until perhaps an AGPLv4 or GPLv4 which is created to counter generative AI exploits.

On a separate note, I am currently with-holding my commits & work on this project until a license is added. And was looking for this exact PR due to the missing license.

RustoMCSpit commented 3 months ago

@SethBling do youve any more questions on a license or can we close this?

aMyTimed commented 3 months ago

SethBling do youve any more questions on a license or can we close this?

typically a github issue would remain open until:

since sethbling said he wants to add a license, the issue would probably remain open until one is added, right? issues are both made to discuss additions and to track the progress on those, so closing an issue on something that isnt finished isnt very helpful i think

nfitzen commented 3 months ago

I appreciate the thoughtful comments here. What I'd like is for this project to be usable by anyone to produce datapacks (or videos about datapacks etc) that they can monetize, but for the code itself not to be monetizeable. I also want credit to remain in any derivative codebases. Does anyone have thoughts as to the best route for that?

Edit: TL;DR, summary, and additional notes about linking:

See below for an essay.

@SethBling the open source and free software definitions require that code can be sold freely, but that it must have source code available to whoever receives a copy. I'm not sure what you mean by "monetizable," but if you mean that neither this project nor derivative works can be repackaged and sold (albeit with source code and credit attached), then you're not going to find much luck in FOSS. You'd probably have to write a custom proprietary license for that, and it wouldn't be open source.

If by "monetizable" you rather mean proprietary (closed source), then that's a different matter. If this is true, then I might suppose you wish to allow people to release their compiled datapacks under whatever license, and not distribute the source code to their datapacks, and so on; but if someone modifies the compiler itself or any standard libraries, then they have to provide source code and allow the recipient to use, modify, and redistribute that derivative code.

If this is the case, then you might be thinking of copyleft. The GNU General Public License is the most common copyleft license, and people in the comments (including me) seem to have been throwing it around a lot. The GPL gives permission to use, modify, and redistribute the code (with or without a fee), but it requires that anyone distributing the code or derivatives a) provides the source code to the whole program; b) licenses the program under the exact same terms; and c) preserves any copyright notices (which, if you're the copyright holder, means at least telling people your name). Section 7 of the GPLv3 provides a framework for you to add conditions prohibiting misrepresenting the origins of the code and/or requiring author attribution (as opposed to just a copyright notice).

GCC is a rather famous compiler that uses this license with an exception for, e.g., libgcc. See this GPL FAQ entry for a little more info on GPL'd compilers. The GNU Project's stance, at least, is that your copyright on the compiler doesn't cover code other people wrote, even if it is passed through the compiler. If the compiler automatically inserts code you wrote (rather than being a mechanical translation of meaning), then that might require an exception. The GCC exception 2.0 might be a more concise model for writing such an exception if you wish to do that. (It might even be usable wholesale.)

As for the libraries that seem to be in Scripts, or otherwise aren't really part of the compiler, the GNU Lesser General Public License is an option. This is just an exception to the GPL that would allow use of covered libraries in proprietary datapacks, but would require distributing the library source code for nontrivial functions. (The GCC exception would do a similar thing but wouldn't include the source code requirement, so that might be better for certain files.)

If you are using the GPL or LGPL, the GNU Project recommends specifying "GPLv3 or any later version" (or "LGPLv3 or later," as applicable). If you're uncomfortable using "any later version," another option is to specify yourself as a proxy for bumping the GPL or LGPL version at a later date, per GPLv3 § 14:

If the Program specifies that a proxy can decide which future versions of the GNU General Public License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the Program.

That way, per GitHub's ToS, any contributors will automatically give you permission to bump the version.

If nothing else, it's best to be clear if you don't wish to support future license versions (e.g. "GPLv3 only" rather than just "GPLv3"). See, e.g., this article.

For applying licenses to your work, the REUSE guidelines and SPDX might be useful resources for some computer-readable formats. That way, in a given file, you can put a comment at the top saying, e.g.,

and so on. This is an approach taken by Linux, for example.

Obligatory IANAL disclaimer here. This comment isn't legal advice.

Also, sorry for the text dump. lmao.