3

I have taken a small chunk of open-source code, around a hundred lines, and found that for whatever reason, I have modified it so drastically that my end result has essentially no resemblance to the original. Maybe a line or two, and a few variable names, are carried over, but the diff is just one or more big chunks of - followed by big chunks of +.

If I'm now distributing my code, it seems clear to me that I should globally credit the original author for providing a foundation, and include the license under which I acquired the code. I'm wondering what my responsibilities in the social or technical dimensions are to mark specific changes, though. Am I rudely misrepresenting the original author's work when I say that mine is derived from it without pointing out the particular lines that were carried over? Is it helpful for another coder looking at my version if I include comments annotating what I've kept and why?

I've used someone else's code as a starting point, taking primarily the ideas and not the substance. Ignoring any legal aspects,* what kind of precise, targeted change documentation should I ideally provide?

What is proper etiquette for releasing a complete rewrite of an existing project? is closely related, but I've already chosen option 1. Best practices when forking code base is also related but doesn't address the specificity of attribution.

*Various aspects of which have already been covered here.

Community
  • 1
jscs
  • 828
  • 9
  • 17
  • what exactly is 'for whatever reason'? i think answering this in your mind will clarify your next step. – Andyz Smith Oct 04 '13 at 23:53
  • @AndyzSmith: In the particular case that prompted this question, it was speed. I think I ended up lowering the time complexity of the procedure, which meant using different framework classes, altered loop conditions, and so on. But I was interested in the general case, if that exists. – jscs Oct 05 '13 at 06:01
  • so this leads me to suggest: so yours is different, with different module dependencies, different performance characteristics, possibly superior, possible inferior in cerain respects. this should guide you as to whether to: replace, inherit from, use as a replacable strategy for, call the original, etc. IE - you may want to leave the original, add a template pattern and allow future implementors to choose the best option for them. you could slightly modify the original to fit a confirming interface that both routines would subscribe to. – Andyz Smith Oct 05 '13 at 07:15
  • Note that these suggestions are part of a more general case. EG if your code signifiantly changed the 'intent', inputs, and outputs, conceptual basis of the code, your options are quite different. even though you 'started' from the same place and 'derived' your code from the same original. the mechanism and intent of your manipulations and resulting deviation from the base-line of should guide your approach to integration – Andyz Smith Oct 05 '13 at 07:22
  • That's useful advice, @AndyzSmith. What could you suggest for a case where I'm not intending to re-integrate my revisions? The code that prompted this is a stand-alone method -- the hundred or so lines are all there are to either version. – jscs Oct 08 '13 at 07:42
  • i can't think of anything that is actually stand alone. Even things that seem like they do one thing, are almost universally part of some larger codebase, *or* process flow. if it's a data process step i think you should document the essential similarities, briefly, as to not overdo it. just show the input and outputs. but then, try to elaborate on why your is different, what possible impact on the bugginess, the flexibility, extensibility, the tolerance for out-of-range inputs, are different. – Andyz Smith Oct 08 '13 at 14:06
  • if this is kind of infrastructure function and you don't intend to integrate your code as a new strategy into the baeline, you may be a little disconnected from the base. EG, you know yours can always be swapped in to replace the original, but you don't want to burden the original project with more 'stuff'. But actually swapping it in, is left as an exercise for others. you could publish your piece as a separate file, and have conditional cmpilation or maybe just put a bracketing comment around it so as to not break the build. but to an astute reader, yours can be trivilially swapped in. – Andyz Smith Oct 08 '13 at 14:10

1 Answers1

2

Your basic obligation is to follow the original author's license terms. But beyond that, it's a good idea to mark off the section with comments that indicate the original source of the code. That allows others to follow the chain back to its origin, and bugs in one might be present in the other.

That said, there are many examples of open source or free software where this isn't the practice. In fact, the larger the project, the less likely it is that you'll find such micro-attributions.

Ross Patterson
  • 10,277
  • 34
  • 43