-
-
Notifications
You must be signed in to change notification settings - Fork 187
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
Pre-submission enquiry #1339
Comments
Are the individual components that you can publically release under an OSI-approved licence usable and useful without the ones that you will be holding back? If not, then the software may not meet JOSS's core "obvious research application" requirement. Regarding the authorship records, AFAIK there's no requirement that these take the form of a Git commit log. You could instead credit the authors in comments in the individual source files, and/or in a dedicated text file listing the contributors. |
not commenting on scope, but you could fork the repo and use git-filter-repo to remove the stuff you need to keep private, preserving the rest of the repo history |
@sneakers-the-rat do you have any experience with https://github.com/open-condo-software/gitexporter ? |
no, but it seems pretty much like a tool to do what i'm thinking of :). make a fork/copy the repo and modify the remotes. edit: this is neither legal, security, or official JOSS advice <3 |
I am currently preparing to submit a paper to the Journal of Open Source Software and intend to publish the accompanying code. The codebase is housed in a private GitHub repository. Due to confidentiality constraints, not all content in the repository can be made public at the time of the paper's publication.
To comply with JOSS's open-source requirements, I am considering creating a parallel public repository that includes only the components releasable at this stage. However, I am concerned that this approach might result in the loss of the original commit history and the contributions' authorship records.
Could you please advise on the best practices or recommend strategies for managing this situation?
The text was updated successfully, but these errors were encountered: