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)
|