Are you breaching Open Source Licenses accidentally?

http://blog.human-friendly.com/are-you-breaching-open-source-licenses-accidentally

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.



1 of 2




 





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.

 Upvote 0

 5 responses

Thank you for getting the word out about open source license compliance techniques. For projects that use many components under open source and commercial licenses, we recommend using IPCompass
(http://youtu.be/55la5sOKRcg) as a hosted tool to track your third-party components and their use case license requirements.
— Entente Software

I can't understand your supposition that open source developers set license terms without thinking about them, and that we don't expect app store apps to obey them. 

I've thought through the implications of all the licenses I've applied my my open source projects. Each individual project doesn't require much thought, because I generally use the same license each time. I understand pretty well what the BSD and MIT licenses
require and what consequences that has. 

I absolutely expect the license terms to be included with app store apps. That's the whole point of using these licenses. You get my code for free, and exchange, you perform the very minimal effort of announcing that you used my code. 

The expectations and guidelines are spelled out with complete clarity already. That's what the license is. There are no additional terms or considerations beyond that. Follow the license, it's the least you must do and the most you're required to do. You may
go beyond it in making the license more easily accessible than the license required, but this is not mandatory.

Excluding the license from mobile apps is not a provided option, nor is this an omission. Ship the code, ship the license. That's on purpose, not some oversight. 

I can't speak for the situation surrounding the choice of PLCrashReporter's license, but I'd bet a decent sum of money that it's exactly the same. 

I don't know where you got the idea that open source developers didn't think of mobile apps when they chose their license, or that they don't actually intend for mobile developers to follow the terms of the license, but it's wrong in my case, and I'd wager
it's wrong in the vast majority of cases.
— mikeash

Thanks for the feedback mikeash. 

Can I ask if for your MIT or BSD licensed code you would expect the License to be presented to app users in the application or if you would be satisfied with it only being included in the bundle and needing to be explored on a computer to get at?
— A posthaven user

I'd be satisfied with it being in the bundle somehow, as that satisfies the license. I enjoy it when it's presented in the UI somehow, but the license doesn't require it.
— mikeash

Mikeash - You said "Ship the code, ship the license." However, when apps are submitted to the store, only the binary is shipped - while it may seem like a minor difference, I think it is significant.
When I publish the source code with my app along with an open source library, the license exists to protect the original developer of the open source library in case somebody copies my copy of their library and hurts themselves. If I were to remove the license
from the code in that case, somebody adapting my code may try to claim liability from the original open source library - this is why the license must be redistributed with the code. However, once I have built my final binary for the end user on the store,
nobody can further use the original code as it is not present on the store. If a user claims damages from *using* my app in its binary form, I'm bound by the license terms of the store - and the original open source libraries licenses to which I am bound prevent
me from "transferring blame upstream". The disclaimer is for the developer, who is accepting responsibility by using the libraries, not the user. Of course, I'm not a legal expert and I have not extensively studied the art of licensing, but this is just my
take on the "shipping binary vs original code" perspective - I'd love to hear your thoughts on this stance.
— Tim about
8 hours ago