Re: [Caml-list] [OSR] Suggested Topic - License

[Edgar Friendly <thelema314@gmail.com>]

Grundy, Jim D wrote:
> One issue to be considered in a an external library standardization
> process is the license under which libraries accepted to the standard
> are made available.
> 
> The obvious choice here is the same license as the OCaml standard
> libraries themselves (LGPL V2 + linking exception).  Except that this
> isn't quite the same as the libraries distributed by INRIA.  For those
> libraries companies have the option of joining the Caml Consortium, in
> which case they may license the standard libraries under a more liberal
> (for my intended meaning of the word) 4-clause BSD-like license, which
> is probably more appealing to many corporations.  For example, you may
> wish to consider if you would like ported versions of the libraries
> released with F# and how the choice of license might make that possible
> or not.  It may be worth investigating simply adopting a more liberal
> (again, for my intended meaning of the word) BSD-like (3 clause version
> perhaps) to  spur wider corporate adoption of the proposed standard.
> 
> Just something to think about.
> 
> Jim

You have an interesting point.  It seems quite reasonable that the
licensing of extensions to the OCaml stdlib have at least as permissive
license as LGPL V2 + linking exception.  For those (7?) companies in the
Caml Consortium, the difference comes down to... having to distribute
source to modifications to the extended stdlib if they distribute code
using those modifications.  (Correct me if I'm wrong on this, IANAL.)

I hear of most companies seriously using OCaml re-implementing their own
standard libraries anyway, and the "cost" of sharing some of their
improvements to community-developed extensions of stdlib seems quite
minor to me.  The easy workaround for these companies looks like not
modifying the extended stdlib, but to use their own stdlib replacements
(which they have license to) and to make the internal stdlib sufficient.

That said, I hope these companies will not adopt such an adversarial
relationship with the community developing an extended stdlib.  I hope
they contribute the gems of code they have in their internal stdlib to
the community one, and gain benefits themselves when others using the
community stdlib contribute their changes back to the community.

E.