How to refer to the license when my code is based on a sample in documentation?

Question

When someone makes a code for their project using a certain library, oftentimes he will refer to the official documentation. But how does he need to think about the license?

Assuming I have been using an npm package @material-ui/core for my react project. The documentation explains that it provides a way to stylize my react component with makeStyles function like this:

// The MIT License (MIT)
// 
// Copyright (c) 2014 Call-Em-All
// 
// 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.
// 
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
// AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
// OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
// SOFTWARE.

import React from 'react';
import { makeStyles } from '@material-ui/styles';

const useStyles = makeStyles({
  root: {
    backgroundColor: 'red',
    color: props => props.color,
  },
});

export default function MyComponent(props) {
  const classes = useStyles(props);
  return <div className={classes.root} />;
}

So, I have added the MIT license statement here because I borrowed the code from them. My concern is that, for example, if I write the following code,

1. Do I need the statement in the file every time I use the makeStyles approach?
2. Do I need to include the statement somewhere in my repository?
3. Don't I need to include it as long as I do not distribute a package based on the library?

If I must take option 1, I have to write the statement in hundreds of the files but is it necessary?

// The code here is based on the @material-ui/core document.
// 
// The MIT License (MIT)
// 
// Copyright (c) 2014 Call-Em-All
// 
// 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.
// 
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
// AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
// OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
// SOFTWARE.

import React from 'react';
import { Grid, Typography, makeStyles } from '@material-ui/styles';

const useStyles = makeStyles({
  headline: {
    fontSize: 120,
    display: props => props.on ? true : false,
  },
});

export default function HeadlineComponent(props) {
  const classes = useStyles(props);
  return (
    <Grid>
      <Typography variant="h1" className={classes.headline}>My excellent headline!</Typography>
    </Grid>
  );
}

Answer 1

Consulting documentation and using that documentation to create your own work does not mean you are "creating a work based on the documentation."

Let's look at the example you have asked about. The documentation explains how to use the makeStyles function of a component which you have included. The component itself, which has its own code, and its own files, undoubtedly has its own copyright, and since it is licensed with the MIT license, you presumably already have permission to include that code, since you presumably followed the MIT requirements when copying it into your project. However, when considering the documentation sample itself about how to use this component, I would argue that the license of that sample itself should not matter so much to you if you are using it for its intended purposes -- to create your own work. Let's look at why: First of all, the license header, and the first two lines of the documentation will be the same for any documentation page which applies the same license and which states that it 'includes' a certain component according to the syntax of the language in question, so they can be excluded from any analysis, so basically we have the following 2 lines of code posted as documentation:

const AA = makeStyles({root: { backgroundColor: KK, color: x1 => props.color}});

export default function BB(props) { const CC = AA(x1); return <div className={classes.root} />; }

Where I have replaced the names that the author seems to have chosen with AA, BB, and CC, and apparent parameter choices with x1 and KK since perhaps these name choices could possibly be considered creative choices. But notice that the rest of this example appears to be dictated by the programming language (const, etc. by JavaScript) or associated standards (e.g. backgroundColor aka background-color by CSS, e.g. div by HTML). In other words, whoever writes such code will have no choice but to write it in this form, where AA, BB, CC, x1 and KK will perhaps differ, depending on who wrote it, but the rest cannot help but be written the same way:

AA = myStyles

BB = MyComponent

CC = classes

KK = 'red'

x1 = params

It seems to me that even if you were only to customize the above elements, you would already have your own creative work, or perhaps have a work so generic as not to be considered creative at all. Indeed, the chosen names of "myStyles" and "MyComponent" of this example seem to heavily imply that the intention is that the reader of the documentation will choose her own names for these things, e.g. 'futuristicStyle' if you are creating a futuristic style, and so on. The color 'red' is obviously an example color, probably chosen to stand out. Of course you will choose your own color. But even if you were to choose 'red' for your background color, the same as the author of this documentation sample, that is just fine. No one 'owns' the singular choice of the color 'red' for the background of some kind of design. The other names 'classes' and 'params' seem entirely generic to me, so you could either customize those or not, depending on your coding style.

In practice you would probably use this example as a starting point to insert your own styles. For example in a style you would have chosen many things other than background color to customize. And of course any style element you customize will be dependent on a relevant standard such as CSS for the name of the element you are customizing. If you consider the entire body of customizations necessary to create your own style, then perhaps that entire body of choices could be considered a creative work and subject to copyright protection, but in this example, we basically have the single choice 'set the background color to red' presented as an example to show how you can insert your own choices into this code in order to create your own unique style.

In other words, using a name such as 'backgroundColor' in your code, does not mean you are 'deriving' your code from someone else, who also happens to be using 'backgroundColor' in his code. Why? This is because anyone who writes such code has no other choice but to use this word, since it is derived from a CSS standard name of background-color. But even if the author had a choice in this name, and came up with the name 'backgroundColor' himself (for example), I still think this name itself is not creative in itself enough to warrant a particular creative choice. What else would you call a background color? It is a completely straightforward explanation of the color of a background of something. Anything else would simply be a different way of saying the same words, for example 'bgColor', which is simply an abbreviation of background, or background-color, which is simply a hyphenated form of the same words.

Such a choice depends entirely on context, however. For example if you make your own fictional tale about a boy wizard, and choose to name the protagonist "Harry Potter," one perhaps could make an argument that you are deriving such a choice of the character name from a different work that you do not own, and you might need a license for that. But if you choose to name him "John Doe," I don't think anyone could argue that such a choice is a derivative of someone else's work or demand that you get a license to use the name "John Doe" for your character, even if it could be shown that someone else wrote his own story about a boy wizard in which the protagonist of that story was also named "John Doe."

In summary, if you are using documentation in the manner it is intended -- to refer to it how to do something, and then you use it in that manner, then what you have written will be considered your own work. There might be some cases where this could be challenged, but you will probably recognize when this is the case. For example, if you have found a very useful function hidden in some documentation and want to copy and paste that into your code without changes (and the code also has its own creative elements), then perhaps you should consider the license. If the license is something like MIT, then including it would be no problem in practice, as long as the requirements of the MIT license are met (for the MIT license, this means including a copyright notice in any distribution of the work that you make).

See also: Abstraction-Filtration-Comparison test