I’m working on a client library in Typescript that’s a re-implementation and extension of another client library. The reason for this is so the client library can be licensed the same as the rest of the project (MIT) since the original library is AGPL. I’m good with that part, and it’s just background info.

The question I have is how to handle the type declarations. In order to be a drop-in replacement, the client code would expect the library’s exported types and their names to be the same.

I know header files are considered non-copyright-able (Oracle v Google), so it seems to me that the type declarations would also fall under that umbrella. I’ve not found anything definitive (yet) that covers those, but they seem analogous.

Is that a safe assumption?

  • @theit8514
    link
    510 months ago

    IANAL, but this is likely a legal gray area regarding software licenses, especially if you read the AGPL code prior to writing your library. Companies that do this sort of thing professionally have a/b teams that don’t speak to each other (one reads and generates design documents, the other uses those design documents to write a new library) to prevent a lawsuit for violating licensing terms. They can claim that the developers writing the library didn’t copy any code from the source library.

    As for the typedef, it’s most likely considered a public definition document. I would think it would be like a public C# interface, where it’s only the method declarations and expected parameters and the actual implementation is not included at all.

    If you’re considering publishing this or using it commercially you should definitely consult a lawyer that specializes in copyright.

    • Admiral PatrickOP
      link
      fedilink
      English
      110 months ago

      Thanks.

      As for the typedef, it’s most likely considered a public definition document.

      That was my take on it as well, but haven’t been able to find any official word. For the other point, I’ll raise it with the project maintainer, but I think our solution should be fine - there’s only so many ways to call an API, and we’ve implemented the mechanics completely differently