4 ms·

The quibble about GitHub not correctly handling files named COPYING is spot on. I have some LGPLv3 projects, and whenever possible I put the license into two fi

by kijin 12y ago

The quibble about GitHub not correctly handling files named COPYING is spot on. I have some LGPLv3 projects, and whenever possible I put the license into two files named COPYING (a verbatim copy of GPLv3) and COPYING.LESSER (an addendum that converts GPLv3 into LGPLv3). Because that's what the FSF recommends. I have no idea how GitHub's crawler will interpret this. Maybe it only sees the first file and thinks I'm using GPLv3? Anyway, the whole "scan the repository for anything that looks like a license" approach seems to be misguided from the beginning. What if the license is in a comment at the top of an ordinary source file, as I often do with short licenses like MIT? What if it's just a link to the FSF or opensource.org? What if it's a translation of a popular license into another language, or a link to a translation? What if the only file that contains a license is a library with a different license than what the owner intended? Approximations and second-guesses are good enough if you're just trying to pull some statistics, but open-source licenses have legal implications for everyone involved. Just let me pick a license in the repository settings, not only for new repos but also for existing ones. And if I do so, please display my choice prominently in search results so that nobody will misunderstand my intentions. I don't really care about the API, I want to see the options in the official web interface. You are welcome to throw a warning if you detect something in the repository that seems to contradict my selection. You are welcome to suggest that I add a license file. But they should be suggestions, not prerequisites for GitHub to recognize a license in the first place. The owner, not some half-baked robot, should have ultimate authority over what the license is. Bonus: Forks automatically inherit the license of the original repo, unless the forker explicitly picks a different one. First-time pull requesters are informed that their patches will be licensed under the same license as the repo, and by clicking "Submit", they agree.

ossreality 12y ago
Hear hear. Licensing is serious business and should be an obvious, explicit opt-in.
pjtr 12y ago
I really like your bonus idea. But it's surprising that after you explain how complex licensing scenarios can be you still recommend to force a very inflexible single-license-per-repository model. What about dual licensing? Differently licensed code in the same repository? (e.g. for vendored third party code etc.)
- kijin 12y ago
  Dual licensing is fine, I simply omitted it from my suggestion because it didn't occur to me at the time. As for third-party code included in a repo, I don't think their licenses should be shown prominently on any listing. It's the job of the project maintainer to ensure that all of the licenses for third-party libraries are compatible with the main license(s) for the project, and if possible, enumerate them somewhere in the tree. Most third-party libraries probably have their own GitHub repos anyway.

by kijin 12y ago

ossreality 12y ago

Hear hear. Licensing is serious business and should be an obvious, explicit opt-in.

pjtr 12y ago

I really like your bonus idea. But it's surprising that after you explain how complex licensing scenarios can be you still recommend to force a very inflexible single-license-per-repository model. What about dual licensing? Differently licensed code in the same repository? (e.g. for vendored third party code etc.)

kijin 12y ago
Dual licensing is fine, I simply omitted it from my suggestion because it didn't occur to me at the time. As for third-party code included in a repo, I don't think their licenses should be shown prominently on any listing. It's the job of the project maintainer to ensure that all of the licenses for third-party libraries are compatible with the main license(s) for the project, and if possible, enumerate them somewhere in the tree. Most third-party libraries probably have their own GitHub repos anyway.