I am pleased to announce that the latest version 1.7 of GNU APL now has an interface from Erlang resp. Elixir. Via that interface you can call any of the powerful APL (actually APL2 with nested values) functions or operators, create and query APL functions and variables, manage entire APL workspaces and so on.
The interface comes as an Erlang module with Erlang functions for the currently anticipated use cases. More can be added as needed. The interface uses Dirk Laurie’s libapl and Erlang native functions.
Since the interface is quite new and has not been used much so far, I am expecting some initial problems. But I am committed to fix them as they are reported. Any feedback is welcome at firstname.lastname@example.org.
Hope you like it,
Dr. Jürgen Sauermann
Maintainer of GNU APL
Can you please provide further Information how and where that library can be obtained from? Also some deeper insight into APL would be nice, I think a link to the official homepage should be sufficient.
At the top-level directory of the package, there is a sub-directory named ‘erlang’ which contains all Erlang related stuff in GNU APL. Including a README file and an Erlang example file. For those whi want to have a look at it first without installing it, you can go to http://svn.savannah.gnu.org/viewvc/apl/trunk to browse the package.
So there is no way to pull it as a dependency via mix or rebar from hex?
As a developer who uses this lib, I have to trust in the system administrator to have all the necessary pathes set up correctly so that either the sources as well as the beam files will be found by the compiler.
Also by making it a single module which is generated on compile it’s even worse. I have to actively remember to build it in my application.
And not making it an otp app on its own makes me nervous about the licensing. Can I pull it into my own sources without needing to release them under the GPL? When I copy the compiled module into my own source tree to vendor it, will this mean I am depriving from it?
Last but not least? Since its a library why not make it LGPL?
mix/rebar: I seriously doubt that using e.g. mix would be the proper way of installing GNU APL. Building GNU APL depends heavily on autoconf/automake. I see no feasible way to change that. The GNU APL interface to Erlang depends on libapl which consists primarily of C++ source files. So you should think of it more as an OTP extension than of an Elixir library. Therefore the installation of GNU APL is more like an OTP installation from C sources than a library written in Elixir. ANd it also addresses Erlang users (which may not use mix).
paths etc: Normally autoconf sets up the paths correctly, so no need for sysadmin. However, normally you need write permission to e.g. /usr/local/bin and /usr/loacl/lib to install GNU APL (as libapl or as executable binary). If you don’t have these permissions then you can still install it into a different location where you have permissions.
otp app: I have not made it an OTP app because I want to be able to use it from Erlang. And you don’t have to copy it into every application. The idea is that the Erlang module (whose format was, BTW, dictated by how native Erlang functions are supposed to work) is installed only once per system and can then be used by different applications.
LGPL: I have consulted http://www.gnu.org/licenses/why-not-lgpl.html and according to that GPL is the license to use, Even though libapl comes as a (shared) library file, it contains the full GNU APL interpreter. Apart from that, GPL is our best friend and not your enemy. I am using it because it protects me from being sued for errors in my own code by third parties who did not even pay for it.
I also believe that the differences that you see between the GPL and the LGPL may not be such as you maybe believe they are. My interpretation of the GPL (which could also be wrong because IANAL) ist that as long as you do not change the libapl sources (i.e. the C++ files) you have no problems. However if you change them, for example by removing the copyright notices in them, then your troubles start. But that should be the same with the LGPL.
The point here is that the only reason why libapl is a shared library is because the Erlang native function interface requires a shared library. The interface could be different, for example a pipe into the an apl executable. I can’t quite see why a minor difference in the implementation details of an interface should require a major change in the license of the components between which the interface is created.
Another question is if we are talking about the license under which GNU APL is released or the license under which the interface from Erlang to GNU APL is released. The latter is almost trivial and below the 300 line limit mentioned in the GNU policies. So maybe all this is not really an issue.
Finally I do not believe that GNU APL can even be distributed in binary form, say as a pre-compiled shared library. I would anticipate a scenario where the user downloads, ./configures, and ‘sudo installs’ GNU APL separately from Erlang, or OTP, or Elixir or whatever. That keeps matters simple without raising any licensing problems.
It may be true the GPL is a virus, but if so then IMHO it is a good one.
Section 4 describes it, subsection d-1 is the detail:
Use a suitable shared library mechanism for linking with the
Library. A suitable mechanism is one that (a) uses at run time
a copy of the Library already present on the user’s computer
system, and (b) will operate properly with a modified version
of the Library that is interface-compatible with the Linked
This is the old old version 1 document though. ^.^
Indeed, hence why LGPL with a static linking exception is usually use for things just like this, it is what it was made for, it still keeps the gpl with forced code modification sharing, but without tarnishing the code it is used in. ^.^
It has its uses, but in software like this it does a lot more harm than good, making the libraries rarely used and making the effort put in to them much less valuable.
I see. I was actually searching the text for dynamic (linking) but not for shared. My fault.
But I still can’t see at which point a combined work occurs, let along modifications (of GNU APL in this case). My thinking is this:
Assume command ls is released under GPL and so is bash. That cannot reasonably mean that in order to use the ls command in bash the license of ls needs to be converted from GPL to LGPL or LGPL with a linking exception?
And again, I do not foresee that anybody would distribute GNU APL along with his/her own work. Or even do modifications of GNU APL.
In other words is the critique of GNU APL using the GPL directed against the GPL as such even though the GPL is de facto not preventing the user from anything he/she should be entitled to do as far as GNU APL is concerned, or is there a real world scenario which is limiting the user of GNU APL in an undue way? And what scenario would that be?
Heh, it has to do with using the ‘APL standard library’ and the interfaces to call in to APL. The interfaces require that anything that uses those interfaces also has to be GPL, and the standard library in APL means that code made in APL that links with it also is bound to the GPL. That is why linking exceptions exist for the standard libraries and calling interfaces for every language that I’ve run across. ^.^
So if anyone wanted to distribute the ability to call APL from their EVM program then their program needs to be GPL as well. If they make a program in APL that makes an APL calls in to the APL standard library that they then call directly from the EVM, then their EVM program needs to be GPL as well.
Things like that, I can go in to more detail but this is discussed to death online. ^.^
But in general, do not just pick a license randomly, actually research in to them, the GPL itself means that it is near impossible to use it with anything that is not GPL, and since most things are not GPL and cannot be GPL, it could never be used with up.
It details it, but in essence that means calling programmatic interface of the program.
No, GPL can work with GPL fine, however bash calls ls via the kernel process command (well actually you usually call the builtin in reality), that is an OS bound, not an application interface. Now if bash talked to ls via a specific protocol, that’d be different.
If this is not intended to be used with a distributed EVM program and an APL ‘compiled program’ (of whatever form it is) is not, then no worry. ^.^
Actually the GPL prevents users from being able to do a significant amount. If you just want to ensure that the APL and any changes to it itself are distributed as open source then there are licenses for that, however the GPL is not one. A real world scenario is a program made with apl that uses the apl standard library would not be able to be linked with a non-gpl program and distributed, ever. Another real world scenario is the apl itself being used as, say, a scripting language, in a program that is not gpl, then those could never ever be distributed as well in that form.
I consulted the GNU web pages regarding licenses and it is in fact so that if you link with libapl then you should GPL you code. Actually you should use a “GPL compatible license”, it does not have to be the GPL itself.
And “learn about the licenses you use”. Of course. In the case of GNU APL I did that and the choice at that time was GPL. At that time there was no interface to other languages in GNU APL. That changed only recently (in GNU APL 1.6 with a LUA interface and in 1.7 with the Erlang interface). Also the choice of the GNU project for hosting GNU APL was not accidental. It would have been far easier for me to go to one of the other hosting sites (if I remember correctly then I already had a small project at sourceforge.net at that time) but I did choose GNU for a number of reasons. One of the reasons was their give-and-take philosophy. GNU APL would not have been possible in its current form without the help of other tools. I have been working in companies that took (financial) advantage of using GNU tools without ever bothering to, for example, donate anything to the GNU project. At the same time they paid millions to MS and forced their employees to use Windows.
So the status quo is this. If you write and distribute a program under the GPL then everything is fine. If you do not want to release it under the GPL or a similar license then I would like to understand why not. I know that there could be several reasons, but most of them consider other aspects (number of users, convenience of use etc) more important than, for example, freedom of software.
Simply put, if someone does not care for my values, why should I bother to care for his?
I am generally open to changing the licensing of GNU APL, but before doing that I would like to see the need for it. And I would also need some help with changing the license. In practice this would mean to contact the GNU project’s legal staff. As of today the only feedback that I have received from the Elixir forum is some dissatisfaction with the license that I have chosen. Which renders the entire discussion as purely theoretical.
I did not mean our discussion but (the lack of) other feedback, in particular
technical issues. Licenses are really not my favorite topic.
But the license does mean that it could not be used with most elixir projects
though, so it is an odd thing…
And that is still the part that I do not understand. I’ve spent some hours
earlier today reading the GPLv3. I am not a lawyer and not a native English
speaker either, so this was somewhat tedious.
According to the GPL, the requirement for an Elixir project to also release
their code under the GPL exists only if the project releases a combined work
based on the GPL’ed program. Following the definitions given in the GPL this
“based on” implies that either a copy of the GNU APL sources or a compiled
version (i.e. libapl.so) is conveyed by the Elixir project. There are 4 cases:
GNU APL sources unmodified
GNU APL sources modified
libapl.so from GNU APL sources unmodified
libapl.so from GNU APL sources modified
Of these cases, 3. and 4. make no sense for technical reasons. The installation
procedure for GNU APL (including libapl) does quite a number of tests in its
./configure script in order to adapts itself to the underlying systems. That
starts with figuring the paths to #include files and to libraries present on
the build machine, proceeds with figuring the installed SQL providers (SQLite,
Postgres, or both) and some other details present on the platform.
This installation process works pretty well these days, but a consequence of
it is that a libapl compiled on one machine will fail with > 99% probability
even if the CPUs and OSs are the same. This completely rules out cases 3.
and 4. above.
As to option 1. above this is handled in chapter 4 “Conveying verbatim copies”
of the GPL and there are no real restrictions on the Elixir project except that
you must not touch copyright notices of GNU APL or the license under which it
What remains is case 2 - the Elixir project modifies GNU APL and conveys the
modified sources (or only the modifications themselves). Only in this case
exists the requirement for the the Elixir project to release its own code under
the GPL. Even though this case is possible in theory, I would call it fairly
unlikely in real life. Only a handful of people was so far able to make changes
in source code GNU APL and none of them could do so without support from the
GNU APL project. I would also assume the maintenance of changes made to the
GNU APL code base requires that such changes are made by the GNU project and
not by other projects because otherwise the changes in the GNU APL code base
would sooner or later conflict with the changes made by other projects. From a
maintenance perspective having Elixir projects shipping GNU APL changes around
is an extremely scary scenario that neither an Elixir project nor the GNU APL
project can really aim for.
And if worst comes to worst then the Elixir project can still publish changes to GNU APL separately from their own project.
But the license does mean that it could not be used with most elixir projects
though, so it is an odd thing…
So taking all this together I would claim that very few, if any, elixir projects
are really harmed in any way by the fact that GNU APL was released under the
GPL. There might be a perception to that effect, but I do not believe that such
a perception would be justified.