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

Change the way we mark an entry as OSS #242

Open
avivace opened this issue Jun 7, 2024 · 6 comments
Open

Change the way we mark an entry as OSS #242

avivace opened this issue Jun 7, 2024 · 6 comments

Comments

@avivace
Copy link
Member

avivace commented Jun 7, 2024

Atm it's a manually applied 'Open Source' tag, I suggest we remove that, as "gameLicense" and "repository" should be enough

@asiekierka
Copy link
Contributor

asiekierka commented Oct 13, 2024

I agree; merely stating that something is "open source", without clear licensing terms attached, is insufficient for qualifiying a given work as OSS, and every license commonly understood to be OSS is probably in SPDX anyway.

Note, however, that some homebrew might not have a "repository" link, but rather source code available as a separate download option (stored in a .ZIP file, say). Such homebrew would still be OSS.

@avivace
Copy link
Member Author

avivace commented Oct 14, 2024

I agree; merely stating that something is "open source", without clear licensing terms attached, is insufficient for qualifiying a given work as OSS, and every license commonly understood to be OSS is probably in SPDX anyway.

Note, however, that some homebrew might not have a "repository" link, but rather source code available as a separate download option (stored in a .ZIP file, say). Such homebrew would still be OSS.

Thanks @asiekierka . I'd like to have this in the Schema Draft 4 if possible, so if we agree on an implementation I can work on it..

So my idea was that the database doesn't decide/marks anymore an entry as OSS, but simply has field for the assets/ocde license as SPDX identifiers (or free text?).
The backend can then qualify an entry as OSS based on the values of these fields.

As for 'where' to find this source, should we have an additional way to mark if we have the source somewhere (and where)? Such as some field for the File object that can mark they contain source?

Further question: should we also try to archive such source if it's on an external repository/link?

@asiekierka
Copy link
Contributor

As for 'where' to find this source, should we have an additional way to mark if we have the source somewhere (and where)? Such as some field for the File object that can mark they contain source?

Yes, that sounds reasonable. Though there might also be the edge case of a homebrew for which the source code is lost.

Further question: should we also try to archive such source if it's on an external repository/link?

I'm worried this may cause strain on the total size of the gbdev/database repository.

@aaaaaa123456789
Copy link
Member

Further question: should we also try to archive such source if it's on an external repository/link?

Why are repositories not archived? Because we trust them to stay online.
Why should tarballs not be archived? Because we trust them to stay online! If there's a risk of some game disappearing from the Internet and someone wants to preserve it, they should mirror it, whether it's a repository, a .zip, or what have you.

@avivace
Copy link
Member Author

avivace commented Oct 14, 2024

Further question: should we also try to archive such source if it's on an external repository/link?

Why are repositories not archived? Because we trust them to stay online. Why should tarballs not be archived? Because we trust them to stay online! If there's a risk of some game disappearing from the Internet and someone wants to preserve it, they should mirror it, whether it's a repository, a .zip, or what have you.

Well, the reality is, we don't. It happens very frequently that repositories disappear. The whole purpose of https://github.com/gb-archive is to keep the resources we link from our documentation/projects online and reachable.

If this is relevant/useful for an archive of homebrew sources I don't know...

@avivace
Copy link
Member Author

avivace commented Oct 14, 2024

I'm worried this may cause strain on the total size of the gbdev/database repository.

What about a quick integration with Software Heritage ? We can ask them to make copies as soon as a new link to a source appears.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants