[Top] [All Lists]

Re: [oor-forum] OOR Sustainability

To: OpenOntologyRepository-discussion <oor-forum@xxxxxxxxxxxxxxxx>
From: John Graybeal <graybeal@xxxxxxxxxxxxxxxxxx>
Date: Tue, 21 Sep 2010 17:16:14 -0700
Message-id: <BCDEC53C-8928-42BF-A598-885DB6D56C90@xxxxxxxxxxxxxxxxxx>
I have been painfully pursuing this question for source code on two projects (a 
big oceanographic cyberinfrastructure project, and MMI's ontology tools) and 
for ontology resources for MMI's ORR (sorry for the near acronym 
near-collision...).    (01)

On Sep 17, 2010, at 12:28, Cameron Ross wrote:    (02)

> The problem with LGPL is that it prevents the code from being re-distributed 
>from projects that are hosted as Eclipse Foundation projects or within Apache 
>products (and probably others).  This reduces the "interoperability" of LGPL 
>components from a licensing perspective (very unfortunate really).      (03)

Yes, precisely. It is also worth noting that some places, UC San Diego in the 
US being one, are fairly strongly opposed to any of the GNU licenses. They are 
OK by policy with BSD, but everything else is on a case-by-case basis. Not that 
it directly impacts OOR, but this obviously creates a BSD bias in my brain.  
(UCSD didn't develop MMI's code, so no worries on that score.)    (04)

> Unfortunately, there are now easy answers.  We're going to have to consider 
>license compatibility very carefully if we're to maximize the interoperability 
>of OOR source code.    (05)

Yes.  I've concluded there is no obviously best answer, or even an obviously 
good answer.  I do think that the idea of making money off the source code 
directly is a non-starter for OOR, in case anyone is still thinking about it.    (06)

There are also other considerations, to wit protecting yourself and/or your 
organization. UCSD suggests a 'click-wrap' permission statement contains 
several important legal statements, which include:
        • Disclaiming any implied or express warranty.
        • Disclaiming any liability that may arise from the use of the program.
        • Requiring the users to acknowledge the copyright is owned by The 
Regents of the University of California and satisfies a requirement for 
continued ownership by the university.    (07)

It is possible all of these are secondary for this kind of software, but sooner 
or later a potential contributing organization may care, and then you'd be 
stuck.    (08)

For a project as diffuse as OOR, I think you should give serious thought to the 
"if it's on the web it's free" model.  Someone who is clearly in a position to 
legally do so starts the project (e.g., on SourceForge or Google Code), 
includes some statement to the effect of 'all contributions must be openly 
available to the entire community', and then it is the responsibility of each 
contributor to contribute their code legally.  Of course, if you are using 
Stanford or other code as the base, and you want *everything* up there on 
SourceForge, you'd need to get clearance for that....    (09)

Last, with respect to the IP of the ontologies, you definitely want to figure 
out what your model is before accepting any. A click-wrap for submitted 
ontologies—which I'd argue should say "you acknowledge this is openly and 
freely available for all uses, and that you have the authority to provide it 
under that agreement"—is the only way users can be sure they can comfortably 
use any of the ontological content, and the only way you can be sure you are at 
least a bit protected when someone submits protected content to your repository.    (010)

John    (011)

John Graybeal
Marine Metadata Interoperability Project: http://marinemetadata.org
graybeal@xxxxxxxxxxxxxxxxxx    (012)

Message Archives: http://ontolog.cim3.net/forum/oor-forum/  
Subscribe: mailto:oor-forum-join@xxxxxxxxxxxxxxxx 
Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/oor-forum/  
Shared Files: http://ontolog.cim3.net/file/work/OOR/ 
Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OpenOntologyRepository     (013)
<Prev in Thread] Current Thread [Next in Thread>