Tuesday, February 5, 2013

Question concerning pull requests

We have received a first pull request to our project (not related to translations, wich we process differently via excellent webtranslateit service. That's actually big news, because it's first ever code submitted to our project. Fairly speaking, code is pretty small and easy, but in raises one very important question... rights for code and application store rules. 

So far, we own all rights to all published code, so while releasing it to public under GNU GPLv3 license we still can distribute this code under any license we like. This is very handy if we'll need to submit our app to some (evil) appstore that requires some evil DRM features that would be incompatible with GNU GPLv3 terms - we can just say that all rights to publish this code is our own, and that despite code published on Github we publish this very instance of an app under our own evil proprietary license. 

We won't have this option if we just accept code from our contributors under GPL license. And we don't want to rely on 'trust' in Google that it won't change Google Play developer terms that it won't be incompatible with GNU GPLv3 (we also don't want to see our app pulled from store because of complaints by some contributors - such things did happen in the past and it wasn't pretty).

Xabber Contributor Agreement?

Many companies avoid these kind of problems by enforcing all contributors sign some form of contributor agreement (most famously Mozilla Comitter's Agreement, and (infamously) Oracle Contributor Agreement). 

An agreement like this would grant us sufficient rights to code so we won't have to worry about problems like we've covered above and would also make us carry quite a burden of administrative work processing & storing all the legal papers. That would also make contributors less likely to submit code to us and we'll also look evil to many-a-developers. 

We'll also be able to screw community in grand way like Oracle did with OpenOffice.org, but all we can do now is to promise not to.

What do you think of it? Should we have such agreement to ensure future of Xabber in various appstores, or should we just accept all the code under GNU GPLv3 and not bother about possible GooglePlay problems?

Please use comments below or just mention @Xabber_XMPP on Twitter. We need your opinion.

GNU GPLv3 is incompatible with Apple Appstore terms and we'll definitely have to think of something similar to solve this problem when we release Xabber for iOS (wich we plan to later this year, btw, work is already in process).

24 comments:

  1. I do not own any smartphone yet and never used one. Do I understand correctly it is not possible to install free software on these devices because installation is forced to be done through an app store which enforces some non free license? This sounds like this whole smartphone stuff is crap!

    ReplyDelete
    Replies
    1. Android smartphones let you install software from any third party source if you wish. I rooted my Android phone and removed ALL the Google spyware, including the Google Play app store. There is a free-software only app-store called https://f-droid.org/ that you can use. There are also other commercial appstores like Amazon's that you can use if you wish. It's different if you buy Apple, but Android gives you some freedom.

      Delete
  2. I prefer pure GPLv3 to maximize my idea of what community value is, but I'm not the critical audience : your critical audience is whoever is most likely to contribute significantly... What impact will the choice of license have on their motivation ? Your license preference question is actually a developer marketing problem.

    ReplyDelete
    Replies
    1. Well, dual licensing under GNU GPLv3 and 'evilproprietaryredsolutionlicense' should not, in theory, reduce value of source code published under GPLv3.

      It should, however, ensure Xabber presence and availability to users (you know, those kind of people that many diehard fans of FOSS usually forget about).

      Delete
  3. That doesn't have anything to do with smartphones per se. There's only only one smartphone vendor, one bad Apple (absolutely no pun intended at all), who are actually banning free software from their store.
    OTOH, appstores, like all walled gardens in an open net should of course be considered evil and mistrusted. But that's basically, what the OP said.

    ReplyDelete
  4. I'm a proud xabber VIPer and commend you guys on your contribution to the FOSS community and desire to do things right and not be evil. I like the dual license idea from Andrew. If you need an agreement for that, I say do it. You don't need a foumdation to do the right thing, keeping a gpl'd codebase on github and also doing what you want with it is cool. It's your blood sweat and tears, after all. Thanks again, I was one of the people working toward 50k followers on twitter. :-) Don't sweat the ideologs, they mean well, but doing right isn't limited to towing the gpl party line. I'm an MIT'er myself... ;-)

    ReplyDelete
  5. Whats the problem with having a GPL codebase and distributing compiled packages to the different stores? (You can make sure that every contributor knows about that in advance)

    ReplyDelete
  6. I basically see two ways to avoid both a contributor agreement and license issues with Google Play:

    1. Don't use Google Play and switch to something like F-Droid. Of course this has the downside that you'll probably lose quite some users.

    2. Change the license to something less restrictive. For example GPLv2 if you think you need a copyleft or something BSD/MIT-like if you don't.

    ReplyDelete
    Replies
    1. GPLv2 is not less restrictive and app stores have the same issues with it.

      Delete
  7. As an author of the pull request mentioned above, I think that license agreement is a drag, and it will make the contribution process more complicated, like it stated : "That would also make contributors less likely to submit code to us and we'll also look evil to many-a-developers." I could sign it, but for 2 developers who would like to sign it there will be 10 more who will just move to another project. As for Google Play license policy, I think Google will not change it. What other stores do you plan to use? So I vote for more open and convinient process and less drag (at least for Android version). Whats the point to release it under GPLv3 if we still need to deal with the papers? Apache/MIT would be OK then.

    ReplyDelete
  8. I think the problems with a contributor agreement are: bureocracy and trust.

    Bureaucracy because after doing a quick two-line code fix, I might need to read the agreement instead of just doing a pull request.
    Trust because, if I grant you ownership of the code, you can do whatever you want with it. Even close it up, without giving me any acknowledgment. It's nothing personal, but other devs don't know you intentions, or if you pretend to, at some point, sell the entire product to Sun, just like what happed with mysql.

    I you need more flexibility (for example, for creating drm'ed versions of the client) you should switch to a BSD/MIT license, so that ANY contributor has the same rights.
    Otherwise, I agree with above; use f-droid's repos. :)

    ReplyDelete
  9. As the original pull request was merged, what's the outcome? I would like to contribute some patches, but I'll likely be unable to do so if assignment is required.

    ReplyDelete
  10. It is true that the biggest issues with copyright assginments are bureacracy and trust.

    In my experience, at least the trust issue can be fixed by codifying good checks and ballances firmly into the agreement. That's exactly what we did in FSFE with our Fiduciary License Agreement¹ [FLA], of which prominent users are KDE and Bacula.

    What makes the FLA unique amongst CA/CLA is that while it gives great power to the fiduciary (e.g. KDE e.V.), the beneficiaries (i.e. contributors) get all the rights back that they need to do whatever they want with *their* own code. What's even more important though is that since it's a fiduciary contract, in case the fiduciary violates the trust (e.g. goes all evil and proprietary only), the copyright assignement terminates and the beneficiaries get all their copyright back.

    As for bureaucracy, there is always some overhead. But depending on your situation, you can adapt the system to your needs. Of course, having all copyright centred into a single entity (i.e. every contributor signs an CA/FLA) is a *lot* easier for governence of the project. But some FS organisations (e.g. KDE e.V.) have decided a softer, yet well defined, approach was better for them².

    If you want to know more, do drop me a line or better yet contact our whole FSFE Legal Team at and we'll be happy to help you out.

    BTW, at FSFE we're great fans of Xabber and we actively promote³ it in our Free Your Android⁴ campaign.


    [1] https://fsfe.org/activities/ftf/fla.en.html

    [2] http://ev.kde.org/rules/fla.php

    [3] http://fsfe.org/campaigns/android/promomaterial/fdroid-folder.pdf

    [4] http://fsfe.org/campaigns/android/

    ReplyDelete
    Replies
    1. Hmm, the form ate the mail address... well, you can find it on:
      https://fsfe.org/activities/ftf/

      Delete
  11. If the idea of FLA does not convince you, you could instead add an exception to the license. It is a well established technique used by various projects for various reasons. For examples see GPL linking exception¹, GCC runtime library exception², or Autoconf configuration script exception.

    The way it work is that you, as a copyright holder, give additional permissions to your software (which is perfectly fine under any Free Software license) and then since submitted patches are assumed to have the same license as the whole work, authors of those patches give you and everyone else the same permissions as well.

    To accomplish it, you just need to add a paragraph to the comments indicating the license and somewhere in the LICENSE file (or wherever you keep the copy of the GPL) stating something like:

    > As a special exception, the copyright holders of this software give you permission to distribute it in binary form without corresponding source code on on-line services you do not control which do not allow for uploading of a source code provided that (i) the terms of the license and on-line location where the corresponding complete source code can be obtained is clearly indicated to the users, and (ii) the corresponding complete source code is available as long as the binary is distributed on such a service.

    I'm not a lawyer so you'll have to consult one to get it properly worded. In fact you might also want to talk to SFLC⁴ or FSFE⁵ to help drafting this.

    ¹ http://en.wikipedia.org/wiki/GPL_linking_exception
    ² http://www.gnu.org/licenses/gcc-exception-3.1.html https://www.gnu.org/licenses/gcc-exception-3.1-faq.html
    ³ http://www.gnu.org/licenses/autoconf-exception.html
    ⁴ http://www.softwarefreedom.org/ help@softwarefreedom.org
    ⁵ https://fsfe.org/activities/ftf/ legal@fsfeurope.org

    ReplyDelete
  12. Hey there.

    I don't think contributors license agreements are too much of a burden. Especially because I don't see a single other way to contribute to a project that wants to retain its possibility to acquire other distribution channels that require a very specific license type.

    And since CLAs are pupular and seem to solve that issue: Go for it!

    There is one thing I would suggest to add to such an agreement: Would be pretty awesom if there was something like "I sign this document under the very requirement the code I provided will be at least published by $anyOpenLicenseYouLike".

    Just think about it. I would refuse to give my code to someone who takes it, makes money out of it and stops providing the whole thing. But as long as there is always a free version I don't care about the maintainer of the project having a second distribution channel that raises some money.

    And that's not a thing of thrust. If I sign an agreement and submit code, I expect the taker of the code not only to bind me on my part of that agreement but also be bound on his part.

    So make such a fragment part of that agreement please.

    Regards,
    Stephan.

    ReplyDelete
  13. What a good suggestion posted by the peoples
    66666q

    ReplyDelete
  14. I have an HTC desire phone and can't access the menu button. Other then that I like the app. Is there a way for me to get a menu up?

    ReplyDelete
  15. This comment has been removed by the author.

    ReplyDelete
  16. Hello
    The Old Xabber have a countacts integration but on the New does not exists

    ReplyDelete
    Replies
    1. Sorry every one
      Hi
      I Have installed the developer apk.
      but when I have downloaded the googlePlay.apk it have the contact integration
      But I am pulling 2 or 3 reqests more please
      1) on the integration add the picture from server and/or edit the contact information like nickname and others.
      2) send files throw
      Regards and good work!!

      Delete