Hi Jesper: On Mon, Oct 23, 2017 at 9:39 AM, Jesper Lund Stocholm <4a4553504...@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 | pombreda...@nexb.com DejaCode : What's in your code?! at http://www.dejacode.com nexB Inc. at http://www.nexb.com _______________________________________________ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss