6

I am considering the usage of various open source libraries in a closed source Android app. The libraries are released under various licenses (MIT, BSD modern, Apache 2.0) which allow this kind of usage, but require that the copyright notice is made available verbatim with the application.

I have seen various approaches, at least four:

  1. A submenu triggers a dialog where project names and relative licenses are displayed, e.g. Google apps.
  2. A message like "This app uses various projects released under license XXXX" is displayed on the app website. No notice is present inside the application or in the Play Store description, e.g. Whatsapp.
  3. No mention is done of the libraries being distributed with the application.
  4. Like 3, but the APK contains a /license folder.

What is the best practice? Maybe something else? Are approaches #2 and #3 even in compliance?

As a passionate contributor to various open source projects, I would really go with #1. Unfortunately, I am not in charge, so I must be able to argue about #2 and #3 too and/or propose a better solution.

Improve this question
5
  • 3
    The most important question to ask is "does this comply with the licence of the OSS library we are using?" If not, then you could be sued for breach of copyright by the library's authors. It's not so much about doing what's "right", but what's legal.
    – Simon B
    Jan 26 '15 at 12:13
  • @SimonB in this case at least, right implies legal.
    – Stefano Sanfilippo
    Jan 26 '15 at 12:28
  • I'd follow the example of those who certainly did due diligence, and could be easily sued if they didn't. For instance, Google itself. I'd go with an 'About' window that lists OSS software used (at least that which requires a notice, like BSD and MIT), and a link to or text of the licenses.
    – 9000
    Jan 26 '15 at 14:15
  • @9000 if it was for me, I'd go #1. But I would like to know if #3 or #2 are feasible, in case the team went that way.
    – Stefano Sanfilippo
    Jan 26 '15 at 14:30
  • 1
    Whenever possible, I always send an email to the project author (or mailing list/issue tracker for large projects) and ask what attribution they prefer. For my own projects, I choose a license that does not require any notice at all. People usually still give notice but that's their choice.
    – Abhi Beckert
    Jan 27 '15 at 5:06
2

Most OSS licenses don't try to precisely prescribe what is expected, as they cannot reasonably know what environment they run in. After all, the freedom to run FOSS code in many environments is a fundamental part of what it means to be FOSS code.

Instead, there's usually a clause that relies on implicit or contextual norms. For instance, the requirement can be to display all the copyright information in one place. Hiding some of the relevant copyright information in another location, just because you don't own those copyrights can be seen as disingenuous. if you think your copyright belongs in dialog X, then you better place all copyrights there. If you find it acceptable to have only a link to a mobile webpage in your app, even for your own copyrights, it's likely the FOSS copyright owners will accept this.

Note that "contextual norm" can be set by third parties. If Apple decides to have a form where you need to state copyrights, then that becomes the norm for all iPhone apps, and you must list FOSS copyrights along with your own.

Improve this answer
1
  • This. Just make sure the license is readily available and easy to find. Since the license is not crystal clear, you cannot be held responsible for having a different opinion to the copyright holder as to how the license should be interpreted. However if the copyright holder does ask you to do things differently you should comply with the new request promptly. A good example is when Apple did not attribute Open Street Maps the way OSM wanted to be attributed. There was no lawsuit, just a complaint, and Apple immediately promised to resolve the issue and a few weeks later did as OSM had asked.
    – Abhi Beckert
    Jan 27 '15 at 5:20
1

The exact terms vary from license to license, but most licenses require that the copyright message is somewhere where the end-user can find them. You can not assume that a regular end-user visits your website. And it is even less reasonable to assume that a regular end-user will unpack the APK file to look for the license files. Android end devices usually do not even provide the tools for doing this.

That means having a menu entry where the user can read the open source licenses is the most reasonable option of those you provided. An about-section which also includes your own copyright notice is a good place for this.

Just because others take license terms lightly is no excuse that you should do the same. Not complying to the license terms opens you up to a lawsuit from the creators of the library. There are non-profit open source organizations which sometimes finance such lawsuits when the case is high-profile enough. Talk to your legal department for further information. You don't have a legal department? Get a lawyer. In todays world you can't do business without legal advise.

Improve this answer
1
  • 1
    Guess what? A "90% there" well-intended attempt to comply with the rules is never a high-profile case. Don't feed the lawyer FUD. Minor compliance details in FOSS have always been settled amicably.
    – MSalters
    Jan 26 '15 at 15:19
1
  1. A message like "This app uses various projects released under license XXXX" is displayed on the app website. No notice is present inside the application...

It’s moot whether BSD licenses allow that, but I could not imagine how the following clause from both MIT licenses (Expat and X11) could be read to make that possible:

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

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.