How should I use someone else's code posted on GitHub?

user_14091616 0
Viewed 4798

I'm working on a project that I want to publish on GitHub. This project requires a specific algorithm Algorithm. Every project I have worked on previously has only used my code (plus STL, etc.), but Algorithm can be a pain in the butt to write, so I want to use someone else's. Algorithm is a small subroutine compared to the size of the rest of my code.

I find a GitHub repository that implements Algorithm, but there is a lot of Junk. By Junk, I mean code I don't need. I want to strip away all the Junk from Algorithm and use it, but I'm not sure how to do that. Ideally, Algorithm could be cleaned off and placed seamlessly within my project directory to reduce dependencies for other users of my project.

I don't know the etiquette for using someone else's code. I don't know how to give credit or what the deal is with all these licenses.

It appears to me that I have five options for how to use someone else's implementation of Algorithm.

  1. include the original header that declares Algorithm and all the Junk that comes with it. (Do I copy the header and all of its dependencies into my project directory?)
  2. Create a new header and source file that keeps the implementation Algorithm as-is with all comments and #include the header into my project (leaving out additional functions and classes that may have appeared in the original header).
  3. Modify the code implementing Algorithm to remove the remaining Junk. Remove comments. Change C arrays to std::vectors. Replace pointers with smart pointers. Change thrown exceptions. Remove "options" that my project doesn't need. Change the representation of data to merge everything with my project.
  4. Rewrite Algorithm from scratch, but model it after the existing code, conforming the implementation to my style and making minor performance improvements (nothing that is worth pulling onto the existing repository, however).

What are the rules of etiquette for each of the 4 situations? Where do I put the Algorithm within the project directory? How do I credit someone else's work? How do I credit someone for their modified work (that, for example, removes their original comments)? How do I avoid crediting someone else for work I did (that they may think, hypothetically, uses bad coding practices)? What GitHub features facilitate all this?

Regarding licenses, if using someone's Algorithm to get my code running forces me to publish it with a specific license, can I later implement my own Algorithm and change the licencing? I don't know if I will care to do that, but it would be nice to know.

github c++
1 Answers

In general, when a developer releases code on Github under a specific license, they expect the code to be taken and used elsewhere in accordance to this license. There is no additional burden on you to appease the developer in any way except following the license.

MPL2 is very open to taking the code and incorporating it in another project even of a different license, as long as the licensed file itself (and any changes you make to it) stays licensed under MPL2. MIT license is even more permissive, here you can relicense as you see fit. Note that you still need to follow the attribution clause, citing MIT licence:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

So just keep this header intact. For MPL2 see the FAQ.

If you later choose to remove the code from your project and reimplement the same logic in a clean way, the copyrighted code is gone and so are the license terms.

Now to the best practices:

  1. If you don't see a need for bigger changes in the code, and it doesn't come with lots of baggage, you would include it (mostly) untouched, which gives you the advantage of being able to upgrade the code easily later on. Expect the original implementation to move on, especially regarding bug fixes. Try to profit from them by staying close to the original instead of ending up with a bunch of code that you now have to maintain yourself.

  2. If you have substantial, general improvements to the code in mind, e.g. modernization as you mentioned, consider to give them back in form of a pull request. For this, again, you need to keep the overall structure of the original code intact so the pull request will indeed only contain these improvements. The original author now may choose to benefit from your improvements or not. If they do, we get back to point 1: even while you did significant changes to the code, you can still profit from maintenance by the original author.

  3. If there is a lot of junk involved that is unnecessary to your project and that you feel is a maintenance burden or comes with additional dependencies, or if your changes are both significant and specific to your own implementation so you don't see them being helpful to the original author (or generally see the chances of a successful pull request being slim) then just bite the bullet and fully assimilate the code. This is also the best option when the original project appears 'dead', e.g. no significant commit activity in ages etc.

Obviously there is no general rule as of what option is best so this is supposed to merely guide you with the decision.

Note that there is also a technical consideration of "how" to adopt the code. It may be beneficial for you to maintain a clean copy of the code (as in, self-contained and not part of your bigger project) with your changes in a separate repository which you explicitely forked from the original repository ("upstream") on Github (but you can also do it privately with git itself). This gives you the advantage of git's features regarding keeping track of changes and merging them between upstream and your fork. The source used by your bigger project is your own forked repository, which you may or may not keep in sync with upstream. This fork is also a starting point for any pull requests you may have in mind for upstream.

When you fork a repository on GitHub, the original author is able to see your fork and therefore that their work is being used. Also if you find and file bugs or suggest improvements you are giving positive feedback to the author. Finally, a pull request is the crown jewel of showing your appreciation. But as a developer who publishes stuff on GitHub, it is never my expectation to receive any of it.

ypnos_219740
Related