Go is using a modified BSD license. I would like to use the same license for some projects, most parts / libraries will be published under an open source license, but clients do demand some of the business logic to be closed. There might be a possibility that a future client needs a copy of the software (distribution).

I found this small Go library which almost fitted some requirements. In order to can really use it, I've created a fork on GitHub and re-written most of it's interfacing methods to fit our needs. Then I found out I've been reluctant to check the LICENSE file, which contains the GPLv2. Bummer.

The library, including unit, integration tests and example code is roughly 500 lines. I've modified 100+ lines, but I haven't published them yet.

Now, can I choose to separate the changes I've done into a new project and fill in the blanks by re-writing those parts? There are large parts of the original code I can do without (like examples), so I imagine this is only a few hours of work.

Some methods of the library are so simple and short that for sure my resulting code will look the original in some parts, that would be unavoidable. Practically those short functions are alias functions for an imported Go standard library, already licensed under modified BSD. The rest I will implement it my own way, so I will not be copy-typing the original library.

1 Answer 1


Implementing your own software that provides similar functionality is always allowed – when it is an independent implementation (not a derivative work in the sense of copyright) and if that functionality is not patented (likely does not apply here). Copyright doesn't protects ideas, it protects a specific expression of an idea.

However, since you already have deep knowledge of the original library, it is going to be difficult for you to write a re-implementation that is clearly not derivative. The issue is not that some small wrappers might be identical (they might not be copyrightable at all) but that you might subconsciously copy some copyrightable aspects.

To avoid these issues, the gold standard for reimplementations is a clean room reimplementation: one person inspects the original software and writes a specification, and another person who doesn't know the original software takes the spec and implements it. This is not necessary, but it shows beyond reasonable doubt that nothing was copied.

In the end, this is a matter of risk management: how do you weigh the risks that your reimplementation may look derivative and that therefore the copyright holders of the GPL version might take steps to enforce their license against you? How would these risks impact your clients?

  • The "clean room" approach is not one I thought of. That would be a very good solution. Thanks!
    – Tim
    Feb 2, 2019 at 21:52
  • @Tim The technique has a Wikipedia article! en.wikipedia.org/wiki/Clean_room_design But it's mostly applicable when you have a high risk of being sued, and want to prepare a strong defense. For a few hundred lines of Go, that risk may be very small and not worth the effort. If you trust yourself to create a non-derivative reimplementation, I'd just do that.
    – amon
    Feb 2, 2019 at 22:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.