4

There are two libraries under MIT, that do the same thing, each with some pros and cons. I'd like to merge them, effectively reworking the public API, but keeping the underlying logic (code). The resulting library should be part of my framework that is currently licensed under apache 2.0.

  • Can I license the resulting library under apache 2.0 or do I have to keep it MIT?
  • Is there any problem with rebranding it as new product?
  • Where should I keep the reference to original code? AUTHORS file in repository? Does it have to be somehow imprinted in the compiled assembly?
8

Can I license the resulting library under apache 2.0 or do I have to keep it MIT?

The MIT license is a permissive license which allows relicensing under other license terms as long as the original MIT copyright message is retained.

Is there any problem with rebranding it as new product?

No, the MIT license puts no further conditions besides the copyright message. Many (but not necessary all) open source products prefer to rebrand a fork as a new product to avoid confusion, as long as it doesn't actively try to hide its roots.

Where should I keep the reference to original code? AUTHORS file in repository? Does it have to be somehow imprinted in the compiled assembly?

This is intentionally left vague in most software licenses to make sure it is applicable to a wide range of possible software products.

Common practice is to put any 3rd party copyright notices wherever you put your own. When you just have a COPYRIGHT or LICENSE text file for your own license terms, you would append any 3rd party licenses below it. If you have an elaborate credits dialog or about screen (unlikely in case of a library), you would also use it to credit the 3rd party software.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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