Our earlier piece on GPL contamination dealt with the code that comes into your product. This one deals with the code you put out: the SDK you publish so that customers integrate faster, the core you open to build a developer community, the internal tool you release because it is good marketing. The moment a Turkish company publishes source code, it grants a licence to the world, and the licence text decides who may run a competing hosted version, whether contributors’ patents are covered, whether the company can ever take the code closed again, and how the code will be classified when a buyer’s diligence team runs a scan. The choice is between four families: permissive (MIT, BSD, Apache-2.0), weak copyleft (MPL-2.0, LGPL), strong and network copyleft (GPL-3.0, AGPL-3.0), and the source-available licences that are not open source at all (BUSL-1.1, SSPL-1.0, Elastic License 2.0). This article explains what each family gives away and keeps back, how the choice interacts with Turkish copyright law, and how to decide. The canonical texts and SPDX identifiers are collected in our open-source licence reference.
What you are actually granting under Turkish law
Under the Law on Intellectual and Artistic Works No. 5846 (FSEK), software is a protected work (Article 2(1)) and its author holds the economic rights. An open-source licence is, in FSEK terms, a ruhsat: a grant of authority to exercise economic rights without transferring them (Article 48(2)). Article 52 requires such dispositions to be in writing and to list the rights granted individually. The well-drafted licences do this naturally: MIT names the rights to use, copy, modify, merge, publish, distribute, sublicense and sell; Apache-2.0 and the GPL family spell out reproduction, preparation of derivative works, public display, distribution and, for Apache, a patent licence. A home-made “free to use” notice usually does not, which is the first reason to pick a standard text rather than write your own.
Two Turkish features shape the analysis. Moral rights (Articles 14 to 16) stay with the individual authors and cannot be assigned, so the attribution and no-misrepresentation conditions in the licences sit comfortably with Turkish law, but the company must first hold the economic rights it is licensing: an employee’s code passes to the employer under Article 18(2), a founder’s or contractor’s code only by written assignment, as we set out in the IP-into-the-company article. And a licence granted to the world in an open-source text is irrevocable in practice: the texts say so, and FSEK gives no general right to withdraw a licence once granted for consideration or on the terms stated, apart from the narrow withdrawal right in Article 58 where a licensee fails to exercise the rights granted. Releasing under MIT is a one-way door for the version released.
The permissive family: maximum adoption, minimum control
MIT and BSD-2/3-Clause require only that the copyright notice and licence text travel with the code. Apache-2.0 adds three things worth having: an express patent licence from every contributor covering their contributions, a patent-retaliation clause that terminates the patent licence for anyone who brings patent litigation alleging that the code infringes, and a NOTICE-file mechanism for attribution. For an SDK, client library or integration that exists to make your paid product easier to buy, permissive is almost always right: you want the widest use and you are not protecting the code itself, you are protecting the service behind it. The cost is that a competitor may take the code, improve it privately and never share back; if that risk matters, you are not looking for a permissive licence.
Copyleft: keeping derivatives open
MPL-2.0 works at file level: modified files must be published under MPL, but the code can be combined with proprietary files in a larger work. LGPL allows linking from proprietary code while keeping the library itself open. GPL-3.0 requires the whole derivative work to be distributed under GPL when distributed. AGPL-3.0 adds Section 13: a user who modifies the software and lets others interact with it over a network must offer them the source, closing the “SaaS loophole” through which cloud providers ran GPL software without distributing anything. For a company whose product is the code, AGPL is the strongest open-source position available: competitors may use it, but only by publishing their changes. The trade-off is adoption. Many enterprises and most cloud marketplaces refuse AGPL components outright, and a buyer’s diligence scan will flag every AGPL dependency in your own stack as well as your own AGPL releases.
Source-available: open code, closed business
Three licences are widely used by venture-backed companies that want to show their code without giving competitors a free hosted product. Business Source License 1.1, created by MariaDB, publishes the source but prohibits “production use” beyond an Additional Use Grant the licensor defines; on a Change Date that may be no more than four years after each release, the code converts automatically to a Change License the licensor names, typically GPL or Apache. Server Side Public License 1.0, written by MongoDB, is AGPL with a wider Section 13 that requires anyone offering the software as a service to release the source of the entire service stack; the Open Source Initiative declined to approve it. Elastic License 2.0 is a short permissive-style text with three prohibitions: no managed service, no circumventing licence keys, no removing notices. None of the three is “open source” under the Open Source Definition, and saying otherwise in marketing invites a correction from the community and a misdescription problem with customers. What they do offer is a defensible middle: transparency and self-hosting for users, a hosted-service monopoly for the company, and, in the case of BUSL, a promise that the code becomes open source on a fixed schedule.
Contributor agreements and the right to change your mind
If you accept outside contributions, you need the right to relicense the combined work later, for example to move from AGPL to BUSL or to sell the company to a buyer who wants a clean chain of title. Two tools exist. A Contributor License Agreement (CLA) has each contributor assign or broadly license their contribution to the company; under FSEK it must satisfy Article 52 and, for individuals, needs a written signature in a form you can prove. A Developer Certificate of Origin (DCO) is a lighter sign-off in each commit that the contributor has the right to submit the code under the project licence; it does not give the company relicensing rights. Companies that intend to keep commercial control choose a CLA; community projects choose a DCO. Either way, record who contributed what, because the diligence question will be “can you show that every line in this repository is licensed to you?”.
How to decide
Ask three questions in order. Is the code a driver of adoption for a paid product, or the product itself? Adoption drivers go permissive, Apache-2.0 if patents could matter. Is a hosted clone by a well-funded competitor a realistic threat to the product itself? If yes, choose between AGPL-3.0 (open source, community-friendly, enterprise-hostile) and BUSL-1.1 (not open source, enterprise-tolerable, converts later). Do you plan to raise from or sell to parties that will scan the code? Then document the choice, use SPDX identifiers in every file header, keep a licence inventory of your own releases next to the inventory of your dependencies, and be ready to explain why. Two regulatory footnotes belong in that file: the EU Cyber Resilience Act (Regulation (EU) 2024/2847) treats commercially supported open-source software as a product; its vulnerability-reporting duties have applied since 11 September 2026 and the full obligations apply from 11 December 2027, and the AI Act’s open-source exemption has limits that matter if the code is a model rather than a tool.
Can we release under MIT now and switch to BUSL later?
You can change the licence for future versions if you hold all the rights (your own code plus CLA-covered contributions). You cannot revoke the MIT grant for versions already released; anyone may keep using and forking those versions under MIT.
Do we need a Turkish-language licence?
No. FSEK does not require a particular language for a licence, and the standard texts are used in English worldwide. Do not translate them: a translation is a different text, and SPDX identifiers refer to the original.
Is dual licensing still an option?
Yes. Dual licensing (AGPL for the community, a commercial licence for customers who cannot accept AGPL) remains a workable model, provided you hold the rights to license commercially, which again means a CLA for outside contributions.
Related: copyleft · open-source licence obligations · open-source licence reference.
Sources. Law on Intellectual and Artistic Works No. 5846 (Articles 2, 14–16, 18, 48, 52); licence texts via SPDX License List (MIT, BSD-3-Clause, Apache-2.0, MPL-2.0, LGPL-3.0, GPL-3.0, AGPL-3.0, BUSL-1.1, SSPL-1.0, Elastic-2.0); Open Source Initiative, The Open Source Definition; Regulation (EU) 2024/2847 (Cyber Resilience Act). Statute links open the official Turkish texts on mevzuat.gov.tr.
This article is provided for general information only and does not constitute legal advice. Please seek legal support for an assessment of any specific matter.
Author
If this is on your desk
Templates and checklists are free in the Founder Academy; for a specific situation, book a 30-minute intro call.
Founder AcademyBook an intro call