Skip to content

Clarify upstream license: MIT declared but no LICENSE file (matters for sail-alone) #8

Description

@AndreaV-Lsi

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)

  1. 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.
  2. 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.
  3. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    backlogLogged future work item, not yet scheduled

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions