Re: [Caml-list] License Conditions for OCaml

[Patrick M Doane <patrick@watson.org>]

On Fri, 9 Nov 2001, Sven wrote:

> On Fri, Nov 09, 2001 at 12:35:11AM -0500, Patrick M Doane wrote:
> > OCaml doesn't provide support for shared libraries (although 3.03 does
> > provide some dynamic loading capabilities for bytecode only). So we
> > need to consider the portions of the license that apply for static
> > linking. The LGPL provides some rather contradictory statements in section
> > 6 regarding that:
> >
> >   1. you may also compile or link a "work that uses the Library" with the
> >      Library to produce a work containing portions of the Library, and
> >      distribute that work under terms of your choice, provided that the
> >      terms permit modification of the work for the customer's own use and
> >      reverse engineering for debugging such modifications.
>
> And you didn't read the part about providing the object files instead of the
> source, didn't you ?

Yes, I refer to that below - and it is in contradiction with this
paragraph. It's not listed as an exception so I don't know what that means
in legal terms. The most conservative answer is that I must do what can
support both clauses - that is to provide source.

> The real problem is that the GPL and LGPL are long, with lot of legalese
> things, and difficult to understand in a fast glance, maybe we should prepare
> a small ocaml and LPGL faq or something such. That said, any legal document
> would cause the same problems, i think.

Hmm... I doubt anyone would be complaining if this were released with the
MIT License. That is much simpler to understand.

> > This clause is enough to throw out most commercial applications. It is
> > standard industry practice to disallow reverse engineering. Most software
> > companies are going to resist changing this - and for good reason too.
>
> Sure, but there is another clause below which lift these problems.

Where?

> > Note that the license terms must also permit "modification of the work for
> > the customer's own use". I'm not sure of any way to comply with that
> > without providing source code.  Object files are certainly not suitable
> > for modification by customer use.
>
> The work being the ocaml runtime system in this case.

No, that is the library. The first sentence of section 6 reads "you may
compile or a link a 'work that uses the Library'" so it is clear that
'work' refers to my application.

> >   2. Accompany the work with the complete corresponding machine-readable
> >      source code for the Library including whatever changes were used in
> >      the work (which must be distributed under Sections 1 and 2 above); and,
> >      if the work is an executable linked with the Library, with the complete
> >      machine-readable "work that uses the Library", as object code and/or
> >      source code, so that the user can modify the Library and then relink
> >      to produce a modified executable containing the modified Library.
>
> Here is all you need to know about it, it says it quite clearly, you have to
> provide the object files, so that your client can rebuild your app with a
> modified version of the Library, that is the ocaml runtime.
>
> What's the problem with that ?

It contradicts what is said earlier - that the user must be able to modify
the "work".

> > Here it suggests that object code is sufficient but this can't be modified
> > for the customer's own use. Perhaps this contradiction invalidates this
> > section of the license, I don't know. I'm not a lawyer. The only
> > reasonable way I see to comply with these two points is to provide source
> > code.  Do you have any suggestions on how a user can modify object code
> > for their own use?
>
>
> No, the customer need to be able to modify the ocaml runtime, not your code,
> and he can do that if you provide the object files.

This might very well be the intent of the LPGL but it clearly says that
the customer must be able to modify my work, not the ocaml runtime.

> If you don't provide the object files, the user cannot modify the ocaml
> runtime, as the LGPL allows him, and as thus you take this right from him.

Of course the user can modify the ocaml runtime - there is the question as
to whether the user can modify it and relink it with my application.

But the object files expose too much proprietary information. The .cmi
files include the names of identifiers plus their types. Even the
identifiers alone are too much.

> > These issues aside, the LGPL is still a real pain to deal with.
> >
> >   - The LGPL text must be included with the distribution.
>
> Well, yes, this is normal, what is the problem with that ? It is just a
> relatively small text file, and any commercial distribution comes with it's
> licence and licence of their subparts, is that not so ?
>
> That said, you could well move all the needed object files and this licence
> into a subdirectory, and no more worry about it.

Sure, this isn't unworkable, my point is that there are things that a user
of OCaml has to do when shipping an executable. Most compilers I've worked
with in the past don't have these kinds of restrictions. You build your
binary and ship it.

> >   - All copyright notices for the product need to include the copyright
> >     notice for Inria
>
> mmm, don't know about this, but it is no more than a line saying that :

>From section 6: "If the work during execution displays copyright notices,
you must include the copyright notice for the Library among them"

> This sotware includes code from ocaml dcopyrighted by inria and licenced under
> the LPGL.
>
> Or something such, what is so difficult about it ? This is a standard legal
> requirement for other stuff, or do you wish to not give proper credit to the
> ocam lteam and inria ?

I never said that it's difficult. I'm just listing what the requirements
of the LGPL are.


> >   - All source to the INRIA libraries and standard runtime must be
> >     included in the distribution. This is particularly annoying for
> >     Windows developers because that distribution doesn't come in source
> >     form.
>
> Huh ? Are you sure, i would have to read again, but i don't think it says
> this, What you may need though, is to give a link to a place were it can be
> downloaded, something like adding 'which can be downloaded from
> ftp.inria.fr.' to the above phrase would be enough to comply with this, or
> maybe just a redirection to the caml web pages.

>From section 6: "Accompany the work with the complete corresponding
machine-readable source code for the Library including whatever changes
were used in the work"

> >   - All source code (or perhaps object code) for my application must
> >     be come with distributed.
>
> Object code only, this you cannot avoid.

I can avoid this with another license - and this is the problem with the
LPGL.

> > There are other license problems as well. In particular, some of the
> > libraries distributed with OCaml (like Str) are based on GPL code, but the
> > manual does not mention this and it would be very easy for a developer to
> > get into trouble because of that.
>
> Only if the authors sue them.

They are still breaking a license regardless of whether the authors sue
them.

> Do you really think the ocaml team or xavier, or whoever will sue you for
> using ocaml ?

No, but they didn't write the regexp package. I certainly believe the FSF
would *love* to do this.

> Please, do you still feel so with these clarifications, i am sure you
> can find a compromise with INRIA, maybe against a small fee or a
> consortium membership, and they can provide you with a version of
> ocaml licenced another way. It will not solve the GPled str problem,
> if it really is so, though.
>
> But then, maybe these clarificatiosn are enough ?

The license is reasonable when delivering a stripped static binary is
sufficent. Additional clauses like giving credit to INRIA are perfectly
acceptable but it's very important to be able to take reasonable steps to
protecting proprietary information.

I can tell you that if I had access to the .cmi file for a competitors
product, it would be very easy to steal their code.  The implementation
hardly matters here. Giving away the names of identifiers and their
corresponding types is so much information. They are in no position to
protect their work because they must allow me to reverse engineer it.

Patrick

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr