Unlist bevy_retro from assets due to controversial, likely unusable license.

[laundmo]

Currently bevy lists bevy_retro in assets. (main/Assets/2D/bevy_retro.toml)
bevy_retro is licensed under what they call the Katharos license

The core issue i have with this license is that very large parts of the limitations it puts on usage are very subjective and up to interpretation. Interpretation of one of the most disputed and re-interpreted texts in human history. Something a user might think the license allows, might be forbidden by the authors interpretation of it. This leads to enormous uncertainty - if i may play devils advocate: the author could turn around and suddenly proclaim that a big project using bevy_retro is infringing on something the author interprets the license to say. This would require a legal battle, which could cost both sides a lot of time and money.

I think keeping something this ambigous on a site which could easily be understood as a "official bevy endorsement" is a risk bevy shouldn't be willing to take.

[wrapperup]

There needs to be a clear set or range of licenses that can be showcased on bevy assets. For a point of reference, the Unreal Marketplace has restrictions on what an asset's license is (though it is quite strict). I don't think going this far is the right move for bevy assets, but I think some range would be good.

Shoving assets that have more restrictive / different licenses than the Bevy MIT/Apache license down the page seems good start, and removing any assets with a deeply infringing license seems like a good way to prevent users from footgunning themselves.

[IceSentry]

As stated on discord. I don't believe it's our responsibility to filter licenses. At most we can clearly indicate if a license is compatible with bevy's own licenses.

It's already hard to even figure out the license used by a project. We could mandate them to set it when adding it to bevy_assets, but if it changes overtime and we don't change it here then we have the same issue if user start trusting everything in the asset list assuming it's always up to date.

We also have various games. tutorials and general website links that don't have common software licenses because they aren't the same as a published crate.

What we can do is make it clear which licenses are compatible with bevy and that the page doesn't endorse anything.

[wrapperup]

As stated on discord. I don't believe it's our responsibility to filter licenses. At most we can clearly indicate if a license is compatible with bevy's own licenses.

This mostly depends on what bevy assets wants to be. If it wants to be some kind of marketplace, then of course it seems reasonable that users know that what they downloaded is under a set of licenses. It would be a bit silly if you didn't really have any guarantees that the asset you downloaded has a compatible license 😄

It's already hard to even figure out the license used by a project. We could mandate them to set it when adding it to bevy_assets, but if it changes overtime and we don't change it here then we have the same issue if user start trusting everything in the asset list assuming it's always up to date.

We also have various games. tutorials and general website links that don't have common software licenses because they aren't the same as a published crate.

It's difficult because currently bevy assets isn't really a "marketplace", it's just a place to showcase things. Most of these ideas really hinge around bevy assets being a hub for downloading bevy plugins/assets. In that case, it should be expected that a project has a publicly visible license, and adhere to some constraints.

Perhaps what we really want is the current "bevy assets" to be split into Bevy Showcase:tm: and a Bevy Marketplace:tm:. I say marketplace, but really I don't intend on people purchasing assets, it's just a hub for people to download consistently licensed assets/plugins (ala, Unreal Marketplace, Unity Asset Store, but free).

[laundmo]

We could mandate them to set it when adding it to bevy_assets, but if it changes overtime and we don't change it here then we have the same issue if user start trusting everything in the asset list assuming it's always up to date.

1. Licenses are already planned to be tracked with/for the new Asset Cards
2. Im not arguing for requiring the licenses in general be known to Assets (in this issue at least), im arguing this specific case is so clearly not great that it should be removed.

[IceSentry]

I should clarify that to me the assets page should be treated purely as a showcase.

Licenses are already planned to be tracked with/for the new Asset Cards

Licenses are planned to be indicated on the cards when we can determine a license from the given link to the asset. Which is only possible when the link goes to github/gitlab/crates.io and even then it doesn't always work because some people use non-standard project setup while still using completely fine licenses.

[wrapperup]

I should clarify that to me the assets page should be treated purely as a showcase.

I think the confusion comes from the name. I petition to rename "Bevy Assets" to something else, like "Bevy Resources", or "Awesome Bevy." 😉

[laundmo]

Just to be clear: im fully arguing for special casing this specific showcase and would likely do so with any name, whatever the larger scope descision is.

[afonsolage]

Bevy Assets is aimed to be a "Community Showcase" IFAIK

A collection of Bevy assets, plugins, learning resources, and apps made by the community. If you would like to share what you're working on, submit a PR! Feel free to create new categories where it makes sense.

Even tho you can't use some of those assets on your own project, it's still a valuable learning resource and showcase.

Also some assets listed there has no license, which means they are fully copy righted.

[mockersf]

I think Bevy Assets should enforce things added to have a license, but should not limit on licenses themselves.

That an asset has a license not compatible with Bevy is not even an issue, because the goal of the asset is not to be used in Bevy. Both Bevy and the asset license have to be compatible with the user's project.

[ozkriff]

My two cents: we faced a similar question in the gamedev.rs newsletter some time ago and decided to keep such entries with an explicit notice:

This project was released under the Katharos License. This license has moral and ethical implications that you may or may not agree with, so please read it before making use of this project.

[PROMETHIA-27]

I think the best approach is to just very clearly signpost on the assets page that there is no guarantee of a license being compatible with one's project. It's the best way to avoid licenses becoming out of date and someone mistakenly assuming that a project which once was MIT is not now GPL, or something like that.

[cart]

I think Bevy Assets should be the "go to" place to list your Bevy-related work. We should be accommodating here and list anything that doesn't violate our community guidelines (or some future "Bevy Assets Rules").

I (think) I'm on board with requiring a license: if there is no license then we're actively putting people at risk. The terms of using something listed should be clear. Ideally this comes from the "source of truth" for the asset (crates.io, github, etc).

But I don't think it is our place to limit what those terms are (or at least, within reason). I think it is our place to control what is most visible / how things are presented:

• We could have a "permissive open source" filter, which only allows a curated list of licenses (MIT, Apache-2.0, ZLib, etc)
• We could generally boost the visibility of things with "preferred" licenses
• We could make "preferred" licenses display a certain "nicer" way and "custom" licenses display a different way (maybe with a warning to read through the license terms).

In short: I do not want to unlist bevy_retro, but I do think we should do all of the things listed above to guide people toward generally preferable licenses and force them to be aware when they're going off of the beaten path.

[laundmo]

I can generally agree that those changes would be much preferable to doing nothing. Any progress on this is blocked/dependent on bevyengine/bevy-website#394 which might need some follow-up changes to allow for clearer warnings once its merged.

[IceSentry]

@laundmo if you didn't see it, we added a short intro text to the asset page to clarify it's purpose. To be clear, it's just a first step, there's plenty more to do.

[tkgalk]

Hm. Thank you for bringing this to light, definitely didn't know about this and will definitely avoid anything like this like the plague.