5

I'm working on various wrappers for web APIs, these wrappers are released under the Apache-2.0 license. For unit tests, I'm running an embedded web server which serves mock responses. The responses served during unit tests were acquired by manually querying the API and saving the JSON response to a file.

This means I'll have .json files in my repository that are actual responses from production APIs. In most cases, this doesn't matter as it contains arbitrary data, and so is in no falls under original or copyrightable content. However, there are examples like the YouTube Data API, which includes the video title and description, which are ultimately under the content creator's copyright.

I'm unsure if it's necessary, but I'd like to avoid including the API responses under the license of the project itself. Otherwise, I'd essentially be redistributing content I don't hold copyright of under Apache-2.0.

Is it a good idea to take measures to exclude these files from the license of my project?

Improve this question
5
  • 4
    What license do you want to distribute these outputs under?
    – MadHatter ♦
    Commented Jun 11, 2020 at 5:32
  • Very sorry for the late response, I was giving this some thought but forgot about it. I think it only makes sense to make them FOSS too and that my question is invalid. They're needed to be copied, modified, and redistributed just like the rest. The solution to my concern probably isn't excluding them but rather for requests where I'm concerned about this I should use mock responses with my own data instead of using the raw response from the API to avoid third-party content in the repository.
    – Seth Falco
    Commented Jun 18, 2020 at 5:53
  • Fair enough! Do you want to write up your own answer then accept it (when permitted), or would you rather delete the question?
    – MadHatter ♦
    Commented Jun 18, 2020 at 5:55
  • Unfortunately the solution doesn't exactly answer the question (XY Problem?), but I'll write up an answer for it later today anyway, if that's alright. Thank you for the help. Your question helped me realize in my case I should probably try make the test responses FOSS friendly, not licensed differently or excluded.
    – Seth Falco
    Commented Jun 18, 2020 at 6:06
  • 1
    Don't forget it's your question; if you're answering it, and nobody else has, you're free to edit the question so it lines up better with the answer. And I'm glad the community helped you to think your way to a position you're happy with!
    – MadHatter ♦
    Commented Jun 18, 2020 at 6:43

1 Answer 1

Reset to default
5

In this scenario, it's not a good idea.

It doesn't make sense to add exclusions because I need the entire project to be under FOSS terms, not just parts of it. By making exceptions, it just creates unnecessary confusion for users and contributors.

  • It creates complexity when someone wants to contribute to those files. Are they entitled to make changes? What license are the excluded files under, if not the Apache-2.0 license?
  • If I wish to exclude content from the license because they can be linked back to another copyright holder, then I'm not entitled to include that content in my repository in the first place. (Though fair use / fair dealing could be argued, this is an unnecessary complication, as including the content can be avoided outright.)

The proper way to handle this is to review the files, and omit or replace content that may be encumbered by copyright.

API responses with arbitrary data are fine, but if a response contains information that can be linked to a copyright holder, I should just obfuscate the content. As usernames are arguably identifiable information, these should be obfuscated as well.

In my scenario, the most notable candidates are responses from the YouTube Data API. For example, I could replace video titles and descriptions with Lorem Ipsum.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.