[Caml-list] ocamlbuild on Windows and bash vs. cmd

[Soegtrop, Michael]

Dear OCaml users and developers,

I looked into the fact that ocamlbuild requires bash/cygwin to run. Actually it does very little use of bash and I think cmd + ln + rm would work quite well.

From comments in various list I understood that people had issues with escaping for cmd. I agree that this is a bit nasty, but not rocket science either. I guess the main issue is that for cmd not only space and tab are command argument separators, but also equal (=), comma (,) and semicolon (;). So for cmd a=b,c;d is the same as a b c d which is the same as a , = , b =;= c==d. Essentially cmd treats unquoted pieces as sed 's/[\t =,;]+/ /g'. If a name contains any of these characters, one has to quote it for cmd, but not for bash. Since = and , are not that uncommon in file names, I guess this resulted in issues.

BUT cmd splits the command line only into command names, complete argument lists and file names for redirection. That is if you call e.g. ocamlc, cmd just replaces shell variables and extracts the executable name, but does not split up the argument list into individual pieces. bash on Windows does this neither, because (afaik) Windows has at the lowest level no mechanism to pass individual arguments to an executable. The command gets a string and splitting this string and even globing is the business of the executable. So it is rather odd that this behaves substantially different for bash and for cmd. The only thing which needs to be quoted properly are command names and file names of redirections.

There might be issue with shell special characters. There are those which are not allowed in file names "\/:*?<>| and those allowed in filenames &(). I guess those not allowed in filenames don't need any special treatment, since one can't do that much with them except their special shell use. The other 3 one should be escape with ^. There is no way to quote shell special characters with cmd - they must be escaped with ^.

The only real issue is that some people seem to use build rules with "real" bash stuff in it - well if you do this I guess you anyway have a cygwin around.

So I wonder if it would be appreciated by the community to have an ocamlbuild (e.g. as a configure option) which uses cmd instead of bash. I think if one does the escaping properly, this should be good for the large majority of projects out there.

Ocamlc seems to run fine without cygwin, but I didn't test other tools like ocamllex or menhir as yet. Are there known issues?

Best regards,

Michael


Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: [phone], www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

[Kakadu]

Will the powershell be more convenient?

Happy hacking,
Kakadu

On Thu, Oct 6, 2016 at 4:38 PM, Soegtrop, Michael

Post by Soegtrop, Michael
Dear OCaml users and developers,
I looked into the fact that ocamlbuild requires bash/cygwin to run. Actually
it does very little use of bash and I think cmd + ln + rm would work quite
well.
From comments in various list I understood that people had issues with
escaping for cmd. I agree that this is a bit nasty, but not rocket science
either. I guess the main issue is that for cmd not only space and tab are
command argument separators, but also equal (=), comma (,) and semicolon
(;). So for cmd a=b,c;d is the same as a b c d which is the same as a , = ,
b =;= c==d. Essentially cmd treats unquoted pieces as sed ‘s/[\t =,;]+/ /g’.
If a name contains any of these characters, one has to quote it for cmd, but
not for bash. Since = and , are not that uncommon in file names, I guess
this resulted in issues.
BUT cmd splits the command line only into command names, complete argument
lists and file names for redirection. That is if you call e.g. ocamlc, cmd
just replaces shell variables and extracts the executable name, but does not
split up the argument list into individual pieces. bash on Windows does this
neither, because (afaik) Windows has at the lowest level no mechanism to
pass individual arguments to an executable. The command gets a string and
splitting this string and even globing is the business of the executable. So
it is rather odd that this behaves substantially different for bash and for
cmd. The only thing which needs to be quoted properly are command names and
file names of redirections.
There might be issue with shell special characters. There are those which
are not allowed in file names “\/:*?<>| and those allowed in filenames &().
I guess those not allowed in filenames don’t need any special treatment,
since one can’t do that much with them except their special shell use. The
other 3 one should be escape with ^. There is no way to quote shell special
characters with cmd – they must be escaped with ^.
The only real issue is that some people seem to use build rules with “real”
bash stuff in it – well if you do this I guess you anyway have a cygwin
around.
So I wonder if it would be appreciated by the community to have an
ocamlbuild (e.g. as a configure option) which uses cmd instead of bash. I
think if one does the escaping properly, this should be good for the large
majority of projects out there.
Ocamlc seems to run fine without cygwin, but I didn’t test other tools like
ocamllex or menhir as yet. Are there known issues?
Best regards,
Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: [phone], www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

[Soegtrop, Michael]

Dear Kakadu,

Post by Kakadu
Will the powershell be more convenient?

I don't think so. It is different from bash and as long as it is different, it doesn't make much of a difference how different. ocamlbuild (as far as I can tell) wraps all commands through as shell / syscall. 99% is really simple stuff like calling an executable with a reasonable parameter list or calling ln or rm. Output redirection happens (e.g. for ocamldep), but nothing complicated.

I think it only get's bad when users have bash code in their rules - but then you are lost anyway without bash.

So I would say keep it simple and give cmd a try. It should work unless people do things like filenames with <|> in it.

best regards,

Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: [phone], www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

[Daniel Bünzli]

Post by Soegtrop, Michael
So I wonder if it would be appreciated by the community to have an ocamlbuild (e.g. as a configure option) which uses cmd instead of bash. I think if one does the escaping properly, this should be good for the large majority of projects out there.

See https://github.com/ocaml/ocamlbuild/issues/64

Best,

Daniel

[Soegtrop, Michael]

Dear Daniel,

Post by Daniel Bünzli
See https://github.com/ocaml/ocamlbuild/issues/64

yes, I have seen the discussion, especially the discussion if one should use cmd vs. removing the use of a shell by ocamlbuild entirely. I agree that the latter would be the better solution, but it would be a major change since currently ocamlbuild wraps everything through string commands. But maybe it is not as bad as it looks.

And I take this as a "yes" on the question if something like this would be appreciated by the community.

I am a bit in a hurry to get something working for Coq 8.6. I guess I first make a cmd based hack for Coq and then look into the real solution.

I will continue the discussion on the ocamlbuild issue tracker item linked above.

Best regards,

Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: [phone], www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

[Gabriel Scherer]

Post by Soegtrop, Michael
And I take this as a "yes" on the question if something like this would

be appreciated by the community.

This is my impression as well, and I would personally warmly welcome
changes to improve Windows users experience -- I think of ocamlbuild as a
portable build system, and I would like to work out of the box; I don't
think there are any fundamental design limitations that would prevent this
good portability experience.


One difficulty right now in term of development dynamics is that I don't
have a Windows machine to test on myself, so I'm rather conservative
regarding Windows-related changes to avoid regressions for non-Windows user
(it's not necessarily easy to predict which changes risk breaking stuff),
or even regressions for other Windows users (some of the non-intuitive
Windows-related code is there because otherwise stuff breaks for some
people). Sometimes Windows developers make a certain amount of changes that
look right to them and fix actual problems on their system, but then it's
hard for me to see what can be safely integrated (see for example
https://github.com/ocaml/ocamlbuild/pull/70 , whose low-hanging fruits I
could merge quickly, but for the rest I worry of regressions ).

To solve that problem we need a better testing infrastructure for
ocamlbuild, but also get more tests from Windows users to provide feedback
on other approaches or patches reworks, etc. If someone, for example you,
is willing to start a more persistent approach of iterative improvements
and tests, I think that things could improve rather quickly.

On Thu, Oct 6, 2016 at 10:15 AM, Soegtrop, Michael <

Post by Soegtrop, Michael
Dear Daniel,

Post by Daniel Bünzli
See https://github.com/ocaml/ocamlbuild/issues/64

yes, I have seen the discussion, especially the discussion if one should
use cmd vs. removing the use of a shell by ocamlbuild entirely. I agree
that the latter would be the better solution, but it would be a major
change since currently ocamlbuild wraps everything through string commands.
But maybe it is not as bad as it looks.
And I take this as a "yes" on the question if something like this would be
appreciated by the community.
I am a bit in a hurry to get something working for Coq 8.6. I guess I
first make a cmd based hack for Coq and then look into the real solution.
I will continue the discussion on the ocamlbuild issue tracker item linked above.
Best regards,
Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: [phone], www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
--
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

[Soegtrop, Michael]

Dear Gabriel,

To solve that problem we need a better testing infrastructure for ocamlbuild, but also get more tests from Windows users to provide feedback on other approaches or patches reworks, etc. If someone, for example you, is willing to start a more persistent approach of iterative improvements and tests, I think that things could improve rather quickly.

well I am using ocamlbuild daily on Windows, currently with MinGW cross OCaml on cygwin, but I would like to switch to a native MinGW solution. I cannot make any long term promises, but at least for a midterm transitional period (say 6 months), I have no issue to run a test suite every week on plain Windows, on plain Cygwin, on MinGW cross on Cygwin and also on Linux.

Also I have scripts which fully automate setup and test of plain MinGW, MinGW cross on Cygwin and plain Cygwin OCaml. That is you start a batch file, and it will install a fresh cygwin and start a bash script which downloads and compiles the respective flavor of OCaml and run some tests with 0 user interaction. If this helps, I would be happy to tailor these scripts to whatever automation systems you have and contribute them.

Privately I am using Amazon AWS (that is rental of datacenter infrastructure of Amazon’s own datacenters) quite a bit. If the OCamlbuild community has issues with setting up a reliable multi-platform server infrastructure, this might be an effective and very low cost solution. You get virtual Windows and Linux servers with root access and customizable specs (memory, CPU). The good thing is that you pay for the servers only when they run. I think you would have to test quite a lot to get a bill of more than 5$ a month, likely it will be around 1$. If this is something we want to look into, I would pay the bill privately for 2 years (up to 100€). One can integrate such systems easily with other systems, e.g. you do some signed http post with a script, which triggers a process on an Amazon lambda server, which boots up the real servers which then runs the tests, post the results on some web storage and shut down again. I really love this stuff ;-)

An interesting question is how many “obscure” test cases for ocamlbuild we can get. My own projects use Menhir, Ocamllex and a few non-standard libraries, so at least this would run.

Best regards,

Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: [phone], www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

[Gerd Stolpmann]

This is also what omake does. Pipes, redirections, and even a number of
commands like rm, cp, ls are completely implemented inside omake, so
that everything works on Unix and Windows the same. I guess this is the
only way to get to a uniform build system, at least if you don't want
to depend on 3rd-party tools like Cygwin.

Gerd

I don't have an opinion on using cmd in ocamlbuild, but I have been
looking at similar things for jenga recently. With jenga the actions
generated by the rules are of the form (prog, args) and when one
wants
to to do something more complicated, they have to manually build a
shell command. In the Jane Street rules we are using bash.
Going through bash is often frustrating, even on Unix. Moreover for
the public release of Jane Street packages I'd like to avoid relying
too much on bash as it has often been a source of problems in the
past.
The solution I'm aimed at is to have the jenga rules produce actions
using a small DSL allowing pipes and other things and interpret this
DSL without the use of a third-party shell, i.e. just using system
calls and threads.
It's still a work in progress but I already have the backend part
working [1]. It's aimed at being portable on Windows. The code for
Windows is written but not yet tested, I plan to do it at some point.
I imagine that it shouldn't be too use this in ocamlbuild if the [Sh]
constructor was removed and replaced by a few other constructors to
express pipes, redirections, etc...
  [1] https://github.com/janestreet/shexp
On Thu, Oct 6, 2016 at 2:38 PM, Soegtrop, Michael

Post by Soegtrop, Michael
Dear OCaml users and developers,
I looked into the fact that ocamlbuild requires bash/cygwin to run.
Actually
it does very little use of bash and I think cmd + ln + rm would
work quite
well.
From comments in various list I understood that people had issues
with
escaping for cmd. I agree that this is a bit nasty, but not rocket
science
either. I guess the main issue is that for cmd not only space and
tab are
command argument separators, but also equal (=), comma (,) and
semicolon
(;). So for cmd a=b,c;d is the same as a b c d which is the same as
a , = ,
b =;= c==d. Essentially cmd treats unquoted pieces as sed ‘s/[\t
=,;]+/ /g’.
If a name contains any of these characters, one has to quote it for
cmd, but
not for bash. Since = and , are not that uncommon in file names, I
guess
this resulted in issues.
BUT cmd splits the command line only into command names, complete
argument
lists and file names for redirection. That is if you call e.g.
ocamlc, cmd
just replaces shell variables and extracts the executable name, but
does not
split up the argument list into individual pieces. bash on Windows
does this
neither, because (afaik) Windows has at the lowest level no
mechanism to
pass individual arguments to an executable. The command gets a
string and
splitting this string and even globing is the business of the
executable. So
it is rather odd that this behaves substantially different for bash
and for
cmd. The only thing which needs to be quoted properly are command
names and
file names of redirections.
There might be issue with shell special characters. There are those
which
are not allowed in file names “\/:*?<>| and those allowed in
filenames &().
I guess those not allowed in filenames don’t need any special
treatment,
since one can’t do that much with them except their special shell
use. The
other 3 one should be escape with ^. There is no way to quote shell
special
characters with cmd – they must be escaped with ^.
The only real issue is that some people seem to use build rules
with “real”
bash stuff in it – well if you do this I guess you anyway have a
cygwin
around.
So I wonder if it would be appreciated by the community to have an
ocamlbuild (e.g. as a configure option) which uses cmd instead of
bash. I
think if one does the escaping properly, this should be good for
the large
majority of projects out there.
Ocamlc seems to run fine without cygwin, but I didn’t test other
tools like
ocamllex or menhir as yet. Are there known issues?
Best regards,
Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: [phone], www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

-- 
Jeremie

[Soegtrop, Michael]

Dear Gerd, Jeremie,

I agree, something like a very simple shell which gets its commands and redirections described as some sort of AST is likely the easiest to port and most robust solution.

I will look into Jeremie's development and omake and see if it is from a technical and licensing point of view reusable for ocamlbuild.

Best Regards,

Michael

-----Original Message-----
Sent: Thursday, October 06, 2016 8:56 PM
To: Jeremie Dimino; Soegtrop, Michael
Subject: Re: [Caml-list] ocamlbuild on Windows and bash vs. cmd
This is also what omake does. Pipes, redirections, and even a number of
commands like rm, cp, ls are completely implemented inside omake, so that
everything works on Unix and Windows the same. I guess this is the only way
to get to a uniform build system, at least if you don't want to depend on 3rd-
party tools like Cygwin.
Gerd

I don't have an opinion on using cmd in ocamlbuild, but I have been
looking at similar things for jenga recently. With jenga the actions
generated by the rules are of the form (prog, args) and when one wants
to to do something more complicated, they have to manually build a
shell command. In the Jane Street rules we are using bash.
Going through bash is often frustrating, even on Unix. Moreover for
the public release of Jane Street packages I'd like to avoid relying
too much on bash as it has often been a source of problems in the
past.
The solution I'm aimed at is to have the jenga rules produce actions
using a small DSL allowing pipes and other things and interpret this
DSL without the use of a third-party shell, i.e. just using system
calls and threads.
It's still a work in progress but I already have the backend part
working [1]. It's aimed at being portable on Windows. The code for
Windows is written but not yet tested, I plan to do it at some point.
I imagine that it shouldn't be too use this in ocamlbuild if the [Sh]
constructor was removed and replaced by a few other constructors to
express pipes, redirections, etc...
  [1] https://github.com/janestreet/shexp

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: [phone], www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

[Soegtrop, Michael]

Dear Yaron,

I very much hope the licensing isn't an issue. We purposely picked a very liberal license to make this kind of thing as easy as possible. Do tell us if you find an issue there.

it is hard to believe, but the licensing is an issue. According to this reference from Apache:

https://www.apache.org/licenses/GPL-compatibility.html

citation:

“Despite our best efforts, the FSF has never considered the Apache License to be compatible with GPL version 2, citing the patent termination and indemnification provisions as restrictions not present in the older GPL license.”

the apache license you use is not compatible with GPL2. Since the OCaml library is LGPL 2.1, it cannot include Apache licensed code. The patent issue mentioned above has nothing to do with the difference between GPL and LGPL, so my guess would be that this also applies to LGPL 2.X.

Please note that the above reference states that Apache is compatible with GPL 3, but I guess you can write a PhD thesis in law and/or computer science about the topic if it is better to have GPL 2.x+ or GPL 3+Apache.

If you think it is worthwhile, I can ask one of our open source lawyers for advice, but I think the above statement from Apache is fairly clear.

So as it looks, I have to rewrite from scratch what I need - sigh

Best regards,

Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: [phone], www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

[Ivan Gotovchits]

Hi Yaron,

Given that most of the Janestreet codebase is developed in-house, it might
be not that hard to relicense it. This is especially true for `shexp` that
currently
has only one contributor. I would suggest switching to ISC or MIT (aka X11,
aka Expat) licenses. Probably the former should be preferred, as it is
shorter and cleaner.
The full list of licenses compatible with GPL is here [1].

Regards,
Ivan

[1]: https://www.gnu.org/licenses/license-list.en.html

You have got to be kidding me.
Maybe we can dual license? It would be lovely to avoid the rewrite.
What license would be adequate? Maybe we can license everything under
LGPLv2+exception and Apache?
I hate licenses.
y
On Tue, Oct 11, 2016 at 7:49 AM, Soegtrop, Michael

Post by Soegtrop, Michael
Dear Yaron,

I very much hope the licensing isn't an issue. We purposely picked a

very

Post by Soegtrop, Michael

liberal license to make this kind of thing as easy as possible. Do tell

us

Post by Soegtrop, Michael

if you find an issue there.

it is hard to believe, but the licensing is an issue. According to this
https://www.apache.org/licenses/GPL-compatibility.html
“Despite our best efforts, the FSF has never considered the Apache

License

Post by Soegtrop, Michael
to be compatible with GPL version 2, citing the patent termination and
indemnification provisions as restrictions not present in the older GPL
license.”
the apache license you use is not compatible with GPL2. Since the OCaml
library is LGPL 2.1, it cannot include Apache licensed code. The patent
issue mentioned above has nothing to do with the difference between GPL

and

Post by Soegtrop, Michael
LGPL, so my guess would be that this also applies to LGPL 2.X.
Please note that the above reference states that Apache is compatible

with

Post by Soegtrop, Michael
GPL 3, but I guess you can write a PhD thesis in law and/or computer

science

Post by Soegtrop, Michael
about the topic if it is better to have GPL 2.x+ or GPL 3+Apache.
If you think it is worthwhile, I can ask one of our open source lawyers

for

Post by Soegtrop, Michael
advice, but I think the above statement from Apache is fairly clear.
So as it looks, I have to rewrite from scratch what I need - sigh
Best regards,
Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: [phone], www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

--
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

[Anil Madhavapeddy]

The standard MirageOS license for our libraries is ISC, which is short and simple (and the standard license used for new code in OpenBSD):

https://github.com/mirage/mirage/blob/master/LICENSE.md

regards,
Anil

Post by Ivan Gotovchits
Hi Yaron,
Given that most of the Janestreet codebase is developed in-house, it might be not that hard to relicense it. This is especially true for `shexp` that currently
has only one contributor. I would suggest switching to ISC or MIT (aka X11, aka Expat) licenses. Probably the former should be preferred, as it is shorter and cleaner.
The full list of licenses compatible with GPL is here [1].
Regards,
Ivan
[1]: https://www.gnu.org/licenses/license-list.en.html
You have got to be kidding me.
Maybe we can dual license? It would be lovely to avoid the rewrite.
What license would be adequate? Maybe we can license everything under
LGPLv2+exception and Apache?
I hate licenses.
y
On Tue, Oct 11, 2016 at 7:49 AM, Soegtrop, Michael

Post by Soegtrop, Michael
Dear Yaron,

I very much hope the licensing isn't an issue. We purposely picked a very
liberal license to make this kind of thing as easy as possible. Do tell us
if you find an issue there.

it is hard to believe, but the licensing is an issue. According to this
https://www.apache.org/licenses/GPL-compatibility.html
“Despite our best efforts, the FSF has never considered the Apache License
to be compatible with GPL version 2, citing the patent termination and
indemnification provisions as restrictions not present in the older GPL
license.”
the apache license you use is not compatible with GPL2. Since the OCaml
library is LGPL 2.1, it cannot include Apache licensed code. The patent
issue mentioned above has nothing to do with the difference between GPL and
LGPL, so my guess would be that this also applies to LGPL 2.X.
Please note that the above reference states that Apache is compatible with
GPL 3, but I guess you can write a PhD thesis in law and/or computer science
about the topic if it is better to have GPL 2.x+ or GPL 3+Apache.
If you think it is worthwhile, I can ask one of our open source lawyers for
advice, but I think the above statement from Apache is fairly clear.
So as it looks, I have to rewrite from scratch what I need - sigh
Best regards,
Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: [phone], www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

--
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

[Hendrik Boom]

We have a CLA from all external contributors, so re-licensing under a
more liberal license should be easy, except insofar as we need to do
some due dilligence on whatever new license we pick. Presumably, the
open source lawyer who advised us to pick Apache 2 had some reason for
it, which we need to think about it.

Doesn't the current Apache license have a clause allowing you to
relicence it with some variety of GPL?

-- hendrik

(By the way: see? CLAs aren't all bad...)
We'll look into it.
y

Post by Anil Madhavapeddy
https://github.com/mirage/mirage/blob/master/LICENSE.md
regards,
Anil

Post by Ivan Gotovchits
Hi Yaron,
Given that most of the Janestreet codebase is developed in-house, it might be not that hard to relicense it. This is especially true for `shexp` that currently
has only one contributor. I would suggest switching to ISC or MIT (aka X11, aka Expat) licenses. Probably the former should be preferred, as it is shorter and cleaner.
The full list of licenses compatible with GPL is here [1].
Regards,
Ivan
[1]: https://www.gnu.org/licenses/license-list.en.html
You have got to be kidding me.
Maybe we can dual license? It would be lovely to avoid the rewrite.
What license would be adequate? Maybe we can license everything under
LGPLv2+exception and Apache?
I hate licenses.
y
On Tue, Oct 11, 2016 at 7:49 AM, Soegtrop, Michael

Post by Soegtrop, Michael
Dear Yaron,

I very much hope the licensing isn't an issue. We purposely picked a very
liberal license to make this kind of thing as easy as possible. Do tell us
if you find an issue there.

it is hard to believe, but the licensing is an issue. According to this
https://www.apache.org/licenses/GPL-compatibility.html
“Despite our best efforts, the FSF has never considered the Apache License
to be compatible with GPL version 2, citing the patent termination and
indemnification provisions as restrictions not present in the older GPL
license.”
the apache license you use is not compatible with GPL2. Since the OCaml
library is LGPL 2.1, it cannot include Apache licensed code. The patent
issue mentioned above has nothing to do with the difference between GPL and
LGPL, so my guess would be that this also applies to LGPL 2.X.
Please note that the above reference states that Apache is compatible with
GPL 3, but I guess you can write a PhD thesis in law and/or computer science
about the topic if it is better to have GPL 2.x+ or GPL 3+Apache.
If you think it is worthwhile, I can ask one of our open source lawyers for
advice, but I think the above statement from Apache is fairly clear.
So as it looks, I have to rewrite from scratch what I need - sigh
Best regards,
Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: [phone], www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

--
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

--
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

[Soegtrop, Michael]

Dear Hendrik,

Doesn't the current Apache license have a clause allowing you to relicence it
with some variety of GPL?

As far as I know the FSF agreed that the Apache license conditions are a subset of the GPL 3 conditions, so that you can redistribute Apache stuff under GPL3. But the references I looked into (Wikipedia + the Apache site I cited below) all state that no version of Apache is compatible with GPL 2 and Ocamllib is LGPL2.1. Furthermore (again afaik) GPL2 and GPL3 are also incompatible, so that you cannot even combine Apache SW and ocammlib and distribute it under GPL3 or LGPL3.

Best regards,

Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: [phone], www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

[Adrien Nader]

The central aspect for these incompatibilities is patents afaik.

GPLv2 forbids additional restrictions being put in place. The GPLv3 has
additional restrictions compared to the GPLv2 (at least because of the
patent clauses) and is therefore obviously incompatible.

The Apache and GPLv3 licenses have patent retaliation clauses which help
deter actors that aren't patent trolls from suing (basically, they say
that if you sue someone over the patents which this software could
relate to, then you lose the right to use the software). Patent trolls
have nothing to lose so they don't really care but they're a different
matter.

Overall the patent retaliation clause is good and the Apache software
helps because it is about /both/ copyrights and patents. Only handling
the copyright aspects nowadays only works if you live in Care Bear's
world.

License compatibility is a fairly complex topic which brings an extra
set of constraints. Dual- or even triple- licensing is a good solution.

NB: this comes with the usual warnings but factored at the end rather
than being written in each and every sentence: IANAL, I'm not an expert,
add "as far as I know" in every sentence you want to.

[Soegtrop, Michael]

Dear Yaron,

I hate licenses.

it is definitely a good source of income for lawyers, and I found it is worthwhile for a SW developer to take a 1 day course on the topic - it is a fairly surprising subject.

I would think it would be best to triple license it under Apache + a verbatim copy of the current Ocamllib license (LGPL 2.1 with link exception) + "the current or any past license of Ocamllib ". The latter would make it easier for the Ocamllib team to change their license later. If this helps, I could ask our in house license lawyers for advice.

But I have no idea if there are, besides the license issues, other reasons for not having common modules. One is likely the different base library, but in this specific case it shouldn't be much of an issue.


One technical note: I would implement in addition to processes defined by executables some simple built in standard processes, like cp, ln, cat, mkdir, tee (might be a combiner) and later maybe even sed, sort, wc, find. It doesn't help to have a portable shell environment, if you don't have portable core commands. Compiling "ln" for Windows is actually harder than compiling gcc or OCaml. Of cause it doesn't make sense to reimplement half of unix, but at least simple forms of those commands used in shell scripts every other line and which are just a few lines in OCaml would make sense.

Best regards,

Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: [phone], www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

[Manfred Lotz]

On Tue, 11 Oct 2016 13:46:28 +0000

Post by Soegtrop, Michael
Dear Yaron,

I hate licenses.

:-)

Post by Soegtrop, Michael
it is definitely a good source of income for lawyers, and I found it
is worthwhile for a SW developer to take a 1 day course on the topic
- it is a fairly surprising subject.

Could you point to such a course?

Post by Soegtrop, Michael
I would think it would be best to triple license it under Apache + a
verbatim copy of the current Ocamllib license (LGPL 2.1 with link
exception) + "the current or any past license of Ocamllib ". The
latter would make it easier for the Ocamllib team to change their
license later. If this helps, I could ask our in house license
lawyers for advice.
But I have no idea if there are, besides the license issues, other
reasons for not having common modules. One is likely the different
base library, but in this specific case it shouldn't be much of an
issue.
One technical note: I would implement in addition to processes
defined by executables some simple built in standard processes, like
cp, ln, cat, mkdir, tee (might be a combiner) and later maybe even
sed, sort, wc, find. It doesn't help to have a portable shell
environment, if you don't have portable core commands. Compiling "ln"
for Windows is actually harder than compiling gcc or OCaml. Of cause
it doesn't make sense to reimplement half of unix, but at least
simple forms of those commands used in shell scripts every other line
and which are just a few lines in OCaml would make sense.
Best regards,
Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: [phone], www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928