[Caml-list] License Conditions for OCaml

[Caml-list] License Conditions for OCaml

[Patrick M Doane]

Earlier this year there was a discussion about the problems of using LGPL
for the OCaml run-time system and associated libraries.

It was suggested that some of the constraints in the LGPL were not
intended. To quote a page from the Caml website:

  "The LGPL puts no restrictions at all on programs linked with LGPL-ed
libraries. Thus, users are free to distribute (or not) OCaml-generated
binaries under whatever conditions they like."

>From my reading of the LGPL, which seems to correspond with the opinions
of others on the list, this just isn't true.  If I develop an application
with OCaml, I must distribute that application with source code.  This
isn't acceptable for commercial development and I'd really hope that the
intention is for OCaml to be used outside of academia.

Will this problem be fixed for the 3.03 release?

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

Re: [Caml-list] License Conditions for OCaml

[Rafael 'Dido' Sevilla]

On Thu, Nov 08, 2001 at 11:30:56PM -0500, Patrick M Doane wrote:
>   "The LGPL puts no restrictions at all on programs linked with LGPL-ed
> libraries. Thus, users are free to distribute (or not) OCaml-generated
> binaries under whatever conditions they like."
> 

Yeah, this is a slightly misleading statement, unless the OCaml
development team has made a modification to the LGPL similar to what was
done for the Guile license, which is LGPL with one additional clause:
blanket linking is allowed for Guile. (OCaml dev team, is this also the
license under which the runtime exists?)

If you read the license, how it works is that if you link *dynamically*
with LGPLed libraries, there are no restrictions on the license of the
linking program.  That means you have to have a shared library version.
If you have a statically linked program, or on some system that doesn't
support shared libraries/DLL's, you are going to be in violation of the
lesser GPL by linking to the static versions of the library.

You do need to distribute source code for the OCaml runtime libraries
though, with any and all modifications you made to those libraries as
well (if any).  But you need not distribute source for those programs
which are linked dynamically to the runtime libraries.  That's why
programs like the Linux Yahoo! Messenger client can get away with
linking to a LGPLed library like GTK+ without revealing their source
code.

-- 
Rafael R. Sevilla <sevillar@team.ph.inter.net>   +63(2)   8177746 ext. 8311
Programmer, Inter.Net Philippines                +63(917) 4458925
http://dido.engr.internet.org.ph/                OpenPGP Key ID: 0x5CDA17D8
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Will Benton]

> [...]
> >From my reading of the LGPL, which seems to correspond with the opinions
> of others on the list, this just isn't true.  If I develop an application
> with OCaml, I must distribute that application with source code.

Whoa, nelly!  I don't know that I'd characterize the LGPL as a
"problem", but your reading of it is completely off the mark.  The LGPL
requires that if you distribute an application linked to a library, that
you must allow users to re-link against newer versions of the library
that maintain interface compatibility, presumably by providing object
files, bytecodes -- OR you must distribute an application that uses
shared libraries.  It is C-centric, but I do not think it poses any
problems.  (You must also redistribute any changes you make to the
LGPLed library itself.)
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Patrick M Doane]

On Thu, 8 Nov 2001, Will Benton wrote:

> Whoa, nelly!  I don't know that I'd characterize the LGPL as a
> "problem", but your reading of it is completely off the mark.  The LGPL
> requires that if you distribute an application linked to a library, that
> you must allow users to re-link against newer versions of the library
> that maintain interface compatibility, presumably by providing object
> files, bytecodes -- OR you must distribute an application that uses
> shared libraries.  It is C-centric, but I do not think it poses any
> problems.  (You must also redistribute any changes you make to the
> LGPLed library itself.)

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.

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.

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.

  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 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?

These issues aside, the LGPL is still a real pain to deal with.

  - The LGPL text must be included with the distribution.
  - All copyright notices for the product need to include the copyright
    notice for Inria
  - All these notices must also direct the user to the LPGL license
  - 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.
  - All source code (or perhaps object code) for my application must
    be come with distributed.
  - Or, as an exception to the previous two, a written letter must be
    included with the product to be able to get those two.

This is a lot of hassle - nowhere near the suggestion that "the LGPL puts
no restrictions at all on programs linked with LGPL-ed binaries."

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.

I'm sorry if this sounds like just a lot of complaining, but I'm sure
folks in the commercial world would rather pay a small fee to avoid these
issues entirely. Ideally, any OCaml executable (with the exception of this
created with ocamlmktop) should be unencumbered from license issues. I
believe this was the intent of the INRIA team, but this is not the current
situation.

-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Michael Welsh Duggan]

Patrick M Doane <patrick@watson.org> writes:

> Earlier this year there was a discussion about the problems of using LGPL
> for the OCaml run-time system and associated libraries.
>
> It was suggested that some of the constraints in the LGPL were not
> intended. To quote a page from the Caml website:
>
>   "The LGPL puts no restrictions at all on programs linked with LGPL-ed
> libraries. Thus, users are free to distribute (or not) OCaml-generated
> binaries under whatever conditions they like."
>
> From my reading of the LGPL, which seems to correspond with the
> opinions of others on the list, this just isn't true.

I agree.  The LGPL does put some conditions on the binaries.
For example, they must be accompanied by a copy of the LGPL license.
But this license is *for the Ocaml libraries linked in*, not for the
whole binary.

> If I develop an application with OCaml, I must distribute that
> application with source code.  This isn't acceptable for commercial
> development and I'd really hope that the intention is for OCaml to
> be used outside of academia.

I suggest you read section 6 of the LGPL a little more closely.  I
have to be able to produce on demand source code for ocaml and its
libraries, but not for the work itself.  I do have to distribute the
work in such a way that ocaml and its libraries could change and be
relinked.  

"For an executable, the required form of the "work that uses the
Library" must include any data and utility programs needed for
reproducing the executable from it."

It should be sufficent to distibute all the precompiled *.cm* files
of the binary in the distribution.  These could be linked with a
modified set of ocaml libraries to create a new program, but the
source to the application need not be shipped.

-- 
Michael Duggan
(md5i@cs.cmu.edu)
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Michael Welsh Duggan]

Patrick M Doane <patrick@watson.org> writes:

> 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.
>
> 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.

That is section 1.  Section 6 begins, "as an exception to the
Sections above"...

-- 
Michael Duggan
(md5i@cs.cmu.edu)
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Patrick M Doane]

On Fri, 9 Nov 2001, Michael Welsh Duggan wrote:

> Patrick M Doane <patrick@watson.org> writes:
>
> > 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.
> >
> > 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.
>
> That is section 1.  Section 6 begins, "as an exception to the
> Sections above"...

It's section 6. I extracted two sections from it (that I labeled 1 and 2).

-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Xavier Leroy]

> Yeah, this is a slightly misleading statement, unless the OCaml
> development team has made a modification to the LGPL similar to what was
> done for the Guile license, which is LGPL with one additional clause:
> blanket linking is allowed for Guile. (OCaml dev team, is this also the
> license under which the runtime exists?)

We haven't yet modified the LGPL to remove these silly restrictions on
linking with LGPL code, but plan to do so in the near future.  

We'd be interested in examples of other software projects that did this.
You mention Guile, however it seems to be under the (standard) GPL
(not even LGPL).

> If you read the license, how it works is that if you link *dynamically*
> with LGPLed libraries, there are no restrictions on the license of the
> linking program.  That means you have to have a shared library version.
> If you have a statically linked program, or on some system that doesn't
> support shared libraries/DLL's, you are going to be in violation of the
> lesser GPL by linking to the static versions of the library.

Not at all.  In case of static linking, the LGPL requires that you
give users the ability to re-link your program with modified versions
of the LGPL-ed library.  In practice, this means that you have to
provide the .cmo or .cmx/.o files for your OCaml program in the
unlikely event that someone asks for them (in order to exercise
his/her LGPL rights of re-linking with modified Caml libraries).

No big deal, really, but still silly.

- Xavier Leroy
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Sven]

On Thu, Nov 08, 2001 at 11:30:56PM -0500, Patrick M Doane wrote:
> Earlier this year there was a discussion about the problems of using LGPL
> for the OCaml run-time system and associated libraries.
> 
> It was suggested that some of the constraints in the LGPL were not
> intended. To quote a page from the Caml website:
> 
>   "The LGPL puts no restrictions at all on programs linked with LGPL-ed
> libraries. Thus, users are free to distribute (or not) OCaml-generated
> binaries under whatever conditions they like."
> 
> >From my reading of the LGPL, which seems to correspond with the opinions
> of others on the list, this just isn't true.  If I develop an application
> with OCaml, I must distribute that application with source code.  This

No, the worse that happens is that you must distribute the .cmo, .cmi, .cmx,
and possibly .o, hopefully with a working makefile, but this last one is not
demanded.

The reason for that, in the C context (you need the .o only), is so if you
link with a buggy version of the LGPLed library, your client, or whatever, can
correct the LGPLed library, or grab a fixed version from the net, and rebuild
your app without the bug.

I don't know if this is really possible in the ocaml case, but i am sure
Xavier or someone else from the ocaml team will clarify it for us. But anyway,
i don't think, need to check though, that it needs to be rebuildable with the
latest version of ocaml, just the one you build your app with, but that,
altough not written explicitly, must also be one of the information you
provide your clients.

This last point would be greatly simplified if the ocaml compiler suite
comprised a little tool to check for the versions of ocaml used to build an
object file.

Also you only need to distribute this object files to the persons you
distribute the files to, and you even can only offer for people to get them on
your web site, or offer them per mail on a request, charging no more than the
shipping fee, but you have to guarantee that this offer stays valid for at
least 3 years.

Is this still unaceptable, or do you think this clarification will be ok with
you ?

That said, another solution would be to distribute the runtime systeme under a
dual licence, but you could not link it with GPLed code if you choose the
other non-GPL compatible licence. This is what trolltech did for the Qt libs.

> Will this problem be fixed for the 3.03 release?

As said, it is not really a licence problem, more a perception problem of the
llicence.

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

Re: [Caml-list] License Conditions for OCaml

[Sven]

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 ?

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.

> 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.

> 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.

And the object files provided permit you to relink the your app with the
modified ocaml runtime system.

>   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 ?

> 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.

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.

> 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.

>   - 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 :

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 ?

>   - All these notices must also direct the user to the LPGL license

Complied by the above small phrase.

>   - 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.

>   - All source code (or perhaps object code) for my application must
>     be come with distributed.

Object code only, this you cannot avoid.

>   - Or, as an exception to the previous two, a written letter must be
>     included with the product to be able to get those two.

Yes, you must inform your client of their right, and this offer has to be up
for at least the next 3 years.

> This is a lot of hassle - nowhere near the suggestion that "the LGPL puts
> no restrictions at all on programs linked with LGPL-ed binaries."

Yes, a little FAQ could be written to clarify this, i would gladly do it, but
next week, when i have more time.

> 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.

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

> I'm sorry if this sounds like just a lot of complaining, but I'm sure
> folks in the commercial world would rather pay a small fee to avoid these
> issues entirely. Ideally, any OCaml executable (with the exception of this
> created with ocamlmktop) should be unencumbered from license issues. I
> believe this was the intent of the INRIA team, but this is not the current
> situation.

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 ?

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

Re: [Caml-list] License Conditions for OCaml

[Sven]

On Fri, Nov 09, 2001 at 12:58:30AM -0500, Patrick M Doane wrote:
> On Fri, 9 Nov 2001, Michael Welsh Duggan wrote:
> 
> > Patrick M Doane <patrick@watson.org> writes:
> >
> > > 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.
> > >
> > > 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.
> >
> > That is section 1.  Section 6 begins, "as an exception to the
> > Sections above"...
> 
> It's section 6. I extracted two sections from it (that I labeled 1 and 2).

But apparently without reading it indepth, or at least understanding what it
trully says.

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

Re: [Caml-list] License Conditions for OCaml

[Julian Assange]

All this legalise is very interesting, but in the end, as with all legalise
there is only one important issue:

     a) Who has the motivation, resources and standing to fuck with you?

Hint: it's not INRIA.

--
 Julian Assange        |If you want to build a ship, don't drum up people
                       |together to collect wood or assign them tasks and
 proff@iq.org          |work, but rather teach them to long for the endless
 proff@gnu.ai.mit.edu  |immensity of the sea. -- Antoine de Saint Exupery
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Sven]

On Fri, Nov 09, 2001 at 08:58:29PM +1100, Julian Assange wrote:
> 
> All this legalise is very interesting, but in the end, as with all legalise
> there is only one important issue:
> 
>      a) Who has the motivation, resources and standing to fuck with you?
> 
> Hint: it's not INRIA.
> 

But still (i have not looked at it) in the case of the str code, if it trully
uses GPLed code, which may be copyrigthed by the FSF, it may cause a problem,
since they would be much more willing to take actions, if it is ported to
their attention.

That said, i have not looked at this code directly, and it may not be a
problem.

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

Re: [Caml-list] License Conditions for OCaml

[malc]

On Fri, 9 Nov 2001, Patrick M Doane wrote:

> On Thu, 8 Nov 2001, Will Benton wrote:
> 
> > Whoa, nelly!  I don't know that I'd characterize the LGPL as a
> > "problem", but your reading of it is completely off the mark.  The LGPL
> > requires that if you distribute an application linked to a library, that
> > you must allow users to re-link against newer versions of the library
> > that maintain interface compatibility, presumably by providing object
> > files, bytecodes -- OR you must distribute an application that uses
> > shared libraries.  It is C-centric, but I do not think it poses any
> > problems.  (You must also redistribute any changes you make to the
> > LGPLed library itself.)
> 
> 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:
While this is true for stock ocaml, there is a patch that adds shared
linking support to 3.03Alpha, with limited scope though - i386 ELF only.
(shameless plug) You can find it here http://algol.prosalg.no/~malc/scaml

> 
>   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.
> 
> 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.
> 
> 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.
> 
>   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 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?
> 
> These issues aside, the LGPL is still a real pain to deal with.
> 
>   - The LGPL text must be included with the distribution.
>   - All copyright notices for the product need to include the copyright
>     notice for Inria
>   - All these notices must also direct the user to the LPGL license
>   - 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.
>   - All source code (or perhaps object code) for my application must
>     be come with distributed.
>   - Or, as an exception to the previous two, a written letter must be
>     included with the product to be able to get those two.
> 
> This is a lot of hassle - nowhere near the suggestion that "the LGPL puts
> no restrictions at all on programs linked with LGPL-ed binaries."
> 
> 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.
> 
> I'm sorry if this sounds like just a lot of complaining, but I'm sure
> folks in the commercial world would rather pay a small fee to avoid these
> issues entirely. Ideally, any OCaml executable (with the exception of this
> created with ocamlmktop) should be unencumbered from license issues. I
> believe this was the intent of the INRIA team, but this is not the current
> situation.
> 
> -------------------
> 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
> 
> 

-- 
mailto:malc@pulsesoft.com

-------------------
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

[Caml-list] ELF i386 dynamic linking patch. was: License Conditions for OCaml

[Jeff Henrikson]

> > 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:
> While this is true for stock ocaml, there is a patch that adds shared
> linking support to 3.03Alpha, with limited scope though - i386 ELF only.
> (shameless plug) You can find it here http://algol.prosalg.no/~malc/scaml

Yes, but those pesky gensym integers lying around prevent exactly this thing.  That is, if I write a library, compile to an
.so/.cmxa pair, and link to it, all is apparently well in the world.  Then if I try to change the implementation of the library but
leave the interfaces alone, I find out all the symbol names will change randomly, eg

	myFunction243     to     myFunction247

Fixing this may be as simple as removing a %s from the source.  I don't know, as I didn't dig that deep.  I also have a suspicion
that entry points are sometimes not unique.  I periodically hear things about multiple optimized entry points and I don't know if
that affects their symbol names.  I would presume it would, which would be another screw case to work on.

The question is that if you provide an .mli, are multiple entry points ever generated.  Actually, the real question is a little
more strict: given an .mli file, are the symbols generated well-defined (except for the arbitrary integer), and will they still be
unique if the integer is deleted?  Does any kind guru care to comment?

Though you aren't defining a calling convention or symbol naming scheme from scratch, you are still, in a sense, defininig a binary
interface here.  IMHO extreme paranoia is warranted!  ;-)

BTW, if you can address these concerns to my satisfaction, (And I wish other people were commenting on this.  The list was
strangely silent when you posted this patch- Am I the only one thinking this is extremely important?)  I'm happy to port it to the
windows dynamic linker.  I already did this for another linking library whose limitations I don't like too much any more.  (dlopen)


Jeff Henrikson


-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Patrick M Doane]

On Fri, 9 Nov 2001, Sven wrote:

> On Thu, Nov 08, 2001 at 11:30:56PM -0500, Patrick M Doane wrote:
>
> No, the worse that happens is that you must distribute the .cmo, .cmi, .cmx,
> and possibly .o, hopefully with a working makefile, but this last one is not
> demanded.

As mentioned before - I don't think this is true. The LGPL is very clear
that the user must be able to modify the work (i.e. the application and
not the library). This is not possible to do with .cm[iox] files.

Also, I still must permit users to reverse engineer my application.

It is standard practice to strip an executable of all symbols to prevent
users from snooping around in the code.  Even if all I had to do was
include object files, the names of identifiers would still be intact.

> The reason for that, in the C context (you need the .o only), is so if you
> link with a buggy version of the LGPLed library, your client, or whatever, can
> correct the LGPLed library, or grab a fixed version from the net, and rebuild
> your app without the bug.

This is a good goal - but it's not what the LPGL says.

> Is this still unaceptable, or do you think this clarification will be ok with
> you ?

It may be acceptable to me, but probably not for my employeer or clients
who work in vertical markets that are very sensitive about proprietary
information.

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

Re: [Caml-list] License Conditions for OCaml

[Patrick M Doane]

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

Re: [Caml-list] License Conditions for OCaml

[Patrick M Doane]

On Fri, 9 Nov 2001, Sven wrote:

> On Fri, Nov 09, 2001 at 12:58:30AM -0500, Patrick M Doane wrote:
> > It's section 6. I extracted two sections from it (that I labeled 1 and 2).
>
> But apparently without reading it indepth, or at least understanding what it
> trully says.

Making assumptions like this is really inappropriate. I have read the LGPL
carefully in hopes that it would not be so restrictive.

I believe there is legitimate confusion in the license as to whether
object code is sufficient. Either way, including object code is still too
much to ask for.

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

Re: [Caml-list] License Conditions for OCaml

[Patrick M Doane]

On Fri, 9 Nov 2001, Julian Assange wrote:

>
> All this legalise is very interesting, but in the end, as with all legalise
> there is only one important issue:
>
>      a) Who has the motivation, resources and standing to fuck with you?
>
> Hint: it's not INRIA.

The issue of morality is very important to me and cannot be ignored.
Besides, the FSF has plenty of motivation and resources.

-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Dave Scott]

On Fri, 9 Nov 2001, Xavier Leroy wrote:

> We haven't yet modified the LGPL to remove these silly restrictions on
> linking with LGPL code, but plan to do so in the near future.  
> 
> We'd be interested in examples of other software projects that did this.
> You mention Guile, however it seems to be under the (standard) GPL
> (not even LGPL).

AT&T's omniORB  ( http://www.uk.research.att.com/omniORB/ ) has a similar
tricky licensing arrangement. The core CORBA library code is LGPL'ed
while the associated tools (including the IDL compiler) are GPL'ed. Since
the IDL compiler emits part of its own source in its output which then 
gets linked statically into all CORBA apps, there is an extra licensing
note covering this (otherwise people might have to GPL all their CORBA
code).

>From the README.FIRST file in the omniORB source distro:

>>>>
omniORB3 is copyright AT&T Laboratories - Cambridge. It is free
software. The programs in omniORB3 are distributed under the GNU
General Public Licence as published by the Free Software Foundation.
See the file COPYING for copying permission of these programs. The
libraries in omniORB3 are distributed under the GNU Library General
Public Licence. See the file COPYING.LIB for copying permission of
these libraries.

We impose no restriction on the use of the IDL compiler output. The
stub code produced by the IDL compiler is not considered a derived
work of it.
<<<<

Not completely the same but nevertheless intersting...

Cheers,
-- 
Dave Scott   --   Lab for Comms Engineering   --   CUED
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Tom]

> > >   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.
> >
> 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.

I believe in this case "supporting modifications" refers to letting end users
modify the binary; the way I understand it, it's not an obligation to provide
source.

Tom.


__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[David Brown]

On Fri, Nov 09, 2001 at 09:45:45AM +0100, Xavier Leroy wrote:
> > Yeah, this is a slightly misleading statement, unless the OCaml
> > development team has made a modification to the LGPL similar to what was
> > done for the Guile license, which is LGPL with one additional clause:
> > blanket linking is allowed for Guile. (OCaml dev team, is this also the
> > license under which the runtime exists?)
> 
> We haven't yet modified the LGPL to remove these silly restrictions on
> linking with LGPL code, but plan to do so in the near future.  
> 
> We'd be interested in examples of other software projects that did this.
> You mention Guile, however it seems to be under the (standard) GPL
> (not even LGPL).

This is the license from the runtime of the GNU Ada Compiler.  Note the
special exception.  Also this is GPL, with the exception:

--           Copyright (C) 1995-1998 Ada Core Technologies, Inc.            --
--                                                                          --
-- GNAT is free software;  you can  redistribute it  and/or modify it under --
-- terms of the  GNU General Public License as published  by the Free Soft- --
-- ware  Foundation;  either version 2,  or (at your option) any later ver- --
-- sion.  GNAT is distributed in the hope that it will be useful, but WITH- --
-- OUT ANY WARRANTY;  without even the  implied warranty of MERCHANTABILITY --
-- or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License --
-- for  more details.  You should have  received  a copy of the GNU General --
-- Public License  distributed with GNAT;  see file COPYING.  If not, write --
-- to  the Free Software Foundation,  59 Temple Place - Suite 330,  Boston, --
-- MA 02111-1307, USA.                                                      --
--                                                                          --
-- As a special exception,  if other files  instantiate  generics from this --
-- unit, or you link  this unit with other files  to produce an executable, --
-- this  unit  does not  by itself cause  the resulting  executable  to  be --
-- covered  by the  GNU  General  Public  License.  This exception does not --
-- however invalidate  any other reasons why  the executable file  might be --
-- covered by the  GNU Public License.                                      --

This seems to be working well.  It allows this library to be linked with
programs.  If someone wishes to incorporate the code, however, it
requires the GPL to be followed.

The wording would have to be changed from instantiating generics,
though.

This does also allow modifications.  If the person doing the
modifications also agrees to the exception.

I also believe this exception has been agreed upon by the FSF.

David Brown
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Brian Rogoff]

On Fri, 9 Nov 2001, Xavier Leroy wrote:
> > Yeah, this is a slightly misleading statement, unless the OCaml
> > development team has made a modification to the LGPL similar to what was
> > done for the Guile license, which is LGPL with one additional clause:
> > blanket linking is allowed for Guile. (OCaml dev team, is this also the
> > license under which the runtime exists?)
> 
> We haven't yet modified the LGPL to remove these silly restrictions on
> linking with LGPL code, but plan to do so in the near future.  
> 
> We'd be interested in examples of other software projects that did this.
> You mention Guile, however it seems to be under the (standard) GPL
> (not even LGPL).

GNAT, www.gnat.com, also uses a modified standard GPL. They've been doing
it for a while, and they even have commercial customers. Here's the whole 
damned thing 
--
-- This is free software; you can redistribute it and/or modify it under
-- terms of the GNU General Public License as published by the Free Software
-- Foundation; either version 2, or (at your option) any later version.
-- This software is distributed in the hope that it will be useful, but WITH
-- OUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
-- or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
-- for more details. Free Software Foundation, 59 Temple Place - Suite
-- 330, Boston, MA 02111-1307, USA.
--
-- As a special exception, if other files instantiate generics from this
-- unit, or you link this unit with other files to produce an executable,
-- this unit does not by itself cause the resulting executable to be
-- covered by the GNU General Public License. This exception does not
-- however invalidate any other reasons why the executable file might be
-- covered by the GNU Public License.

Why not just translate Ada jargon to OCaml and swipe this? 

-- Brian
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Vitaly Lugovsky]

On Thu, 8 Nov 2001, Patrick M Doane wrote:

>   "The LGPL puts no restrictions at all on programs linked with LGPL-ed
> libraries. Thus, users are free to distribute (or not) OCaml-generated
> binaries under whatever conditions they like."
> 
> >From my reading of the LGPL, which seems to correspond with the opinions
> of others on the list, this just isn't true. 

 Please, read it again. Carefully.

> If I develop an application
> with OCaml, I must distribute that application with source code. 

 No. You must distribute a runtime source or just put a link how to get
it. Nothing more. There are a lot of commercial, closed source 
applications linked with LGPL libraries - e.g. any Linux commercial
apps linked with GNU Libc.

> This isn't acceptable for commercial development

 It IS acceptable. But here, I think, it's offtopic. Read slashdot, and so 
on. Look at WineX, for example: open source, commercial binaries.

-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Patrick M Doane]

On Fri, 9 Nov 2001, Vitaly Lugovsky wrote:

> On Thu, 8 Nov 2001, Patrick M Doane wrote:
>
> >   "The LGPL puts no restrictions at all on programs linked with LGPL-ed
> > libraries. Thus, users are free to distribute (or not) OCaml-generated
> > binaries under whatever conditions they like."
> >
> > >From my reading of the LGPL, which seems to correspond with the opinions
> > of others on the list, this just isn't true.
>
>  Please, read it again. Carefully.

I have read it again today, carefully, and still come to the same
conclusions:

  1. Users are allowed to reverse engineer the application

  2. Source (or possibly object files) for my application must be included
     in the distribution.

I could probably be convinced that object files are sufficient for
purposes of satisfying the license, but that just exposes the next major
problem (i.e. point #1).

> > If I develop an application
> > with OCaml, I must distribute that application with source code.
>
>  No. You must distribute a runtime source or just put a link how to get
> it. Nothing more. There are a lot of commercial, closed source
> applications linked with LGPL libraries - e.g. any Linux commercial
> apps linked with GNU Libc.

The runtime source for OCaml must be included or a "written letter" must
be provided. That's quite a bit different than a link.

You also need to include either source (or again maybe object files) of
the application that uses the library.

It's not sufficient to simply ship a static executable and include a
notice where one can get the OCaml source code.

> > This isn't acceptable for commercial development
>
>  It IS acceptable. But here, I think, it's offtopic. Read slashdot, and so
> on. Look at WineX, for example: open source, commercial binaries.

I agree that for open source commercial software, there are no problems.
This hardly represents the majority of commercial development though.

If this isn't an appropriate place to discuss issues with the Caml
license, where else is?

-------------------
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

[Caml-list] Re: ELF i386 dynamic linking patch. was: License Conditions for OCaml

[malc]

"Jeff Henrikson" <jehenrik@yahoo.com> writes:

> > > 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:
> > While this is true for stock ocaml, there is a patch that adds
> > shared linking support to 3.03Alpha, with limited scope though -
> > i386 ELF only.  (shameless plug) You can find it here
> > http://algol.prosalg.no/~malc/scaml
>  Yes, but those pesky gensym integers lying around prevent exactly
> this thing.  That is, if I write a library, compile to an .so/.cmxa
> pair, and link to it, all is apparently well in the world.  Then if
> I try to change the implementation of the library but leave the
> interfaces alone, I find out all the symbol names will change
> randomly, eg
>  myFunction243 to myFunction247
I consider it low priority for now. More interested to add unloading
support for native compiled modules first.

>  Fixing this may be as simple as removing a %s from the source.  I
> don't know, as I didn't dig that deep.  I also have a suspicion that
> entry points are sometimes not unique.  I periodically hear things
> about multiple optimized entry points and I don't know if that
> affects their symbol names.  I would presume it would, which would
> be another screw case to work on.
I dont know, i dont expect any problems here. But then again, havent 
looked closely at this.

>  The question is that if you provide an .mli, are multiple entry
> points ever generated.  Actually, the real question is a little more
> strict: given an .mli file, are the symbols generated well-defined
> (except for the arbitrary integer), and will they still be unique if
> the integer is deleted?  Does any kind guru care to comment?
.mli doesnt give you this information, .cmx does.

>  Though you aren't defining a calling convention or symbol naming
> scheme from scratch, you are still, in a sense, defininig a binary
> interface here.  IMHO extreme paranoia is warranted!  ;-)
Well, i posted very sketchy first patch here, to collect comments,
feature requests and so on. I guess you have seen how miserably i failed.
I _really_ dont want to set standards on my own, but since almost
nobody is interested im forced to implement things the way they suit me.

>  BTW, if you can address these concerns to my satisfaction, (And I
> wish other people were commenting on this.  The list was strangely
> silent when you posted this patch- Am I the only one thinking this
> is extremely important?)  I'm happy to port it to the windows
> dynamic linker.  I already did this for another linking library
> whose limitations I don't like too much any more.  (dlopen)
If i'm reading apache log's correctly, there where 12 downloads of
1_shared.patch and 8 of 2_shared.patch. Overwhelming success. Sigh. 
Plus Xavier expressed team's disinterest in native dynamic linking
(at least in forseeable feature)

On the bright side Fabrice Le Fessant put it into CDK, on the down
side, after Xaviers message about CDK and patches, he decided to
remove them all. If he will go for optional patched compiler, it will
screw shared patch because of .cmx .cmxa incompatibilities. And i bet
not many possible CDK users will tollerate two(or more) multimegabyte
trees.

As for windows port, id happily provide any support i can. However
i forsee many obstacles. Windows's PE isnt really as feature packed
as ELF, there will be all sorts of visibility, scope etc problems.
(Not that it cant be done or anything ;)

P.S. Answering this message was a huge pain in the ass, i had to visit
XEmacs to fight this horrible mess Outlook produced. Maybe you
can fix that?

-- 
mailto:malc@pulsesoft.com

-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Sven]

On Fri, Nov 09, 2001 at 10:13:41AM -0500, Patrick M Doane wrote:
> On Fri, 9 Nov 2001, Sven wrote:
> 
> > On Thu, Nov 08, 2001 at 11:30:56PM -0500, Patrick M Doane wrote:
> >
> > No, the worse that happens is that you must distribute the .cmo, .cmi, .cmx,
> > and possibly .o, hopefully with a working makefile, but this last one is not
> > demanded.
> 
> As mentioned before - I don't think this is true. The LGPL is very clear
> that the user must be able to modify the work (i.e. the application and
> not the library). This is not possible to do with .cm[iox] files.

Please reread the stuff carefully, or if you are not able to understand it,
search for legal advice, or ask the FSF or someone such who has knowledge in
open source licences about it.

In this case, the right that the LGPL gives to the user is to modify the work
(the LPGLed library) and to relink your app with it. Why would you want to
stripe us of that right ? And despite what Xavier does say, it is no a silly
restriction, it guarantees the user that they are ever able to correct bugs in
the LGPLed library, and that all the bugs in your app are originated from you,
and not the ocaml compiler suite.

> Also, I still must permit users to reverse engineer my application.
> It is standard practice to strip an executable of all symbols to prevent
> users from snooping around in the code.  Even if all I had to do was
> include object files, the names of identifiers would still be intact.


Reverse engineering is legal in many european countries, ...

And anyway, there is no way you can take to completely stop reverse
engineering, 

Tell me, what application do you want to write that you are so afraid people
will reverse engineer ?

Often it is less expensive to rewrite the program from scratch than to do
reverse engineering, and anyway, maybe it is even cheaper to buy it from you.

The only viable reason for reverse engineering would be if you don't provide
adequate support for your stuff, inspecial if you don't provide binaries that
are portable to the arch i am using, or if you don't bother to correct bugs or
other such stuff.

And in these cases, you get what you deserve, and if you want it for less
recomendable reasons, then you have no sympathy from me.

Please think again about it, and see if it really is that important for you,
and if yes, i am sure you can negotiate a proper arrangement with the ocaml
copyright holders.

> > The reason for that, in the C context (you need the .o only), is so if you
> > link with a buggy version of the LGPLed library, your client, or whatever, can
> > correct the LGPLed library, or grab a fixed version from the net, and rebuild
> > your app without the bug.
> 
> This is a good goal - but it's not what the LPGL says.

Yes, it is, the FSF has spent  a lot of ressource with lawyers to ensure that,
thus the seemingly obscure legalistic wordings, but it says that.

> > Is this still unaceptable, or do you think this clarification will be ok with
> > you ?
> 
> It may be acceptable to me, but probably not for my employeer or clients
> who work in vertical markets that are very sensitive about proprietary
> information.

Mmm, ...

Is it because there are real fears, or because they are just misinformed, as
clearly you are only, ...

Perhaps did they receive the visit from some of those MS FUd spreaders trying
to remove confidence into the opensource movement, and saying that in the end,
going opensource will be more expensive than paying millions to MS for
software licences ? The 20 Million US$ saving of amazon.com for going with
linux notwithstanding ?

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

Re: [Caml-list] License Conditions for OCaml

[Sven]

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

Re: [Caml-list] License Conditions for OCaml

[Sven]

On Fri, Nov 09, 2001 at 04:39:13PM -0500, Patrick M Doane wrote:
> On Fri, 9 Nov 2001, Vitaly Lugovsky wrote:
> 
> > On Thu, 8 Nov 2001, Patrick M Doane wrote:
> >
> > >   "The LGPL puts no restrictions at all on programs linked with LGPL-ed
> > > libraries. Thus, users are free to distribute (or not) OCaml-generated
> > > binaries under whatever conditions they like."
> > >
> > > >From my reading of the LGPL, which seems to correspond with the opinions
> > > of others on the list, this just isn't true.
> >
> >  Please, read it again. Carefully.
> 
> I have read it again today, carefully, and still come to the same
> conclusions:
> 
>   1. Users are allowed to reverse engineer the application
> 
>   2. Source (or possibly object files) for my application must be included
>      in the distribution.
> 
> I could probably be convinced that object files are sufficient for
> purposes of satisfying the license, but that just exposes the next major
> problem (i.e. point #1).
> 

Yes, this is the real problem for you, why not say it from the begining and
explain a bit ?

> > > If I develop an application
> > > with OCaml, I must distribute that application with source code.
> >
> >  No. You must distribute a runtime source or just put a link how to get
> > it. Nothing more. There are a lot of commercial, closed source
> > applications linked with LGPL libraries - e.g. any Linux commercial
> > apps linked with GNU Libc.
> 
> The runtime source for OCaml must be included or a "written letter" must
> be provided. That's quite a bit different than a link.

Well, you have :

    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.

That is, if you offer your app as downloadeable, you just need to offer the
object code from the same place.

In the other case, you probably ship a CD or something such, and probably
acompany it by a documentation, in this case, just add a page to the
documentation to comply with the LGPL.

> You also need to include either source (or again maybe object files) of
> the application that uses the library.

No, it is the source you need to provide for the LGPLed library.

but again, either a letter or a downloadable version would be ok.

> It's not sufficient to simply ship a static executable and include a
> notice where one can get the OCaml source code.

Well, not sure, the reasoning here is that you must agree to make the object
and library source available for at least 3 years. You cannot guarantee that
the ocaml team will be doing this for the next 3 years, altough it certainly
would. Now if you were a member of the consortium, then this may be
legailistically sufficient, but again, i am no lawyer.

That said, if you modify the ocaml compiler suite to build your app, then you
have to make these modifications available, maybe it is this that is required
?

> > > This isn't acceptable for commercial development
> >
> >  It IS acceptable. But here, I think, it's offtopic. Read slashdot, and so
> > on. Look at WineX, for example: open source, commercial binaries.
> 
> I agree that for open source commercial software, there are no problems.
> This hardly represents the majority of commercial development though.

But study have said that this represent a big share of those commercial
software that will still exist in the next few years, you have been warned
:)))

> If this isn't an appropriate place to discuss issues with the Caml
> license, where else is?

Don't know, is this of interrest to the other list participants ? If yes, we
can continue here, users bored with it can easily send it to /dev/null with a
proper mail filter. If not, then we could continue privately, or create a new
list ocaml-legalese, or something such ? What do the other mailing list member
say about this, and in particular the ocaml team ?

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

Re: [Caml-list] License Conditions for OCaml

[Patrick M Doane]

Hi Sven,

I agree that this discussion maybe getting a bit much for the list. Here
are responses to a few of those points that I think are relevant:

On Sun, 11 Nov 2001, Sven wrote:

> Tell me, what application do you want to write that you are so afraid people
> will reverse engineer ?

I'm not afraid of it - but those around me who pay the bills are. I'm
relating the opinions of what I see in the commercial world. It is very
common to strip binaries of all identifiers (or at least munge them beyond
comprehension), and to have copy protection code. People are taking
reasonable steps to protect their intellectual property.

I want to see Caml succeed in that world. Now, it seems that Xavier
indicates that these problems will be fixed which is great. We have had a
number of good suggestions posted to the list that should be acceptable.

> > Hmm... I doubt anyone would be complaining if this were released with
> > the MIT License. That is much simpler to understand.
>
> 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.

Sure you can, it is perfectly acceptable to link non-LPGL code with LPGL
code provided that you follow the rules of the LGPL.

> > 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 ?

There are already several tools included in the distribution to get you
started. Look under the tools directory at application like 'dumpapprox'.
Luckily, the .cmi files should not be needed to relink an application.
These would contain the most information.

It is relatively easy to reverse engineer assembly when identifiers are
still present in the code. Take these out and the problem get much harder.

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

Re: [Caml-list] License Conditions for OCaml

[Tom]

> >   1. Users are allowed to reverse engineer the application
> > 
> >   that just exposes the next major problem (i.e. point #1).

You cannot realistically protect yourself from reverse engineering.
In many countries, you cannot even prohibit reverse engineering in your
license.  Reverse engineering for the purpose of building a work-alike
solution is an important part of a free market in software.

I suspect many businesses that have concerns about reverse engineering
are more concerned about having some dirty secrets exposed (like
GPL violations or the unlicensed use of commercial software) than about
a realistic expectation of anybody cloning their product by reverse
engineering.

Tom


__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Tom]

I think it is great that enabling more widespread usage is
high on the list of goals of the OCAML project.

As far as I can tell, the GPL license that GNAT is under is 
considerably more restrictive than the LGPL license used by 
OCAML.  Under the GPL license, you cannot incorporate any 
GNAT source code into your code without redistributing your 
code under the terms of the GPL.

Furthermore, I believe Guile is distributed under the terms 
of the GPL (not the LGPL), and that is why it needs a special exemption 
when embedded in some other software system.

As I understand it, no further exemptions should be needed for a system
covered by the LGPL in order to allow its use as part of a
closed-source, proprietary system.  I would recommend consulting
a lawyer before making any changes to the LGPL--it has been carefully
crafted and vetted over many years.  Modifying it risks not only
breaking the protection it attempts to achieve, it may also scare
people away, since nobody will have any experience with what "a modified
LGPL license" actually means.  If you want to enable even more free 
distribution and usage than the LGPL, maybe it's worth considering 
another license that people already understand pretty well, like BSD or X11.

Tom

--- Brian Rogoff <bpr@bpr.best.vwh.net> wrote:
> On Fri, 9 Nov 2001, Xavier Leroy wrote:
> > > Yeah, this is a slightly misleading statement, unless the OCaml
> > > development team has made a modification to the LGPL similar to what was
> > > done for the Guile license, which is LGPL with one additional clause:
> > > blanket linking is allowed for Guile. (OCaml dev team, is this also the
> > > license under which the runtime exists?)
> > 
> > We haven't yet modified the LGPL to remove these silly restrictions on
> > linking with LGPL code, but plan to do so in the near future.  
> > 
> > We'd be interested in examples of other software projects that did this.
> > You mention Guile, however it seems to be under the (standard) GPL
> > (not even LGPL).
> 
> GNAT, www.gnat.com, also uses a modified standard GPL. They've been doing
> it for a while, and they even have commercial customers. Here's the whole 
> damned thing 
> --
> -- This is free software; you can redistribute it and/or modify it under
> -- terms of the GNU General Public License as published by the Free Software
> -- Foundation; either version 2, or (at your option) any later version.
> -- This software is distributed in the hope that it will be useful, but WITH
> -- OUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
> -- or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
> -- for more details. Free Software Foundation, 59 Temple Place - Suite
> -- 330, Boston, MA 02111-1307, USA.
> --
> -- As a special exception, if other files instantiate generics from this
> -- unit, or you link this unit with other files to produce an executable,
> -- this unit does not by itself cause the resulting executable to be
> -- covered by the GNU General Public License. This exception does not
> -- however invalidate any other reasons why the executable file might be
> -- covered by the GNU Public License.
> 
> Why not just translate Ada jargon to OCaml and swipe this? 
> 
> -- Brian
> -------------------
> 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


__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[David Brown]

On Mon, Nov 12, 2001 at 12:07:42AM -0800, Tom wrote:
> I think it is great that enabling more widespread usage is
> high on the list of goals of the OCAML project.
> 
> As far as I can tell, the GPL license that GNAT is under is 
> considerably more restrictive than the LGPL license used by 
> OCAML.  Under the GPL license, you cannot incorporate any 
> GNAT source code into your code without redistributing your 
> code under the terms of the GPL.

Neither license will allow you to incorporate code from the library into
your code and distribute it without being covered under the GPL (or
LGPL).  The issue is how easy is it to _use_ the library in another
program.

The GNAT license allows executables to be freely made that use the
library though.  The LGPL does not allow this.  There is an extra burden
on the developer to make sure that users have the ability to change the
library.

For example:  Let's say I write a proprietary program foo and wish to
distribute it to my customers.  If the ocaml library is LGPL, I have to
distribute at least a .cma (or .cmxa) for my application so that the
recipient of my software can relink it with the library.

With the GNAT modified library, I can just distribute my program.  I
don't need to provide source, that is up to me.

It really is a matter of what Inria wants people to be able to do.

Dave Brown
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Fergus Henderson]

On 09-Nov-2001, Patrick M Doane <patrick@watson.org> wrote:
> On Fri, 9 Nov 2001, Sven wrote:
> 
> > On Thu, Nov 08, 2001 at 11:30:56PM -0500, Patrick M Doane wrote:
> >
> > No, the worse that happens is that you must distribute the .cmo, .cmi, .cmx,
> > and possibly .o, hopefully with a working makefile, but this last one is not
> > demanded.
> 
> As mentioned before - I don't think this is true. The LGPL is very clear
> that the user must be able to modify the work (i.e. the application and
> not the library).  This is not possible to do with .cm[iox] files.

The LGPL says that the derived work must be licensed under terms
which "permit" the user to modify the work.  "permit" does not mean
the same thing as "make possible", and it definitely does not mean
the same thing as "make easy"!

It is in fact *possible* to modify the application given just the binary
files, of course, just not *easy*.

> Also, I still must permit users to reverse engineer my application.

Yes, that's correct.  You must give users the legal permission to reverse
engineer your application.  However, you are under no obligation to make
it easy.

> It is standard practice to strip an executable of all symbols to prevent
> users from snooping around in the code.  Even if all I had to do was
> include object files, the names of identifiers would still be intact.

For C code, you can through various techniques (such as `ld -r'
and the `--retain-symbols-file' options of GNU ld) link your object
files into a single object file and strip out all of the symbols except
those undefined symbols that refer to the LGPL'd library or libraries
that you are linking with.  These techniques can also be used with other
programming language implementations that generate standard object files,
such as (my favourite example ;) Mercury.

I don't know if this is possible for Ocaml code, but if it is not, then
I think it might perhaps be more useful to ask for similar technical
features, rather than complaining about the license.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Patrick M Doane]

On Tue, 27 Nov 2001, Fergus Henderson wrote:

> > Also, I still must permit users to reverse engineer my application.
>
> Yes, that's correct.  You must give users the legal permission to reverse
> engineer your application.  However, you are under no obligation to make
> it easy.

Okay, true enough. There is some loss of legal action a company can take,
but it is probably fine.

> For C code, you can through various techniques (such as `ld -r'
> and the `--retain-symbols-file' options of GNU ld) link your object
> files into a single object file and strip out all of the symbols except
> those undefined symbols that refer to the LGPL'd library or libraries
> that you are linking with.  These techniques can also be used with other
> programming language implementations that generate standard object files,
> such as (my favourite example ;) Mercury.
>
> I don't know if this is possible for Ocaml code, but if it is not, then
> I think it might perhaps be more useful to ask for similar technical
> features, rather than complaining about the license.

There are many ways to address the issue and this could be good
functionality to have. However, it's a lot less work to change the license
and let developers simply strip the binaries after compilation.

I brought up the topic of licensing as a status update. Xavier has said in
the past that the conditions in the LGPL are silly and I agree with him.
He also indicated that they would be looking into modifications in the
future. My intent was not to start a flamewar on license issues, although
they can be very hard to avoid with such a topic!

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

Re: [Caml-list] License Conditions for OCaml

[Fergus Henderson]

On 26-Nov-2001, Patrick M Doane <patrick@watson.org> wrote:
> ... it's a lot less work to change the license ...

Well, maybe, maybe not...
you might be surprised at how difficult that often is ;-)

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Rafael 'Dido' Sevilla]

On Tue, Nov 27, 2001 at 09:28:59PM +1100, Fergus Henderson wrote:
> On 26-Nov-2001, Patrick M Doane <patrick@watson.org> wrote:
> > ... it's a lot less work to change the license ...
> 
> Well, maybe, maybe not...
> you might be surprised at how difficult that often is ;-)

Especially if not all the code is really yours.  I believe that's the
case with OCaml.  There have been whispers here and there that the OCaml
regular expression code contains code taken from a LGPLed regex library,
whose copyright is owned by the Free Software Foundation.  THEY
definitely are not going to agree with any sort of change away from the
(L)GPL, and will not look kindly on any violation.  The sort of code
sharing we usually see is encouraged, and very few projects of any great
magnitude can  say that their code is completely written by them.  It
isn't true of Linux (there's a lot of code 'stolen' from BSD in there)
and that certainly isn't true of the OCaml runtime and libraries.

And even if you owned all the code and decided to change its license,
especially to something less liberal than the GPL, people who don't like
it can just take your old GPLed version and use THAT instead and hack on
THAT instead.  Like what happened with Sistina and GFS.

Changing licenses of a major project, especially one that has been a
community effort is not something that can be done without the aid of a
lawyer experienced in the entanglements of copyright law...

-- 
Rafael R. Sevilla <sevillar@team.ph.inter.net>   +63(2)   8177746 ext. 8311
Programmer, Inter.Net Philippines                +63(917) 4458925
http://dido.engr.internet.org.ph/                OpenPGP Key ID: 0x5CDA17D8
            Heute die Welt und Morgen das Sonnensystem!
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Xavier Leroy]

> There have been whispers here and there that the OCaml
> regular expression code contains code taken from a LGPLed regex library,
> whose copyright is owned by the Free Software Foundation.

Yes, the "Str" library of OCaml is built on top of the "regexp"
library, which is owned by the FSF and distributed under the GPL.

> THEY definitely are not going to agree with any sort of change away from the
> (L)GPL, and will not look kindly on any violation.

Sure.  When we're talking about changing the OCaml licensing terms, it
really means changing the licensing terms of the code for which we are
the copyright owners.  (The LICENSE file in the OCaml distribution is
carefully worded to cover only the source files that are copyright INRIA.)

Fortunately, all of the OCaml code is copyright INRIA except this
lousy "regexp" library, which no-one is forced to use (the remainder
of the OCaml system doesn't depend on it), and which we'll replace
eventually by something more efficient.

> And even if you owned all the code and decided to change its license,
> especially to something less liberal than the GPL, people who don't like
> it can just take your old GPLed version and use THAT instead and hack on
> THAT instead.  Like what happened with Sistina and GFS.

We're talking about making the OCaml license *more* liberal, by
*removing* silly requirements of the LGPL.  I don't see users
objecting to this.

- Xavier Leroy
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Sven]

On Wed, Nov 28, 2001 at 07:00:38PM +0100, Xavier Leroy wrote:
> > There have been whispers here and there that the OCaml
> > regular expression code contains code taken from a LGPLed regex library,
> > whose copyright is owned by the Free Software Foundation.
> 
> Yes, the "Str" library of OCaml is built on top of the "regexp"
> library, which is owned by the FSF and distributed under the GPL.
> 
> > THEY definitely are not going to agree with any sort of change away from the
> > (L)GPL, and will not look kindly on any violation.
> 
> Sure.  When we're talking about changing the OCaml licensing terms, it
> really means changing the licensing terms of the code for which we are
> the copyright owners.  (The LICENSE file in the OCaml distribution is
> carefully worded to cover only the source files that are copyright INRIA.)
> 
> Fortunately, all of the OCaml code is copyright INRIA except this
> lousy "regexp" library, which no-one is forced to use (the remainder
> of the OCaml system doesn't depend on it), and which we'll replace
> eventually by something more efficient.
> 
> > And even if you owned all the code and decided to change its license,
> > especially to something less liberal than the GPL, people who don't like
> > it can just take your old GPLed version and use THAT instead and hack on
> > THAT instead.  Like what happened with Sistina and GFS.
> 
> We're talking about making the OCaml license *more* liberal, by
> *removing* silly requirements of the LGPL.  I don't see users
> objecting to this.

Well, you are the copyright owner, but going away from the LGPL is more
liberal for the user, but less liberal for others, so it is a compromise, a
subtle balance that must be met.

The current 'silly' requirement you object to is there to guarantee the right
of the user of a tool written in ocaml to use with the latest bug fixed
version of the ocaml runtime libs even if the producer of the product don't
care about it.

This may be an important issue, especially if ocaml gets used in more
security-conscious stuff.

Also there is the fact that some may want to produce only the i386 native code
and distribute this to their clients, which ties them to use i386 hardware,
and is a restriction of their liberty to use whatever they want.

Sure, true arch indepent bytecode as we will soon have may well solve this
problem.

You may think that this is not a real problem, and it is not, provided the
provider of the product is conscious enough to provide a rebuild or something
like it when it is needed, but this is not something you can guarantee, and it
may have repercussions on the perception of ocaml in some ways.

Anyway, this is a hairy discution, which we should maybe port to a specialized
list or something like that ?


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