Problem
Upstream AndyEverything/openproject-mcp-server declares MIT three times (README prose,
pyproject.toml license = {text = "MIT"}, and the License :: OSI Approved :: MIT License
classifier) but has no LICENSE file — the README's [LICENSE](LICENSE) link is dead, and
GitHub detects no license (licenseInfo: null). The MIT text, copyright holder/year line, and
warranty disclaimer are therefore all absent.
This is an ambiguity (intent-without-execution) that matters for our "sail alone" option: if we
maintain/deploy the fork independently, we want the base code's license to be unambiguous.
Plan (in order)
- Internal LSI risk decision first (the real gate). Whether the thrice-declared MIT is good
enough to invest in/deploy the fork is an LSI legal/management call — the maintainer cannot give
legal certainty either way. Their adding a LICENSE strengthens the position but does not gate us.
→ TODO: get LSI sign-off on relying on the declared MIT.
- Raise with the maintainer opportunistically, helpfully — not as a cold demand. Preferred:
offer a LICENSE PR (does the work for them). Time it to ride on goodwill once
AndyEverything/openproject-mcp-server#22 gets engagement, rather than competing with it. Avoid a
blunt standalone "you have no license" issue.
- If we sail alone: proceed on the documented basis of the repeated MIT declarations, add LSI's
own copyright/MIT notice for our contributions, and record LSI's risk sign-off.
Ready-to-send LICENSE PR draft (do NOT post until timing is right + user OK)
Suggested message to the maintainer:
Hi! While working on AndyEverything#22 I noticed the README links a LICENSE file
([LICENSE](LICENSE)) that isn't in the repo, and GitHub doesn't detect a license even though the
README and pyproject.toml both say MIT. Happy to open a tiny PR adding the standard MIT LICENSE
text so the declared license is explicit — could you confirm the copyright holder/year you'd like
on it (e.g. "Copyright (c) 2024 <your name/handle>")? No worries if you'd rather add it yourself.
Proposed LICENSE file content (fill holder/year on confirmation):
MIT License
Copyright (c) [YEAR] [COPYRIGHT HOLDER]
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, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
Acceptance criteria
- LSI has recorded a risk decision on relying on the declared MIT.
- Either upstream adds a LICENSE file (clarifying MIT), or — if we sail alone — the fork carries an
explicit license/notice and LSI's documented basis.
Type: legal/process. Related: #1, upstream AndyEverything#22. Label: backlog.
Problem
Upstream
AndyEverything/openproject-mcp-serverdeclares MIT three times (README prose,pyproject.tomllicense = {text = "MIT"}, and theLicense :: OSI Approved :: MIT Licenseclassifier) but has no
LICENSEfile — the README's[LICENSE](LICENSE)link is dead, andGitHub detects no license (
licenseInfo: null). The MIT text, copyright holder/year line, andwarranty disclaimer are therefore all absent.
This is an ambiguity (intent-without-execution) that matters for our "sail alone" option: if we
maintain/deploy the fork independently, we want the base code's license to be unambiguous.
Plan (in order)
enough to invest in/deploy the fork is an LSI legal/management call — the maintainer cannot give
legal certainty either way. Their adding a LICENSE strengthens the position but does not gate us.
→ TODO: get LSI sign-off on relying on the declared MIT.
offer a LICENSE PR (does the work for them). Time it to ride on goodwill once
AndyEverything/openproject-mcp-server#22gets engagement, rather than competing with it. Avoid ablunt standalone "you have no license" issue.
own copyright/MIT notice for our contributions, and record LSI's risk sign-off.
Ready-to-send LICENSE PR draft (do NOT post until timing is right + user OK)
Suggested message to the maintainer:
Proposed
LICENSEfile content (fill holder/year on confirmation):Acceptance criteria
explicit license/notice and LSI's documented basis.
Type: legal/process. Related: #1, upstream AndyEverything#22. Label: backlog.