new release of the MLton Standard ML compiler
Stephen Weeks
optimizing compiler for Standard ML, available at http://mlton.org/.
MLton version 20051202 is the first public release since 20041109.
The major improvements are:
+ The MLton license is now BSD-style instead of the GPL.
+ New platforms: X86/MinGW and HPPA/Linux.
+ Improved and expanded documentation, based on the MLton wiki.
+ Improved foreign-function interface, now with support for ML-NLFFI.
+ New ML Basis annotations.
+ New libraries: ckit library, SML/NJ library.
MLton has the following features.
+ Portability.
MLton runs on the following platforms.
o HPPA: Debian.
o PowerPC: Debian, Mac OSX.
o X86: Linux, Cygwin/Windows, FreeBSD, MinGW/Windows, NetBSD,
OpenBSD.
o Sparc: Debian, Solaris.
+ Robustness.
o Supports the full SML 97 language.
o Follows the Definition of SML closely.
o Has a complete implementation of the Basis Library.
o Generates standalone executables.
o Compiles large programs (hundreds of thousands of lines).
o Supports large amounts of memory (up to 4G).
o Supports large arrays (up to 2G elements).
o Supports large files (using 64-bit integers for file positions).
+ Performance.
o Executables with excellent running times.
o Untagged and unboxed native integers and words.
o Unboxed reals.
o Unboxed arrays.
o Multiple garbage collection strategies.
o Fast arbitrary-precision arithmetic based on the GnuMP.
+ Tools.
o Source-level profiler for both time and allocation.
o Lexer generator.
o Parser generator.
o ML-NLFFIGEN.
+ Extensions.
o Fast C FFI for calling from SML to C and from C to SML.
o ML Basis system for programming in the very large.
o Libraries for C pointers, continuations, interval timers, random
numbers, resource limits, resource usage, signal handlers,
system logging, threads, and heap save and restore.
For more information, go to the MLton home page.
Enjoy!
-- The MLton Team
Joachim Durchholz
> The major improvements are:
>
> + The MLton license is now BSD-style instead of the GPL.
The topic says it all: what's the rationale behind that change?
(No criticism intended, just an interest in what how people decide in
this matter.)
Regards,
Jo
Paul Rubin
> > The major improvements are:
> > + The MLton license is now BSD-style instead of the GPL.
>
> The topic says it all: what's the rationale behind that change?
> (No criticism intended, just an interest in what how people decide in
> this matter.)
In my case, I was once asked to change a GPL license to BSD, and I
offered to do so on the condition that the requester provide funding
for the the project. I didn't get taken up on the offer.
I don't see the MLton license switch as an improvement. I'd describe
it as a neutral change at best. I don't mind working on proprietary
code, or on BSD-licensed code that can make its way into proprietary
products, but when I do either of those things I expect to get paid.
I do like doing volunteer work on free software but I try to limit it
to GPL projects. I don't have much interest in doing some software
company's development work for nothing.
I'm guessing MLton's license change was also because someone who
wanted to fork MLton into a proprietary program requested the change.
I hope that person or company is now funding MLton, rather than just
getting a handout.
Stephen Weeks
>
> The topic says it all: what's the rationale behind that change?
In short, given the competitive landscape, it is the best way to grow
the MLton community and to help MLton's users and potential users.
The GPL hurt those aims in a number of ways. First, because MLton
includes SML and C library code in every executable, the GPL infected
MLton-generated executables. This made MLton a non-starter for a
number of potential users, especially commercial ones, who typically
don't want to open source their code. We could have fixed that
problem by licensing the runtime and library under a different license
than the compiler proper, but chose not to because of the complexities
of doing so, plus the competitive landscape.
We did seriously consider commercial dual licensing in the Cygwin
model, the idea being to charge users a fee for a non-GPL license on
the runtime and libraries. Again, we ruled this out because of the
competitive landscape. The point is that there are many other
comparable language implementations out there (SML/NJ, Haskell,
OCaml), all of which offered superior licensing to a potential
commercial user. Given the extremely small size of the MLton/SML
community, anything that turns off potential new users is a mistake,
and the GPL did that.
Another issue that we had to deal with was a disinterested copyright
holder, NEC, who held the copyright on the original work done on MLton
from 1997-1999, and who had originally released the work under the
GPL. It was quite a challenge to get them to relicense the code, and
we wanted to put ourselves in a situation where we never had to go
through that process again. That argued for getting as permissive a
license as possible from them, which we did. Of course, we could have
then licensed the work we've done since 1999 under a compatible, but
more restrictive license. Again, we chose not to do so because of the
complexity of multiple licenses and because it would make us less
attractive than our competitors.
There is the issue of proprietary forks, which are enabled by the new
license. I think even those would be a plus, because in all
likelihood they wouldn't have happened with the old license, and
because even they will likely offer some positive feedback to the
open-source MLton. The benefit could be in the form of contributed
code, donations, or even in consulting or support contracts. Again,
the more people using MLton/SML, the more help the community will see,
even if everything people do isn't given back.
There is still the problem of funding the MLton project, which is not
self funded. But I believe that problem is much more likely to solve
itself with a larger community than by trying to extract money from
the very few commercial users that MLton has.
To close, the decision to go a BSD-style license was a very pragmatic
one, depending on the market, the community, the competition, and
other circumstantial considerations. It is not easy to generalize to
other situations, especially outside the language implementation area.
Paul Rubin
> The point is that there are many other comparable language
> implementations out there (SML/NJ, Haskell, OCaml), all of which
> offered superior licensing to a potential commercial user. Given
> the extremely small size of the MLton/SML community, anything that
> turns off potential new users is a mistake, and the GPL did that.
I don't think it's a one-sided question. The GPL might turn off
some users, but it turns some other users on. Referring to non-GPL
licenses simply "superior" is propagandistic.
Matthias Blume
I think he explicitly said "superior to a potential commercial user",
where by "commercial users" he proably means those that want to sell
products containing code produced by MLton, and who might not be
willing to release the full source code of their product to each of
their customers. To me it seems that it would be difficult to argue
that certain non-GPL licenses such as BSD are not "superior" to such a
user.
Matthias
Christopher Browne
Propaganda can go both ways on that.
There are proponents of the GPL that would promote propaganda that it
is superior.
There are proponents of the BSDL that would promote propaganda that it
is superior.
And reality is that if you choose one or the other, that will lead to
both "turning on" some would-be users and "turning off" others.
What is *actually* of importance is whether or not there are some
would-be major users that have expressed a preference.
If there is *one* user, who, if listened to, on their licensing
preferences, would bring tens or hundreds of thousands of dollars
worth of sponsorship in, that is worth *way* more than any grousing on
Usenet...
--
select 'cbbrowne' || '@' || 'gmail.com';
http://linuxdatabases.info/info/x.html
"What Would Jesus Drive? Well, he was a carpenter, so what with
needing to cart wood and tools and such around, it probably would be a
truck or an SUV..." -- Jay Leno, chatting with Dennis Miller
Paul Rubin
> And reality is that if you choose one or the other, that will lead to
> both "turning on" some would-be users and "turning off" others.
Yes, better to acknowledge this, rather than treat it as a one-sided
question.
> If there is *one* user, who, if listened to, on their licensing
> preferences, would bring tens or hundreds of thousands of dollars
> worth of sponsorship in, that is worth *way* more than any grousing on
> Usenet...
Even the offer of big bucks of sponsorship money has to be weighed
carefully. If the goal is simply to attract money, why not just work
for a company instead of writing free software? Especially in
academic projects that are already funded, one must consider carefully
whether accepting sponsorship money that's subject to
otherwise-undesired conditions is in the project's best interests.
Thant Tessman
> [...]If the goal is simply to attract money, why not just work
> for a company instead of writing free software? [...]
I suspect the goal is to make programming more fun and more productive
even if you're trying to make money while doing it.
-thant
--
"When fascism comes to America, it will be wrapped in the flag and
carrying the cross." -- Sinclair Lewis, "It Can't Happen Here" (1935)
Hermann Jurksch
>>> + The MLton license is now BSD-style instead of the GPL.
>>
>> The topic says it all: what's the rationale behind that change?
> In short, given the competitive landscape, it is the best way to grow
> the MLton community and to help MLton's users and potential users.
> The GPL hurt those aims in a number of ways. First, because MLton
> includes SML and C library code in every executable, the GPL infected
> MLton-generated executables. This made MLton a non-starter for a
> number of potential users, especially commercial ones, who typically
> don't want to open source their code. We could have fixed that
> problem by licensing the runtime and library under a different license
> than the compiler proper, but chose not to because of the complexities
> of doing so, plus the competitive landscape.
May a MLTon compiled binary now be part of a distribution of
a GPLed program?
Regards
Hermann
Stephen Weeks
> May a MLTon compiled binary now be part of a distribution of
> a GPLed program?
Yes. One of the main points of this change was to eliminate
restrictions on MLton-generated executables, which can now be licensed
however you choose.
Paul Rubin
> I don't see what a BSD-style license takes away from those who
> like GPL licensing. It's completely compatible, so you can even write
> a GPLed addition and release the whole derivative work under your GPL,
> as far as I can see it.
toby
> Hello!
Agree with Paul on that.
>
> I don't see what a BSD-style license takes away from those who
> like GPL licensing. It's completely compatible, so you can even write
> a GPLed addition and release the whole derivative work under your GPL,
> as far as I can see it.
You may be right about 'additional' parts being licensable under GPL,
but I don't think any part of MLton (or modifications thereto) could be
re-licensed as GPL except by the copyright owners. But their license
grants you freedom to modify and distribute it anyway, which is
probably what you meant.
IANAL, etc.
>
> Kind regards,
>
> Hannah.
Stephen Weeks
> You may be right about 'additional' parts being licensable under GPL,
> but I don't think any part of MLton (or modifications thereto) could be
> re-licensed as GPL except by the copyright owners.
I am also not a lawyer. But here is my understanding.
It is true that copyright holders choose the license(s) for their
code. However, one may license a derivative work of MLton in any way
that is compatible with the MLton license. Since we have chosen a
BSD-style license, one could license a derivative work under the GPL,
as long as the restrictions of the MLton license (which includes the
BSD-style no advertising clause for NEC) are also preserved.
Paul Rubin
> Since we have chosen a BSD-style license, one could license a
> derivative work under the GPL, as long as the restrictions of the
> MLton license (which includes the BSD-style no advertising clause
> for NEC) are also preserved.
The "old" BSD advertising clause is incompatible with the GPL. That
was the reason for the change.
Henning Makholm
> "Stephen Weeks" <swe...@sweeks.com> writes:
An old-style BSD license has _two_ clauses that have to do with
advertising:
3. All advertising materials mentioning features or use of this
software must display the following acknowledgement:
[bla bla bla]
4. The name of [copyright holder] may not be used to endorse or
promote products derived from this software without specific
prior written permission.
The first one (3) could be called a must-advertise clause. That is
GPL-incompatible and is left out of the newer BSD variant.
The second one (4) is the "no advertising" clause that Stephen speaks
of. It is widely believed, also by the FSF, to be GPL-compatible -
mainly because it just restates a restriction that already exists by
virtue of ordinary trademark/marketing law in most jurisdictions and
can therefore be considered a legal no-op.
--
Henning Makholm "Det er jo svært at vide noget når man ikke ved det, ikke?"
Paul Rubin
> The second one (4) is the "no advertising" clause that Stephen speaks
> of. It is widely believed, also by the FSF, to be GPL-compatible -
Oh, ok, it wasn't clear that MLTon is now using the new BSD license
and not the old. I've lost track of some of this stuff.
toby
I still don't see how that is possible (I've already disclaimed
Lawyerness but I May Simply Be Dense, so I am prepared to be
corrected). How can this derivative work be, at the same time, GPL'd
yet still subject to "parts of" the original MLton license? Since the
GPL imposes its own, *incompatible*, labelling and distribution
requirements.
(This isn't "dual licensing" in the way I understand it either - under
a dual scheme, a derivative is either GPL, or under a commercial
license, at the option of the licensor - never a hybrid.)
--T
Paul Rubin
> How can this derivative work be, at the same time, GPL'd
> yet still subject to "parts of" the original MLton license? Since the
> GPL imposes its own, *incompatible*, labelling and distribution
> requirements.
The GPL is supposedly compatible with the current BSD license. There
was an older BSD license that had an incompatible clause, since removed.