oor-forum
[Top] [All Lists]

Re: [oor-forum] OOR Sustainability

To: apease@xxxxxxxxxxxxxxxxxxxxxx
Cc: OpenOntologyRepository-discussion <oor-forum@xxxxxxxxxxxxxxxx>
From: Cameron Ross <cross@xxxxxxxxxxxx>
Date: Fri, 17 Sep 2010 15:28:18 -0400
Message-id: <AANLkTi=CY-ET2VejiVVFp+VRza9z1Ykwv6St8VzFehx9@xxxxxxxxxxxxxx>
Hi Adam,

On Fri, Sep 17, 2010 at 12:25 PM, Adam Pease <adampease@xxxxxxxxxxxxx> wrote:
Hi Cameron,


> I've used a similar model for some of the initiatives I've worked on
> and one of the challenges I've faced is that evangelizing is a huge
> effort.  This is not necessarily a bad thing, I love doing it, but how
> do you fund the champion to do the evangelizing... its not a
> deliverable that is often covered by most funding sources.  Perhaps
> you have some suggestions around funding the champion(s).
>

Most of my government projects encourage, if not explicitly pay for,
publication.  Presenting results at conferences has been one way of
getting the word out, and talking with people who wind up adopting SUMO
in their work.

I think this is a great opportunity where funding agencies support it.  Unfortunately, this hasn't been the case in my jurisdiction.
 

>         - Open source.  Ontology, and particularly formal ontologies
>         in first
>         order logic, are still a bit speculative as far as the
>         marketplace is
>         concerned.  This was dramatically more so in the year 2000.
>          Giving away
>         SUMO has led to its adoption on many projects.  Academic
>         projects
>         certainly would not have paid for it, and it is that body of
>         experience
>         in validating SUMO that has led to commercial use.
>
>

I'm not a lawyer, and as you note there are many licenses, but I like
LGPL for software and GNU FreeDoc for ontology (recalling that I don't
have the power to change my all own stuff to this model at the moment).
Even with my slightly suboptimal current licensing, there have been few
obstacles.  A few companies have balked at the GPL, but my sense is that
they weren't going to contribute to the project or buy a license anyway.

I see most companies selling services or custom software.  That's what
has worked for me.  A few very large or well-funded niche providers may
sell shrink-wrapped software.  Many seem to take a model of keeping the
software proprietary mainly as a way of keeping their competitive
advantage and barriers to entry, while still mainly selling services.

Using LGPL would allow incorporation of open source code into commercial
software and seems to me to be the best option on balance.

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).  The Apache position in this matter may be found here: http://www.apache.org/legal/3party.html (search for LGPL). The Eclipse Foundation's current position w.r.t. to the LGPL may be found here: http://www.eclipse.org/org/foundation/boardminutes/2010_03_exhibits/ExhibitK.pdf.  The Eclipse Foundation position w.r.t. the GPL is summarized here: http://dev.eclipse.org/blogs/mike/2010/04/06/epl-gpl-commentary.  

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.


Adam

> I think there's consensus in the group on releasing both the OOR
> content and source code under open licenses.  I also believe that many
> in the group would agree that supporting commercial use is a good
> thing (or it is at least acceptable).  I think that the main problem
> will be in deciding which licenses we will choose.  Here's my two
> cents...
>
>
> As a software developer that has contributed to several open source
> projects, I have some relatively strong opinions on open source
> licenses.  There is no single license that view as being the one
> "true" open source license.  Rather, it depends on the situation at
> hand.  Here are some of the rules I go by:
>
>
> 1)  If I invest a non-trivial amount of time on an open source project
> then it just has to have a commercial play for me... period.  As they
> say, there is no free lunch, and since I work for a small company, I
> need to make every hour countso that we can keep the lights on, pay
> our mortgages, feed our families etc.  It's just reality... take this
> ability away and the investment must be made elsewhere.  Note,
> however, that some investments can be strategic and longer term, which
> is what the Samian Platform and COLORE project represent for Kojeware.
>
>
> 2) If I invest a non-trivial amount of time on an open source project
> then I want to be able to use this project's code within my
> proprietary products (see #1).  A significant part of our business
> model is selling software products.  We want to share the development
> costs of building software infrastructure that would be of use to
> others, but we need to be able to sell software that uses this
> infrastructure.  We're doing this now with the Samian Platform.  It's
> an open source project that we've funded, but we would like to share
> future development costs with a broader community.   We use Samian
> within our commercial Ontology Development Environment product.  The
> project license must support this kind of commercial application,
> which is why Kojeware can't invest in projects that adopt the GPL.  I
> suspect that Articulate can live with the
> GPL because its business model is based on consulting services (Adam,
> please correct me if I'm wrong).  However, IMHO the OOR must support
> both product and service models.
>
>
> 3) I am not a fan of the dual licensing model whereby software is
> released under GPL for open source projects and a proprietary license
> for commercial applications.  I think that this model imposes a
> barrier to recruiting contributors.  Why would I write software and
> then give it to you so that you can go and sell it?  So, if down the
> road I want to use the code I've written within a commercial app, I
> will have to buy a license from you!  I think that most developers are
> smarter than that and won't contribute to the project.
>
>
> 4) Gift licensing is a reasonable alternative from my perspective.
>  However, as Bruce Perens noted, it can be a barrier to recruiting
> other developers (Bruce indicated that he wouldn't contribute to
> projects that release under a gift license... or maybe he just meant
> BSD... I can't remember).   The problem here is similar to my concern
> with the dual licensing model mentioned above in that a developer
> gives their work to someone else who can make money on it.  However, I
> see gift licensing as an improvement over dual licensing in that at
> least the code remains open and I can use it within my own future
> commercial applications without having to pay someone else.  I just
> can't stop you from making money with it.
>
>
> 5) I like the Eclipse Public License (EPL) because it's "something
> in-between" a gift license and the GPL.  That is, you are still
> required to release derivative works under the EPL, but you can use
> the code within commercial applications.  I believe that this is the
> best model to support open source infrastructure that is intended to
> support a software ecosystem and there are some great examples, the
> Eclipse Tool Platform for one.
>
>
> 6) I still don't have a opinion on which option is best for licensing
> ontology content.  However, based on Jon Wilbank's comments yesterday,
> it is clear that we have to balance ontology "interoperability" with
> "openness".  Interoperability seems best serviced with something like
> CC-by, whereas openness seems best serviced with something like
> CC-by-sa.  Given a choice between the two, I would lean towards
> interoperability.
>
>
>         - Good technical solution.  Obviously, what's being produced
>         has to
>         work, and be broadly applicable to get traction with a group
>         of
>         committed users.
>
>
> I agree.  Broad applicability seems like it will be key to a healthy
> ecosystem for OOR.
>
>
>         - Continued change and evolution.  The product has to respond
>         to the
>         marketplace.  Good customer service in making changes and bug
>         fixes is
>         important.  So is a bit of "push" in creatively adding new
>         features and
>         components.
>
>
> Absolutely!  Again, the ecosystem model leaves thinks free so that
> niche players within the ecosystem can differentiate and innovate as
> the market evolves.
>
>         Adam
>
>
>         On Fri, 2010-09-17 at 08:43 -0400, Cameron Ross wrote:
>         > In yesterday's ONTOLOG session on IPR, Alan Rector
>         summarized his
>         > experiences with the GALEN and SNOMED projects.  During his
>         > presentation Alan brought up the issue of sustainability
>         (i.e. the
>         > ability for a project to continue to survive once its
>         initial seed
>         > funding has been depleted).  I'm not aware of any discussion
>         related
>         > to OOR sustainability as yet.  I believe this is a problem
>         as we are
>         > starting to talk seriously about licensing models for OOR
>         and the
>         > licensing models we choose will have a definite impact on
>         the business
>         > models that the OOR will be able to support.  Presumably,
>         the long
>         > term sustainability of the OOR will be predicated on its
>         licensing
>         > models.  I'd like to start a thread on this topic so that we
>         can
>         > elicit input from the OOR group prior to our final session
>         on IPR on
>         > September 30th.
>         >
>         >
>         > What are the groups thoughts in this regard?
>         >
>         >
>         > Cameron.
>         >
>         > --
>         > Kojeware Corporation
>
>         >
>         _________________________________________________________________
>         > 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
>
>
>
>         _________________________________________________________________
>         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
>
>
>
> --
> Kojeware Corporation
>





--
Kojeware Corporation

_________________________________________________________________
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     (01)
<Prev in Thread] Current Thread [Next in Thread>