DConf 2013 Closing Keynote: Quo Vadis by Andrei Alexandrescu

[Joseph Rushton Wakeling]

On Monday, 1 July 2013 at 17:45:59 UTC, Joakim wrote:
> Then they should choose a mixed license like the Mozilla Public 
> License or CDDL, which keeps OSS files open while allowing 
> linking with closed source files within the same application.  
> If they instead chose a license that allows closing all source, 
> one can only assume they're okay with it.  In any case, I could 
> care less if they're okay with it or not, I was just surprised 
> that they chose the BSD license and then were mad when someone 
> was thinking about closing it up.

The trouble is, even very weak copyleft licenses like MPL and 
CDDL can result in licensing incompatibilities.  Only by granting 
very permissive licensing terms can you guarantee that your 
software will be usable by the full range of free software 
alternatives.

For what it's worth, I have also made the argument on many 
occasions that projects shouldn't pick permissive licenses unless 
they're happy to see their work turned into proprietary products. 
  But if a developer releases software under a liberal license, 
saying "I'm doing this so that everyone can use it but please 
keep it free," I think they have a right to be pissed off when 
someone ignores their moral request.

> There's no doubt that even if they chose a permissive license 
> like the MIT or BSD license, these communities work primarily 
> with OSS code and tend to prefer that code be open.  I can 
> understand if they then tend to rebuff attempts to keep source 
> from them, purely as a social phenomenon, however irrational it 
> may be.  That's why I asked Walter if he had a similar opinion, 
> but he didn't care.

Yes, the conscious choice of an extremely permissive license for 
druntime and Phobos is a different situation.  It's completely 
right in this case to facilitate all forms of development and 
re-use, under all licensing scenarios.

> I still think it's ridiculous to put your code under an 
> extremely permissive license and then get mad when people take 
> you up on it, particularly since they never publicly broadcast 
> that they want everything to be open.  It is only after you 
> talk to them that you realize that the BSD gang are often as 
> much freetards as the GPL gang, just in their own special way. 
> ;)

It's a shame that you feel the need to resort to name-calling 
because someone has come to a considered moral or strategic 
position that's different from yours.  It also doesn't really 
help your position -- you're better off just getting on with 
developing software using your strategy and showing how it serves 
free software in the long run.

> I wouldn't call closing source that they legally allowed to be 
> closed antisocial.  I'd call their contradictory, angry 
> response to what their license permits antisocial. :)

Personally speaking, I find there are a lot of things in life 
which I prefer to be legally permitted, but still nevertheless 
consider antisocial -- and I don't think there need be a 
contradiction there.

> http://www.phoronix.com/scan.php?page=article&item=sprewell_licensing
>
> Note that this article was written when Android had less than 
> 10% of the almost billion users it has today, by using a 
> similar hybrid model, and I was thinking up these ideas years 
> before, long before I'd heard of Android.
>
> My project was a small one, so it couldn't be a resounding 
> proof of my time-limited version of the hybrid model, but it 
> worked for its purpose and I'm fairly certain it will be the 
> dominant model someday. :)

Thanks for the interesting read.  I think you have a point 
inasmuch as this is a model that clearly works very well from a 
business perspective where apps are concerned -- and if you're 
going to have open core, I'd rather it be one where the closed 
parts are guaranteed to eventually be opened up.  Of course, this 
is not the same as moral approval :-)

What I'd say, though, is that what works for apps isn't going to 
be what works for languages or their core development tools.  
Most apps seem to be single- or small-team developments, not 
community projects, they are targeting niche requirements, and 
ultimately they're being delivered to a target audience that's 
used to paying for software.

On the other hand with a language your overwhelming goal is to 
grow the user community, and (unless you're Microsoft or Apple, 
who can dictate terms to software developers) the best way by far 
to do that is to secure the language quality while keeping the 
development tools available free of charge.  You'll get more 
mileage out of monetising other things -- e.g. bug-fixing 
services, support, consultancy -- than you will out of 
restricting access to tools that enable people to use the 
language effectively.

You also have to consider the user perspective.  If I was offered 
a new language whose tools were delivered with open core terms, I 
would almost certainly refuse -- I'd feel unable to trust that I 
wouldn't at some point find all future releases locked up, 
leaving me with the Hobson's choice of either porting all my 
software to another language or coughing up the licensing fee.