Attributions & Copyright

[Feoramund]

I've recently been learning more about licensing in open source software development and had an overview of how Odin's copyright situation is.

I did this because I'd like to release a compiled binary of my own Odin code one day, and I want to know what I would be legally obligated to do. I've also been curious about the sporadic copyright notices throughout the project.

I want to preface this with saying that I'm not a lawyer, nor legally trained, nor am I in a legal profession, so my judgment may not be as sharp as someone from that background.

I'd like to resolve two questions with this discussion:

• What legal obligations does someone have for releasing a binary compiled from their own code with the Odin compiler?
• Can we codify the copyright notice practice within the codebase?

I'll go into my attempt at answering the first question myself, to show I've tried to figure this out on my own.

NOTE: Much of my understanding of late comes from this article.

Copyright Claims

Legend:
† "All rights reserved."
~ denotes several files under a name or subdirectory as being under the same license or claim.

A search for the word "Copyright" reveals the following claims:

Location	Holder	License
(many)	Jeroen van Rijn	"Odin's BSD-3 license"
LICENSE	Ginger Bill	BSD-3-Clause †
base/runtime/dynamic_map_internal.odin	Dale Weiler	(not listed)
base/runtime/wasm_allocator.odin	Emscripten authors	MIT
core/c/libc/README.md	Dale Weiler	"Odin's BSD-2 license" *1
core/crypto/_aes/ct64/~	Thomas Pornin	BSD-1-Clause †
core/crypto/_aes/hw_intel/~	Thomas Pornin	BSD-1-Clause †
core/crypto/_fiat/field_~	the fiat-crypto authors	BSD-1-Clause †
core/crypto/~	zhibog	"the BSD-3 license" *2
core/encoding/entity/LICENSE_table.md	"COPYRIGHT HOLDERS"	W3C 2002
core/encoding/entity/generated.odin	David Carlisle	W3C 2002
core/encoding/uuid/LICENSE	Feoramund	BSD-3-Clause
core/flags/LICENSE	Feoramund	BSD-3-Clause
core/math/big/prime.odin	Thomas R. Nicely	public domain
core/math/cmplx/~	Stephen L. Moshier	(custom) *3
core/math/math.odin	Sun Microsystems, Inc.	(custom, SunPro) †
core/math/math.odin	Sun Microsystems, Inc.	(custom, SunSoft) †
core/math/math.odin	The Go Authors	BSD-3-Clause †
core/math/math_basic.odin	Sun Microsystems, Inc.	(custom, SunPro) †
core/math/math_erf.odin	Sun Microsystems, Inc.	(custom, SunPro) †
core/math/math_gamma.odin	Stephen L. Moshier	(custom) *3
core/math/math_lgamma.odin	Sun Microsystems, Inc.	(custom, SunPro) †
core/math/math_log1p.odin	Sun Microsystems, Inc.	(custom, SunPro) †
core/math/math_sincos.odin	Stephen L. Moshier	(custom) *3
core/math/noise/internal.odin	Yuki2	(not listed) *4
core/math/noise/opensimplex2.odin	Yuki2	(not listed) *4
core/mem/tlsf/LICENSE	Matthew Conte	BSD-3-Clause
core/net/~	(multiple holders) *5	"Odin's BSD-3 license"
core/slice/heap/heap.odin	Dale Weiler	"Odin's BSD-3 license"
core/text/table/table.odin	oskarnp	"Odin's BSD-3 license"
core/thread/thread_pool.odin	eisbehr	"Odin's BSD-3 license"
core/unicode/tools/generate_entity_table.odin	David Carlisle	W3C 2002
src/libtommath/LICENSE	(no specific holder)	Unlicense/public domain
src/ucg/~	Feoramund	BSD-3-Clause
src/utf8proc/~	(multiple holders) *6	MIT

---

1. This is a reference which comes from the era when Odin was under the BSD-2-Clause license.

Every file within this directory is made available under Odin's BSD-2 license
with the following copyright.

Copyright 2021 Dale Weiler <[email protected]>.

Odin's license is currently under the BSD-3-Clause variant. See commit 1cd3b69 for the change.

2. Does not specify which license.

3. License text refers to https://netlib.sandia.gov/cephes/readme:

   Some software in this archive may be from the book _Methods and
Programs for Mathematical Functions_ (Prentice-Hall or Simon & Schuster
International, 1989) or from the Cephes Mathematical Library, a
commercial product. In either event, it is copyrighted by the author.
What you see here may be used freely but it comes with no support or
guarantee.

  The two known misprints in the book are repaired here in the
source listings for the gamma function and the incomplete beta
integral.

  Stephen L. Moshier
  [email protected]

4. The code that it is ported from (https://github.com/KdotJPG/OpenSimplex2) is licensed as CC0 1.0 Universal.

5. Multiple holders include: Tetralux, Colin Davidson, and Jeroen van Rijn.

6. Multiple holders include: Steven G. Johnson, Jiahao Chen, Peter Colberg, Tony Kelman, Scott P. Jones, and other contributors. and Public Software Group e. V., Berlin, Germany.

Interpretations

I've read that the phrase "All rights reserved." complicates licensing permissions, but there are opposing opinions on this. I'm inclined to believe the latter, but I've noted this here with what licenses use that phrasing.

---

Clause 2 of the BSD-3-Clause requires redistributions in binary form to reproduce the license.

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.

I'm assuming all of the claims referring to "under Odin's BSD-3 License" would act as references of authorship, but they would not necessarily require additional licenses included in a redistribution of binary code.

So at bare minimum, every program compiled from Odin source with the Odin compiler should include LICENSE found at the root of this repository, because unless I'm mistaken, all of the code under the base and core library collections, unless otherwise stated, is under the root LICENSE.

---

The BSD-1-Clause license does not explicitly require reproduction for binaries (that requirement which is usually found in clause 2 of the BSD-3-Clause), but it does have the typical opening statement: (emphasis is mine)

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

I could assume that the 1 clause overrides the opening statement referencing binary forms, but then I'd wonder why it was written to begin with anyway. Does "binary forms" in this instance refer to compressed forms of the source code only and not compiled forms?

Depending on how that's interpreted, the licenses of Thomas Pornin and the fiat-crypto authors may or may not be required to be carried in compiled binary distributions.

---

I am interpreting compilation of source code into machine code as a modification of source code. This seems common sense to me, but I was able to find this StackExchange answer that makes a more legal justification for this line of reasoning.

---

The W3C 2002 license does not differentiate between source or binary and only states that it permits modification, provided that its NOTICE is included.

---

Stephen L. Moshier's copyright appears to have no redistribution requirements; it grants free use but states there is no support and no guarantees.

Requirements

Based on my reading and interpretation of the licenses, this is what I've concluded is required, if you distribute a compiled binary of your own Odin code using the Odin compiler and its included library collections.

1. Ginger Bill's LICENSE reproduced, bare minimum.
2. Emscripten authors license from wasm_allocator.odin reproduced if using a wasm build.
3. W3C 2002 license if core:encoding/xml is imported.
4. Feoramund's BSD-3-Clause core/encoding/uuid/LICENSE if core:encoding/uuid is imported.
5. Feoramund's BSD-3-Clause core/flags/LICENSE if core:flags is imported.
6. The Go Authors BSD-3-Clause license if you use (or use code that uses) core:math procedures: round_f16, round_f32, round_f64.
7. Sun Microsystems, Inc. license (SunPro variant) if you use (or use code that uses) core:math procedures: asinh, acosh, atanh, ln_f64, erf_*, lgamma_*, log1p_*.
8. Sun Microsystems, Inc. license (SunSoft variant) if you use (or use code that uses) core:math procedures: asin_f64, acos_f64.
9. Matthew Conte's BSD-3-Clause core/mem/tlsf/LICENSE if core:mem/tlsf is imported.

NOTE: I am uncertain if any code from utf8proc is used in decoding runes from within a compiled Odin program (i.e. the rune-based iteration of a string), but if it is, it may be the case that the utf8proc MIT license is necessary to be included for such programs.

For the vendor library collection, the situation's simpler, since everything's divided already. If you make use of one of the packages, the licenses are right there and able to be copied. This is more what I'm used to handling prior to Odin.

Vendor Package	License
ENet	MIT
OpenEXRCore	BSD-3-Clause
OpenGL	2 separate MIT licenses
cgltf	MIT
commonmark	multiple BSD-2-Clause and MIT licenses
darwin	(no explicit license included)
directx	multiple BSD-3-Clause, MIT, Spencer-94 licenses
egl	(no explicit license included)
fontstash	(no explicit license included)
ggpo	MIT
glfw	zlib-acknowledgment
lua	MIT
microui	MIT
miniaudio	MIT No Attribution
nanovg	(no explicit license included, but the project is under zlib)
portmidi	MIT
raylib	zlib
sdl2	zlib
sdl2/image	multiple licenses for subprojects: JPEG group, libpng, MIT, BSD-3-Clause, zlib
sdl2/mixer	multiple licenses for subprojects: zlib, BSD-3-Clause, public domain, LGPL
sdl2/net	zlib
sdl2/ttf	2 zlib licenses, FreeType license
stb	public domain
vulkan	Apache 2.0
wgpu	(no explicit license included)
x11	(no explicit license included)
zlib	zlib

Uncertainties

1. Dale Weiler's copyright in dynamic_map_internal.odin does not list license/permissions.
2. Yuki2's copyright does not list license/permissions.
3. zhibog's copyright refers to the license but not Odin's license specifically. I could assume it's the Odin license, but maybe this is a weak point in the wording.
4. I am uncertain if the BSD-1-Clause requires representation for compiled forms or not.

Survey of Odin Programs

I was curious how other projects handled this, and if my interpretations about needing to include the Odin license would hold up. I went through the Odin showcase of projects that had demos for download.

EmberGen

I downloaded EmberGen 1.1.2 for Linux from the website and opened THIRD_PARTY_LICENSES.txt. A quick search revealed no mention of the Ginger Bill BSD-3-Clause LICENSE.

LiquiGen

Same situation as EmberGen. I checked this one out, since my understanding is that it's a newer product of JangaFX.

Todool

No mention of the Odin LICENSE.

Conclusions

As far as the base and core of Odin go, it's not too complicated of a licensing situation, from what I can tell.

Originally, I included my own licenses with my flags and uuid PRs, because that's what Bill did when he put up the original flags PR which was porting my package. My limited understanding at the time was that because Odin's under a BSD-3-Clause license too, that the two would somehow "merge," but I've since learned that my license is something that stands on its own.

I'd be okay with changing my licenses to simplify this process for other people if it's an issue.

It also seems like the three projects I checked out did not include the LICENSE from this repository, so I'm wondering if I've misinterpreted something.

As an addendum, I did a little digging and found this answer about how the GCC handles the library code situation in their own scenario. I think it's an interesting case, since the GPL is supposed to be one of the most explicit open source licenses. In short, despite the libraries being under the GPL, they warrant an exception to code compiled using them to not be under the GPL. I'm not sure if there's a precedent for similar exceptions under BSD licenses, but I can't imagine why one wouldn't be able to be made if necessary.

Contribution

As I mentioned in the intro to this issue, I've noticed sporadic copyright statements made within the core library during my time contributing, many of them belonging to Jeroen van Rijn.

Is there an unwritten rule about these? I ask because it seems to be a non-standard practice, i.e. not every file or package has them and some are formatted or placed differently compared to others. I couldn't find any directions regarding this, either.

@Kelimion, can you provide some wisdom about this?

I can see the benefit in having a list of contributors section in files or packages, in case it gets reformatted or jumbled around, and you needed to contact someone about something particular, as digging through git blames can sometimes be a pain.

I also think it would be helpful to have a list of procedures or code that's in the core/base of Odin which warrants specific license inclusion, as the ones I've pointed out up in the math library. (This is of course pending that my interpretation that such things are needed is actually true.)

Other Projects

I know the Godot Engine project has a LICENSE where they have a copyright statement that lists "Godot Engine contributors" which points to an AUTHORS.md file listing individual contributors.

I went to look at how Zig handles this, and it looks like they have a LICENSE with a copyright to "Zig contributors" but no AUTHORS type of file.

The article I mentioned at the start of this has a section on this type of situation as well as this note.

Conclusions

I make no decree about what to do about this since I'm hoping for some wisdom from the elder contributors. :) I am curious though what your thoughts are, based on my observations. Do let me know if you think I have the wrong interpretation. I admit I'm new to this side of open source.

[gingerBill]

From what I understand, BSD 3-clause is about the source code itself and not the final produced binaries. So if you ship the source code, it should include the license file.

The Odin code base use to use BSD 2-clause but I changed it to 3-clause because more people were contributing to the project.

As for the uncertainties: assume anything in the Odin code base to be always BSD 3-clause unless otherwise mentioned.

[Feoramund]

Within EmberGen 1.2.0's Linux zip file is THIRD_PARTY_LICENSES.txt. Inside that, there are two BSD-3-Clause licenses included, one for Blosc and the other for OpenEXR. Naturally as this is a binary distribution, no source code is present, but the licenses are still provided.

While looking for a clarification online, I found this FAQ from the FreeBSD website. Mind that FreeBSD is under the BSD-2-Clause license.

Excerpt, emphasis theirs:

The license means you are free to modify, distribute, and even sell FreeBSD
without **being required to release your modifications as open source**. However,
there are some minimal conditions, such as retaining the original copyright
notice and disclaimers when distributing FreeBSD.

This seems to be in line with my original interpretation about license inclusion with compiled binaries, meaning that any program compiled using the Odin core or base libraries, given that it's largely under the Ginger Bill BSD-3-Clause license, would need to carry the accompanying license terms and the Ginger Bill copyright as a third-party attribution, at minimum.

[cyyynthia]

From what I understand, BSD 3-clause is about the source code itself and not the final produced binaries

IANAL/TINLA

That's wrong, as explicitly stated by the license preamble and 2nd condition. For other licenses such as MIT or ISC, binary forms are also subject to attribution requirements by default. For the purposes of copyright law, a compiled binary is considered a derived work of the source text and therefore subject to attribution clauses. That's why the zlib license and the Boost Software License exist; they explicitly grant the right for binary redistributions to omit attribution and are the only mainstream licenses (besides public domain equivalent ones) to behave that way.

LLVM and Swift use a dedicated exception for the Apache-2.0 license as well (making the license respectively Apache-2.0 WITH LLVM-exception and Apache-2.0 WITH Swift-exception in SPDX terms). The fmtlib/fmt project also have used their own exception on top of the MIT license to drop the attribution requirement of binaries.

[rant]
That's why I like the BSD licenses and dislike the ISC/MIT; those licenses are crystal clear on the matter whereas these "minimalistic" licenses rely on international law (the Berne convention specifically). They're functionally equivalent but the lack of clarity makes them a lot more opaque to a lot of people, as demonstrated herein...
[/rant]

[graphitemaster]

To help alleviate some of these pain points I think we should try to get most of the code as possible in Odin all licensed under the BSD 3-clause license. As such, as author of base/runtime/dynamic_map_internal.odin, core/c/libc, core/slice/heap/heap.odin, and documentation, I consent to it being contributed under any licensing terms Odin requires. In general I relinquish it into the Public Domain (or compatible license such as CC0 or Unlicense where the public domain isn't recognized).

[zhibog]

I also consent to the code being contributed under any licensing terms Odin requires, with regards to code within core/crypto/~, where my name is at the top of the file

[flysand7]

Speaking of core:net, I remember I did some refactorings and changes, but didn't put my name on the copyright list. My country doesn't have a copyright law, so it didn't feel right to include my name there, hope that doesn't create any issues.

[laytan]

I haven't put my name/copyright anywhere so that this whole thing could be hopefully be avoided, I assume that just means it is copyrighted by Odin's own license. I feel like putting your name somewhere is fine but adding mention of copyright that is not the same as Odin's complicates matters and should be avoided.

[Yawning]

I believe that your understanding is correct, though INAL.

• "All Rights Reserved" is largely historical
• The interpretation I use for BSD-1 is that attribution is not required when distributing compiled binaries. The Boost license has better language but I view the attribution requirements as equivalent (https://www.boost.org/LICENSE_1_0.txt).
• The attribution requirements applies to binaries for BSD-2/BSD-3 (clause 2, see: https://www.tldrlegal.com/license/bsd-3-clause-license-revised).

Like with laytan unless I pulled in or heavily derived code from others, I explicitly omitted licenses for my contributions. For my personal contributions I am ok with most things within reason (BSD-3/BSD-1/Boost Software License etc are perfectly fine).

While it is possible to re-implement a lot of this code, my primary contributions are places where reusing prior art if possible is good practice. With that in mind, these are the primary sources that I used, and why the licensing is the way it is:

• monocypher (core/crypto/x25519): BSD-2 or CC0 (the code itself is basically the same as in the RFC)
• fiat-crypto: Choice of BSD-1/MIT/Apache (BSD-1 chosen)
• BearSSL (core/crypto/_aes, aes): Upstream is licensed under the MIT license, explicit permission from the author was obtained for how we license it (we do have some flexibility here, but with the common interpretation of BSD-1, I think this is fine)

The libraries I see myself (potentially) pulling code/ideas from in the near future are:

• fiat-crypto: Already used
• libjade: CC0/Apache
• The Go stdlib (They have a nice constant time mod p big integer implementation, alternatively BearSSL also has the relevant math)

[ghost]

Feoramund, your post is very helpful - thank you for sharing with all.

I had very similar questions on the Odin Discord and Laytan shared this link. I thought you might find this post interesting as related to GNU GCC executables compiled by that venerable compiler.

Maybe Odin could at a minimum create a runtime exception so for a simple program with no other imports no license statement is required for said executable, unless you literally copy the source code into the executable (something silly). This is not addressed by the BSD 3-Clause license for actual source or binary of the implemented compiler.

What are the licensing requirements for a program I compile using GCC? - this is a clickable link to the SO post

This would be covered by the GCC Runtime Library Exception. If you use GCC as-is to compile your program, the resulting binary is not covered by the GPLv3 and you can license it under any terms you wish. Your source code is not subject to the GPLv3 merely because you use GCC to compile it to a binary, the only way GCC's license would impact your source code is if you directly copy portions of the GCC code into your source code itself (which, of course, would mean some of the source code isn't yours).

[ghost]

The GCC Runtime Library Exception

https://www.gnu.org/licenses/gcc-exception-3.1.html

[siemato]

Since the topic came up: the issue with CC0, unlicense or public domain is, that it's not applicable across all jurisdictions. Some countries don't have the concept of a 'public domain', so 0BSD or MIT-0 is the closest you can get. 'Do as you want with it, don't hold me accountable for anything, no need to attribute anything'. Ideally, code under such licenses should be relicensed by a person in a country with PD under 0BSD for vendoring, imo.

[gingerBill]

The more I think about it, everything in the core library could be BSD 1-Clause if possible.

The compiler code could easily remain BSD 3-Clause, and I think that would be fine with pretty much everyone.

It's probably the best "compromise" I can think of.

[Feoramund]

I have no issue with the compiler remaining BSD 3-Clause. From what I recall, no code within the compiler is used within compiled binaries.

BSD 1-Clause for the standard importables (base, core) sounds fine. I admit I don't know what the legal ramifications of not having the non-endorsement clause are, since it's not like the BSD 1-Clause gives explicit permission for endorsements anyway.

[siemato]

My understanding of the 3rd clause seems to be different. This is not for protecting the contributors for all I can tell. It's about maintaining the integrity of trust in the project, by preventing the use of the project name and it's contributors, so that nobody can fork the project and say: "This [forked, sketchy] version is Odin. The language made by the one and only @gingerBill". The EU (GDPR), Australia, Japan, USA and Canada are protecting one's name by law, and to be frank, I'd expect most countries to have some form of laws protecting people's names, I didn't check more though.

[cyyynthia]

This is not for protecting the contributors for all I can tell. It's about maintaining the integrity of trust in the project, by preventing the use of the project name and it's contributors

IANAL/TINLA

I'd consider the latter as protecting the contributors ;) But your understanding is correct. It's theoretically redundant as it's already protected by law roughly worldwide, although my opinion is that it's always a good thing to be explicit and clear to avoid ambiguity...