From: Sven <luther@dpt-info.u-strasbg.fr>
To: Patrick M Doane <patrick@watson.org>
Cc: Will Benton <willb@cs.wisc.edu>, caml-list@inria.fr
Subject: Re: [Caml-list] License Conditions for OCaml
Date: Sun, 11 Nov 2001 13:25:48 +0100 [thread overview]
Message-ID: <20011111132548.B23725@dpt-info.u-strasbg.fr> (raw)
In-Reply-To: <20011109101353.X80907-100000@fledge.watson.org>; from patrick@watson.org on Fri, Nov 09, 2001 at 10:33:02AM -0500
On Fri, Nov 09, 2001 at 10:33:02AM -0500, Patrick M Doane wrote:
> > 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.
I am not sure, in my opinion the GPL/LGPL is better, since it ensures that
people don't take the code without giving anything back.
I am sure it is nicer to people wanting to use it and sell things, but not to
people writing the code you use. In any case, i guess your company has enough
ressources, that they could negotiate a more traditionnaly licenced version of
ocaml if they whish to.
That said, you cannot link with other usefull GPL/LGPLed stuff then, and i
doubt you will ever convince the FSF or other such to relicence their code.
> > > 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?
The one you said was incompatible, it is not.
> > > 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.
I must look, but again, from previous discution on the debian-legal list, and
reading of the FSF GPL/LGPL FAQ, i belive this is not so.
> > > 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".
In section 6, you read, at the end of the second paragraph :
directing the user to the copy of this License. Also, you must do one
of these things:
followed by :
a) 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. (It is understood
that the user who changes the contents of definitions files in the
Library will not necessarily be able to recompile the application
to use the modified definitions.)
here, you clearly see that :
o you need to acompany the complete machine readable source code for the
library (ocaml runtime) => note, this can be a link to a place were you
can find it.
o and, if the work (your programm) 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 (the ocaml runtime) and then relink to
produce a modified executable containing the modified Library.
e > > 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.
Please consult your firm's lawyer about it, or search advice from the FSF, but
that is what is meant in legalese terms, and if it is not so, i am sure the
FSF may be very happy with you finding a problem with their licences and
modify it acordyingly.
> > 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.
What good will it do him if he can correct a bug in the ocaml runtime, but not
in the version of the runtime that is already linked to your app ?
> 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.
Mmm, this is something Xavier or others from the ocaml team should respond to,
But i think someone able to reverse engineer the .cmi, is also more than
likely to be able to reverse engineer the asm code as well. Maybe even more
likely ?
> > > 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.
Well, the problem is not with the compilers, but with the support libraries, i
am sure you have the same problem when linking with the libc on linux systems,
which is also LGPLed, i think.
> > > - 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"
Sur, but you could go also with :
c) Accompany the work with a written offer, valid for at least
three years, to give the same user the materials specified in
Subsection 6a, above, for a charge no more than the cost of
performing this distribution.
or
d) If distribution of the work is made by offering access to copy
from a designated place, offer equivalent access to copy the above
specified materials from the same place.
or
e) Verify that the user has already received a copy of these
materials or that you have already sent this user a copy.
> > > - 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.
Yes, but is it really a problem, and you don't even need to provide it with
your app, just offer to make it available as per d) above for example ? Most
people would not care anyway.
> > > 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.
Who is not breaking licences, how comes there are so many cross licencing
agreement all over the industry ? Because people are breaking licences all
over the place, and need to tidy up afterward.
> > 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.
But, isn't the regexp code linked dynamically ?
> > 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.
And striping your client with the reasonable assurance of a bug free app, even
if your company goes broke or the source code is lost in a disk crash or a
terrorist attack on your firm ?
> 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
and you can't from the plain asm code ?
> 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.
Again, if this is so important to you, your firm surely has the ressources to
reach another argument with INRIA and the ocaml team with regard to licences,
isn't it ?
I am still curious about what kind of code you really developp, the opensource
theory is that such protectionnism is only applicable to domains of very
leading edge technology, which are not all that numerous still today.
And that often you save more by having people with access to the source code
helping you debugging your products, than by doing it yourself. That said, i
am not sure this argument is as valid for ocaml than it is for C.
But i think we are repeating ourself here, and maybe we are boring a whole lot
of peoples on this list, so we may better take this offlist into personal mail
?
Friendly,
Sven Luther
-------------------
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
next prev parent reply other threads:[~2001-11-11 12:27 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-09 4:30 Patrick M Doane
2001-11-09 4:48 ` Rafael 'Dido' Sevilla
2001-11-09 8:45 ` Xavier Leroy
2001-11-09 15:52 ` Dave Scott
2001-11-09 16:40 ` David Brown
2001-11-09 16:40 ` Brian Rogoff
2001-11-12 8:07 ` Tom
2001-11-12 15:58 ` David Brown
2001-11-09 4:49 ` Will Benton
2001-11-09 5:35 ` Patrick M Doane
2001-11-09 5:53 ` Michael Welsh Duggan
2001-11-09 5:58 ` Patrick M Doane
2001-11-09 9:27 ` Sven
2001-11-09 9:58 ` Julian Assange
2001-11-09 10:37 ` Sven
2001-11-09 15:39 ` Patrick M Doane
2001-11-09 15:36 ` Patrick M Doane
2001-11-09 9:25 ` Sven
2001-11-09 15:33 ` Patrick M Doane
2001-11-09 16:26 ` Tom
2001-11-11 12:25 ` Sven [this message]
2001-11-09 11:09 ` malc
2001-11-09 14:46 ` [Caml-list] ELF i386 dynamic linking patch. was: " Jeff Henrikson
2001-11-10 0:32 ` [Caml-list] " malc
2001-11-09 5:50 ` [Caml-list] " Michael Welsh Duggan
2001-11-09 8:59 ` Sven
2001-11-09 15:13 ` Patrick M Doane
2001-11-11 12:00 ` Sven
2001-11-11 14:56 ` Patrick M Doane
2001-11-26 16:21 ` Fergus Henderson
2001-11-26 16:47 ` Patrick M Doane
2001-11-27 10:28 ` Fergus Henderson
2001-11-27 10:58 ` Rafael 'Dido' Sevilla
2001-11-28 18:00 ` Xavier Leroy
2001-11-30 8:05 ` Sven
2001-11-09 20:54 ` Vitaly Lugovsky
2001-11-09 21:39 ` Patrick M Doane
2001-11-11 12:42 ` Sven
2001-11-11 22:05 ` Tom
2001-11-09 15:55 Dave Berry
2001-11-28 20:29 John Field
2001-11-28 22:08 ` Al Christians
2001-11-29 1:25 ` james woodyatt
2001-11-29 8:47 ` Florian Hars
2001-11-30 7:12 ` james woodyatt
2001-11-29 7:11 Ohad Rodeh
2001-11-29 19:49 David Gurr
2001-11-30 1:18 Don Syme
2001-11-30 1:59 ` Julian Assange
2001-12-01 3:23 ` Richard Stallman
2001-12-04 18:53 ` Sven
2001-12-06 2:46 ` Richard Stallman
2001-11-27 19:10 ` John Field
2001-11-28 18:22 ` Xavier Leroy
2001-11-28 19:14 ` Ronald Kuehn
2001-11-29 0:38 ` Julian Assange
2001-11-29 8:32 ` Xavier Leroy
[not found] ` <20011129105008.DEBFD25A1B@suburbia.net>
2001-11-29 12:50 ` Xavier Leroy
2001-11-29 13:42 ` Jérôme Marant
2001-11-29 13:11 ` Greg Bacon
2001-11-29 23:01 ` Julian Assange
2001-11-29 23:13 ` Greg Bacon
2001-11-29 8:31 ` Florian Hars
2001-11-29 8:43 ` Daniel de Rauglaudre
2001-11-29 9:04 ` Jérôme Marant
2001-11-29 9:15 ` Xavier Leroy
2001-11-29 9:29 ` Jérôme Marant
2001-11-29 9:25 ` Daniel de Rauglaudre
2001-11-29 9:35 ` Jérôme Marant
2001-11-29 8:53 ` Xavier Leroy
2001-11-30 8:09 ` Sven
2001-12-07 0:09 ` YAMAGATA yoriyuki
2001-12-07 7:11 ` Richard Stallman
2001-12-06 12:26 ` Sven
2001-12-07 3:12 ` Richard Stallman
2001-12-10 15:28 ` Sven
2001-12-10 23:24 ` Jacques Garrigue
2001-12-11 4:22 ` hooh pxw
2001-12-11 10:19 ` Sven
2001-12-11 7:15 ` Richard Stallman
2001-11-30 4:25 Gregory Morrisett
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20011111132548.B23725@dpt-info.u-strasbg.fr \
--to=luther@dpt-info.u-strasbg.fr \
--cc=caml-list@inria.fr \
--cc=patrick@watson.org \
--cc=willb@cs.wisc.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox