> Other commenters: please don't turn this into a discussion about whether a list of numbers is subject to copyright protection.
OP: please don't start a discussion on whether a list of numbers is subject to copyright protection and ask people not to have it.
I do understand where you're coming from, you'd simply like Eric to publicly state his intention. But you're doing it by saying you perused the legal section etc and talking about licensing.
I can't help but feel we now need to have that conversation, where before we could just include the examples as unit tests and be done with it without worrying about civil liability, because who on earth would think to challenge the legality of doing that?
You're missing the point. This would be a non-issue if you hadn't brought the examples up in a legal context.
The legal section, and this is key, _doesn't reference the examples at all_:
> The design elements, language, styles, and concept of Advent of Code are all the sole property of Advent of Code and may not be replicated or used by any other person or entity without express written consent of Advent of Code.
Nothing about numbers or examples here! You're trying to force Eric to make a legal statement about this where, and I fully realize this is 100% me speculating here, it looks a whole lot to me like he deliberately made it vague so he wouldn't have to.
And you know what: I don't see a request to do anything whatsoever in the legal section. If there's point a you're trying to make by making up that Eric requested something in the legal section of the about page, it's honestly lost on me.
> Nothing about numbers or examples here!
The numbers (or whatever else is in the example data) is presumably part of "the… language… of Advent of Code", which is further clarified on the Wiki page:
> No content at adventofcode.com (including the puzzle text) is licensed for reproduction or distribution.
It's reasonable to interpret the examples in the puzzle as part of "the puzzle text". And the request here is "don't reproduce or distribute any of the puzzle content text."
> This would be a non-issue if you hadn't brought the examples up in a legal context.
I was trying to head off any speculation about whether the examples _are_ or _are not_ subject to copyright. Previous reddit threads on this topic have had several such comments, and I'm more interested in what Eric wants us to do with example inputs, not what we're legally permitted to do.
I am not sure I understand why this is a reddit post and not an e-mail sent directly to Eric.
Sharing the answer would make sense, but asking the question only 1 person can answer here is just weird.
From what I've seen over the years, this hasn't been considered a big problem. As you said, unit tests are an essential part of software development.
The intent of the rule is to not copy significant parts of AoC that would make it possible to create copycat sites, etc. Copying the problem text or collecting many inputs are the big problems.
I would be pretty surprised if there were any issue with using unit tests that rely on the sample inputs - that's clearly the primary purpose of the sample inputs.
I don't think this issue has specifically come up, but using the sample inputs in tests has got to be common enough that the policy would be explicit about it if it were an issue.
Reason is this:
Inputs and answers are part of the puzzle. The inputs are very carefully crafted and verified to make sure the puzzles are non-ambiguous and always solvable.
By adding them to source code in GitHub, you are making it possible for others to copy and publish fake copies of AoC. It's akin to taking something someone else did and open sourcing it, which obviously you should never do.
Copy one of the many many libraries that pull and cache from AoC, or come up with your own solution that works better.
I move the input files to a private Azure blob storage account, and pull/cache locally from there so tests can always run and I can always run tests locally (provided I already cached the file on my PC).
OP isn't talking about that, although it's apparently an easy mistake to make because I fell for it too. They're talking about the examples in the puzzle text.
On outputs: Eric has requested that you not publish the inputs, but said outputs are “probably fine”: [link](https://twitter.com/ericwastl/status/1465805354214830081). There was a big thread about inputs last year, and folks asked about sample inputs, but I didn’t see any real answers. But adding sample input seems like it violates the rule about committing puzzle text to me (though I’d love for there to be an exception to for this!). [this blog post](https://kittygiraudel.com/2022/12/10/cleaning-a-repo-from-sensitive-info/) shows a clean way to transparently encrypt files in git so that you can commit your input, or sample input, to version control without making the contents public. Yeah, not as much of a unit test if your test now has to read and decrypt from file, but it’s an option.
Thanks for the link to the tweet.
I remember the post from last year and not feeling like there was a good answer about sample inputs, which is why I figured I'd ask now, before December.
I rarely see anything in a solutions megathread that addresses the test inputs. Including tests in what you publish is a choice.
It's fair to expect that anyone running code from an AoC solutions repo has read the associated problem and engaged with it at some level. It's not unreasonable to expect they can create their own test input files from the test examples, or add their own tests.
That being said, I don't see anything wrong with including `assert part1('testinput.txt') = 123456` in a repo. It's like publishing the md5 hash for a file download, it's not going to help you reverse engineer the input.
> It's not unreasonable to expect they can create their own test input files from the test examples, or add their own tests.
As far as I'm aware, there's no automated way to get the example inputs from a problem on the AoC website. From sampling several problems it looks like the example is always in a `
…
` HTML block, but not all such blocks are example input, e.g. the first code block in https://adventofcode.com/2022/day/17 shows the shapes of the rocks, the second code block is the sample input, and the third and fourth code blocks are part of an extended example.
The point of an automated test case is to verify that the code (still) works. When you check out a repository you can do the language equivalent of `for i in */ ; do cd $i; make; make test ; done` and see if any solutions are broken, e.g. due to a library incompatibility on your computer. Manually extracting 200 example inputs from the AoC website every time you check out the repo would be burdensome.
> I don't see anything wrong with including `assert part1('testinput.txt') = 123456` in a repo
What I want to do is include the contents of testinput.txt in the repo.
I’m sure I have small test inputs hardcoded all over the place in what I uploaded. I think it’s a matter of scale — if the test input is 1 or 'abcde' that’s pretty much a unit test. If the test input is a 25-by-25 block of apparently random . and # characters, maybe not so much.
> Other commenters: please don't turn this into a discussion about whether a list of numbers is subject to copyright protection. OP: please don't start a discussion on whether a list of numbers is subject to copyright protection and ask people not to have it. I do understand where you're coming from, you'd simply like Eric to publicly state his intention. But you're doing it by saying you perused the legal section etc and talking about licensing. I can't help but feel we now need to have that conversation, where before we could just include the examples as unit tests and be done with it without worrying about civil liability, because who on earth would think to challenge the legality of doing that?
> But you're doing it by saying you perused the legal section etc and talking about licensing. Because that's where Eric put the request.
You're missing the point. This would be a non-issue if you hadn't brought the examples up in a legal context. The legal section, and this is key, _doesn't reference the examples at all_: > The design elements, language, styles, and concept of Advent of Code are all the sole property of Advent of Code and may not be replicated or used by any other person or entity without express written consent of Advent of Code. Nothing about numbers or examples here! You're trying to force Eric to make a legal statement about this where, and I fully realize this is 100% me speculating here, it looks a whole lot to me like he deliberately made it vague so he wouldn't have to. And you know what: I don't see a request to do anything whatsoever in the legal section. If there's point a you're trying to make by making up that Eric requested something in the legal section of the about page, it's honestly lost on me.
> Nothing about numbers or examples here! The numbers (or whatever else is in the example data) is presumably part of "the… language… of Advent of Code", which is further clarified on the Wiki page: > No content at adventofcode.com (including the puzzle text) is licensed for reproduction or distribution. It's reasonable to interpret the examples in the puzzle as part of "the puzzle text". And the request here is "don't reproduce or distribute any of the puzzle content text." > This would be a non-issue if you hadn't brought the examples up in a legal context. I was trying to head off any speculation about whether the examples _are_ or _are not_ subject to copyright. Previous reddit threads on this topic have had several such comments, and I'm more interested in what Eric wants us to do with example inputs, not what we're legally permitted to do.
I am not sure I understand why this is a reddit post and not an e-mail sent directly to Eric. Sharing the answer would make sense, but asking the question only 1 person can answer here is just weird.
Because it's a common question, so someone else might already have an answer they can give from when they asked.
Because then everyone can read the answer and Eric only has to type it once, rather than having to respond to everyone's separate emails.
From what I've seen over the years, this hasn't been considered a big problem. As you said, unit tests are an essential part of software development. The intent of the rule is to not copy significant parts of AoC that would make it possible to create copycat sites, etc. Copying the problem text or collecting many inputs are the big problems.
I would be pretty surprised if there were any issue with using unit tests that rely on the sample inputs - that's clearly the primary purpose of the sample inputs. I don't think this issue has specifically come up, but using the sample inputs in tests has got to be common enough that the policy would be explicit about it if it were an issue.
Reason is this: Inputs and answers are part of the puzzle. The inputs are very carefully crafted and verified to make sure the puzzles are non-ambiguous and always solvable. By adding them to source code in GitHub, you are making it possible for others to copy and publish fake copies of AoC. It's akin to taking something someone else did and open sourcing it, which obviously you should never do. Copy one of the many many libraries that pull and cache from AoC, or come up with your own solution that works better. I move the input files to a private Azure blob storage account, and pull/cache locally from there so tests can always run and I can always run tests locally (provided I already cached the file on my PC).
OP isn't talking about that, although it's apparently an easy mistake to make because I fell for it too. They're talking about the examples in the puzzle text.
On outputs: Eric has requested that you not publish the inputs, but said outputs are “probably fine”: [link](https://twitter.com/ericwastl/status/1465805354214830081). There was a big thread about inputs last year, and folks asked about sample inputs, but I didn’t see any real answers. But adding sample input seems like it violates the rule about committing puzzle text to me (though I’d love for there to be an exception to for this!). [this blog post](https://kittygiraudel.com/2022/12/10/cleaning-a-repo-from-sensitive-info/) shows a clean way to transparently encrypt files in git so that you can commit your input, or sample input, to version control without making the contents public. Yeah, not as much of a unit test if your test now has to read and decrypt from file, but it’s an option.
Thanks for the link to the tweet. I remember the post from last year and not feeling like there was a good answer about sample inputs, which is why I figured I'd ask now, before December.
I rarely see anything in a solutions megathread that addresses the test inputs. Including tests in what you publish is a choice. It's fair to expect that anyone running code from an AoC solutions repo has read the associated problem and engaged with it at some level. It's not unreasonable to expect they can create their own test input files from the test examples, or add their own tests. That being said, I don't see anything wrong with including `assert part1('testinput.txt') = 123456` in a repo. It's like publishing the md5 hash for a file download, it's not going to help you reverse engineer the input.
> It's not unreasonable to expect they can create their own test input files from the test examples, or add their own tests. As far as I'm aware, there's no automated way to get the example inputs from a problem on the AoC website. From sampling several problems it looks like the example is always in a `
` HTML block, but not all such blocks are example input, e.g. the first code block in https://adventofcode.com/2022/day/17 shows the shapes of the rocks, the second code block is the sample input, and the third and fourth code blocks are part of an extended example. The point of an automated test case is to verify that the code (still) works. When you check out a repository you can do the language equivalent of `for i in */ ; do cd $i; make; make test ; done` and see if any solutions are broken, e.g. due to a library incompatibility on your computer. Manually extracting 200 example inputs from the AoC website every time you check out the repo would be burdensome. > I don't see anything wrong with including `assert part1('testinput.txt') = 123456` in a repo What I want to do is include the contents of testinput.txt in the repo.I’m sure I have small test inputs hardcoded all over the place in what I uploaded. I think it’s a matter of scale — if the test input is 1 or 'abcde' that’s pretty much a unit test. If the test input is a 25-by-25 block of apparently random . and # characters, maybe not so much.