 |
 |
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 yyyy 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 <[log in to unmask]> 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 >>