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 think Xamarin open source their Visual Studio integration or their Mac OS Build Host. So this would be following in those footsteps: if you want these features, pay for them.
Mono is different than Xamarin. Xamarin works on and supports Mono, but it's not their core product. Their core product is the Xamarin Platform, which is what you're talking about.
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).
> 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.
Apple has a conflict with the LGPL in iOS apps, so Xamarin offers a commercial license. I'm not sure why this restriction would apply on other platforms though.
It's not a conflict with the LPGL, it's technical. Apple does not allow iOS apps to link to any shared libraries, they must be statically linked. Apple does not care how you license your libraries, only that you have the permission to do so, just like any other licensed content like photos or music.
It's also because Apple would be considered a distributor of the final application, thus according to the rules of the GPL, they'd be forced to provide the source code for any app that used GPL code.
Since they don't have access to the source code, they can't fulfill the legal obligation outlined in the GPL license.
Uhm, they only support mono because they simply can't close it and have lots of proprietary libraries built around it. Some they developed on their own, some were bought/licensed from previous Mono maintainers. Xamarin is not a FOSS company by a long shot.
I don't think Xamarin has open sourced anything that they didn't have to. All tools developed exclusively by Xamarin are closed source (e.g. Xamarin build host, the Mono packager, Xamarin.Insights, Objective Sharpie, etc...).
Xamarin contributed several projects to the .NET Foundation. Mono is also permissively licensed, so every contribution Xamarin makes that does up in the open (instead of locked up, which they could do by actually taking advantage of the terms in those permissive licenses) is something "that they didn't have to" do.
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.
tl;dr they weren't receiving any contributions, and people were using their open source code directly against them.
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.
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.
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.
I'm investigating combinations of proprietary and OSS models that combine benefits of both. I explained in the essay below that countered that false dichotomy as it applies to security/verification.
My main stance, for now, is dual licensing. Any commercial use requires a license. Any other use is free. Both are perpetual, come with source, and allow modifications. Core staff of paid developers do most work. OSS contributors get free licenses, name recognition, and possibly gifts (esp money) for big contributions. Any improvements to the software must be sent back to software owner that redistributes it under the same license. Contract requires this happen post acquisition. If company stops meaningful updates or wants to abandon it, product is released under full OSS license and that's in the contract. Company is also a non-profit, public benefit, or just private with certain structure that helps force this.
What do you think of such a setup? Again, main point is to force any user to be contributing to its development or maintenance while ensuring it stays available and has key FOSS benefits. Would you contribute to such a dual-licensed, carefully-setup piece of software?
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.
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.
If they cannot figure out a business model that lets them make a profit without them re-licensing and selling code the that I wrote, then perhaps they should be doing something else. As I said, I'm 100% on-board with them making money, just not by selling my code under a closed source license.
They cannot take away licenses already granted nor stop existing holders from redistribution however I would think that the other poster would agree that such contributions are effectively wasted if the company discontinued the oss version.
And so we see that the legal infrastructure they put in place as an escape hatch from free software was the very reason they received few contributions and needed to use it.
There are other factors, but a medieval CLA definitely didn't help their cause.
I know it may be shocking, but companies are going to do what they want. Replacing the code of even hundreds of contributors, given a bunch of full time engineers, is just not that big a deal.
This is even more true when, as here, the project almost entirely made by a small group of engineers (which is the case for a lot of projects).
Legal infrastructure will not solve these problems for single projects.
Additionally, even companies that have "good" CLA's find ways to be evil.
Doing things like threatening other companies over the "compilation copyright" they claim they own on the work, etc.
So yeah.
Bottom line:
CLA's, no CLA's, whatever, none of it is loophole or problem free, and there is no simple solution to these problems.
Planning to rip out code after accepting it is silly. Yes, I suppose people could do that if they don't plan to make a proprietary fork but change their mind later.
clearly, the issue is whether the contributions amount to a substantial enough part of the software that the ripping out isn't feasible.
Also, if you build up a community and then violate their trust, you lose the community. It's not a great strategy.
"Planning to rip out code after accepting it is silly."
They didn't plan on it.
Plans changed.
"clearly, the issue is whether the contributions amount to a substantial enough part of the software that the ripping out isn't feasible."
Having legally supervised tons of these processes for open source projects (most trying to relicense things after discovering their licenses were hurting their communities):
It's always feasible. Actual code is often not that important.
Knowing what code to write is often important.
(I know there are beautiful unique snowflakes who think otherwise ;p)
"Also, if you build up a community and then violate their trust, you lose the community. It's not a great strategy.
"
Sure, but you assume "random people kibitzing on hacker news" represents their community.
For all you know, the actually community is entirely in favor!
Again, IME, having helped projects through these processes, there is often a huge difference in opinion between the people kibitzing on the sidelines and those who actually contributed meaningfully.
My experience is that people who contribute meaningfully are often more sympathetic and understanding of various situations.
People who are kibitzing from the sidelines are often more ideological.
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.
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.
I was wondering why no one mentioned Avian... I'm not a mobile developer so I wasn't sure, but I thought that it does the same thing essentially.
Avian is a fantastic platform and the maintainers are true friends of free software, even though their license is as permissive as you can possibly get.
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.
"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."
The first indicates that they unwisely picked a license that allowed their competitors to do that and hoped they would share out of the kindness of their heart, the second indicates that they failed to find people interested in working for free on their commercial product.
Maybe if they had been less generous with their competitors they would have paid them money which could have made it possible to keep it free.
So no the "freetards" didn't kill it and by using such terms instead of logical arguments you reveal the quality of your intellect.
You seem to show contempt for people preferring open-source platforms. Well, I for one refuse to build on top of proprietary platforms, because there have been countless of examples of people getting burned. One way people get burned is because of bait and switch strategies, often employed by companies (especially startups) in order to attract interest and grow their product in popularity and then breaking their original promise. Or sometimes the company gets acquired in an acquihire and the product simply vanishes. One famous and recent example is FoundationDB - I'm pretty sure that the people that invested time and resources in FoundationDB are sorry for doing it.
I also don't see how the "freetards" killed RoboVM, but you seem to agree with me that RoboVM is dead.
WURFL did a very similar thing as well and it felt pretty disingenuous. Consequently we ended up switching to 51Degrees.
I personally don't like the OSS bait and switch tactic either. I prefer when companies offer other products, extensions, and/or services on top of the OSS core. If the company is still major contributors they still can shape the OSS core more suited to their proprietary offerings.
It just happens that I am from the generation that used to pay for software.
Also I kind of lost my FOSS enthusiasm, after learning the hard way if software is the product one sells, there is hardly any money to pay the bills, if the product isn't amendable to consulting and support.
We are far from the supermarket taking pull requests.
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 ... 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.
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.
> 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.
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.
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.)
"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.
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) and the Free Software Foundation's Free Software Definition (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.
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.
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).
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.
> 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.
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.
The dual-licensing problem for software freedom is easily dealt with: just accept community contributions WITHOUT requiring a CLA. That is enough to legally guarantee the software will stay free for everyone.
Dual licensing isn't otherwise a loophole since it is a decision the primary author organization makes for themselves, not something someone else can do to your copyleft code.
> A successful open-source project is also about building a community of third-party contributors.
Not necessarily. Depends on your goals. You might want to free up your software because it's the right thing to do and it guarantees your customers have a way out should should your business ever fail. You might scare away a few contributors by requiring copyright assignments so you can sell GPL exceptions, but the whole idea that you should free your software so you'll get more contributors is (1) sometimes false as it is in the present case, and (2) part of the campaign slogans that OSI made when they tried to rebrand free software as "open source".
> 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.
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.
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.
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.
> 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 easier both to do and to get away with when there's an open license. They can adjust it to integrate, and claim confusion or delay while rounding up source code.
I'm about to do a Java to iOS shootout, so this is fairly apposite for me. RoboVM's big advantage for us at the moment is that it's a commercially-supported product in a space where you are completely at the mercy of your tools; if your use case falls outside Google's, then j2objc is a potential cul-de-sac; XMLVM looks interesting but may still be more of an academic project than professional tool, and so on. Ultimately, it makes more sense for Xamarin to give RoboVM more resources and take the codebase internal: the end result is likely to be a better tool and higher revenue.
There have been several projects closing the source of their software due to the competitors-stealing-their-code angle. All of those projects I know of are dead, because in most cases what makes them interesting is the open-source nature.
This is kind of the elephant in the room isn't it? I know there are a lot of mediocre FOSS software I tolerate solely because its FOSS. I know of several commercial or free closed alternatives that are better in a lot of ways, but the FOSS angle makes it interesting to me and others (others who freely contribute support in forums, code, etc).
> 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).
Implicit in this argument is the assumption that Xamarin ever wanted RoboVM to "win" at all.
I'm not saying that they don't... just that they subsumed a smaller competitor with an arguably superior product. Its logical to conclude that there exists a possibility that they simply paid to buy out RoboVM because they thought it would be cheaper than trying to compete head to head (especially, since as your c+p points out, competitors were/are using RoboVM code), and if RoboVM returns some of that money then it is just gravy on the biscuit.
If that's the case then too bad for Xamarin... it is more of a sign of their ineptitude and of their eventual demise... if their leadership choose to use cash to knock out competitors instead of innovation, it will be interesting to see how long they can keep that up.
I don't think shutting down RoboVM to avoid competition is Xamarin's goal, after all if RoboVM were to shut down there is no reason to assume that the Java developers that use it would migrate wholesale over to the Xamarin C# development environment.
My theory is that Xamarin is starting to care less and less what language is used to build mobile apps (for a while they claimed to care more about C# than Microsoft did); and instead own the products that become a natural pipeline into their service offerings like Test Cloud. Buying RoboVM lets Xamarin build in hooks that will mean staying in Xamarin platform is a natural progression.
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.
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.
so everyone just built wheels in a little close source circle just like traditional company.
the real value of open source software project is the uers and community who used the software。the decision of xmin will lost many uers and destroy the community,i don't think it a good decision.
Several months ago, after consulting with HN community (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) 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?
Yeah you can't use anything else that Red Hat uses like CentOS (which Red Hat saved) or use Fedora. Heck even Oracle rips off Red Hat and calls it Oracle Linux. I don't see your point.
Can't you just keep it open source for non-commercial use and require license fee for commercial use? Or is that too hard to enforce? (i.e. companies use the open source version for non-commercial use).
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.
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 ).
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.
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).
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)…
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.
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.
"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."
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.
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.
104 comments
[ 4.8 ms ] story [ 160 ms ] threadI don't get it.
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
From what I understand lot of code is GPLv2 as well, which would make the project as a whole GPLv2 licensed.
From http://www.mono-project.com/docs/faq/licensing/
The C# compiler is dual-licensed under the MIT/X11 license and the GNU General Public License (GPL).
The tools are released under the terms of the GNU General Public License (GPL).
The runtime libraries are under the GNU Library GPL 2.0 (LGPL 2.0).
The class libraries are released under the terms of the MIT X11 license.
When distributed 'as a whole' it is distributed under the terms of GPLv2.
The runtime libraries (LGPL) and class libraries are indeed not under GPLv2 .
Since they don't have access to the source code, they can't fulfill the legal obligation outlined in the GPL license.
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
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.
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.
https://www.schneier.com/blog/archives/2014/05/friday_squid_...
My main stance, for now, is dual licensing. Any commercial use requires a license. Any other use is free. Both are perpetual, come with source, and allow modifications. Core staff of paid developers do most work. OSS contributors get free licenses, name recognition, and possibly gifts (esp money) for big contributions. Any improvements to the software must be sent back to software owner that redistributes it under the same license. Contract requires this happen post acquisition. If company stops meaningful updates or wants to abandon it, product is released under full OSS license and that's in the contract. Company is also a non-profit, public benefit, or just private with certain structure that helps force this.
What do you think of such a setup? Again, main point is to force any user to be contributing to its development or maintenance while ensuring it stays available and has key FOSS benefits. Would you contribute to such a dual-licensed, carefully-setup piece of software?
There are other factors, but a medieval CLA definitely didn't help their cause.
Hint: They'll just rip out your code.
I know it may be shocking, but companies are going to do what they want. Replacing the code of even hundreds of contributors, given a bunch of full time engineers, is just not that big a deal.
This is even more true when, as here, the project almost entirely made by a small group of engineers (which is the case for a lot of projects).
Legal infrastructure will not solve these problems for single projects.
Additionally, even companies that have "good" CLA's find ways to be evil.
Doing things like threatening other companies over the "compilation copyright" they claim they own on the work, etc.
So yeah. Bottom line: CLA's, no CLA's, whatever, none of it is loophole or problem free, and there is no simple solution to these problems.
clearly, the issue is whether the contributions amount to a substantial enough part of the software that the ripping out isn't feasible.
Also, if you build up a community and then violate their trust, you lose the community. It's not a great strategy.
They didn't plan on it. Plans changed.
"clearly, the issue is whether the contributions amount to a substantial enough part of the software that the ripping out isn't feasible."
Having legally supervised tons of these processes for open source projects (most trying to relicense things after discovering their licenses were hurting their communities):
It's always feasible. Actual code is often not that important. Knowing what code to write is often important. (I know there are beautiful unique snowflakes who think otherwise ;p)
"Also, if you build up a community and then violate their trust, you lose the community. It's not a great strategy. "
Sure, but you assume "random people kibitzing on hacker news" represents their community.
For all you know, the actually community is entirely in favor!
Again, IME, having helped projects through these processes, there is often a huge difference in opinion between the people kibitzing on the sidelines and those who actually contributed meaningfully.
My experience is that people who contribute meaningfully are often more sympathetic and understanding of various situations. People who are kibitzing from the sidelines are often more ideological.
Well, now is the time for a fork and I hope it will happen.
Avian is a fantastic platform and the maintainers are true friends of free software, even though their license is as permissive as you can possibly get.
https://github.com/ReadyTalk/avian
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 [2] http://docs.robovm.com/advanced-topics/bro.html
The RoboVM developer's realized that they couldn't count on the FOSS community to pay their bills and accepted the deal proposed by Xamarin.
Next time something similar comes out, people should think about paying for support instead of threatening to fork and use for free.
If anything, the freetards have killed it.
EDIT: Typo someone => something similar
The first indicates that they unwisely picked a license that allowed their competitors to do that and hoped they would share out of the kindness of their heart, the second indicates that they failed to find people interested in working for free on their commercial product.
Maybe if they had been less generous with their competitors they would have paid them money which could have made it possible to keep it free.
So no the "freetards" didn't kill it and by using such terms instead of logical arguments you reveal the quality of your intellect.
I also don't see how the "freetards" killed RoboVM, but you seem to agree with me that RoboVM is dead.
I personally don't like the OSS bait and switch tactic either. I prefer when companies offer other products, extensions, and/or services on top of the OSS core. If the company is still major contributors they still can shape the OSS core more suited to their proprietary offerings.
Also I kind of lost my FOSS enthusiasm, after learning the hard way if software is the product one sells, there is hardly any money to pay the bills, if the product isn't amendable to consulting and support.
We are far from the supermarket taking pull requests.
Presumably there is an open-source version of RoboVM still around. Perhaps here: 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.
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.
Who were they ?
if you can name that direct competitor? I'd like to know who to avoid in the future.
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.
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.
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.)
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.
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.
How can close source the compiler if it is on GPL license ?
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).
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.
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.
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.
Dual licensing isn't otherwise a loophole since it is a decision the primary author organization makes for themselves, not something someone else can do to your copyleft code.
Copyleft does protect the commons. https://www.youtube.com/watch?v=UneYZikN85Q
Not necessarily. Depends on your goals. You might want to free up your software because it's the right thing to do and it guarantees your customers have a way out should should your business ever fail. You might scare away a few contributors by requiring copyright assignments so you can sell GPL exceptions, but the whole idea that you should free your software so you'll get more contributors is (1) sometimes false as it is in the present case, and (2) part of the campaign slogans that OSI made when they tried to rebrand free software as "open source".
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.
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.
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.
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.
It's easier both to do and to get away with when there's an open license. They can adjust it to integrate, and claim confusion or delay while rounding up source code.
Then sue them for damages immediately. If they offer up their source code during the lawsuit then great! If they don't then you get damages.
Implicit in this argument is the assumption that Xamarin ever wanted RoboVM to "win" at all.
I'm not saying that they don't... just that they subsumed a smaller competitor with an arguably superior product. Its logical to conclude that there exists a possibility that they simply paid to buy out RoboVM because they thought it would be cheaper than trying to compete head to head (especially, since as your c+p points out, competitors were/are using RoboVM code), and if RoboVM returns some of that money then it is just gravy on the biscuit.
If that's the case then too bad for Xamarin... it is more of a sign of their ineptitude and of their eventual demise... if their leadership choose to use cash to knock out competitors instead of innovation, it will be interesting to see how long they can keep that up.
My theory is that Xamarin is starting to care less and less what language is used to build mobile apps (for a while they claimed to care more about C# than Microsoft did); and instead own the products that become a natural pipeline into their service offerings like Test Cloud. Buying RoboVM lets Xamarin build in hooks that will mean staying in Xamarin platform is a natural progression.
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.
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.
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.
-- Richard Stallman (Open Sources, 1999 O'Reilly and Associates) https://github.com/llimllib/personal_code/blob/master/python...