Human Friendly

Posts for Tag: mobile

Are you breaching Open Source Licenses accidentally?

MIT Licenses and Requirements in Mobile Apps

I am not a lawyer, this is not legal advice I only read the plain text of licenses and try to comply.

TL;DR

Much open source licensed software even permissive licenses like the MIT license and the Apache license require a copyright notice to be distributed with derivative works (although the Apache licences definition of derivative doesn't include where linked by name).  In the case of mobile apps you should at least be including the license text in the bundle and to comply with the spirit of the license I think that you should be exposing it to the end user through the interface.

If your app uses PLCrashreporter, Crashlytics, HockeyApp or uses any open source licenses and you haven't carefully thought about presenting those licenses to the user you should read the long version.

Background

I developed the Fast Lists app for the iPhone and iPad.  It is a fairly simple app focussed on use for check lists, shopping, packing, emergency services divers checklists or really anything that you can think of.

Until version 1.60 is released I was using Parse for anonymous logging (including a self implemented crash reporting system) and for managing promotional in-app upgrade codes.  However when Facebook bought Parse I felt that I needed to move away from their services [I may post separately].  I can live without the anonymous logging and promocodes temporarily but I didn't want to be without crash logging as Apple only seems to provide reports when crashes reach a certain frequency that Fast Lists was not reaching

I looked at a number of hosted and self hosted solutions including:

  • Crashlytics
  • Flurry
  • HockeyApp
  • Quincy Kit.net
  • PLCrashReporter (and writing my own server)
  • JIRA and JIRA Mobile Connect Plugin

In the end I picked JIRA largely for reasons unrelated to to this post.

    The Problem

    Most (all?) of these are based on PLCrashReporter and potentially other Open Source software and as far as I know they all comply with the license.  However none of these take explicit steps to bring to your attention your obligations as a downstream user.  At the VERY least you need to be including a copy of the Licence and copyright notice within your app bundle and I think to comply with the intent of the licenses you should be exposing them to the user in some way as while I know that you can ask iTunes to show the .ipa in finder and then you can unzip and explore it I don't think many users would do that.

    MIT License

    The MIT License PLCrashReporter mostly uses says:

    Copyright (c) <year> <copyright holders>

    Permission is hereby granted ...[lots of good stuff do what you want]...

    The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

    [Legalese to say no warranty]

    So if a substantial portion e.g. (the PLCrashReporter library) is included in your app so must the permission and copyright notice.  For this as I read it including in the bundle with no user accessibility may be legal.

    The Apache License

    The PLCrashReporter uses the protobuf-c library which is licensed under the Apache License version 2.0.  This is longer and more detailed and makes clear than simply linking does constitute the creation of a derivative work.  However by including the library in your application you not only link to it but distribute the library.  Clause 4 of the license is about Redistribution and part 4 says:

    If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.

    Now it may be possible to get around this in a couple of ways, firstly possibly intentionally neither the PLCrashReporter or the protobuf-c one seem to have a NOTICE file so this section may not apply although the material in the PLCrashReporter LICENSE file is similar to that which I would expect in a NOTICE file.  Secondly even if NOTICE file existed you might just be able to place it within the app bundle under the "within a NOTICE text file distributed as part of the Derivative Works" option only if you did not otherwise have third party licenses appearing within the display generated by the app.

    However even if you use the lack of the NOTICE file part 1 of the same clause says:

    You must give any other recipients of the Work or Derivative Works a copy of this License; and

    So you must at least include the copy of the LICENSE file inside your bundle and not giving them the opportunity to access it would to me seem to break the spirit of the license if not quite its precise language.

    How is this presented by service providers and downstream licenses?

    The closest of the commercial offers to making it clear was probably Crashlytics whose legal page has a link to "Open source licenses" that isn't buried in the text of a long legal document or in a sub-folder of a download.  It doesn't actually seem to be referenced from the legal document so it isn't completley apparent that it needs to be followed by downstream users.

    In fact when I queried Crashlytics about the open source license and the end user requirements and whether I needed to add a licenses section to my app (I'm lazy and I didn't want to spend the time including additional UI on iPhone and iPad) I got this response which I didn't find reassuring about the correctness of the approach although in practice it is probably valid:

    Joseph, great question!

    None of our customers, to my knowledge, has distributed our license with their app and we've seen no cause for alarm so far. That said, it might make sense for you to do so out of an abundance of caution if you are concerned.

    Hope this helps,

      Now I believe that following this advice would technically lead you to breaching at least two licenses. I think as you include the Apache licensed Proto-bufs in your bundle you are certainly distributing even if your app is not a derivative work.

      The Blame and What Should be Done Better

      I'm going to talk about PLCrashReporter because that is the specific software where I hit this issue but I really don't want to pick on them or be making a specific point about them.  Its really about mobile targeted open source.  I really appreciate the PLCrashReporter software that has been provided by the Plausible Labs and they have done nothing wrong but they could help the situation.

      App Developers

      Now we should all read every word of the legal documents we receive, read and understand the details of the licenses for all software we include in our apps so we all share some blame.  For now we need to not be lazy and actually add the UI to our apps to present these licenses (or write all the code ourselves)

      Open Source Library Developers

      I think that the source of the problem is that the original upstream projects set license terms without thinking about them.  I have the feeling that the PLCrashReporter developers don't really expect the license terms to be included with app store apps.  They just used the MIT license because it is standard and permissive.  I think that they should set out their expectations and guidance about how the license should be presented or bundled or possibly even better add additional terms allowing the license to be excluded from mobile apps (and possibly linked to from the developer's site or the app description).

      Now in many cases not thinking about how the documentation would be handled in mobile apps is completely understandable but they are the main target for some libraries such as this so it really should be considered.

      Commercial Services and Downstream Libraries

      The services and derived libraries should include in their user instructions the requirement to add the license to the end user's software bundle. They could even offer a convienience ViewController and Xib to present it (and other licenses if the user needs to show them too).  I think this is the place where the greatest responsibility lies.  These services largely have paying customers whose work is being put into some legal risk, they have a responsibility to their customers to explain what is necessary to comply with the upstream license and it should be in the main how to get started documentation not tucked away in the legal agreement.

      My Solution

      I implemented the license screen in the end.  I want to be squeaky clean.

      My current overall solution is using the JIRAMobileConnect and self hosting a starter licensed version of JIRA.

      You can find the open source code that I have used:

      • PLCrashReporter (not really modifed from the original).

      • JIRAMobile Connect iOS (small modifications from original to support embedding in Xcode project as subproject and git submodule - but that is another story).

      • MinimalGoogleToolbox is a hugely stripped down version of Google Toolbox For Mac extracting only a couple of text processing (particularly JSON) categories for use in my app without bloating the binary.  You could probably use the minimal version and then add other parts in if you wanted to.