
RoboVM Is No Longer Open-Source - macmac
http://www.infoq.com/news/2015/10/robovm
======
hitekker
Copy pasting what I think to be the most important part of the article:

    
    
      RoboVM is a complicated piece of technology that we have worked hard for years to 
      create. Over the past few months, we have seen competitors actively exploiting 
      our good faith by using our open source code to compete with us directly in 
      commercial products. On the flip side, we have received almost no meaningful 
      contributions to our open source code. 
      You can imagine how disappointing this has been to us; we had hoped our initial 
      business model of OSS with proprietary extensions (like our debugger and 
      interface builder integration) would work.
      But in light of the low contributions and behavior of competitors, we decided 
     to stop automatically releasing changes to the core of RoboVM as open source.

-Zechner

I'm not sure what to think about the competitors-stealing-our-code angle, but
the OSS-is-being-used-as-freeware argument is certainly one point in favor of
closing/controlling their code (as a business).

~~~
admax88q
They should have used a viral license like GPLv3, and sold commercial license
exceptions.

~~~
zxv
Yes, the GPLv3 is a powerful tool, but it doesn't completely eliminate the
need to control when and how source code becomes open.

In practice, GPLv3 may only offer hope that one could some day prevent
violations after the time and expense of litigation. VMWare and Tivo are
examples.

Consider Google Android, which releases sources with binaries when the release
occurs, not before. Balancing the how and when is just as important as the
license.

Gnu Ghostscript was an example for many years. They used a dual license and
released source to the public six months after binaries.

~~~
admax88q
> In practice, GPLv3 may only offer hope that one could some day prevent
> violations after the time and expense of litigation

That's overly pessimistic. People abusing your GPLv3 licensed code would be
almost the same as people pirating your proprietary software. It would still
be copyright infringement and with prices already set for commerical license
exceptions it would be relatively easy to sue for damages plus legal fees.

It's funny in this case that the Free Software approach may actually be a more
viable business model for RoboVM than the OSS approach. Many people consider
Open Source to be better for business and Free Software to be a bunch of
hippies. But had RoboVM used a viral license and sold commercial exceptions (a
model that the FSF considers acceptable) they could be defending user's
freedoms while also building a viable business.

~~~
bad_user
A successful open-source project is also about building a community of third-
party contributors. Or at least the possibility of one such community
happening. Dual licensing basically kills off that discussion, because in
order for dual licensing to work, then contributors need to sign a
contributors agreement that licenses their work for whatever purpose the
parent company sees fit.

And this is where I've always disagreed with FSF's stance. Many people claim
that GPL is inadequate because of the "ASP loophole". But a much bigger
loophole is dual licensing. This is because dual licensing happens (and is
useful) only when the product is unusable as open-source. For example
Gitorious is AGPL licensed and does not need dual licensing because you know,
it's meant for people to have an on-premise solution for Git hosting and it's
a take it or leave it thing. A Javascript library on the other hand is totally
useless as AGPL. Dual licensing is also what made Qt and consequently KDE to
be less popular than Gtk+ and Gnome in distributions such as Red Hat's or
Ubuntu, or why popular project such as Firefox or LibreOffice are better
integrated with Gtk+/Gnome, even though Qt has always been technically
superior. Heck, Qt's licensing is why Gtk+/Gnome happened in the first place.

You see, the biggest advantage of open-source, its raison d'être if you will,
is the possibility to fork. But if a fork cannot survive because of licensing
reasons, maybe because it cannot be applied to the same projects as the
original, then that's not really open-source.

Personally I prefer the open core. For example I currently work with Scala and
the JVM and I use IntelliJ IDEA as my IDE. It has a community edition with
everything I need. Yet I pay for the Ultimate edition anyway. If the community
edition gets discontinued, I'll switch in a heartbeat.

~~~
mehrdada
> You see, the biggest advantage of open-source, its raison d'être if you
> will, is the possibility to fork

It might be the _raison d 'être_ of _open source_ , but the goal of _free
software_ is preserving _users '_ freedom, not ensuring usefulness of software
in some commercial proprietary context. That seems to be at the root of your
disagreement with FSF. You simply care about different things and therefore
prioritize differently; everything else is secondary. FSF does not aim for
popularity, convenience, or playing well with one's commercial interests as
its primary goal.

~~~
bad_user
The right to fork is a prerequisite for users' freedom and without it the
software is not free. The right to fork is about having complete control over
the software that you're using. And it's usually a fact - either you have that
right, or you don't, instead of being a warm and fuzzy social ideal, like the
issue of " _users freedom_ " tends to be.

Because the second you said " _users freedom_ ", you're in danger, because
what constitutes a "user" is unclear. Is a user a person that pushes buttons
providing input for your program to produce its destined output? Or can a user
be a programmer as well? Because depending on its needs, different users want
different freedoms. And for example I do not consider AGPL to be open-source
(or free software for that matter) because modifying code without
redistributing the binaries is simple usage for a developer, which means AGPL
imposes restrictions on usage, being a freaking EULA.

But going back to our subject, dual licensing, take a look at projects that
are dual licensed and usually you'll notice that the choice of the license had
nothing to do with users freedom, quite the contrary, after all, without
serious constraints dual licensing wouldn't work.

~~~
admax88q
What constitues a user is not unclear.

A user is both someone who uses the compiled software (pushes the button in
your example) or a developer capable of modifying the software.

A developer doesn't need the freedom to redistribute the software to other
users without also respecting their freedoms.

Dual licensing does nothing to hurt freedom, as a user of the GPL licensed
software your freedom is protect, both to use the software, and to modify it
for your usage.

Needing to assign copyright to make upstream contributions may hurt the rate
at which the upstream project develops, but in no way hurts your freedom.

------
bad_user
RoboVM was basically the competition of Xamarin and Xamarin killed it. RoboVM
was cheaper and had a bigger market, since it targeted JVM developers. With
RoboVM you aren't even tied to Java the language, being entirely possible to
use a language like Scala. And contrary to Xamarin, in order to use IntelliJ
IDEA or Eclipse, or in other words the state of the art in IDEs, you didn't
need to pay $999 per year, like you need for using Visual Studio with Xamarin.
And RoboVM has been open-source, which brings with it benefits, like trust,
trust because should things go wrong, you can always fork it.

Well, now is the time for a fork and I hope it will happen.

~~~
johncolanduoni
I think putting more effort into Avian would probably be time better spent.
Their static code-gen is lacking (it currently just runs the JIT ahead of
time, instead of taking more time with something like LLVM), but they've got a
lot of things going for them including a superior GC.

~~~
joel_dice
I wrote most of the Avian VM, and I agree that the code generation is quite
primitive compared to LLVM's. We've considered using LLVM as an alternative
code generator, but hesitated partly because LLVM used to require a shadow
stack to support accurate GC. I just checked they're latest docs[1], though,
and it seems that there are other options now.

All in all, adding LLVM support to Avian would be challenging but doable.
However, Avian's generated code is already fast enough for most purposes, and
it's not too hard to fall back to a bit of native code when you need maximum
performance. My impression is that Java-on-iOS developers are less concerned
about performance and more concerned with ease-of-use (e.g. tool integration)
and convenient access to native APIs (e.g. Bro[2]). The RoboVM devs have
apparently done a great job on both of those things.

I sympathize with Zechner and the other RoboVM devs. Development on Avian was
originally funded by the company I was working at since it neatly addressed a
problem we had: extending the lifetime of a large body of client-side Java
code in a world that was/is increasingly unfriendly to client-side Java. Once
it was good enough for that purpose, there was no business reason to continue
investing in it besides bug fixes and maintenance, so we had to move on to
other things.

I'd love to keep working on Avian full time and do cool stuff like an LLVM
port or trace-based JIT compilation, but it's hard to justify when there are
bills to pay. In my case, that means focusing primarily on other, income-
producing projects. In RoboVM's case, it means trying a new approach to
licensing to make development sustainable. I wish them luck with it.

[1]
[http://llvm.org/docs/GarbageCollection.html](http://llvm.org/docs/GarbageCollection.html)
[2] [http://docs.robovm.com/advanced-
topics/bro.html](http://docs.robovm.com/advanced-topics/bro.html)

------
MikeTaylor
There is no such thing as "no longer open source". The story here is in fact
"the copyright holders of RoboVM have made a proprietary derivative".

~~~
johncolanduoni
Well, one complication here is that the only reason they were allowed to do so
was that their CLA gave RoboVM AB an unrestricted license to the
contributions, not merely the license the code was released under. If that
were not the case, the compiler could not have gone simply gone proprietary
because it was GPL licensed.

In practice, I suspect they would have been able to do this anyway because the
biggest independent contributors joined RoboVM prior to this move.

edit: typo

~~~
lsaferite
And this is the _exact_ reason I will not contribute code under a CLA that
gives a project the right to re-license my code as commercial.

~~~
fhd2
All the CLAs I've seen so far give the project the right to license the code
under a proprietary license, as long as it (and derivates of it) remains
available under a free license as defined in the CLA.

I would also have concerns signing a CLA that doesn't ensure the code will
stay available under a free license, but I don't think that's a very common
case.

~~~
lsaferite
Early in my career I signed CLAs like this and contributed code under them.
Later down the road I wizened up and realized it was free work for a
commercial entity that was then relicensing my work under a closed source
commercial license and making a profit. They are welcome to a profit, sure,
but not if it is via closed source licensing of work that I contributed to the
OSS community.

So, no more CLAs for me. If they require a CLA (that lets them relicense my
work) then I'll just never contribute to them.

~~~
jahewson
CLAs on their own aren't bad. All Apache projects use a CLA to ensure that the
contributer has he right to contribute the code under the Apache license.

~~~
lsaferite
You are correct, not all CLAs are bad. That is why I said "that lets them
relicense my work" to clarify that it's a specific type of CLA that I take
issue with.

------
ex3ndr
Several months ago, after consulting with HN community
([https://news.ycombinator.com/item?id=9757243](https://news.ycombinator.com/item?id=9757243))
what we can do with our startup, we open sourced our platform and now our team
feels pretty well. But after months, we see that powerful companies just
silently use our software to solve there's needs and making no contributions.
We accept small contributions, but we can't count on them as platform is much
bigger than contributions. We tried to write Wikipedia-like letter to ask for
donations - doesn't work. Tried to make consulting - eats too much time. Now
we releasing enterprise version
([https://corp.actor.im](https://corp.actor.im)) and we decided not to open
sources of it as it is almost impossible to earn money without pushing people
to pay. And pushing can be performed only with limitations that is, actually,
harming people in some cases. Does anyone know any other solution for this?

~~~
merb
the problem is your product.

there are way too many messaging platforms like actor. many of them are older.
it's hard to compete in this market since you would need to be better than all
the others.

I mean the others are costing money at least some of them still they have
mostly a bigger integration in the products the companies made. and thats why
its impossible to earn money for you, you won't get enough users to stay
rentable.

~~~
ex3ndr
Yes, of course.

------
codeulike
I've been using libgdx and was meaning to explore the whole iOS/RoboVM angle,
I finally got around to it this weekend, ironically just in time to catch the
kerfuffle around this.

Presumably there is an open-source version of RoboVM still around. Perhaps
here: [https://github.com/robovm/robovm](https://github.com/robovm/robovm) ...
though I gather the problem with that is that it does not include any of the
latest iOS 9 work, which was done in a closed repository somewhere.

Looks like the Libgdx guy (Mario?) fought hard to keep a free version of
RobobVM for Libgdx users. Not sure how long that can last; its currently based
on self-identifying yourself as a Libgdx user and hence easily abused.

The other irony is that Libgdx used to use Xamarin to target iOS, but they
switched to RoboVM because it was free/open.

~~~
badlogic
Mario here, libGDX author and part of the RoboVM team. We switched from
Xamarin to RoboVM for libGDX because it worked better for our purposes and was
free. It being OSS was a plus, but that wasn't really a factor in the
decision. We've been happily using Xamarin for a year, even though it was
closed. I constantly evaluated other options, including Avian and XMLVM,
neither of which came close to either Xamarin or RoboVM in terms of
functionality and performance. That is still true today.

The free indie licenses for libGDX and PlayN users will last. It's very easy
on our end to prevent abuse automatically. We never considered not making it
free for indie game devs. From RoboVM's standpoint, it makes zero sense to 1)
try monetizing a community that can't be monetized and 2) alienate the
community that helped RoboVM a lot over the past two years. If RoboVM stopped
the free indie licenses, it would only hurt RoboVM's bottom line.

The close sourcing was badly communicated, no question about that. But
contrary to popular believe, it was not the longest bait and switch in the
history of evil plans (RoboVM's been out there for almost 4 years), it was a
business decision. A direct competitor exploited the free OSS version, hurting
our bottom line.

~~~
JoshTriplett
> A direct competitor exploited the free OSS version, hurting our bottom line.

It's not "exploiting" to use the license as offered.

Why not use a FOSS license that prevents this? For instance, why not use GPL,
at which point you could sell licenses for use in proprietary apps? With the
right licensing structure, you wouldn't even need a CLA.

~~~
nickpsecurity
I just made that comment with some specifics here:

[https://news.ycombinator.com/item?id=10500298](https://news.ycombinator.com/item?id=10500298)

I'm curious what you and Mario think about my scheme of paid, perpetually-
licensed, OSS software. It's in alpha stage obviously with potential for
improvement.

~~~
JoshTriplett
If by "commercial use" you meant "proprietary use": requiring payment for
proprietary use seems like a well-established business model that works
reasonably well, and I don't see any problem with contributing to such a
project. In an ideal world, I'd suggest doing so in a way that doesn't require
a CLA, such as a carefully written license exception referencing an updatable
list of licensees.

If you actually meant "commercial use", such that the default version
prohibited commercial use, that's a non-starter, as it's incompatible with the
standards for either Free Software or Open Source Software; you would
massively curtail both contribution and usage of the project by doing so.
You'd also, in the process, likely prevent anyone from contributing to that
project in the course of their job, which doesn't seem like your intent.

(Requiring submission of contributions back to the original project rather
than only to those you distribute a binary to is also slightly questionable,
though some will accept it. Prohibiting commercial use is the dealbreaker.)

~~~
nickpsecurity
"In an ideal world, I'd suggest doing so in a way that doesn't require a CLA,
such as a carefully written license exception referencing an updatable list of
licensees."

That's worth remembering if possible.

"If you actually meant "commercial use", such that the default version
prohibited commercial use"

The idea is it's just like open-source software except you pay for it. People
can fix it, modify it, contribute to it, whatever. Might force the mods to be
shared with everyone if using free license or let them not be shared if people
are paying for it. The money coming in creates active development. The license
keeps them from closing things back up or pulling it off the market. Trying to
figure out what terms maintain the major benefits of FOSS while preventing the
worst parts of proprietary model and keeping money in for
development/maintenance.

The philosophy is basically "you get what you pay for or contribute to," with
source and benefits that brings. Sort of a middle ground between proprietary
and FOSS. Gotta be one that could work but devil is in the details.

Note: Burroughs' 1960's OS, MCP, was delivered as source to paying customers.
They could modify it as they saw fit and optionally submit modifications back.
Burroughs would try to integrate good submissions into later releases. It was
the first or one of the earliest proprietary and OSS combinations.

~~~
JoshTriplett
The problem is that FOSS already exists, and anything incompatible with FOSS
isn't likely to gain traction among existing FOSS developers. It isn't a
question of "which terms would maintain the major benefits of FOSS"; to get
any traction, you need to actually be compatible with the Open Source
Initiative's Open Source Definition
([https://opensource.org/osd](https://opensource.org/osd)) and the Free
Software Foundation's Free Software Definition
([https://www.gnu.org/philosophy/free-
sw.html](https://www.gnu.org/philosophy/free-sw.html)). And neither of those
allow a prohibition on commercial use.

Now, on the other hand, you _could_ build a community around a GPLed project,
or an AGPLed project, funded by selling licenses to use that project in
_proprietary_ software. In practice, that will have a very similar effect,
while remaining FOSS. And your comments and ideas about using that licensing
revenue to directly support the community rather than just a company sound
quite appealing.

------
seibelj
I originally thought this was a bad idea, then changed my mind. I was going to
contribute to the fork but decided not to. What sealed it was several
competitors to RoboVM emailed me directly after seeing my posts in the RoboVM
fork message boards begging me to help them. No one wants to pay for anything
anymore. RoboVM made the right decision.

~~~
logn
Sounds like you're in a good position to get paid to write open source
software.

------
JustSomeNobody
Have we just become too selfish for OSS? We're going to end up punishing
ourselves by having to use proprietary, closed systems for everything. I don't
want to compute in that world. That would be awful.

------
scrollaway
So let me get this straight... RoboVM is acquired by Xamarin, the company
behind Mono (the open source c# implementation)... and they therefore go
closed source?

I don't get it.

~~~
johncolanduoni
Xamarin's .NET mobile/mac offerings are closed source. Mono itself fills the
role of the OpenJDK does for Java, but it alone is not suitable for running on
mobile. Also, Mono is licensed under the LGPL and Xamarin's interpretation of
that license precludes using the runtime in a closed-source program without a
alternative license from them (which they provide with their paid plans).

~~~
billsix
> Also, Mono is licensed under the LGPL and Xamarin's interpretation of that
> license precludes using the runtime in a closed-source program without a
> alternative license from them

Citation? I've never heard anyone interpret the GPL and LGPL as the same.

Embedding mono is different than using mono.
[https://xamarin.com/licensing](https://xamarin.com/licensing)

~~~
johncolanduoni
Sorry, I meant on mobile (like RoboVM). There is no way to comply with the
LGPL on iOS.

------
aurelien
Once again Open Source demonstrate its danger in front Free Software. Stop to
waste your time, bring progress to fsf.org

~~~
maxerickson
Structurally, the FSF works the same as this project and works to unilaterally
control the copyright of projects (by only accepting contributions under a
license agreement: [http://www.gnu.org/licenses/why-
assign.en.html](http://www.gnu.org/licenses/why-assign.en.html) ).

I agree it would be a departure from their core philosophy to act against
their contributors, but if evil goblins took control of the FSF, there would
be no way to stop them from using whatever license they wanted, and the
community would be left with the last release under the old license, just as
in this case.

edit: oops, there are FSF projects where the FSF does not hold the copyright.
Anyway, what I said works for the projects that FSF holds copyright for.

~~~
quadrangle
FSF is still a 501(c)(3) with legal obligation to their stated mission, so it
couldn't just be taken over and corrupted quite so simply.

~~~
maxerickson
I think if they stopped accepting donations and spent remaining funds
carefully, there would be no penalty for losing that status (it's largely an
exemption from income taxes).

~~~
quadrangle
I doubt it is that simple to change a 501(c)(3). I'm not a lawyer, but
_getting_ the tax exemption under 501(c)(3) has all sorts of requirements
including things in Articles and Bylaws about how dissolution / acquiring
works. Even losing 501 status doesn't instantly eliminate the legal status of
the Articles/Bylaws that founded the (c)(3)…

------
Zardoz84
> Several RoboVM components used to be made available under the Apache 2.0
> license while the compiler was open sourced under the GPL license

How can close source the compiler if it is on GPL license ?

~~~
johncolanduoni
I commented about this elsewhere in this thread, but the Contributor License
Agreement for RoboVM gives RoboVM AB (the company) an unrestricted license to
your contributions. As a result, the contributors cannot assert that they are
violating the GPL since RoboVM is not actually on the receiving end of it.

------
synic2
People don't respect those who give away their labor for free.

Consider doctors, dentists, lawyers, CPAs, or other higher-prestige
professionals. They engage in protectionism to restrict competition and drive
up their earnings and rarely if ever give away their services for free, and
they are much, much more respected than we are. And on the rare occasion that
they do perform some act of charity, such as working as a public defender or
providing discounted dental care to the poor, they usually still get paid for
it, just not as much, and they make a big show of it so everyone knows that
they're taking a huge paycut for a good cause and thus deserve even more
respect than they get already.

Programmers by contrast are rapidly conditioning the public to expect software
to be cheap or free, regardless of how long and difficult it is to produce, to
the point where iPhone devs complain they can't sell their apps for the price
of a cup of coffee.

Programmers need to worry about their future and should probably spend their
20s and 30s making as much money as they can writing proprietary software
before they hit 40 and become increasingly unhirable due to ageism instead of
performing unappreciated acts of charity in the form of open source for an
ungrateful public.

~~~
oberstein
"The straightforward and easy path was to join the proprietary software world,
signing nondisclosure agreements and promising not to help my fellow
hacker.... I could have made money this way, and perhaps had fun programming
(if I closed my eyes to how I was treating other people). But I knew that when
my career was over, I would look back on years of building walls to divide
people, and feel I had made the world ugly."

\-- Richard Stallman (Open Sources, 1999 O'Reilly and Associates)
[https://github.com/llimllib/personal_code/blob/master/python...](https://github.com/llimllib/personal_code/blob/master/python/wc/osfortune)

~~~
synic2
And when you're old, unemployable, and in need of expensive dental work, do
you seriously think any dentist will offer you some massive discount because
of your short-sighted history of altruism? Please. Proprietary software isn't
even one tenth as immoral as the rent-seeking and profiteering that other more
respected professions engage in. Make your money and look out for yourself,
because no one else is going to.

------
merb
I don't think that everything of RoboVM could be closed source, since you are
doing the same things just for another platform, that google did and got sued
by oracle.

------
mahyarm
As a dev, a big thing for me is being able to see the source code for the full
callstack in the debugger, and possibly making derivatives of that code in my
app. As long as they provide that in some form, then closing the source isn't
as big of a deal.

