Open-source front end and commercial back-end? Is this feasible?
April 7, 2011 4:02 PM Subscribe
I have written software that I would love to make open source. However, I would like to take the back-end, the core of the application, and sell Android and iOS implementations of it while keeping the front-end for PC development open. Is this possible? Practical? Even worth considering?
I saw a question posted earlier today that basically asked the same question, however it was closed for further comments and wasn't specific enough to my situation.
Ideally, I would love to keep the back-end code open so that people could modify it, but I would like to be able to sell its implementation on other platforms (different front ends) even if this means that someone was allowed to sell a competing version of it.
I saw a question posted earlier today that basically asked the same question, however it was closed for further comments and wasn't specific enough to my situation.
Ideally, I would love to keep the back-end code open so that people could modify it, but I would like to be able to sell its implementation on other platforms (different front ends) even if this means that someone was allowed to sell a competing version of it.
Check a little bit into the history of MySQL. I know that they've both kept versions of their system proprietary, and released it as GPL. If you're the sole contributor, you can do whatever you want with one version, and release some subset of it under whatever license you wish.
And I think another way to look at what you're proposing is as two applications: The PC end of things is one application, the Android and iOS another, they talk to some common code base (which may be a third server application).
People have made the various open source licenses work in all sorts of weird situations. If you wrote the code, you can release it, or portions of it, under any terms you wish. You might tread carefully where you have code shared between platforms (put the common code in a shared library and use the LGPL, perhaps?) or where you hope to incorporate improvements made by other people.
Finally, if you just want to release the source code and sell a binary, even allowing for others to sell binaries (but compelling them to release their improvements as well), well that's the GPL. And lots of people are doing that. Heck, I've bought binaries for GPL apps that are freely released as source code because I was happy to toss a few bucks the way of the author rather than typing "./configure ; make; sudo make install".
posted by straw at 4:28 PM on April 7, 2011 [1 favorite]
And I think another way to look at what you're proposing is as two applications: The PC end of things is one application, the Android and iOS another, they talk to some common code base (which may be a third server application).
People have made the various open source licenses work in all sorts of weird situations. If you wrote the code, you can release it, or portions of it, under any terms you wish. You might tread carefully where you have code shared between platforms (put the common code in a shared library and use the LGPL, perhaps?) or where you hope to incorporate improvements made by other people.
Finally, if you just want to release the source code and sell a binary, even allowing for others to sell binaries (but compelling them to release their improvements as well), well that's the GPL. And lots of people are doing that. Heck, I've bought binaries for GPL apps that are freely released as source code because I was happy to toss a few bucks the way of the author rather than typing "./configure ; make; sudo make install".
posted by straw at 4:28 PM on April 7, 2011 [1 favorite]
I haven't done much Android Market work, but if you were to distribute a opened, zipped-up Xcode project, the best someone with an App Store developer license could do is run a version with provisioning profile that will expire every so often. So even if you were to post all the code, it would be in the interests of a frequent and lazy user to buy the App Store version.
I wrote a hobbyist app a while back where I posted the C++ back-end on Google Code, where the back-end does all the number crunching. The back-end does calculations that anyone with a day or two could implement in their language of choice, so I don't think the value is there, per se. I charge a buck for the front-end, which is what I think makes the app worth someone's hard-earned money. This arrangement works fine for me.
posted by Blazecock Pileon at 4:45 PM on April 7, 2011
I wrote a hobbyist app a while back where I posted the C++ back-end on Google Code, where the back-end does all the number crunching. The back-end does calculations that anyone with a day or two could implement in their language of choice, so I don't think the value is there, per se. I charge a buck for the front-end, which is what I think makes the app worth someone's hard-earned money. This arrangement works fine for me.
posted by Blazecock Pileon at 4:45 PM on April 7, 2011
Subsonic uses a model quite similar to your idea. The server is open-source and web-based, but also includes an API that lets you access it from a smartphone client. (The Android client is open-source; the versions for other platforms are for sale by third parties.) To use the API after a 30-day trial period, you're supposed to donate, and in exchange they send you a server license key.
Anyone sufficiently motivated can look at the server source and figure out how to generate their own key. But it at least strongly encourages the user to make a donation.
(With an Android app, anyone with your source code could easily build and sign their own APK, and distribute it from their own website. They might even be able to put a free version on the Market under their own name; I don't know what Google's policy is in that situation.)
posted by teraflop at 7:34 PM on April 7, 2011 [1 favorite]
Anyone sufficiently motivated can look at the server source and figure out how to generate their own key. But it at least strongly encourages the user to make a donation.
(With an Android app, anyone with your source code could easily build and sign their own APK, and distribute it from their own website. They might even be able to put a free version on the Market under their own name; I don't know what Google's policy is in that situation.)
posted by teraflop at 7:34 PM on April 7, 2011 [1 favorite]
as an aside, if you want to target iOS and are serious about the "open source" aspect, you should use the BSD license or similar - there's a strong argument that GPL software can't be distributed through the App Store (since even with access to source, the recipient of the binaries can't make a working application themselves unless they pay Apple for the privilege, and this conflicts with the GPL's "no further restrictions" requirement). the license choice also includes any patches you accept from an external community.
If you don't plan on accepting patches, or will require a copyright assignment, then of course you can license the source however you like, as everyone else has said.
posted by russm at 4:48 AM on April 8, 2011
If you don't plan on accepting patches, or will require a copyright assignment, then of course you can license the source however you like, as everyone else has said.
posted by russm at 4:48 AM on April 8, 2011
RE: Apple AppStore vs. GPL. Apple explicitly do not allow GPL-licensed software onto the AppStore. This situation was finally and cataclysmically resolved vis-a-vis VLC:
I'm happy to be proven wrong, with references!
posted by asymptotic at 5:56 AM on April 8, 2011
- Apple Pulls VLC Player from App Store Due to GPL: "Thus the incompatibility between the GNU General Public License and the AppStore terms of use is resolved - the hard way," writes Denis-Courmont. "This end should not have come to a surprise to anyone, given the precedents."
- VLC for iOS vanishes 2 months after eruption of GPL dispute: "It's official: the iOS version of VLC has been yanked from the App Store. Though Apple didn't offer any reasons for its removal, the media player is believed to have been pulled thanks to a licensing dispute that started more than two months ago."
- No GPL Apps for Apple's App Store: "Be that as it may, the Free Software Foundation (FSF) agreed with Denis-Courmont that the GPLv2 does, indeed, conflict with Apple’s App Store ToS."
I'm happy to be proven wrong, with references!
posted by asymptotic at 5:56 AM on April 8, 2011
Apple explicitly do not allow GPL-licensed software onto the AppStore
huh?
"explicitly do not allow" would mean that the vague-as-fuck review guidelines and license agreement state "no software under the GPL will be approved on the store"... there's no mention in the review guidelines, and the iOS dev agreement just says that if you include FOSS then you're responsible for making sure the license terms are met (§3.3.20). the articles you've linked just say that the app was pulled with no explanation after a copyright infringement claim was made by a dev with GPL-licensed code in VLC.
in practice, it's clear that Apple will pull apps at the first sign of an infringement complaint by the copyright holder of GPL code, but there's no explicit guidance for developers as to how the app store works with FOSS (apart from the §3.3.20 "it's all down to you" thing).
if the copyright holder of some GPL code uses it in an app there's no reason to think (other than "oh noes! apple is teh suxxor!") that there will be an issue with app store approval. if OP writes and GPLs some code, and either a) never accepts external patches, or b) requires a copyright assignment, then there's no problem using that code in the app store.
as for BSD/MIT, they lack the "no further restrictions" language of the GPL and are completely free of all this uncertainty. as long as you include the copyright notice, disclaimer, and conditions, and don't claim endorsement, you're good to go with 3-clause BSD. MIT is even easier - you just need to include the copyright notice.
posted by russm at 7:42 AM on April 8, 2011
huh?
"explicitly do not allow" would mean that the vague-as-fuck review guidelines and license agreement state "no software under the GPL will be approved on the store"... there's no mention in the review guidelines, and the iOS dev agreement just says that if you include FOSS then you're responsible for making sure the license terms are met (§3.3.20). the articles you've linked just say that the app was pulled with no explanation after a copyright infringement claim was made by a dev with GPL-licensed code in VLC.
in practice, it's clear that Apple will pull apps at the first sign of an infringement complaint by the copyright holder of GPL code, but there's no explicit guidance for developers as to how the app store works with FOSS (apart from the §3.3.20 "it's all down to you" thing).
if the copyright holder of some GPL code uses it in an app there's no reason to think (other than "oh noes! apple is teh suxxor!") that there will be an issue with app store approval. if OP writes and GPLs some code, and either a) never accepts external patches, or b) requires a copyright assignment, then there's no problem using that code in the app store.
as for BSD/MIT, they lack the "no further restrictions" language of the GPL and are completely free of all this uncertainty. as long as you include the copyright notice, disclaimer, and conditions, and don't claim endorsement, you're good to go with 3-clause BSD. MIT is even easier - you just need to include the copyright notice.
posted by russm at 7:42 AM on April 8, 2011
A copyright owner of VLC had the app pulled — not Apple on its own.
posted by Blazecock Pileon at 10:07 AM on April 8, 2011
posted by Blazecock Pileon at 10:07 AM on April 8, 2011
Response by poster: Thanks for all the feedback, you guys have pointed me in some good directions. Here seems to be the wording in the GPLv2 that could present a problem.
Going with the GPL version 1 seems to be the best option for me so far since I do like the idea of keeping any revisions open, but I'm not opposed to forking or allowing apple to keep control of their app store.
posted by hellslinger at 10:46 AM on April 8, 2011
Going with the GPL version 1 seems to be the best option for me so far since I do like the idea of keeping any revisions open, but I'm not opposed to forking or allowing apple to keep control of their app store.
posted by hellslinger at 10:46 AM on April 8, 2011
Best answer:
Please, again, references to the contrary are welcome; Section 3.3.20 of the App Store TOS simply states:
posted by asymptotic at 2:15 PM on April 8, 2011
@hellsinger: Going with the GPL version 1 seems to be the best option for me so farAgain, incorrect. The position of the Free Software Foundation is that all versions of GPL are incompatible with the TOS of the Apple App Store, i.e.:
In the App Store Terms of Service, the programs that you download from the App Store are called "Products" (the definition is in section 4). In section 9(b), the Terms set out "Usage Rules" for the software:@russm: Again, you are incorrect, or so I believe, nor did I use the phrase "suxxor" in my answer. The FSF article goes on to state that:You acknowledge that Products contain security technology that limits your usage of Products to the following applicable Usage Rules, and, whether or not Products are limited by security technology, you agree to use Products in compliance with the applicable Usage Rules.The Terms go on to list the specific usage rules. In effect, the Usage Rules do the same thing as Apple's Digital Restrictions Management—narrowly limiting what you can do with the software—but the method is different: they work legally instead of technologically. Rules (i) and (iii) say that you are required to accept the Terms of Service to use the software, and that you may only install the software on five approved devices. These rules are exactly the kind of "further restrictions" that are prohibited by the GPL: they limit your ability to use and distribute the software.
Some people have pointed out that the App Store Terms of Service say that a separate license to the software is provided to you by the developer, and that's true. But the Usage Rules are imposed on you no matter how the software is licensed.i.e. Apple choose to impose restrictions on all developers, regardless of how they choose to license their software.
Please, again, references to the contrary are welcome; Section 3.3.20 of the App Store TOS simply states:
Apple Push Notification server: All use of the APN must be in accordance with the terms of this AgreementHow is the APN related to GPL, or other copyleft software licenses?
posted by asymptotic at 2:15 PM on April 8, 2011
Best answer: @Blazecock Pileon: In the case I believe you're absolutely right. Here's another example of GNU Go being rejected by Apple:
posted by asymptotic at 2:18 PM on April 8, 2011
Apple has removed an application from the iPhone App Store after the Free Software Foundation complained that the store's terms of service undermined the application's open source license.The fine distinction here is that Apple rejected the app after the FSF actively complained. Hence, my saying that Apple is actively rejecting GPL apps is unfair and misleading; Apple, instead, refuse to come into compliance with the GPL's rules, leading to the FSF to complaining, leading to Apple's rejection. The clear driver in this process is the FSF.
posted by asymptotic at 2:18 PM on April 8, 2011
Best answer: and the iOS dev agreement just says that if you include FOSS then you're responsible for making sure the license terms are met (§3.3.20)
but still, if OP writes and releases code under the GPL, he is still perfectly free to use that code in the app store under a different license. being the copyright holder, you get to do that. as I've said several times this only becomes impossible if he accepts GPL-licensed patches without a copyright assignment, because then he loses the ability to re-license the entire codebase as used in his own app to one that is compatible with the app store distribution terms.
posted by russm at 3:52 PM on April 8, 2011 [1 favorite]
3.3.20 If Your Application includes any FOSS, You agree to comply with all applicable FOSS licensing terms. You also agree not to use any FOSS in the development of Your Application in such a way that would cause the non-FOSS portions of the Apple Software to be subject to any FOSS licensing terms or obligations.again, "Apple explicitly do not allow GPL-licensed software onto the AppStore" isn't correct because Apple isn't being explicit bout their decision making process, although we can infer pretty easily what it is. the FSF of course is being explicit in their statements about the incompatibility of GPL licensed code in the app store.
but still, if OP writes and releases code under the GPL, he is still perfectly free to use that code in the app store under a different license. being the copyright holder, you get to do that. as I've said several times this only becomes impossible if he accepts GPL-licensed patches without a copyright assignment, because then he loses the ability to re-license the entire codebase as used in his own app to one that is compatible with the app store distribution terms.
posted by russm at 3:52 PM on April 8, 2011 [1 favorite]
« Older I need terrible killer and/or lover robot movies... | Help Me Escape Craigslist Purgatory Newer »
This thread is closed to new comments.
posted by orthogonality at 4:05 PM on April 7, 2011 [2 favorites]