Help with GitHub

[vanarp]

After seeing Minstall and Lowendscript like scripts hosted on GitHub, I too feel like using it for my script collection / own scripts if any. I have no prior experience with GitHub or Git and so here I seek your help.

Few quick questions:

- Are all repositories accessible on GitHub considered to be Open Source code?

- Can I copy pieces of code from others' repositories and paste into my own?

- What kind of licensing/attribution should be mentioned when I copy code from others?

Also it would be great if you can share any thing about GitHub that you learned the hard way and any best practices you came across.

 

[wdq]

- Are all repositories accessible on GitHub considered to be Open Source code?

Sort of. All public repositories have source that anyone can view and edit to suit their needs. However there are private repositories. Even the public ones might have specific licensing restrictions stating what you can and can't do with the code.

- Can I copy pieces of code from others' repositories and paste into my own?

It really depends on the licensing terms of the project. There are different licenses like Apache, GPL, and MIT. With some you have to keep the same license in your code. With others you can really do anything, even make closed source commercial applications.

- What kind of licensing/attribution should be mentioned when I copy code from others?

It's all up to the license. 

http://opensource.org/licenses

 

[acd]

- Are all repositories accessible on GitHub considered to be Open Source code?

No. Repositories on GitHub are licensed as listed in their source files; No additional license is compulsory from GitHub, even for public repositories, save that other members can use the "fork" feature on the website. No listed license == No license (ie, no redistribution, no compilation--a derivative work transformation, no copying, etc.)

- Can I copy pieces of code from others' repositories and paste into my own?

You can fork other repos into your own account. If the license allows it, you can even change the code you forked.

Recommendations/best practices:

• Even if the license does not require attribution (wtfpl, et.al.) you should attribute and comment on where you got it, just in case you need to update it in the future. It's also good form to not take credit for other people's work and conversely take blame for their mistakes.
• Check the pull request list for un-merged pull reqs. after forking a repository. They may contain features or bug fixes you want to incorporate that the repository owner was too lazy or just unwilling to merge (or wants other updates, like doco fixes before merging).
• Before issuing a pull request, make sure someone else hasn't already made a similar fix and request. That happens surprisingly often.
• Test code before checking it in so someone cloning doesn't get a buggy version and curse your family for 3 generations.
• Version control (and dev cycles) works best when you make many small-to-medium sized check-ins that are individually testable as working. This makes it easier to validate your code and find bugs and if bugs are found later, version control comments may give you a hint as to why you did this or that silly thing. Which leads to...
• Leave useful commit comments. You can leave silly ones too, those are fun, but definitely explain what you did and why.

best regards,

-tw