Re: [CODE4LIB] know of guidelines for contributing to open source projects?
Thanks very much, Tom. This is really helpful stuff. On Sat, Jan 10, 2015 at 1:34 PM, Tom Cramer tcra...@stanford.edu wrote: John, Here are the relevant source docs at Stanford: Research Policy Handbook, Section 9.2: Copyright Policy, which states that the copyright of artistic, scholarly and pedagogical works remain with the creator, unless the work is a work-for-hire, or an institutional work. (We interpret that our work is generally if not always work-for-hire.) Office of Technology Licensing, Software, which states that Stanford-copyrighted software can be licensed to the academic or commercial community under an open source license. (It can also be put in the public domain.) Office of Technology Licensing, Open Source Primer, which states that Stanford staff may open source software with the appropriate departmental approval. Based on the university policies, our departmental policy states: As a matter of practice, we publish software into publicly accessible code repositories. This facilitates the review, exchange, reuse and possible code contributions from other sites--a key part of our development strategy and methodology. As best practice, we endeavor to put a clear license on this code so others know what they may and may not do with it. Staff should release it under an open source license. If it is a contribution to a current codebase that has an approved OSS license, we should contribute the code back under the this same license. If it is new Stanford code, then it should use an Apache 2 license as the default. Why Apache 2? It is desirable to have a single license to consistently to apply across all our products: so developers and managers need not try and follow a (potentially complex) decision tree on which license to apply so potential collaborators can encounter a single, well-known OSS license on our code, which facilitates adoption and contribution most if not all current projects (e.g., Hydra, Blacklight, Fedora, solr, grant-funded development is licensed under an Apache 2 license, either due to an IP agreement (with the funder), or Contributor License Agreements (CLA's) and project convention with other project stakeholders as software created in one project / effort often makes it way into reuse in another project (by design); a single license allows for this portability (i.e., local Stanford code could easily become Hydra code without a relicense or rewrite) How to License the Code: Follow the instructions here: http://www.apache.org/licenses/LICENSE-2.0.html The name of the Copyright Owner is The Board of Trustees of the Leland Stanford Junior University Copyright The Board of Trustees of the Leland Stanford Junior University Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. Finally, the Hydra Project has put considerable effort into defining a clear, repeatable licensing procedure for the community's efforts, which is particulalry useful for community-sourced efforts. (A lot of our work is contributing to shared projects, not stand-alone projects.) The Hydra community software licensing mechanics are outlined here: https://wiki.duraspace.org/display/hydra/Code+Copyright+Statement. (FYI, there is much current discussion within UC about how to legally and effectively contribute to Hydra, so this may be particularly germane.) Hope this helps, - Tom On Jan 9, 2015, at 12:11 PM, John Kunze wrote: Hi Tom, This sounds terrific. Yes, it would be very useful if you could share the source docs. I assume that the Research Policy Handbook is at https://doresearch.stanford.edu/policies/research-policy-handbook ? -John On Thu, Jan 8, 2015 at 5:10 PM, Tom Cramer tcra...@stanford.edu wrote: John, At Stanford, this is governed by the Research Policy Handbook; there is some tech transfer and copyright detail, but essentially it says staff may release University-funded code with with an open source license with officer (Dean-level) approval. At Stanford, we have put this into place with blanket approval for releasing any code we deem shareable under a license (Apache 2 being default, but not required). We have similar approval under the same terms to release non-code artifacts under a CC license. Based on this, we have templates for inserting license files into repos on Github, and default text to use for copyright statements. I can dig up source docs if that's useful.
Re: [CODE4LIB] know of guidelines for contributing to open source projects?
John, Here are the relevant source docs at Stanford: Research Policy Handbook, Section 9.2: Copyright Policy, which states that the copyright of artistic, scholarly and pedagogical works remain with the creator, unless the work is a work-for-hire, or an institutional work. (We interpret that our work is generally if not always work-for-hire.) Office of Technology Licensing, Software, which states that Stanford-copyrighted software can be licensed to the academic or commercial community under an open source license. (It can also be put in the public domain.) Office of Technology Licensing, Open Source Primer, which states that Stanford staff may open source software with the appropriate departmental approval. Based on the university policies, our departmental policy states: As a matter of practice, we publish software into publicly accessible code repositories. This facilitates the review, exchange, reuse and possible code contributions from other sites--a key part of our development strategy and methodology. As best practice, we endeavor to put a clear license on this code so others know what they may and may not do with it. Staff should release it under an open source license. If it is a contribution to a current codebase that has an approved OSS license, we should contribute the code back under the this same license. If it is new Stanford code, then it should use an Apache 2 license as the default. Why Apache 2? It is desirable to have a single license to consistently to apply across all our products: so developers and managers need not try and follow a (potentially complex) decision tree on which license to apply so potential collaborators can encounter a single, well-known OSS license on our code, which facilitates adoption and contribution most if not all current projects (e.g., Hydra, Blacklight, Fedora, solr, grant-funded development is licensed under an Apache 2 license, either due to an IP agreement (with the funder), or Contributor License Agreements (CLA's) and project convention with other project stakeholders as software created in one project / effort often makes it way into reuse in another project (by design); a single license allows for this portability (i.e., local Stanford code could easily become Hydra code without a relicense or rewrite) How to License the Code: Follow the instructions here: http://www.apache.org/licenses/LICENSE-2.0.html The name of the Copyright Owner is The Board of Trustees of the Leland Stanford Junior University Copyright The Board of Trustees of the Leland Stanford Junior University Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. Finally, the Hydra Project has put considerable effort into defining a clear, repeatable licensing procedure for the community's efforts, which is particulalry useful for community-sourced efforts. (A lot of our work is contributing to shared projects, not stand-alone projects.) The Hydra community software licensing mechanics are outlined here: https://wiki.duraspace.org/display/hydra/Code+Copyright+Statement. (FYI, there is much current discussion within UC about how to legally and effectively contribute to Hydra, so this may be particularly germane.) Hope this helps, - Tom On Jan 9, 2015, at 12:11 PM, John Kunze wrote: Hi Tom, This sounds terrific. Yes, it would be very useful if you could share the source docs. I assume that the Research Policy Handbook is at https://doresearch.stanford.edu/policies/research-policy-handbook ? -John On Thu, Jan 8, 2015 at 5:10 PM, Tom Cramer tcra...@stanford.edu wrote: John, At Stanford, this is governed by the Research Policy Handbook; there is some tech transfer and copyright detail, but essentially it says staff may release University-funded code with with an open source license with officer (Dean-level) approval. At Stanford, we have put this into place with blanket approval for releasing any code we deem shareable under a license (Apache 2 being default, but not required). We have similar approval under the same terms to release non-code artifacts under a CC license. Based on this, we have templates for inserting license files into repos on Github, and default text to use for copyright statements. I can dig up source docs if that's useful. - Tom On Jan 8, 2015, at 4:22 PM, John A. Kunze wrote: Does anyone have existing institutional policy guidelines for staff who contribute to
Re: [CODE4LIB] know of guidelines for contributing to open source projects?
Thanks, Stuart. This is great site to know about. -John On Thu, Jan 8, 2015 at 4:56 PM, Stuart A. Yeates syea...@gmail.com wrote: OSS Watch is a JISC-funded, Oxford, UK-based service that is funded to answer questions like this: http://oss-watch.ac.uk/ cheers stuart -- ...let us be heard from red core to black sky On Fri, Jan 9, 2015 at 1:22 PM, John A. Kunze j...@ucop.edu wrote: Does anyone have existing institutional policy guidelines for staff who contribute to open source software projects? A group at the California Digital Library is looking to learn from prior art in dealing appropriately with non-technical things like licensing, intellectual property, legal policy, cost/benefit issues, etc. It would be great if any of you have something like that to share. -John
Re: [CODE4LIB] know of guidelines for contributing to open source projects?
Hi Tom, This sounds terrific. Yes, it would be very useful if you could share the source docs. I assume that the Research Policy Handbook is at https://doresearch.stanford.edu/policies/research-policy-handbook ? -John On Thu, Jan 8, 2015 at 5:10 PM, Tom Cramer tcra...@stanford.edu wrote: John, At Stanford, this is governed by the Research Policy Handbook; there is some tech transfer and copyright detail, but essentially it says staff may release University-funded code with with an open source license with officer (Dean-level) approval. At Stanford, we have put this into place with blanket approval for releasing any code we deem shareable under a license (Apache 2 being default, but not required). We have similar approval under the same terms to release non-code artifacts under a CC license. Based on this, we have templates for inserting license files into repos on Github, and default text to use for copyright statements. I can dig up source docs if that's useful. - Tom On Jan 8, 2015, at 4:22 PM, John A. Kunze wrote: Does anyone have existing institutional policy guidelines for staff who contribute to open source software projects? A group at the California Digital Library is looking to learn from prior art in dealing appropriately with non-technical things like licensing, intellectual property, legal policy, cost/benefit issues, etc. It would be great if any of you have something like that to share. -John
Re: [CODE4LIB] know of guidelines for contributing to open source projects?
OSS Watch is a JISC-funded, Oxford, UK-based service that is funded to answer questions like this: http://oss-watch.ac.uk/ cheers stuart -- ...let us be heard from red core to black sky On Fri, Jan 9, 2015 at 1:22 PM, John A. Kunze j...@ucop.edu wrote: Does anyone have existing institutional policy guidelines for staff who contribute to open source software projects? A group at the California Digital Library is looking to learn from prior art in dealing appropriately with non-technical things like licensing, intellectual property, legal policy, cost/benefit issues, etc. It would be great if any of you have something like that to share. -John
Re: [CODE4LIB] know of guidelines for contributing to open source projects?
John, At Stanford, this is governed by the Research Policy Handbook; there is some tech transfer and copyright detail, but essentially it says staff may release University-funded code with with an open source license with officer (Dean-level) approval. At Stanford, we have put this into place with blanket approval for releasing any code we deem shareable under a license (Apache 2 being default, but not required). We have similar approval under the same terms to release non-code artifacts under a CC license. Based on this, we have templates for inserting license files into repos on Github, and default text to use for copyright statements. I can dig up source docs if that's useful. - Tom On Jan 8, 2015, at 4:22 PM, John A. Kunze wrote: Does anyone have existing institutional policy guidelines for staff who contribute to open source software projects? A group at the California Digital Library is looking to learn from prior art in dealing appropriately with non-technical things like licensing, intellectual property, legal policy, cost/benefit issues, etc. It would be great if any of you have something like that to share. -John
[CODE4LIB] know of guidelines for contributing to open source projects?
Does anyone have existing institutional policy guidelines for staff who contribute to open source software projects? A group at the California Digital Library is looking to learn from prior art in dealing appropriately with non-technical things like licensing, intellectual property, legal policy, cost/benefit issues, etc. It would be great if any of you have something like that to share. -John
