Add LICENSE and Copyright Notice

[michdolan]

This is a DRAFT PR, intended for initial review and discussion.

Many source files in this repo have no license or copyright notice. In preparation for moving the repo to the ASWF GitHub account, we need to add the correct notice. In config sub-directories with no notice, I have added the recommended SPDX notice as outlined here: https://github.com/AcademySoftwareFoundation/tac/blob/master/process/contributing.md#copyright-notice-format

The three latest aces config directories do carry an existing copyright attributed to "ACES Developers". That needs to remain intact, but the related license entry is blank. I would assume that implies the OCIO BSD-3-Clause license, in which case the standard SPDX header comment could be added (but not the OCIO copyright statement). Along with that, my thought is to also change:

__license__ == '' to __license__ == 'BSD-3-Clause'

That is a bit of a legal gray area to me though, so I have not touched these files yet. Sage OSS legal wisdom is appreciated here as we determine how best to proceed.

I have also added an initial LICENSE file to the repo, which currently includes both the standard OCIO statement for the work overall, and the ACES Developers statement for the three aces configs.

[KelSolaar]

I never filled the __license__ == '' field because we never came to a conclusion on the topic. Given it was A.M.P.A.S. mandated, the license adopted could be the Academy one. We would need to check with all the contributors for that part of the code though before: https://github.com/hpd/OpenColorIO-Configs/graphs/contributors

• @hpd
• @KelSolaar: I'm fine either way
• @selfshadow
• @JGoldstone
• @KevinJW
• @alexfry

[KevinJW]

As a lesser contributor, I don't mind, which ever is easier.

[hpd]

A little late to the conversation, but the Academy license should hold. The work I did on this was under contract for the Academy. Alex Forsythe (aforsythe) should be the point person for that code now.

[doug-walker]

I would recommend only moving the latest ACES config over to ASWF. Partly because most of the issues you have are with the 0.1.1 and 0.7.1 configs and partly because I don't think those older configs are relevant more than 4 years after the 1.0 release.

We should also have a discussion about versioning for the ASWF repo. Rather than creating new directories for each ACES point release, would it make more sense to just have one ACES config and create git tags or branches for different ACES versions?

[KelSolaar]

We should also have a discussion about versioning for the ASWF repo. Rather than creating new directories for each ACES point release, would it make more sense to just have one ACES config and create git tags or branches for different ACES versions?

We talked about that quite a few times with @aforsythe, and I think it is the way to go. Now that being said before doing that and because I'm in the middle of 1.1 I would preferably wait for that to be done the old way and when the config works, we then cleanup the stuff.

[michdolan]

Now that being said before doing that and because I'm in the middle of 1.1

@KelSolaar , if you are working on the 1.1 config, could you provide a brief update on that work? The topic came up in last week's TSC meeting, along with the discussion leading to this draft PR, and issue #18 .

I have wondered a time or two if the aces config would be better in its own repo, so it could have independent release versioning specific to aces. Perhaps even in a repo managed by A.M.P.A.S, since it is licensed by A.M.P.A.S. Tags or branches in this repo is another option, but since there are multiple configs besides aces, versioning could be confusing between them. Just a thought.

[KelSolaar]

@michdolan : so I started to look at that last week, the idea as discussed with @aforsythe is for now to not break the house, and I will keep the current structure until I have an effectively working 1.1. It requires a bit of work to include the new outputTransforms.

I have wondered a time or two if the aces config would be better in its own repo, so it could have independent release versioning specific to aces.

Yes! My answer to that is summarised here in what we wrote in the ACES R.A.E. paper:

The official ACES OCIO configurations are hosted by Sony
Pictures Imageworks on Github with multiple forks being used
to feed the main repository. This organization is inconvenient
for various reasons, most notably when it comes to tracking
down where current work is happening [Jon17]. It raises the
question of whether the Academy should take the repository
under its wing, or make their fork the official entry point for
pull requests toward the Sony Pictures Imageworks repository.
This dependency structure further raises the questions on
the status of the development of the ACES OpenColorIO
configurations relative to the core ACES repository. The 1.0.1
configuration was developed as part of the ACES 1.0.1 release,
but the 1.0.2 and 1.0.3 were created somewhat independently.
Given the configuration’s role in enabling the use of ACES,
it could be more directly developed and supported by the
Academy team, and released alongside updates to the master
branch.
Adoption of ACES by VFX vendors would also benefit from
the Academy hosting the ACES OCIO configuration builds,
i.e. the config file, LUTs and ICC profiles along with the CTL
transforms, as first class products directly available from the
oscars.org website with links to the different versions. This
opportunity could be taken to prune the builds from the main
OCIO config repository as its size, 3.8 GB, is becoming a
worrying version control issue.

[KelSolaar]

I have a 1.1 config here with the SSTS based OTs: https://github.com/colour-science/OpenColorIO-Configs/tree/feature/aces-1.1-config/aces_1.1

It needs to be tested thoroughly but so far seems to be working.

Would be good to catch up with all the stakeholders to know how we move forward from this as The Foundry expressed the need for a 1.1 config as soon as. There are also the questions of alternate shapers (#18) and potential definition of both to_reference/from_reference for some difficult colourspaces.

Please note that any changes will be done under the Build "ACES 1.1" config. commit to avoid repo size explosion, i.e. I will re-write history of the feature branch as required.

[scoopxyz]

I've created a draft repo structure in my fork: https://github.com/scoopxyz/OpenColorIO-Configs

And started a more long-form discussion thread here: https://lists.aswf.io/g/ocio-dev/message/1839

[KelSolaar]

I just remembered that we should clarify with @JGoldstone what is the license for the code he added that implements the Hermite splines.

[alexfry]

All good from my end.

[selfshadow]

Fine by me.

[KelSolaar]

Thanks a lot @alexfry and @selfshadow!

[JGoldstone]

We are OK with this (the Hermite spline function definition and the augmentation of the IDT generator to use it) being released under the Academy license.

[KelSolaar]

Thank you so much @JGoldstone!

[michdolan]

Thanks all! I'm closing this PR since another will be opened from https://github.com/colour-science/OpenColorIO-Configs to update the ACES config license.