Does code comply with OpenZeppelin license and copyright terms?

Hello, this is my project which is literally forked and edited from OpenZeppelin, I’m just interested if I actually deploy this contract, will it comply with OpenZeppelin license and copyright terms?

I’ve mentioned credits in and will also mention in whitepaper and the whole project is under MIT license.

1 Like

Hi @kanedaaaa,

Welcome to the community :wave:

To keep your system secure, you should always use the installed code as-is, and neither copy-paste it from online sources, nor modify it yourself.


You should install OpenZeppelin Contracts (npm install @openzeppelin/contracts) and then import.

Your contract could then look as follows (and you wouldn’t need to clone the other contracts from OpenZeppelin Contracts):


// contracts/Kata.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract Kata is ERC20 {
    constructor() public ERC20("Kata", "KATA") {
        _mint(msg.sender, 700 * (10 ** uint256(decimals())));

Please note, in the OpenZeppelin Contracts ERC20 implementation, the default decimals is 18, whilst you were doing 10**9. If you want to use a different number of decimals you can call _setupDecimals in your constructor.

As for the OpenZeppelin Contracts license and copyright, as long as you are compliant with the MIT license (e.g. don’t try to change to a non-compliant license) and don’t remove OpenZeppelin copyright then you should be compliant.

I recommend when you verify your contract on Etherscan, that you do multi-file verification to maintain imports and SPDX License identifiers: Verify smart contract inheriting from OpenZeppelin Contracts

You could add a Built with OpenZeppelin badge:

I recommend creating some tests to ensure that your contract functions as expected. See:

I also suggest looking at: Points to consider when creating a fungible token (ERC20, ERC777)

1 Like

Hey @abcoathup , thanks for detailed response.

I understand how OpenZeppelin npm package works and i also understand the consequences of editing code, its just something that i feel more comfortable when every script is under my observation, as you can see ive also merged math/address/context into ERC20.sol.

I’m experimenting on decimals, total supply, etc. and probably will change it back to 18.

Code is tested and works just fine on test networks, made several transactions between my phone and pc through metamask.

I was just interested, if doing all those stuff and editing actually fits in your license agreements.

I’ve mentioned your website/github in and also code is licensed under the MIT.

P.S yep, i will add your badge and will verify contract correctly on etherscan

1 Like

Hi @kanedaaaa,

As far as I can tell, you haven’t changed the license from MIT nor have you changed the copyright.

If you proceed with cloned code (which I don’t recommend), I would include in each contract a comment at the top with a link to the original contract in the OpenZeppelin Contracts repository and that it was cloned under MIT license. That way when your contract is verified on Etherscan, anyone reading the code can see where it came from.

I would encourage you to use npm imports.

Merging the code yourself means that anyone reading your contract has to check all the code for themselves to understand what changes you have made, whether this is by one of your token holders or an auditor, rather than checking that the code was imported from a specific version of OpenZeppelin Contracts.

See the verified example:

Manual testing is great but I didn’t see any unit tests in your repository and would encourage you to write appropriate unit tests. This is also useful for prospective token holders.

I suggest looking at the following regards using OpenZeppelin Contracts, testing and auditing:

1 Like

Thanks, appreciate your answer.

1 Like