You are here

Rosetta-based projects using and licensing

4 posts / 0 new
Last post
Rosetta-based projects using and licensing
#1

Dear Rosetta Team,

Is it possible to share a code of my Rosetta-dependent non-profit research project and upload it to a publicly accessible GitHub repository licensed under open source license? Is Rosetta License restricts that?

For example, I have "project" like this:

1. Source files that links to Rosetta headers:

#include <devel/init.hh>
#include <core/pose/Pose.hh>
#include <core/pose/annotated_sequence.hh>
#include <core/chemical/ChemicalManager.hh>
// plus a lot of other includes: scoring, relax and etc
int main(int argc, char *argv[]){
    devel::init(argc, argv); 
    core::pose::Pose pose;
    std::string protein_seq = "AAAAA";
    core::pose::make_pose_from_sequence(
	pose, protein_seq, 
	*core::chemical::ChemicalManager::get_instance()->residue_type_set( 
	core::chemical::FA_STANDARD));
    pose.dump_pdb("ala.pdb");
    // using a lot of other Rosetta functions and classes
}

2. In Makefile I use path to Rosetta libs and headers:

MAIN = path_to/rosetta_src_2018.42.60459_bundle/main
INCLUDE = -I$(MAIN)/source/src -I$(MAIN)/source/external/include ... etc
LIBS = ... -ldevel -lprotocols.8 -lprotocols.7 ... -lcore.3 ... etc
all:
	g++ -c -std=c++11 ... $(INCLUDE) main.cc -o main.o
	g++ -o main ... main.o $(LIBS)

3. There is a path to libs and database in the run script:

export LD_LIBRARY_PATH=/path_to_rosetta_shared_libraries
./main -database rosetta_src_2018.42.60459_bundle/main/database -mute all

This program require only a path to a standalone Rosetta default build. Thus, if I'm right, the first statement of Rosetta Software Academic License Agreement is not violated.
1. The Software remains at your institution and is not published, distributed, or otherwise transferred or made available to other than institution employees and students involved in research under your supervision.

According to rmoretti comments (1, 2), the license don't restrict my "own creations which are otherwise Rosetta related". Please indicate if I'm mistaken.

Thanks in advance

 

update 8.11

I mark this topic as solved. I have an answer from CoMotion team. Unfortunately, didn't notice this post.

Category: 
Post Situation: 
Fri, 2018-10-26 15:45
SergeyP

I would figure you should be fine, as plenty of PyRosetta scripts that do not include PyRosetta, but scripts built calling it are in the wild and in papers.  Same for RosettaScripts.  I'm not sure I gather what the answer was from your linked post.  

Fri, 2018-11-09 09:31
jadolfbr

Sorry for the delay in getting back to you on this -- I had to consult with some people to clarify the current state of things.

The comments that you linked were referring strictly to the scientific outputs of Rosetta - that is models, designs, analysis results, etc. RosettaCommons makes no claims to the ownership of any models, designs, energy analysis, etc. you produce with the Rosetta software. Those are yours to do with as you please.

-- Note the following discussion assumes that you're an academic group, distributing your modifications for free. While the general outline should be the same for commercial entities, or those charging for their additions, the details can get complicated. Consult with UW licensing to clarify in that case.  --

The Rosetta license *does* place limitations on the Rosetta *code* (both in source and compiled form). The code which RosettaCommons provides for download is copyright of the RosettaCommons institutions, and is only permitted to be (re)distributed through the terms of the Rosetta License. The Rosetta License, however, only applies to the code which is originally distributed from the RosettaCommons website. Code that you develop yourself is not restricted by the Rosetta License, even if it makes use of Rosetta.

This means that you're permitted to distribute scripts/code which use Rosetta wherever and under whatever terms you wish, provided you've written those scripts/code yourself. This includes shell scripts which launch Rosetta, Python scripts which use the PyRosetta library, RosettaScripts XMLs, etc. This even includes C++ code for new applications or additions to the Rosetta core. So long as what is being distributed is *just* the code you've written yourself, there's no limitations imposed by the Rosetta license. You're free to upload this to Github or elsewhere under whatever license you wish. (Though see license choice discussions below.)

Where things get tricky is where you have a mix of RosettaCommons code and your own code. For example, if you have a modification to an existing Rosetta source file. Or if you've copy/pasted chunks of existing Rosetta code into your application file. In those cases, you only have the rights to distribute the portions of the code you've written yourself. The code which originated from the RosettaCommons still falls under the Rosetta license, and cannot be distributed by third parties (i.e. you). One way around this is by distributing patch files. If you distribute patch files, you're only distributing your changes to the files, and not the RosettaCommons code. You'd then distribute the patch file along with instructions on how to apply this patch file to the Rosetta code (which any potential user would have to obtain separately).

Several points on this: *de minimis* inclusion of RosettaCommons code in patch files or new code is okay. Boilerplate like general format of how a mover is set up is inconsequential. In particular, your examples of `#including`Rosetta headers, calling Rosetta functions and linking the Rosetta libraries is perfectly fine.  As long as there's not a "substantial" amount of RosettaCommons code in what you're distributing, it doesn't fall afoul of the Rosetta License. Likewise, a couple of lines of context in "context diffs" is fine too. Conversely, including significant sections of RosettaCommons code in patches because of copy/paste isn't good, even if it you did retype it, rather than a literal copy/paste. (Patch programs are rather simplistic, so if you use one, double check that the code your patch program extracts is indeed entirely your own work.)

 

Discussion on licensing: While you're free to license your additions under whatever terms you wish, I'd encourage you to pick a license which is compatible with the Rosetta license. Certain licenses (the GPL and CC-SA are two prominent examples) have requirements/goals which are at odds with the Rosetta license. While technically you can distribute a GPLed patch to Rosetta, the conflict in licensing could make things a bit thorny for people who want to use it later. I'd personally recommend something like the MIT or 3-clause BSD license, if you're looking at Open Source licenses. (A potential added benefit is that with MIT/BSD licensed code, things become easier if you want to work with RosettaCommons developers later to include your improvements into the main Rosetta release.)

Fri, 2018-11-09 13:31
rmoretti

jadolfbr, you're right, the short answer is yes. As far as I understand the post from smlewis the only proper way is to address questions like mine directly to the UW CoMotion team. Therefore I didn't post a complete answer from the team. As you said, there are plenty of PyRosetta scripts. However, I found very few Rosetta Cpp code. So the question came up.

rmoretti, thank you for the detailed and informative answer. The discussion is about non-profit research project written by an academic group for an academic purpose only. There will be no any Rosetta code modification, mixing, copy/paste, code rewriting or copying program/algorithm logic. Thank you for explaining the patch approach and that it is OK to use short (a couple of lines) standard procedures for some object configuration as well as linking the Rosetta libraries. The question wasn't directly about it, but it was bothering me. Thank you for discussing licenses. My first thought was to use the GPL, but after some search, it seems that using any copyleft license isn't the best way for research projects. Your reasoning helped me to choose a correct license.

Thanks for the replies.

Mon, 2018-11-12 09:19
SergeyP