Hello,
My name is Or and I'm new to this forum so I appologise if my query is trivial or if this is not the right sub forum or category.
I work as a software developer at a company that uses Rosetta, we have a commertial licence. Sometimes, we change the CPP code, for example to add a new mover.
We wish to create an inner github repo of Rosetta to keep track of our own changes.
We have tried to naively creating a local repo and pushing it to gihub, using the source that we download using our commertial license, this method introduces some problems such as handeling very large commits.
I know I can create a script that takes the source code and commits mini baches of it every time, I fear this might break things.
Is there anything easier/safer I can do?
I know that Rosetta's repo is only accessible for academic users, is there a way I can create a fork of the repo for commertial usage?
Thank you kindly!
Or
Hello,
There are a few things in development in regard to this (https://rosettacommons.blogspot.com/2023/02/future-of-rosetta-task-force-update.html), but in the meantime, you should be able to ask for commercial developers license. In that way, you would have access to the private github repo and can put your changes back into Rosetta for others to use. You could also work in a branch with your code, but any fixes/etc. could be merged in to benefit the code base. If you are interested in this, you can sign an agreement through CoMotion license group. It's pretty straightforward. I would ask whomever setup the license to email CoMotion in order to ask about it.
The Official Rosetta development Git is for RosettaCommons members only, and we don't (currently) permit forks. I think we do have a "releases" repository that's accessible for academic users which has just the release version of the code in it. I don't believe we have issues with it, though I don't believe it's on Github. (Github will enforce size restrictions over and above what Git itself imposes.)
What I might suggest you do is based on what we do with the development Git repo -- submodules. You can break the Rosetta distribution down into submodules, and thus each submodule only has to take a fraction of the code. For example, you could split source/ out as a separate submodule from demos/ and documentation/, rather than attempting to put everything together into a single repo. (Honestly, unless you're actively working on demos and documentation, etc., you might just be able to omit them from your repo altogether.) By being judicious about which subdirectories are submodules, you can probably reduce things to be small enough.
One final note, of which you're probably already aware. If you do post your internal Rosetta repo to Github (or some other such site), make sure you make it a private repo, accessible only by company-internal people. Posting the code in a way the general public can access would be a violation of your licensing terms.
The problem might be about wanting to set up a private repo to protect proprietary code that the company has developed. If the company is paying for Rosetta, they have absolutely no obligation to turn over new algorithms (new IP that they own) to the Commons, or make their new methods visible to their competitors by putting them in a shared repository. (Indeed, no one has any obligation to turn over new IP to the Commons, unless their employer expects them to do so, or they themselves are employed by the Commons.)
You can set up a private fork of the RosettaCommons repository using either Bitbucket or Gitlab; either of these have repo size limits that are larger than the Rosetta repository. Alternatively, you can set up a partial or shallow clone (with history only going back a certain amount of time) on Github. In any of these cases, you'll need to do this on the commandline. (You create a new repo at, say, Bitbucket, set a new origin for your clone of the Rosetta repo that points to the Bitbucket repo, and push the branches and tags that you want in your fork for a full clone. For a partial or shallow clone, there may be additional steps.) You will also need to fork a number of the submodules that are necessary for compilation, and you'll need to be sure to grab the tags (not just the commit history), since the versioning script looks for these.