Re: The Swift Programming Language: what is our position towards this?

[David Chisnall]

On 4 Jun 2014, at 22:20, Gregory Casamento <greg.casamento@gmail.com> wrote:

> AS AN ASIDE: I think it's interesting that, in the wake of recent discussion 
> about licensing, that we should now happen upon why the GPL is a GOOD THING

As a direct reply to an aside containing a straw-man argument: bullshit.

The Swift front end is a completely new project.  It generates LLVM IR, but 
there is no reason at all why it would have been open sourced if LLVM were 
GPL'd.  XCode was not open sourced because it communicated with GDB, which is 
GPL'd, and the mechanism by which the front and back ends communicate in an 
LLVM-based compiler is fairly similar - one produces output in a well-defined 
format that the other consumes.  

The only difference if LLVM were GPL'd would be that they'd have to make an 
inefficient implementation that did the serialisation and deserialisation via a 
pipe or shared memory segment, rather than just using the in-memory version.

Unless your argument is that the GPL contributes to global warming, it is 
misplaced.

The reason that GCC can not easily be used in this way is that they 
intentionally avoid having a serialisation format.  This means that existing 
proprietary front and back ends for GCC end up implementing incompatible 
[de]serialisation engines, which are used for a single project.  The GPL 
doesn't prevent people doing this, it just causes more wasted time duplicating 
effort.  

The GPL is a set of complex rules.  Clever people find loopholes in complex 
rules and do what they want anyway.  You can't use legal means to compel people 
to join a community, you have to convince them that it's in their best 
interests.  Hostility and antagonism towards them, and the threat of legal 
action, rarely achieve this.

Oh, the other outcome if LLVM had been GPL'd would be that the REPL 
implementation would have been very difficult without making the entire 
environment GPL'd.  The most likely outcome of this would have been Apple 
writing two implementations, one that's a static compiler using LLVM, and one 
that's a JIT using libjit or similar (possibly something developed in-house).  
The result for LLVM would have been fewer contributions to the MCJIT layer and 
less bug testing.

A company like Apple has the manpower to develop a compiler in house (although 
they'd rather not, as it's not a direct contributor to their core business).  
If LLVM had not existed and been permissively licensed, then they would most 
likely have written their own compiler back end and licensed EDG for the front 
end (hacked up to support Objective-C), once the GPL became too onerous for 
them.  The net result would have been more proprietary code in the world and 
one fewer large contributors to Free Software.  I don't speak for the FSF, but 
I don't believe that this is their goal.

>> - If the code generator does not become available, I'd say it's unlikely 
>> that GNUstep developers would write one. (Though, who knows?)
> 
> ​I wouldn't say it's unlikely.  I would say that this project is and should 
> always be more focused on the API than on the language itself.  GNUstep has 
> never maintained a compiler of any kind (unless you count the Smalltalk 
> implementation that is in the repo, but I don't count that).​

I like Swift, so if there is no open source front end forthcoming, I'd be 
tempted to write one.  I'm also working on a design for a language that shares 
a lot of common features with Swift (which is partly why I like it - they've 
added a lot of the features that I put on my want list for a new language), so 
I might not.  

I'd quite like to be able to use a Swift-like language in the FreeBSD base 
system though, so I probably won't be working on it as a GNUstep project.  

David

-- Sent from my Cray X1