choosealicense.com
choosealicense.com copied to clipboard
github
Describe best practice if including code from other projects
As GitHub obviously encourages, some projects will include code from other projects. What is the best thing to do in that situation? Should the originator's copyright info in their license be added to the license file in the new project? Something like this? e.g.
The MIT License (MIT)
Copyright (c) 2014 <author of new code and the project this license file is part of>
Copyright (c) 2013 <author of included code>
Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction...
+1. I'd like to know this myself, specifically how authors of abandoned works should be attributed in derived and heavily-modified codebases.
@pmackay @Alhadis for MIT (and most open source licenses) you have to keep copyright notices and copies of licenses. This is true whether a project is "abandoned" (assume you mean unmaintained) or not.
You CAN add your own copyright notice (and even license, if the original license is compatible), but you don't have to.
This explains various patterns you see, like
Copyright X LICENSE A
and
Copyright X and contributors LICENSE A
and
Copyright X Copyright Y LICENSE A
and
Copyright X LICENSE A Copyright Y LICENSE B
If there are copyright notices in file headers it's a very good idea to keep those as well.
You CAN further annotate a LICENSE file with information about what files are taken from what projects. You see this ad hoc in many older or larger projects, eg https://github.com/nodejs/node/blob/master/LICENSE. You can even make these annotations machine readable with SPDX, though this is not yet a common practice.
I've kept this issue because I agree it would be good to have some very easily understandable information about using others' open source licensed code on choosealicense.com. No great idea of how to do this or existing materials to use have struck me yet. I'll keep this open...suggestions welcome.
@mlinksva Okay, different question, and I'm not sure if this is the place for it... but since you're site staff, I have an impetus to ask:
Would GitHub allow the transfer of my repositories to a willing maintainer if I dropped dead, if I explicitly stated it in a will, or something?
I know, stupid question. But this PR got me thinking, and I realised how much I'd hate for a grammar I'd worked so hard on falling beyond the ability of somebody to keep it going. I'm somewhat of a hermit, so I have no friends or "next of kin" I can just offer my projects to if I suddenly cark it.
FYI, I've written two grammars that're being used to provide syntax highlighting on GitHub:
- https://github.com/Alhadis/language-apl
- https://github.com/Alhadis/language-maxscript
There's another grammar pending, and I'm busy working on yet another (probably the most detailed grammar I've written to date). These are also Atom packages, so I'd prefer they be transferred instead of forked...
(Sorry for the awkward question, but I'm kind of a forward-thinker...)
@Alhadis definitely good to think ahead and not a stupid question at all. It is a bit out of scope for this issue and this repo. You should submit your question at https://github.com/contact.
Now my unsolicited and probably obvious advice that doesn't directly answer your question:
- Make sure your projects are unambiguously released under an open source license. Yes there will be some friction of migrating users (such as package collections) to a fork if the new maintainers can't take over your repo, but if a project in question is valuable to its users, that's a relatively small hurdle, compared to additionally having to find and ask permission of heirs if the project does not have a license.
- Consider adding collaborators when you find people who are interested and able. After all you might just get tired of maintaining a project long before you drop dead.
I like having a file called ACKNOWLEDGMENTS(.txt|.md)? and it is what is mentioned in special-files-in-repository-root, but I have not really seen standardization on this front (NOTICE, ThirdPartyLicences.txt, etc.) and that repo used to rank higher than it does now in search results.
