Yes. You can sell code that uses open-source components when you meet their license terms. The Open Source Definition(opens in a new tab) permits commercial use and redistribution for a price. Both permissive and copyleft licenses allow commercial use, with different conditions.
On Kurodyne, you must also have authority to offer your own material under the Kurodyne Commercial License. Third-party components keep their own licenses, and you must identify their terms and any obligations buyers need to follow.
License names in this article use SPDX identifiers(opens in a new tab), which distinguish the exact license and version. A component's own license notice determines which identifier applies.
Permissive licenses generally let you include their code in a commercial product and choose different terms for your own material, provided you meet the original license's conditions.
- MIT: Include the original copyright notice and permission notice with copies or substantial portions of the software. Keep the full license text, including its disclaimer, with the component. MIT(opens in a new tab) expressly permits selling copies.
- BSD-3-Clause: Preserve the copyright notice, conditions, and disclaimer in source distributions. Reproduce them in the documentation or other accompanying material for binary distributions. The BSD-3-Clause(opens in a new tab) also prohibits using the copyright holder's or contributors' names to endorse your product without permission.
- Apache-2.0: Include the license, mark files you modified, retain applicable notices in
distributed source, and carry forward relevant attribution from an upstream
NOTICEfile when distributing a derivative work. These duties come from Apache-2.0, Section 4(opens in a new tab).
For example, if your original starter uses an unchanged MIT library, you can put your original files under the Kurodyne Commercial License while preserving the library's MIT terms and notices. Buyers retain the rights MIT grants them for that library.
Copyleft licenses require specified material to remain available under the same license when you share it, and some impose source-sharing duties for network use. The scope depends on the license, its version, any exceptions, and how you combine the code.
- GPL-3.0-only: When you distribute a modified or combined work covered by this license, the whole covered work must use it. Recipients retain redistribution rights, and distributing compiled code requires providing corresponding source through a permitted method. See GPL-3.0-only, Sections 5, 6, and 10(opens in a new tab).
- AGPL-3.0-only: Alongside distribution duties, a modified covered program must offer its corresponding source at no charge to users who interact with it over a network, if it supports that interaction. Hosted access can therefore carry obligations even without a download. See AGPL-3.0-only, Section 13(opens in a new tab).
- LGPL-3.0-only: An application can use a covered library under different terms if the arrangement meets the license's conditions. These include notices, license copies, applicable library source, a way to relink with or use a modified library, and permission to reverse engineer for debugging library modifications. Read LGPL-3.0-only, Section 4(opens in a new tab) for the permitted approaches.
- MPL-2.0: Covered source files, including your changes to them, remain under MPL-2.0. A larger work can use different terms for separate files outside that coverage, while preserving access to the covered source and its notices. See MPL-2.0, Section 3(opens in a new tab).
These scopes differ. GPL-3.0-only also distinguishes a combined program from an aggregate of separate, independent works; merely distributing independent programs together doesn't put them all under GPL-3.0-only. Separate folders alone don't establish that the programs are independent.
The version 3 examples describe that version's terms. A component may instead permit later versions,
identified as GPL-3.0-or-later, AGPL-3.0-or-later, or LGPL-3.0-or-later. The -only and -or-later
identifiers record different grants; the component's notice determines which applies.
Fonts, icons, images, and other assets keep their own license conditions, including attribution and redistribution limits. Common examples include:
- CC-BY-4.0: Retain the supplied creator credit, copyright, license, and disclaimer notices, and the source link where reasonably practicable. Identify modifications, preserve prior modification notices, and provide the license text or link. See CC-BY-4.0, Section 3(opens in a new tab).
- OFL-1.1: Include the font's copyright notice and license. The font stays under that license; modified fonts must also respect any Reserved Font Names. It allows bundling fonts with software but prohibits selling the font by itself. See the OFL-1.1 conditions(opens in a new tab).
Paid assets may permit use in a finished website without permitting redistribution of editable files in a starter or template. CC-BY-NC-4.0(opens in a new tab) doesn't grant commercial-use rights. Attribution alone doesn't supply missing permission.
A conflict arises when copyleft requires rights for your combined work that the Kurodyne Commercial License restricts. Kurodyne lets buyers use and modify seller-owned material. Buyers may distribute and sell finished end products only when they don't expose that material for reuse or function as a competing substitute for the purchased product. Sharing or reselling the seller-owned material as reusable source or templates is restricted. Read the Commercial License restrictions.
For example, GPL-3.0-only, Section 5(opens in a new tab) requires a starter derived from a covered app to remain under GPL-3.0-only. Read together, these terms mean you can't put that work under Kurodyne's restrictions on reusable source. Shipping readable source alone doesn't resolve the conflict.
The Commercial License third-party material clause preserves a component's own license. It doesn't give you permission to restrict rights that copyleft requires for the combined work. A separately licensed component can fit when its obligations and the rights promised for your own material remain compatible.
Check the actual code and assets you deliver, plus the dependencies buyers need to install or use. Start with your dependency manifests and lockfiles, then inspect the package and its built output. Include dependencies of dependencies, copied snippets, vendored code, fonts, icons, images, and templates. Record the exact versions and licenses; a project's current license may differ from the one attached to the version you ship.
A development tool and code included in your product play different roles. Check whether the tool's output contains licensed material. Having buyers install a dependency separately doesn't by itself establish that the resulting combination is compatible.
Publicly visible code isn't automatically licensed for reuse. GitHub's repository licensing guidance(opens in a new tab) explains that ordinary copyright restrictions apply when no license is provided. A license that prohibits commercial use doesn't meet the Open Source Definition(opens in a new tab). For missing or restrictive terms, obtain the necessary permission or replace the material before selling it.
For a package containing third-party material, use THIRD_PARTY_NOTICES.md to identify the
components, their licenses, and the obligations that apply. The
Kurodyne seller terms require applicable source links, license texts, notices,
and buyer obligations.
For each component, record:
- Its name, version, source link, and location in your product
- Its SPDX license identifier when available, with the required full license text in the package
- The original copyright and attribution notices, including applicable upstream
NOTICEcontent - Any modifications and the notices the license requires for those changes
- Any source availability, relinking, attribution, or redistribution duties buyers must follow, with the files or instructions needed to fulfill them
You can keep license texts in separate files and identify their locations in the notices file. Keep notices in source files wherever the license requires them. A list of license names or links alone doesn't replace required license copies, source delivery, or other obligations.
Material third-party obligations must be visible to buyers before purchase, including for a product without a package. Follow Describe Buyer Obligations Before Purchase for the listing and delivery steps.
Follow Third-Party Notices for Code You Sell for a worked example and the steps to check your final package.
Replace or remove the component, or obtain a separate license that permits the distribution and buyer uses your product promises. If a project offers a commercial license, check that it covers reselling source in a starter and downstream buyer use; permission to run it in your own business may be narrower.
A README, listing, or bundled license file can't override Kurodyne's standard license or add seller-specific restrictions. The Commercial License seller authority and warranty clause sets that rule. Resolve incompatible terms before submitting the product.
Once your components, notices, and public requirements are ready, publish your first product.