Open Source Policy

Philosophy

Jesus once told his disciples, “freely you have received; freely give”. At Kwila Development, we are uniquely positioned to live out this principle through our day-to-day work. Our business (and most other businesses in our industry, whether they want to admit it or not) is built on foundational software that was written and freely shared by open source contributors from across the globe. Without these contributors and the countless hours they put in, we would have no chance at building a profitable business. Everything would have to be built from the ground-up, or we would have to rely on expensive proprietary solutions. Given that we are benefiting immensely from all of this work freely shared, it would be ridiculous to consider any other option than to publish at least a portion of our code under open source licenses.

It is our goal to operate on an “open source by default” policy. This is not the same as open source for everything. Some code will have a very clear need to be proprietary. It would be unethical for us to share the sensitive business logic that gives our customers their competitive advantage. On the other hand, we will write plenty of code that has no such sensitive nature. Things like infrastructure tooling, UI frameworks, backend systems, and CLI tools could and should be freely published under open source licenses. Our core product is not the code we write. Our core product is the service we do - the ability to provide each and every customer with the high-quality custom-tailored software solution they deserve.

Decision Framework

Now that we have clearly described our open source philosophy, how do we determine which code should be open source and which should be proprietary?

By default, the code for each new project is published on our git forge with an MIT license from day one. The customer agreement for each project should clearly communicate to the customer that we retain ownership of the code. The customer agreement should also clearly include a link to our open source policy, hosted on our git forge. The customer benefits in several ways from relying on open source software: they avoid vendor lock-in, and they potentially benefit from community contributions that they don’t have to pay for.

If the client prefers to have an entirely proprietary codebase, they can choose to pay a premium to retain ownership of their project’s code. This premium is set by Kwila management. We will host the code in a private repository on our git forge and give the customer access to the code. We can only guarantee access to the private repository for as long as the customer maintains a support contract with us. At the end of the support contract, we will provide a final copy of the code as-is. The customer agreement should clearly communicate the drawbacks of this approach: the customer may end up with vendor lock-in where we are the only ones who understand how their code works, and they will not benefit from community contributions.

Regardless the project, proprietary business logic and trade secrets must be appropriately protected. What should be regarded as proprietary is determined after careful discussion with the customer. There must be a clear common understanding between the customer, management, and our engineers before we begin work on any project. For example, we may develop inventory software for a customer who has a proprietary process for determining how things should be organized. The inventory software itself should be open source, but the code for the proprietary organization process should be handled in a separate private repository without an open source license. We can not open source our customer’s “secret sauce”.

Technical Guidelines

What follows are a few guidelines for how our engineers should handle open source.

For each new project, the kickoff meeting should clearly cover which code will be open source and which code will be proprietary. If anything is unclear, an engineer should ask management for guidance and avoid making assumptions.

For open source projects, they should be created as public git repositories with an open source MIT license. If a project is based on an existing open source project with a copyleft license (for example, GPL), we will use an appropriate license that complies with those requirements. The LICENSE file should list Kwila Development as the copyright holder.

For proprietary projects, they should be created as private git repositories. It is important to make sure the LICENSE file lists the customer as the copyright holder and clearly states that the project is proprietary. The git repository must also include read access to at least one person at the customer. Management will communicate which people at the customer need to be given access to the repository.

From time to time, it will be beneficial to contribute to open source projects which we do not own. For example, we might need to improve a project we rely on as a dependency or for infrastructure in order to unblock our work for a customer. In these cases our engineers have full autonomy to choose how and when to make these contributions. The important thing is clear communication. Engineers should mention open source contributions in the dev standup meetings, log it in their work logs, and use their Kwila email on their commits. This ensures we have a clear record of where company time was spent on contributions to outside projects. Management will provide clear feedback when engineers are spending too much time on outside contributions.

Conclusion

At Kwila Development, we are dedicated to producing high-quality software of all sorts, both open source and proprietary. The open source ethos is core to our values and identity. We are and always will be anti vendor lock-in.

Have any questions? Please contact us at opensource@kwila.dev.