Thanks very much, Tom. This is really helpful stuff.
On Sat, Jan 10, 2015 at 1:34 PM, Tom Cramer <[log in to unmask]> wrote:
> 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
> Office of Technology Licensing, Open Source Primer, which states that
> Stanford staff may open source software with the appropriate departmental
> 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
> > 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
> > 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
> >> 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
> >> to release non-code artifacts under a CC license.
> >> Based on this, we have templates for inserting license files into repos
> >> 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
> >>> 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