-
-
Notifications
You must be signed in to change notification settings - Fork 244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Everything an open source maintainer needs to know about open source licensing #443
Comments
Q: If I fork a project (in the traditional sense as opposed to the GitHub sense), what is the expectation for me to include in the copyright/license/readme/other documentation? Do I add my name to the original copyright line in the license? Do I include some note in the README that the code originated somewhere else? Something else? All of the above? |
Q: Why do end-user applications like Atom have huge license documents that list every component and sub-component and sub-sub-component but other times (most notably when writing a library) only the license for the actual component is included? How do I know when to do which? |
Needs seems too strong. Disproved by existence of successful open source maintainers who know zero or less about most of the topics listed. Maybe might need? 😁 |
WIP over in #445. |
❤️
Kinda covered that. TL;DR: It depends on the particular licenses requirements. Some e.g., require documenting changes (which I argue a Git history is sufficient to do).
Again, depends on the license. Some require that all derivative works require a copy of the upstream project's license, others require only copyright, others nothing.
👍 |
Like https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/, but less government focused.
The text was updated successfully, but these errors were encountered: