We just went through that formal process internally at the University of Florida to get approval for some software that we had actually released the code for already, since it was partly paid for by federal grants. Overall the process wasn't super-streamlined and one felt they needed to be arguing for the lack of commercial viability. (This won't be the next Gatorade.. I promise...)
Here are some comments from Laurie Taylor who drove most of the process here at UF:
"The University of Florida handles all software and licensing, open source and otherwise, through the Office of Technology Licensing. The official process is there for legal compliance, to ensure the correct open source licenses are used as is required when components are already open source and released under viral licenses. The official statements on policy for this aren't super clear from the outside. Our open source software releases state what open source license (https://code.google.com/p/sobekcm/ and http://ufdc.ufl.edu/software/download) but don't link people back to the main policy pages, which are complex."
"As we do more with data/digital curation and more data and software in our repository (http://ufdc.ufl.edu/), we've started talking with the Office of Technology Licensing (OTL) about doing new trainings and workshops for UF researchers who are releasing their data sets, digital materials, and open source software to parse, visualize, and otherwise interpret the raw materials. We're looking into how to best do combined trainings to fit the OTL concerns and support researchers with the least amount of additional work and confusion over complex policies."
Cheers!
Mark Sullivan / UF Libraries
________________________________________
From: Code for Libraries [[log in to unmask]] on behalf of Doran, Michael D [[log in to unmask]]
Sent: Tuesday, May 28, 2013 3:37 PM
To: [log in to unmask]
Subject: Re: [CODE4LIB] Open Source release policies
Hi David,
> If you work at an organization that releases open source software that
> your staff coders develop, I would be interested in reading your policy
> on that,
I did a presentation on that general topic at Code4lib 2007:
The Intellectual Property Disclosure Process:
Releasing Open Source Software in Academia
http://code4lib.org/2007/doran
...and have some additional info on this page:
http://rocky.uta.edu/doran/ip/
-- Michael
# Michael Doran, Systems Librarian
# University of Texas at Arlington
# 817-272-5326 office
# 817-688-1926 mobile
# [log in to unmask]
# http://rocky.uta.edu/doran/
> -----Original Message-----
> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
> David Lowe
> Sent: Tuesday, May 28, 2013 11:40 AM
> To: [log in to unmask]
> Subject: [CODE4LIB] Open Source release policies
>
> All-
> If you work at an organization that releases open source software that
> your staff coders develop, I would be interested in reading your policy
> on that, if you have one written up that you can share, or otherwise in
> hearing your common practice, if that's not too much trouble. On or off
> list as your preference would have it.
>
> I've located the following so far:
> UCSD
> https://confluence.crbs.ucsd.edu/display/CRBS/Releasing+Open+Source+Soft
> ware+at+UCSD
>
> Stanford
> http://otl.stanford.edu/inventors/resources/inventors_opensource.html
>
> Texas
> http://www.utexas.edu/cio/policies/pdfs/Procedure%20for%20Releasing%20So
> ftware%20as%20Open%20Source%20or%20Contributing%20Software%20to%20Existi
> ng%20Projects%20Licensed%20Under%20the%20GNU%20General%20Public%20Licens
> e.pdf
>
> Austrailian Computer Society
> http://people.oregonstate.edu/~alhasheh/ose/sources/OpenSourcePolicy.pdf
>
> Much obliged,
> --DBL
|