Repository navigation
Change the way we mark an entry as OSS #242
Description
Activity
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.
Reacted by Antonio VivaceI 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?
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/databaserepository.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.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...
I'm worried this may cause strain on the total size of the
gbdev/databaserepository.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.
Atm it's a manually applied 'Open Source' tag, I suggest we remove that, as "gameLicense" and "repository" should be enough