Open source software is software distributed under a licence that lets anyone read, modify and redistribute its source code. That licence hands the software over as is, and it leaves updates and the ownership of the application built on top to the proposal and the contract. Vipkurum’s question cropping tool runs every kind of part in one chain: open source libraries, an outside provider’s language model and code written for the job.
What is open source software: code you can read, under a licence that permits it
A proposal can promise that the code will be open to you, or it can say the system is built on open source. The first is an access promise and may be perfectly honest; the second names a licence, and that licence has a text you can read. The difference comes from the definition. Software counts as open source when its licence grants access to the source code together with the right to modify and redistribute it; being able to see the code is not enough on its own. The Open Source Initiative, the body that maintains the definition, opens its own text with the same point: “open source doesn’t just mean access to the source code.”
Code you can read but may not change or pass on is visible, and that is all it is; the industry sometimes calls this source-available software. The Initiative is blunt about the label. Only software under a licence it has approved should be called open source, and to anyone hoping to use the name without one, its answer is “please don’t do that.” Visibility is a precondition of openness, which is exactly why the two are so easy to confuse.
What, then, is the source code the licence is about? The definition calls it the preferred form in which a programmer would modify the program. It is human-readable text; the program your computer runs is produced from it. Code that has been deliberately obscured does not count, and the source has to be distributable alongside the compiled form. The definition’s unit is the version a person can change, and the rest of this article follows from keeping access and permission apart.
Open source does not mean free of charge
Where does the money go when a component carries no licence fee? Nowhere new: someone still installs it, hosts it, maintains it and adapts it to your business, and those are the separate jobs where the cost in your proposal actually sits. The Open Source Initiative’s FAQ says as much when it explains how anyone earns a living from code everybody may sell. Its list is selling assurances, customisation and maintenance.
Selling is allowed, too. A licence says what you may do with the code and nothing about its price, and the definition goes further than silence: a licence that stops anyone from selling the software, or from giving it away, fails it. Asked whether you may sell a program you did not write, the same FAQ gives a plain yes, adding that depending on the licence you probably cannot stop your customers from selling it in turn. The reverse case exists as well, since plenty of closed software is handed out at no charge. Price and openness are separate axes. Much of the muddle comes from the English word free, which can mean freedom or only that no money changes hands, an ambiguity the FAQ names directly; in a proposal, free software and open source tend to sit side by side, and neither phrase is about the bill.
Nor does an open framework make the question of upkeep go away. Our guide to custom software development cost takes up whether the technology choice changes the price, and its answer points elsewhere: the choice shapes who can keep the system running after launch.
What the licence grants: reading, changing and redistributing, each on the licence’s own terms
A proposal that mentions open source technologies is describing a stack of separate licences, one per component, rather than a single agreement. Components sitting in the same system can each carry a different text. Laravel’s licence file in its repository is the MIT text, Node.js ships under a licence in the same permissive shape, and Python is distributed under its own foundation’s licence, with documentation stating that all Python releases are open source.
What separates those licences is not the rights. Every one of them lets you read, change and redistribute; they differ in the condition attached to redistribution, which is either keeping the copyright notice or releasing derived work under the same licence. At the permissive end sits MIT. Anyone who obtains a copy may, free of charge, use, copy, modify, merge, publish, distribute, sublicense and sell the software, provided the copyright notice and the permission notice travel with every copy or substantial portion. Reciprocal licences, usually called copyleft, grant the same freedoms on a heavier condition: change the work and distribute it, and the result goes out under the same licence, with its source. The GNU General Public License describes this as passing on to recipients the same freedoms you received and licensing the entire work, as a whole, under its terms. Most copyleft licences are open source, the Initiative notes, but not all open source licences are copyleft.
The condition lives in the component’s own licence text, and that text can change between versions. OpenCV, the image processing library, says on its licence page that newer releases are licensed under Apache and older ones under a BSD licence. A component’s name is therefore half an answer; the version in your stack is a question of its own and deserves its own line on a handover list.
Which licence suits your business is not something this article will try to say. It can say where to look: the licence file in the component’s repository, for the version you actually run.
What the licence does not give you: updates, support, or anything beyond “as is”
Open source components, the usual reply goes, are kept up to date by their community. A community can indeed publish a new release, but that is a different event from the copy running in your system being updated, and the licence explains why nobody else is bound to close the gap. Common open source licences hand the software over as is: the authors owe no update, no support and no fix, and the text disclaims fitness for any particular purpose. The MIT text provides the software “as is” and states that its authors cannot be held liable for any claim; the GNU General Public License disclaims responsibility for the program as far as the applicable law allows; the Apache and Python licences carry the same “as is” wording.
Read MIT from top to bottom and no clause obliges anyone to update the code, answer a question or fix a fault; a disclaimer stands where such a clause would be. Assurance and maintenance, in other words, do not arrive with the licence; they are work someone sells or takes on separately, and until a name is written against it, nobody has.
So the work of bringing a release into your system, checking it against the parts that already work and sometimes deciding to wait falls to whoever maintains the system. Each open part of a stack is a maintenance line the licence leaves uncovered. That is why, on KGM SsangYong’s corporate site, the application framework and the front-end set were left alone. The site is looked after by a team on the brand’s side, and adding a component that team did not know would have tied its upkeep to an outside party. The article on who maintains software after launch follows how a choice of tools becomes a maintenance decision.
Paid support and security follow the same logic. Some companies sell an open source product with a support contract, and the licence underneath still hands the code over as is; the assurance comes from the contract signed next to it, never from the licence. As for whether open source is secure, a licence that will not even promise the software suits a particular purpose is not promising that anyone checked it. Public code makes a review possible without meaning one has happened on your behalf: a review exists where a person or a firm carried one out, and it has an author you can name. No verdict that open code is safer or less safe than closed code follows from the licence, only the practical step of looking for the review separately.
An application built on an open framework is not itself open source: the contract names the owner
KGM SsangYong’s corporate site shows the arrangement from the inside. The site runs on Laravel, a framework anyone can download under a public licence, and above it sits the application that belongs to the site. When it came to us it was live and working, and the work began by reading its code. Read access to the code is also the one thing asked for on handover day in our takeover work, because an application does not sit in a public repository just because its framework does.
The rule behind that arrangement is short. A framework’s licence covers the framework; who owns the application written on top of it is settled by the signed contract, not by the licence. Laravel is distributed under the permissive MIT text, whose only request is that the framework’s copyright and permission notice stays in the copies; it does not ask for the application on top to be opened up. A reciprocal framework could change that answer, since distributed derived work has to carry the same licence, and the framework’s own licence text is where to read which case applies.
Ownership is answered in the contract, then. Our own Terms of Use do not settle intellectual property on the website at all; they hand its transfer to the contract the two parties sign. What belongs in a website contract covers where that clause sits and how it is worded, and at proposal stage the lines to look for are short: who the intellectual property in the application passes to, and where delivery of the source code is written down. What the contract cannot do is dissolve the licences inside the application. It can assign the application to whoever it names, yet the open components bundled into it keep their notices, because two parties cannot rewrite a licence a third party published; an MIT-licensed library’s notice stays in the copy whoever owns the code around it.
The parts that sit side by side in a system: open source libraries, an outside provider’s service, code written for you
Put a real system on the desk and the parts of a proposal sort themselves. In Vipkurum’s question cropping tool, the code written for the job is what ties everything together: pulling questions off a page, matching the answer key, drafting new questions from samples, keeping the question pool in order. Code of that kind comes with neither a library’s licence nor a provider’s terms, and whose it is gets decided in the contract between the party that commissions it and the party that writes it.
Around that code sit parts of other kinds. OpenCV separates a printed booklet page into its questions, and the Python service doing the image work reaches the Laravel content management side by way of Node.js; each of those names is an open source library or runtime with its licence in its own repository. Matching each answer in the key to the right question, though, is done by Gemini and OpenAI models, and neither sits in the stack as a library. The tool calls them as services. Their code stays with the provider, what comes back is an answer, and you receive no licence text at all, only the provider’s terms of use, so that part does not belong under the open source line of a proposal. What an API is describes this as passing through someone else’s gate, where the far side decides the names and the format.
In the table the kinds sit in rows, with the questions a proposal should answer for each; the examples come from the cropping chain, and the rows are slots for the parts in your own proposal.
| Kind of part | Example in the cropping chain | Can you read and change its code? | Who tracks its versions and updates? | Where permission and ownership are written |
|---|---|---|---|---|
| Open source library or runtime | Python, OpenCV, Node.js and Laravel | Yes; the condition is keeping the notice or releasing derived work under the same licence | Nobody, under the licence; tracking goes on the maintaining team’s line | In the component’s own licence text, which can change between versions |
| An outside provider’s service | Gemini and OpenAI models, called over an API | No; the code stays with the provider | The provider; your side’s job is fitting each answer into your own records | In the provider’s terms of use, and in whose name the account is opened |
| Code written for you | Pulling questions off a page, answer key matching, the question pool | Depends on the contract rather than a licence; at a takeover, read access is the one thing asked for | Whoever the contract’s maintenance line names | In the signed contract; our Terms of Use point intellectual property there |
Kinds can overlap in a single part. An open source product hosted for you by a provider has code anyone may read, yet the copy you use is the provider’s and the provider decides when it is updated, so the library row and the service row apply at once. Subscription software is the extreme case of the service row: the source code is never handed over in the first place, and what you receive at handover sets out what to ask for instead. Whatever the part, once it sits in the right row, who watches it can be read straight off the cells to its right.
What “built with open source technologies” says in a proposal, and what it leaves out
None of the questions below depends on the open source line being in the proposal; a proposal built entirely on closed products raises every one of them. What the line adds is narrow. “Built with open source technologies” tells you which parts carry no licence fee and that their code is public, which is the right the licence grants and nothing beyond it.
It is silent on the rest. Fitness is the gap the licence names outright: it disclaims fitness for any particular purpose, so whether a part suits your work is settled in acceptance, through scenarios picked from the hard parts of the project and closed with a written record, as what to test before accepting software sets out. Version tracking lands on you quietly, because a part handed over as is needs someone to keep it current; that is maintenance, it belongs on the maintenance line with a name beside it, and if the line names nobody the job has stayed with you. Ownership is the easiest to place: the contract’s intellectual property line answers it, and the contract guide mentioned earlier shows where to start looking before anything is signed.
Nearby questions have their own homes: asking outright what was added to the stack is one of the questions to ask a software company, and reading a proposal’s tool list without knowing the tools by name is covered in choosing a software development company.
If you run a system that another team wrote on an open source framework, the project takeover page explains how handover day runs and how the list of parts is kept. On KGM SsangYong’s corporate site every part that entered the stack is recorded on that list by name, and its only new entry is a cache layer.
