5 ms·

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 kerf

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 11y ago
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.
- gillianseed 11y ago
  >A direct competitor exploited the free OSS version, hurting our bottom line. Who were they ?
  - deleted 11y ago
    [deleted]
- chii 11y ago
  > A direct competitor exploited the free OSS version, hurting our bottom line. if you can name that direct competitor? I'd like to know who to avoid in the future.
- JoshTriplett 11y ago
  > 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 11y ago
    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 11y ago
      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 11y ago
        "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.

badlogic 11y ago

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.

gillianseed 11y ago
>A direct competitor exploited the free OSS version, hurting our bottom line. Who were they ?
- deleted 11y ago
  [deleted]
chii 11y ago
> A direct competitor exploited the free OSS version, hurting our bottom line. if you can name that direct competitor? I'd like to know who to avoid in the future.
JoshTriplett 11y ago
> 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 11y ago
  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 11y ago
    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 11y ago
      "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.