Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] possible typechecker bug
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: skaller <skaller@o...>
Subject: Re: [Caml-list] Commercial application written in O'Caml: ExcelEverywhere
On Sat, 2003-09-20 at 00:49, Richard Jones wrote:
> On Fri, Sep 19, 2003 at 09:10:49PM +1000, skaller wrote:
> > Agree. Too many LGPL contributions, which I can't
> > use in my open source project because it has a 
> > public domain licence -- I *desire* to encourage
> > commercial use of my code: the more users the better.
> 
> Are you sure LGPL is a problem in this case? LGPL is a great
> compromise license because you get the changes to your library back,
> but commercial (and other) users can always use the library. I prefer
> it over GPL most of the time.

Yes:

LGPL is not a problem for Ocaml Standard Libraries.
I am happy to require my clients to download and
build the Ocaml standard distribution (or obtain
some prebuilt version, eg for Windows).

But I am not willing to require they download
a fourth party library (unless it is in heavy use).
In the case I need some library functionality,
I have to take responsibility for it myself,
and I can't do that for LGPL libraries because
my sources are FFAU (free for any use).

In particular FFAU permits a commercial developer
to take my source codes -- including any included
fourth party library -- and do whatever they want
to with them (provided they don't lie about who
is responsible).

In particular, I would like my product to
be ISO Standardised, and that requires
unequivocable unencumberance: there is no way
an ISO committee can standardise something they're
not free to modify, and whose interface
specification cannot be owned by ISO.

In the case of C++, for example, a sort algorithm
in STL had a performance requirement which 
some vendors feared would require using a 
particular patented algorithm (since it is 
the only sort known meeting the requirements).
To proceed a letter was required from the patent
owner relinquishing all ownership (the owner
was Hewlett Packard and the permission was given).

For this reason C++ boost required all contributions
to be FFAU. In particular, LGPL codes were not
acceptable. 

You will see then that I CANNOT make my codes
LGPL, because 200 people might contribute,
and it is very hard to get 200 people to all
agree to a change of licence conditions :-)

I can tell you my experience in commerical organisations
is that whilst they're happy to use GPL'd products as
tools in-house, they won't risk distributing anything
with such a woefully complex licence as LGPL, no matter
what the actual implications of the licence are, or are
intended to be (unless they're very big and have lots of
lawyers :-)

I had this problem myself with Ocaml, where I was only
using it to build a product to be sold (but that product
would contain library codes from the standard distribution).
That company didn't have any lawyers, and the issue was considered
by a technical product manager who was a C++ devotee.

As an example, they already used some open source code
in their product, and modified it. No way it would make
ANY sense at all to give back the changes, since they
were related to their particular needs, and the result
would not built without proprietary parts of their product.
Had *that* library been LGPL, they would not have been
able to use it.

Whilst its doubtful GPL or any other software licence
has any legal standard whatsoever, most companies
don't want to risk litigation. They'd rather pay
someone or someones to develop an equivalent they
have unequivocable ownership of: this is true even
if they're willing to make the sources publically
available (they still have to sell the product built
on those sources, and thus need to claim ownership
thereof).

There are exceptions, for example specialist open source
companies such as RedHat or VA Linux.


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners