I think this is the best solution out of the ones that have been proposed. How do we all feel about this?
Copyright 2018-2026 Linus Åkesson and the Dialog Project contributors
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
[TWO-CLAUSE BSD LICENSE HERE]
This license is intended to apply to the Dialog compiler and debugger and the source code of the standard libraries. Any time those components are distributed, this copyright notice should be attached. But it is not meant to limit what the compiler’s output can be used for, even for projects that include the standard libraries. To make this explicit, the project is ALSO released under a modified two-clause BSD license, which is exactly the same as the above but adds this exception:
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 redistribute such embedded portions without complying with condition 2 of the license.
Distribution of something made with a library does not distribute the library in binary form. But … I may be wrong, of course. A licence may apply to a derivative work. But if the licence assumes that there will be “documentation”, and applies to a “redistribution in binary form” – no, I don’t think that the distribution of something made using the library is a “redistribution in binary form”. And since, as Daniel says, that is clearly not the author’s intent, and the documentation that the author prepared confirms this, I don’t think there’s really a huge amount of doubt about it. But the fact you think that it’s obviously the opposite does indeed support making the intent clear.
If I had to draft , I’d simply add a clause “The distribution of a work of interactive fiction made using the standard library does not constitute redistribution of the library in binary form.”
That was my initial thought, but Hanna pointed out that the license gives permission for redistribution in source and binary form—without that permission, you’re not allowed to make derivative works at all. Whereas the intent is that you have even more permission for this kind of redistribution (not needing to include the copyright notice).
Not that it matters at all, but I don’t think this is correct. The start of the license.txt permits two different things “redistribution” and “use”:
Redistribution and use in source and binary forms, with or without
modification
The clauses that follow impose conditions on redistribution, not use. Where the licence itself envisages, permits, and distinguishes between “redistribution” and “use”, but the conditions it imposes relate to redistribution only, and where the intent (in this particular case) is clear for the reasons you give, I would effectuate that intent. The assumption everyone is making in this thread is that the use of the library to produce a derivative work involves “redistribution”, and I simply think that’s a false assumption.
But as I say (a) it’s not really important because as this thread shows there’s ample room for disagreement and different legal systems could reach different results, (b) it’s entirely academic in the real world anyway because it’s not practically possible to imagine any circumstances in which this is ever going to be tested in court. It’s really more a matter of etiquette than law.
(I’d add: common as it may be, the release under two different and inconsistent licenses actually makes little sense. If you release under two licences you must be releasing under the broadest of the two, and why not just do that?)
As a layperson, I mostly do this when the licenses accomplish the same thing by different means. The MIT license is designed for source code, so it requires credit in a format that’s easy to use for source code. CC-BY is designed for art and writing, so it requires credit in a format that’s easy to use for art and writing. Since my IF works are both source code and writing, if I release them under both licenses, then people always have to give credit, but they can do it in a way that makes the most sense for their medium.
In this case, it would mean even if we non-lawyers completely screw up this exception and it makes the license not work at all—or even just if someone doesn’t trust us non-lawyers to have done this effectively—then people can use the familiar, well-trodden BSD license and not have to worry about it.
Well, from a legal perspective it doesn’t really make sense to think about people “using a licence”. People don’t “use a licence” … they just do something that either is or is not permitted by a licence. If you have two licences, then they can do anything that is permitted by either. To a lawyer it’s a horrible messy way of licensing something, and if the licences are inconsistent (one is not simply broader than the other) then it’s really something a lawyer would always try to avoid. Cobbling together two standard forms is not usually a good plan.
People do all sorts of things with licences which, when you think about it in legal terms, are odd. Luckily nobody worries, but that’s mostly because there’s nothing worth litigating over. From a legal perspective, 99.9 percent of FOSS licences are not “production code”–indeed, they are code that’s never even going to be run. So, really, do whatever you think will work, but mostly safe in the knowledge that it’s not important whether it makes legal sense or not.
I know this is drifting off-topic, but I’m sincerely curious: is there a better way to say “you can give me credit in the MIT way, or in the CC-BY way, whichever works better for your project, but you have to credit me one of those two ways” than dual-licensing MIT and CC-BY?
We have drifted off topic, but the example you give shows the difficulty.
CC-BY authorises (Section 2.A.(1)(a)) the “reproduction” of the original work with attribution “in any reasonable manner” (Section 3(a)(2)). It requires the reproduction to include identification of the creator, a notice that refers to CC-BY, a notice referring to the disclaimer of warranties, and a URL if possible.
MIT requires a specific form of disclaimer of warranty (written, which is very bad practice in capital letters!). It insists that there is “no form of limitation” on what may be done.
These are not compatible licences. In particular, CC-BY is more restrictive than MIT. It deals with various rights (including moral rights and trademarks) in a way that might be incompatible with CC-BY. Your intent, as I understand it, is to have a licence which allows redistribution in any form with credit in appropriate form, not necessarily a specific copyright notice. The MIT License is a bit weird on attribution, because it doesn’t explicitly require attribution, but it does require a “copyright” notice to be included, which some people might think is similar. That’s odd actually, because it’s not clear what the copyright actually relates to, particularly in a derived work: nobody looking at a derivative would have any idea what bits are whose. And in fact it’s arguable that the MIT License doesn’t require attribution at all in derivative works, because all it says is that the copyright notice must be included in copies of “all or a substantial portion” of the software, and that’s a recipe for argument when it comes to derivatives.
And what happens “down the line”? If one person redistributes “using” only CC-BY and another person redistributes only “using” MIT, a subsequent redistributor must use the relevant licence. If A takes your software and redistibutes it under MIT, and B does the same and redisributes under CC-BY, there are now two versions with different “licensing DNA” out in the wild. Is this even permitted? Could it even be argued that one must combine the requirements of both licences restrictively (so that in fact what is now required is both the copyright notice that MIT wants, and the URL that CC-BY wants …)
There are various reasonable options here. One is to just use the CC-BY licence. That will, in practice, allow redistribution of the source code too, and get you the attribution you want (both in source code and derivatives). It’s still possible to use any form of attribution that “makes most sense” because that is precisely what the license requires.
The other would be to use the MIT licence–which is the most permissive in terms of uses, but as you say requires a specific form of attribution, though not a very onerous one.
The third would be to use the MIT licence but modify it so that it says something like “The above copyright notice or some other attribution in any reasonable form shall be included in all copies or substantial copies of the software or works derived from it”.
Using both of them though? Neither necessary nor desirable. For your use-case, I’d probably pick CC-BY because i think it’s a more carefully thought-through licence which deals more comprehensively with the full range of issues, at least in most cases, and will work well-enough.
This may be a reasonable answer to the immediate question asked, but it’s missing the bigger picture of the FOSS ecosystem. There are countless pieces of software, most of which don’t have a single copyright holder but many, every piece get (potentially) reused and changed and recombined many times. Everyone involved wants to make it easy to add more of all that while maintaining the legal framework they consider useful for their respective goals, e.g., the free software ideals, “anyone can use my stuff for whatever they want” attitudes, or the ability of corporations to use open source components in proprietary software without their IP lawyers getting nervous.
Obviously, all of that is far removed from releasing an IF game. But one thing can lead to another. Maybe an IF game has a neat implementation of some storytelling mechanic, then someone turns that into an extension to be used by other games, later the extension moves into the authoring system’s standard library, maybe the line between library and compiler gets blurry, and now the person who wants to package the authoring system for Debian theoretically faces some hard questions about the licensing situation.
Since it’s so common to combine open source software released under different licenses, and getting all relevant copyright holders to agree to a single license is impractical, there is no way around figuring out what it means to combine those licenses (if it’s possible at all). So the question of license compatibility is crucial for FOSS. For the most popular licenses, there are widely agreed upon answers (or perhaps they’re popular because of the compatibility). When introducing new licenses, compatibility with existing licenses is a major concern. All the lay people want the ecosystem to work this way, so the experts and relevant organizations try hard to provide a plausible explanation for how it makes sense from a legal POV (even if there’s still gaps between the orthodox legal advice and common practice of most developers).
Consequently, license proliferation has a huge negative externality: those who take license compliance seriously not only have to evaluate every license on its own merits, but also need to evaluate if and how any new license can be combined with all of the existing licenses. Taking an existing license and modifying it in any way is hardly better, since it either substantially changes the license and thus causes the same problem, or at best causes extra work to determine that the modification has no effect and could’ve been omitted.
When FOSS licenses turn out to be “incompatible” (or if it’s not clear whether they are compatible) this causes a lot of trouble that nobody wants. Completely routine and expected acts like linking OpenSSL turn out to be illegal on a technicality. Typically the only fix is re-licensing, which is very difficult when many decentralized contributors hold some relevant copyright.
License (in-)compatibility is also one reason why Creative Commons explicitly advises against using any CC licenses for software:
Additionally, our licenses are currently not compatible with the major software licenses, so it would be difficult to integrate CC-licensed work with other free software. Existing software licenses were designed specifically for use with software and offer a similar set of rights to the Creative Commons licenses.
For works of IF, which aren’t mainly/entirely software source code as commonly understood, using CC is probably very reasonable and useful. But for the parts that are like software, if the author intends to allow use of them as open source software (see e.g. game → library → authoring system example above), using only CC is a bad idea! That’s why dual-licensing (choice-of-terms) is useful in this case. It would cause more work for a lawyer trying to answer specific questions about the combination of licenses from scratch, but it’s simpler for the FOSS melting pod where standard licenses and choice between them are well understood.
In common practice, the answer is that people don’t unnecessarily limit their redistribution to one of the two licenses. If they do it anyway, it’s usually feasible to track down some other source that preserved the choice-of-terms (attribution, whether required by the license or socially expected, helps with this). Tools such as package managers or REUSE help with keeping track of all this information, but are obviously overkill for hobbyists.
Ultimately, at some point, people need to make a choice of which terms they’re using software under. But this choice rarely has to be made explicitly outside of large Linux distributions or commercial corporations that deal in distributing lots of software to many end users and want to do everything by the book. For everyone else, choice-of-terms dual licensing is just some reassurance that there’s more ways for the experts to find a workable solution if it ever becomes necessary.
My guess, frankly, is that the “ecosystem” of FOSS licenses largely works because it almost never gets seriously tested. Occasionally, yes, when a large corporation butts its head against an issue; but even then, in many cases, it’s David and Goliath and … Goliath doesn’t bother too much. There are very common practices (such as multiple licenses, and changes of licensing terms) which are hard to validate – and that’s even before you start thinking about the very complicated private international law issues. It works largely because there’s mostly good faith, and even when there isn’t good faith, very few people are ever actually going to sue: there are a few cases, but not many. I’m not even sure that the standard licenses are always well understood: there is a common understanding of some of them, but whether that understanding is a good one, I’m less sure.
For most people I’d say: go with a single licence, preferably unmodified, which comes closest to what you want, and don’t fuss too much about it. I agree with @Hanna’s view that CC is probably a good choice of licence for IF works, and not for software.
Thank you all for your input here! It’s been very helpful.
I find this argument compelling, and…
…also this one. I don’t think it’s likely that Dialog will ever run into any real problems here.
So this is what I’ve gone with for now.
This license is intended to apply to the Dialog compiler and debugger and
the source code of the standard libraries. Any time those components are
distributed, this copyright notice should be attached. But it is not meant
to limit what the compiler’s output can be used for, even for projects that
include the standard libraries. To make this explicit, the project is ALSO
released under a modified two-clause BSD license, which is exactly the same
as the above but adds this exception:
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 redistribute such embedded portions without complying
with condition 2 of the license.
In other words, you can distribute the Z-machine and Å-machine bytecode that
the compiler produces 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).
I understand now that this isn’t great from a formal legal perspective, but I don’t think it has to be—it’s less something that will be tested in court and more a reassurance to authors that we won’t sue you for using our compiler. I’ve gotten approval from Linus and all the other necessary people, so unless someone has a big problem with this solution, it’ll be included in the pending 1b/01 release.
I’ve also added the whole license in a comment at the bottom of stdlib.dg, stddebug.dg, and unit.dg. Linus explicitly wants the license distributed along with those (well, the first two at least, and unit.dg is explicitly under the same license as the rest of Dialog), and if it’s in the file itself, then it’ll automatically get included whenever someone releases their source code.