How to reuse code in GitHub without passing other code as mine?

Question

I'm doing my first real project on Github (in Python) and I'm using functions from two other repos (which I'll call foo and bar) as well as rewriting some of their modules.

I have two options.

• Option 1: separate my code and theirs, rewrite what I need and import the rest.

Structure on my computer:

.
├── foo
├── bar
└── mypackage

Structure on Github (When someone clones my repo then they need to clone foo and bar as well)

.
└── mypackage

• Option 2: mix my code and theirs, such that it may be indistiguishable that I used another code.

Structure on my computer and on Github:

.
└── mypackage

I feel like option 2 is simpler since my code is standalone, but I also feel like it does not make clear what I reused and what I coded myself.

Of course in both options I would mention foo and bar in my README. Foo has licence Apache 2.0 and bar has licence CC BY-NC-SA 4.0.

So my question is: which option should I choose?

Answer 1

You have actually a 3rd possibility to structure your code:

project root
  +--- your code
  +-+- 3rd party
    |--- project A
    |--- project B

This form is used in several projects where files from 3rd-party libraries are included for simplification or where maybe some small custom adjustments to interfaces need be done or a very specific version is needed to not deal with varying ABI / API or similar.

Another option is to create a sub-project which contains your 3rd-party dependencies. That has the advantage that it is more clearly separated, and the disadvantage that one has to clone at least two repositories. There are many examples for this approach, too.

You might (and possibly should) consider to add the 3rd-party stuff as sub-modules, if they remain unmodified. See this answer in another thread.

Answer 2

I like this question and how in a lot of fields in Computer Science the answer depends.

I put my idea of a "real project" and how to customize other projects for your feature.

Before all, the first question is "What is the Object of your project?", in other words, is it a real project because you are starting to work with passion or it is a real project because your objective is to have a community that works with your project and supports your project?

If you want to create a project to have a community, I suggest you Option one, in particular, create your custom fork and make the change in this fork, and add this fork as a submodule.

In this case, you can offer customization of the library for another user, you can maintain the code update with the main branch of the library. However, this required a lot of work to support libraries. The last but not least, I suggest this option if you have the intention to maintain the project in the time, in other words, if you are ready to fix the bug and resolve community issues.

If your objective is to create a real project but don't work to maintain it or you don't care about the library (that you are forking) bugs, option two is easier to implement but I don't preferer this solution because it is unclear. In my opinion, it's not good for future contributors that need to learn your source code, because if inside the project there are different projects together it is difficult to understand for new people.

The short answer is, depend on the object of your project, there is not a good way to do this operation without knowing the goal, but there is a responsible way to do that if you believe in opensource and believe in your code that is developing I think that the options one is the good way to start.