Licensing the Dialog standard library

Authoring Dialog
,
1

I was contacted today by someone working on a translation of Dialog’s stdlib.dg, who raised a very good point. The LICENSE.txt file in the repository applies a two-clause BSD license to everything, which means:

  1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

  2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

Which means, in theory, every Dialog project that uses the standard library needs to include this LICENSE.txt file somewhere in the distribution.

But that’s clearly not Linus’s intent. (And it’s definitely not mine!) This is what the manual says about credit, for example:

The default implementation of (intro) just prints the story banner by querying (banner), then prints the initial room description with (try [look]). The banner includes the title, author, and serial number of your story, plus the version information for the compiler and the standard library. By convention, stories should print the banner at some point during play. With Dialog, there is no formal requirement to print the banner at all, but it is helpful to the community and to your future self, and it looks professional.

Emphasis mine. Linus’s own games also don’t include anything like this in their READMEs. Strictly speaking, he didn’t need to when he was the sole contributor; but it’s more evidence that it’s not something he expected.

So…how do we make the legalities line up with this intuitive understanding? Is my reading of the license correct? If so, we’ll probably need to contact Linus about applying a different license to the standard library (but if so, which one?).

My personal inclination is to sidestep the headache by just adding a note to LICENSE.txt saying that we understand “redistributions in source or binary form” to mean distributing the compiler and/or library, not distributing things made with the compiler and/or library. Imo if this wasn’t Linus’s intent, he would have called it out specifically in the manual to avoid tripping up new authors. But I don’t know if that actually solves the problem.

5 Likes
2

I think it might be hard to draw a line between “distributing the library [as part of a larger project]” and “distributing things made with the library”. It might be easier to just exempt the compiled/binary form of the library from the requirement.

FWIW, for ZILF, we use separate licenses for the libraries (modified BSD) and the rest of the compiler (GPL). The modifications allow compiled works to credit the project one way or another instead of including the license material:

  • Redistributions in binary form must reproduce the above copyright notice,
    this list of conditions and the following disclaimer in the documentation
    and/or other materials provided with the distribution. In the case of a
    binary z-code file compiled by the ZILF compiler, the appearance of the
    library version number within the text of the introductory title credits of
    your game (text that is displayed to a person who plays your z-code file
    via a z-code interpreter) is sufficient to satisfy the requirements for
    redistribution of said binary z-code file. (By default, using <V-VERSION>
    in your game’s source code will display the library version number to a
    person playing your game on a z-code interpreter.)
  • Redistributions in binary form must reproduce the above copyright notice,
    this list of conditions and the following disclaimer in the documentation
    and/or other materials provided with the distribution. In the case of a
    binary story file compiled by the ZILF compiler, the inclusion of the
    plaintext compiler version string within the file is sufficient to satisfy
    the requirements for redistribution of said binary story file, provided that
    the file is accessible to players. (By default, ZILF includes the compiler
    version string in its output in such a way that it can be viewed by the
    player in the binary story file using a hex editor.)
2 Likes
3

You absolutely need to contact Linus and discuss this.

I suggest the CC0 license, which is more-or-less equivalent to public domain. I am using that license for Vertigo’s stdlib.

Otherwise get an exception for games built with Dialog, similar to what GCC (which is GPL licensed) has for software built with it.

2 Likes
4

You could have a copyright verb that shows the library’s license.

1 Like
5

Maybe file size could be an issue though? Since Dialog targets small computers as well, including extra license text in the game could mean cutting material from the game itself. Although I suppose falling back on distributing the license in a separate file in that case would be possible.

6

stdlib.dg isn’t the only library out there that has a BSD license. Most of them don’t print a message when they’re invoked.

7

Thank you all for the feedback!

I’ve written to Linus about this, and in the meantime, I think the best course of action is to put a note in LICENSE.txt saying that we understand “distribution in binary form” to mean the compiler binaries themselves, not Z-machine or Å-machine bytecode output from those binaries. I think the way Linus talks about it on his site (he says the compiler is released under two-clause BSD but notably says nothing about the library) and in the manual (the comment that Dialog doesn’t require you to print a banner, but it’s appreciated) implies that this was his intention, and even if it’s not a formal legal document, hopefully people trust us enough to accept a “we’re not going to sue you for using our software in the way we explicitly encourage you to use it” for the interim.

(Plus, given that Linus wrote the library, I think he would have included a COPYRIGHT command that printed the BSD license if he wanted that to be a requirement. It would have been trivial.)

Once he writes back, we can figure out a way to formalize this properly. I believe only three people have contributed to the standard library specifically (Linus, me, and one other), so it won’t be impossible to get all three to agree to whatever new license Linus okays. Then, if nobody objects, we can apply that same license going forward to any other libraries we distribute (like unit.dg).

Any objections to this course of action?

1 Like
8

For reference, other projects with a compiler / runtime library split similarly have “exceptions” to the main license for the runtime library parts linked into the resulting binary:

  • GCC and related compilers are generally under a GPL license but the associated runtime library like libgcc use the GCC Runtime Library Exception that makes it possible to build binaries with GCC without having to distribute them under the GPL.
  • Clang and LLVM are Apache-2.0 licensed with the so-called LLVM Exception that the waives attribution requirement for runtime library bits linked into compiled binaries. (The same exception also serves to solve another problem related to license compatibility that’s not relevant here.)

Both of those exception probably had lawyers involved in their drafting, to avoid unintended side effects. Naturally, an IF authoring system doesn’t have a lawyer on retainer. But the LLVM exception may be a useful reference, as it’s functionally very similar to what you’re proposing to do for Dialog’s library, just applying the exception to a different permissive license. In particular, the phrasing “we don’t consider […] to be distribution in binary form” seems ambiguous to me. The current license states that

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: […]

If my use of the compiler’s output is “not considered to be distribution in binary form” then does the license still give me any rights to redistribute the output? Of course the intent is that it’s still permitted, only the second condition (about what a binary redistribution needs to “reproduce”) should be waived. In addition, I don’t see a reason to imply anything about the part of the license that’s shouting in all-caps about software being provided as-is, without warranty, etc.

So I’d suggest similar phrasing as the LLVM exception, in particular stating explicitly which conditions are waived instead of touching the definition of “redistribution in binary form” or other terms. Perhaps something like:

As an exception, if, as a result of you compiling your source code, portions of this software are embedded into compiler output in binary form, you may redistributed such embedded portions without complying with condition 2. of the license.

Aside: this thread is about the Dialog standard library, but a similar question arises for tools like aambundle that bundle an interpreter with a compiled interpreter that’s also under the same two-clause BSD license, right? With an exception targeted at compiler output or Z-machine/Å-machine bytecode, games distributed with a bundled interpreter would technically still need to include a LICENSE.txt for the interpreter itself. If this is not intended, maybe the exception needs to be phrased differently to also cover everything else that a tool like aambundle outputs.

4 Likes
9

Those are very good points! This is what I’m currently thinking:

Note that these requirements are meant to apply to the Dialog compiler, not to the output of that compiler. You can distribute the resulting Z-machine and Å-machine bytecode in any way you like, without needing to include this license file or comply with the attribution requirements (for the library or for the Z-machine runtime routines). We hope to formalize this properly in a future release.

I think this will be a reasonable stopgap until we can get in contact with Linus to officially re-license everything.

1 Like
10

I think the better approach here is for aambundle to automatically emit an interpreter_license.txt file along with the rest of the interpreter. Since it already creates a whole directory of files, adding one more shouldn’t be a problem.

2 Likes
11

Update! Linus wrote back and confirmed his intent: the BSD license is supposed to apply to both the compiler and library, but not to the output of the compiler (even if that includes the library). We’re talking about adding Hanna’s version of the “LLVM exception” to the license now, and I’m going to be adding the full text of the license as a comment in stdlib.dg, so that it doesn’t get overlooked when someone packages up their source code to publish.

5 Likes
12

On which topic—I believe @sue and @averyhiebert are the only people other than Linus and myself to have contributed to the Dialog libraries. Do either of you have objections to adjusting the license to match Linus’s original intent?

(For the unit testing library, it doesn’t matter as much, because it’s for, well…unit testing. I don’t expect big chunks of it to end up in people’s released binaries. But it’s nicer to have all the Dialog libraries under the same license just for the sake of consistency.)

13

unit.dg already includes a statement in it that it’s licensed under the same terms as the rest of Dialog. Adjusting the license won’t change anything, so no problem.

1 Like
14

I’m fine with whichever license other people prefer.

1 Like
15

Actually, guess I should give actual thoughts on the topic while I’m here.

I’m personally happy to license my (small) contributions under basically any license, but my understanding is that, as far as the question of “should we modify the license” is concerned, it’s usually considered bad practice to use a modified/customized version of an existing license, because it means there isn’t a body of existing case law/practice to draw on regarding the precise interpretation details.

In any case, I’m not sure that relicensing is actually necessary, for two main reasons:

  1. As I understand it, a compiled game using the standard library would not be considered a “redistribution” of the library. I think it would be, if anything, a derivative work, which would not be subject to the requirement to reproduce the copyright notice. But I’m not a lawyer, so don’t quote me on that. EDIT: Although I guess I don’t know what exactly the line on “redistribution with modification” is, maybe that includes all derivative works?
  2. Even if games using the standard library are required to retain the copyright notice, I think this could be elegantly accomplished by adding a COPYRIGHT command that prints the copyright notice & license text for the stdlib (to which authors could then also add further copyright info specific to their game), as suggested by @Dannii. I think this would satisfy the requirement by distributing the copyright notice in the form of in-game documentation.

So my belief is that the 2-clause BSD is already in line with the original intent, and if you’re really worried about being extra-safe it could be done with a small addition to the library, rather than modifying the license. But, again, if the decision is made to adopt another license then I’m perfectly fine with that.

1 Like
16

That’s a fair point! I guess my logic is:

  • We’re not fundamentally modifying the BSD license, in my eyes—we’re not removing any permissions or adding any restrictions to it. We’re offering the whole repository (source, compiler, library, etc) under the BSD license, and also offering a separate “do what you want” permission that only applies to the compiler’s output. This kind of dual-licensing isn’t uncommon in my experience (e.g. I dual-license most of my games under MIT and CC-BY).
  • If the BSD license doesn’t require a copyright notice on the compiler output, then this separate permission doesn’t matter at all. If the BSD license does require a copyright notice on the compiler output, then this separate permission matters quite a lot!
  • I don’t have the legal chops to know whether it does or not, but the fact that LLVM added a special exception suggests that the Apache license does, and Apache and BSD are pretty similar in the ways that matter here.
  • If the BSD license on the library applies to the compiler output, then the BSD license on the compiler’s internal Z-machine routines presumably does too—and that one can’t be fixed by a COPYRIGHT command in the library.
  • If we don’t add this permission now, it’ll be basically impossible to add it in the future (since it’ll require contacting everyone who’s worked on the repo, and that number can only grow). If we do add it now, it’s quite easy to remove in the future (we just stop giving people that extra permission; taking away permissions is easy).
  • So in my eyes, adding this separate “you can also do what you want with the compiler output” licensing has a lot of potential benefit and not a lot of potential drawback.

But, we’ll see what Linus says. If this extra permission isn’t required, then keeping the existing license is trivial.

1 Like
17

I am a lawyer, but not an expert in IP. In fact, lawyers are a bit over-rated in this stuff, because it’s massively unclear what legal system is going to apply if there’s ever an argument about it, and answers could differ. Besides, it’s really not credible to see a dispute about the Dialog standard library ever getting to court …

FWIW, my pretty strong view is that if you use a library to produce an executable, you are not “redistributing” the library in the executable. You are using it, sure. But all that remains of it in the executable is the opcode result of compiling something else alongside it. I don’t think you could “decompile” the binary to re-create the standard library’s text. That’s not a “distribution” of the library. You add to this the fact that the author of the library well understood that this was what was going to happen (and intended it to happen) and very obviously (because he wrote the system that would use it) did not intend a copyright notice to appear in the resulting executable.

So, quite apart from the massive improbability of this ever actually being something anyone would fight over, I am really pretty confident that there is no requirement for a notice in the compiler output, and it would be better not to complicate the licence.

None of this is a reason not to ask Linus, of course. That’s simple politeness and recognition of his labour and brilliance.

18

I agree that this situation shares some of the downsides of license proliferation. As @Draconis said, the intent is that the “exception” only grants more permissions and can be ignored if and when it causes headaches (falling back to the classic two-clause BSD license). But people still have to look at the customization and convince themselves that it’s “harmless” in this sense. Sometimes people take existing licenses and add weird things to them that can’t be “ignored”.

If there was already some recognized way of phrasing the intent “compiler output doesn’t need to reproduce the compiler’s license” then it would be good to reuse that. But I’m not aware of any such thing for BSD-style licenses.

There is one way to make the “you can ignore the exception and use the vanilla license” intent even more explicit. The project could be explicitly dual-licensed as “normal two clause BSD OR two clause BSD with Dialog exception” at the recipient’s choice. This is somewhat silly but slots neatly into existing formalizations of FOSS licensing like SPDX (which standardizes “this license AND that license” as well as “this license OR that license” but not the concept of “additional optional terms you can ignore”).

1 Like
19

Um… this is a joke, right? The conditions under which you are allowed to distribute the binaries compiled from source code is the ENTIRE POINT of open source licenses - if you distribute the compiled binary, then you have to also distribute the source code and attribute it correctly.

1 Like
20

Yeah, my understanding is that the output of the compiler does count as a derivative work, which is why things like the GPL exist. I know this hasn’t been thoroughly tested in court, but it seems like the hobbyist community generally agrees that the GPL should work, and tries to abide by it.