[License-discuss] Guidance for making license information available to users

[Philippe Ombredanne]

Hi Jesper:

On Mon, Oct 23, 2017 at 9:39 AM, Jesper Lund Stocholm
<4a4553504552 at gmail.com> wrote:
> We are distributing (selling) an application written i JavaScript. Since it
> is JavaScript (no obfuscation) all source code is technically available to
> anyone who would like to look for it.
>
> We include a number of components in our application and I am looking for
> guidance to how we handle the licenses for them.
>
> As an example:
> We use a component called "jQDataRangeSlider"
> The JavaScript file contained in our app contains this line:
>
> /*! jQRangeSlider 5.7.2 - 2016-01-18 - Copyright (C) Guillaume Gautreau 2012
> - MIT and GPLv3 licenses.*/
>
> However, the MIT license says this at https://opensource.org/licenses/MIT
>
> Copyright <YEAR> <COPYRIGHT HOLDER>
>
> Permission is hereby granted, free of charge, to any person obtaining a copy
> of this software and associated documentation files (the "Software"), to
> deal in the Software without restriction, including without limitation the
> rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> sell copies of the Software, and to permit persons to whom the Software is
> furnished to do so, subject to the following conditions:
>
> The above copyright notice and this permission notice shall be included in
> all copies or substantial portions of the Software.
>
> Our question is: how do we handle the requirement in the last line?
>
> It is enough for us to "do nothing" - meaning simply keeping this line in
> the JavaScript file:
>
> /*! jQRangeSlider 5.7.2 - 2016-01-18 - Copyright (C) Guillaume Gautreau 2012
> - MIT and GPLv3 licenses.*/
> ?
>
> Or do we need to include the entire paragraph from the official MIT license
> in our application?

IMHO you should also include the MIT license text [1] and eventually
the GPL text [2] : "Dual license" technically means both... but the common
understanding is that this is a choice of license. What is not clear is if here
the choices are something you can or must pass downstream or if you
can only pass downstream your MIT choice: including both is simpler.
In any case, the authors includes the MIT text in their upstream repo [1]
so you would need to include it too. If the text was missing (which
is common for JavaScript libraries...) I would add it back.

> And how should we handle the complete list of components that we use?
> Is it enough simply to write "Contains software licensed under MIT, Apache,
> GPLv3 ..."?

This may not be enough. I wrote about this in general [3] the context of the
GPL [4] and it applies to most open source licenses. At least you might want
to include copyrights, notices and the full text of the licenses in your app.

> Or do we need to explicitly mention each component somewhere in a
> "Readme"-file?
>
> Like:
>
> * Uses jQDateRangeSlider licensed under MIT and GPLv3 license, Copyright
> Guillaume Gautreau 2012
> * Uses numeral.js licensed under MIT license Copyright Adam Draper

This would be much better, but still may miss the license texts and the original
notices --if any-- that some licenses have and require.

Technically listing the name of the libraries and their licenses is not entirely
needed, but it makes sense as a human-readable summary attribution.
You could add a link to the upstream library in your list for good measure.

> And finally - can we simply add a "readme"-file with license information to
> our application such that a developer/techie can find it - or do we need to
> create some sort of link/page where "ordinary" users can find it as well?

It is typically best to have a link in the user app where a user can find it.
Some licenses require this in some form with a "prominent" notice: an
about page, a documentation page, etc. and not something semi-hidden
is prominent enough and better.
Since each license has different requirements, using a highest common
denominator is a simple approach that works: attribute all the same way,
typically in the code (if it existed) in the doc and some about page.

An approach to limit the boilerplate is to use SPDX license expressions
and identifiers [5] in the code as Linux kernel maintainers are starting to
use them [6] (note that I chipped in to help with this)

Also automation can help.  Check out some open source tools to scan
for licenses and copyrights [7] , review results [8] and generate
attribution [9]
Note: I maintain or co-maintain these tools.
See also this list [10] for other tools.

[1] https://github.com/ghusse/jQRangeSlider/blob/master/MIT-License.txt
[2] https://github.com/ghusse/jQRangeSlider/blob/master/GPL-License.txt
[3] https://opensource.stackexchange.com/a/4587/947
[4] https://opensource.stackexchange.com/a/4582/947
[5] https://spdx.org/sites/cpstandard/files/pages/files/using_spdx_license_list_short_identifiers.pdf
[6] https://patchwork.kernel.org/patch/10016189/
[7] https://github.com/nexB/scancode-toolkit
[8] https://github.com/nexB/aboutcode-manager
[9] https://github.com/nexB/aboutcode-toolkit
[10] https://wiki.debian.org/CopyrightReviewTools
-- 
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombredanne at nexB.com
DejaCode : What's in your code?! at http://www.dejacode.com
nexB Inc. at http://www.nexb.com