License issues

[OndrejPopp]

Hi opentimeline community,

I am just looking at your software that I want to incorporate in the open source kdenlive editor project that I am extending with features that I want. More specificaly a redesigened bin, or the root project folder where you can organize your media, subclips and folders.

I also want to have a more compact and readable project file, and so I have decided to incorporate your C++ API directly into it, to initialize timelines through it. In addition, I will be extending your software with an "open bin" API, to import and export the root project folder analogous to what you are already doing with the timelines.

In addition, I would also like to have yaml and (xml) import/export and so I will be adding that as well, especially yaml. (Although I will also add xml for completeness, but maybe not use it ..)

And now about the Apache license,
If I understand this correctly then apparently everyone can make money from my contributions without acknowledging me for a single penny... Depending ofcourse on your personal circumstances that does not look exactly fair. Ofcourse I can also sell my own work if I want to, but still.

Also with kdenlive, there are these donations, for 15000 Euro's, so they claim that are needed to implement new features while I was planning to release my derivative work to them, at my convenience, but free of charge.

So, when money comes along the whole open source ideology gets a bit more complicated. So I need some time to think this through, concerning kdenlive.

In the meantime, concerning your license, Apache license, concerning Article 2, I think it would be more fair to let the provider of the derivative work decide whether others are allowed to make money on it, or also give it away free of charge, like they have received it, or under what financial agreement, may also concern one's personal circumstances for example at older age, they are allowed to sell one's derivative woks.

Then, what does not seem fair to you, that if an author of a derivative work does not agree with your license to waive certain rights, and especially those I have mentioned here, then he or she does not have to release his derivative work to you, while he or she gets everything free of charge from you... And so, he or she can even sell it without acknowledging you or the authors from the past for a single penny... That's kind of the same thing isn't it?

In any case, these are my thoughts on this subject, and so maybe you could adjust a thing or two in your license? In any case, if you don't it's not really my problem, but still concerning also all the authors I wrote this down for you, free of charge, and you are not supposed to make money from this contribution without involving me. I write this last part in a funny way, but it kind of shows the issue at hand.

P.S, I just checked but the Apache license appears to respect my rights better than your contribution agreement that I am supposed to sign? Actually I wrote the above based on this contribution agreement assuming it would be the same as the Apache license but it appears to be more tight?

kind regards,
Ondrej Popp

[meshula]

Regarding Article 2, if you make a fork of the code, and apply your modifications to the fork, what you do with your modifications are up to you. Your only obligation is to make notes, in your own fork, about the things you modified so as not to misrepresent the origin of the modifications. There's no obligation to the original repo to contribute your modifications back.

The way to think of the Contributor's License is that it's simply a document stating that for anything you contribute to the project, you actually have the rights to do provide that code to the project.

It's true that anything that you contribute back is available for use by anyone using the project, and we haven't got any intent to introduce a commercial aspect to the licensing of the project. The license does allow you to sublicense your modifications in your own redistribution, as the license is intended to be friendly both to open source and proprietary uses.

Thanks for your thoughtful questions, I hope this brief explanation helps.

[OndrejPopp]

Tx for your explanation. Concerning the Contributors's License, I have already decided to "waive my rights to contribute to the project", because this gives me freedom to decide for myself under what license I want to release my derivative work.

Concerning the obligation to make notes in my derivative work about the modification, I would need to study this a bit more, looking at some real life examples to see how much effort it takes to make these notes, apparently in every file. When that proves too much of a hassle, I already figured out that I don't have to make any modifications to the original project, and use inheritance and make the modification in the derived classes, and in that way I don't have to explain anything, and it will be apparent already from the derivative work itself what the modifications entail.

Have a nice day,
kind regards,
Ondrej

[jminor]

Since you mention combining Kdenlive and OpenTimelineIO you may want to research some of the limitations that come up when mixing code with different licenses. For example here: https://stackoverflow.com/questions/1978511/is-there-a-chart-of-which-oss-license-is-compatible-with-which or this https://github.com/readme/guides/open-source-licensing

OpenTimelineIO's Apache 2.0 License is intended to make it very easy for you, and anyone else, to embed OTIO as a library within your application without imposing restrictions on your application. It is a gift to you, with very few strings attached (details in the license).

Also, I believe that OTIO is already in use within Kdenlive so all of this may already be settled: https://invent.kde.org/multimedia/kdenlive/-/blob/master/data/scripts/otiointerface.py#L6

[OndrejPopp]

Looked into that yesterday, Kenlive is at this moment released under GPL 3 which is compatible with Apache 2.0

As far as I understand it, ottio is at this moment used in Kdenlive only at the script level,
https://github.com/KDE/kdenlive-opentimelineio/blob/master/otio_kdenlive_adapter/adapters/kdenlive.py

So that's not really a derivative work of ottio.

In any case, the problem is not about using the software under Apache 2.0 or under any other license concerning the derivative work, but about the rights that the contributors are supposed to waive... Also, when you are required to sign a contribution contract when you want to give something back, then that's already a message all by itself...

I know ofcourse where this is coming from : This comes from employment contracts that some companies have. So when you are on a pay roll as an engineer or software developer, then it happens that for that financial compensation you are required to relinghuish your intellectual property rights, and sign a contract for that. You have also no ownership rights and so you can not decide on a license concerning your work either. This is already what this is, but at least you get a salary for that so you are financially (well) compensated.

Now, it can so happen that these companies such as Pixar presumably, decide to release some of their software as open source, and then think that they can impose the same restrictions on the contributors like on their employees. And now comes the catch : the contributors are not on the companies payroll... while they are required to relinghuish their intellectual property rights exactly in the same way or in a similar way as the employees have to, but without being financially compensated for that. And thàt is where the problem lies.

And so, like I already wrote, I rather relinghuish my "rights" to "contribute" under these conditions, than having to relinghuish my rights concerning the intellectual property of my derivative work.

Still, thank you for the software, and I don't have to, or even can not give my modifications back to you because "I have no right to contribute without signing a contract with you"

And so I would say this clearly illustrates where the problem lies, and where there is no problem at all, because the Apache lisence is very permissible...

Have a nice day,
Ondrej

[JeanChristopheMorinPerso]

Now, it can so happen that these companies such as Pixar presumably, decide to release some of their software as open source, and then think that they can impose the same restrictions on the contributors like on their employees. And now comes the catch : the contributors are not on the companies payroll... while they are required to relinghuish their intellectual property rights exactly in the same way or in a similar way as the employees have to, but without being financially compensated for that. And thàt is where the problem lies.

OTIO is not a Pixar project anymore. It's an Academy Software Foundation project, which make it a top level Linux Foundation project. These projects (including OTIO) have to protect themselves from corporations. They have to make sure that no company can claim ownership of their contributions and compromise the projects. As an individual contributor (IC), I would see the CLA as a protection for you and the project. (The usual warning: I am not a lawyer).

[OndrejPopp]

I know it's not a Pixar project anymore. But I still have a clone on my pc of that repository. So I could compare the commits to see where they stopped and you took over.

However, you are still using the same license Apache 2, under which they released it. Also this collaboration agreement is already there. So you took that over as well... Kind of weird isn't it, how open source projects protect themselves against companies by the same CLA they got from those companies in the first place while those companies are not the ones who have to sign these CLA's but people who would like to contribute to this project have to...

Furher, I don't know exactly how you think projects can protect themselves against ownership claims, but maybe you think that when you request from people to sign a contract before they can collaborate to waive their intellectual property rights the project is safe or what? Looks like the easy way out to me by means of abuse of power.

In any case, I already said more than enough about this, I think.

An other thing, you call this a top notch project but I don't really understand why. From what I can see in the C++ API its a not such a big amount of classes that form a representation of a timeline. Today I wrote some classes on my own because I needed those for the media bin and it's done in a day. So, I am thinking that I am also going to write some classes for a timeline as well. It's actually much easier than having to deal with all these legal issues. Having to document every change, or subclassing the whole API.... Might as well write my own classes then. And as an extra advantage I can tune this representation exactly towards kdenlive, and actually at this moment I don't need anything else. You still have a nice viewer though, but maybe I will connect to that later, or maybe make it work from my representation.

In any case,
Have a nice afternoon,
Ondrej

[meshula]

This reply isn't a comment about licensing, as everyone has to draw their own conclusions about project licenses.

I don't think Jean-Christophe was boasting about top-notch quality. Top level to me would mean that the ASWF is project directly under the Linux Foundation umbrella, and the Linux Foundation provides infrastructure and support to the project.

To your application use case, OTIO is meant as an interchange library, not as a timeline editing library. There are proposals to create editing interfaces, but that hasn't progressed to the stage of a PR. It makes sense for an editing application to have it's own unique timeline data structures tuned for the application itself, and to use OTIO to write your data in a format that other applications can use and to read files from other programs.

[OndrejPopp]

My application case, at least that part that I discussed over here is about data interchange and not editing.

At least data interchange between an infrastructure and xml/json/yaml. When you talk about data interchange between different video editors, and you would have standardized all that, that would be ofcourse great, and that's actually also the reason I am here, but you have only timelines and no media bins and you can only serialize/deserialize with json.

So, whatever "top notch" means exactly, and maybe it just means "Pixar Animation Studios" but like it is now, it is incomplete and so I would need to do some work on it, and then I get all these license issues, and a "Collaboration Agreement" that needs to be signed, and so it is much easier, I have decided on that now, to make my own data interchange infrastructure, and serialize and deserialize to and from that, and then connect the rest of the application to it. And at this moment I don't really care that much about standardisation, but once this infrastructure is operational you can ofcourse write serializers and deserializers to any other application you like. I have been even thinking about Dolpin over a socket or whatever.

Concerning standardisation, once I have extracted the IO data model from kdenlive it may prove to be very useful as a standard on itself. But in the meantime I don't care that much about that, and so this infrastructure will fit inside kdenlive as a glove, but that does not mean that it would not be a good abstraction to connect to other video editors.

But fine, if you want to talk top notch, then I would suggest to ramp this project up, to a complete data IO model for video editors. So OpenTimeline would then have to be renamed to OpenVideoEditorIO and then also release that under GPL and eliminate this Collaboration Agreement. So that people can just work with it... Under GPL.

So that would be great if something like that would be operational and standardized, but in the meantime I am going to make my own infrastructure, based on the data IO model of kdenlive, once I have dug that out, because that is kind of a problem with kdenlive, but on the other hand it has all the wistles and bells you would ever need. But it lacks a solid infrastructure. Actually thats not exactly true, there is an infrastructure that people have put in in the past, and so I am connecting to that, but that is not how the current development is going, because the current development is relying heavily on properties and mlt. And so I am kind of turning this tide back again towards the original infrastructure that is a bit abandoned here and there.

Concerning this I/O infrastructure, I don't really want to do this, putting this in, because I am implenting other features, but I am forced to do this otherwise I can't continue with the features I am putting in... Because the properties swamp is just not good enough.

And at the same time there is this fundraiser, you can read all about it here, https://kdenlive.org/en/fund/ And so it is about 15000 Euro's, 20000 Euro's and 25000 Euro's and then what they are going to do for that money.... yes.... and then I have to do all this to put my features in.

And we have now kind of come to a full circle, like I started this discussion that there are people that want money, let me put it like that, and then there are the Collaborators that work for free.... So at this moment I don't really know how I am going to release my work on kdenlive back to the good people, let's call them that, and make sure that the money craving people can not take advantage of this. And there is not a single open source license that can prevent this...

But that's for later, I just want to finish my features but that's not going to happen without a solid IO infrastructure for example.

Have a nice weekend,
Ondrej

[JeanChristopheMorinPerso]

So, whatever "top notch" means exactly, and maybe it just means "Pixar Animation Studios" but like it is now, it is incomplete

Just to clear things up, I didn't say top notch. I said top level. If you go on https://www.linuxfoundation.org/projects, you'll see both ASWF and OTIO are listed. This is what I mean by top level.

[OndrejPopp]

Tx Jean,
I had a look at it, and I found it yes. Among so many other projects. I will have a look at all of them later.
And just to clear things up a bit further, if I have to, concerning this terminology, all these projects must then apparently be top level according to you, whatever that really means then.

In any case I don't see the classificstion top level mentioned anywhere on that website.

But that's not really the issue is it? I wrote that I don't understand why you call this project top notch / top level, and I also explained why.

For the rest it's up to you.

Have a nice weekend,
Ondrej

P.S,
Just to clarify things a bit further, I just looked up the definitions of "top notch" and "top level",
https://www.merriam-webster.com/dictionary/top-notch
https://www.merriam-webster.com/dictionary/top-level

Apparently top notch means of the highest quality while top level means involving people of the highest level, position or rank... So it is possible that you have an issue that you need to take care of, if you think you or this project is of the highest level...

[reinecke]

@OndrejPopp I think you're still misunderstanding the meaning of "top level" in this context.
When @JeanChristopheMorinPerso and others from the community were saying "top level", they aren't referring to the quality of the project (I don't think any of us will ever be satisfied with that) - he was using "level" in reference to the levels in the hierarchical structure of The Linux Foundation, ASWF, and member projects.

Below is an illustration in awful ascii art:

     The Linux Foundation     <- Top level
             |
             v
           ASWF               <- Next level down
             |
             v
       OpenTimelineIO         <- Bottom level

From a governance perspective, the diagram shows the heirarchical levels in the organization. We're on a level below the ASWF - which is a level below the Linux Foundation.
By contrast, as a legal entity we exist at the "top level" of that hierarchical structure as part of The Linux Foundation's LF Projects, LLC. The "level" in this context was meant to convey that anything donated to this project when traced to the root of the ownership tree (or top level of the ownership hierarchy in other terms) is donated to The Linux Foundation's LLC.

In terms of the CLA and licensing question - we, as project maintainers, are mostly concerned with:

• Being good and inclusive community leaders
• Making direct contributions to the project
• Shepherding contributions from collaborators
• Teaching people about what the project is and how to use it to try and make it useful for them
• Understanding how to make the project more useful for it's intended purposes

We all care deeply about the legal framework under which this happens (especially how it applies to our ability to be inclusive), but we aren't lawyers and our expertise is limited in this area. The project moved into the ASWF and Linux Foundation in no small part because we trust their wisdom on things like what legal framework we should use to enable collaboration from a diverse set of contributors while being honest and fair about who benefits from the work. Your feedback about licensing is valuable and appreciated, but we may not be the exact right people to talk to about it because we aren't the experts in that area. As project maintainers, we largely defer the licensing questions to our mentors at the Linux Foundation who we genuinely believe are trying as hard as they can to be collaborative, inclusive, positive, and fair about contributions and ownership of the project's IP.

In terms of OTIO's technical suitability for your needs, it sounds like you may have made up your mind, but I just want to make sure you have the information you need to make a decision. We think there are some places where we do a pretty good job, and know there are many others where we're working on improving. If you haven't seen it already, the Application Integrator's Guide might be useful for some tips about how to think about OTIO and what tools it provides for integrating with applications like kdenlive.

Some other points that might be helpful based on your previous comments:

• You discussed needing a "bin" construct, OpenTimelineIO has something called a SerializableCollection which is meant to represent something like a bin.
• Among other things, a SerializableCollection can contain Clips, Timelines, and other SerializableCollection instances allowing you to create a deeply nested structure.
• You are correct, we don't currently have a concept of a root "project" object, but a SerializableCollection could potentially be used to serve this purpose.
• If there are OTIO objects that carry most of what you need but you want to add a little extra information, consider using the metadata dictionary available on all objects to carry the supplemental data - this may be able to add whatever you need extra to make a SerializableCollection usable as a "project" container.
• OpenTimelineIO supports serializing any kind of schema object as the root object in a .otio file - this means you can make an OTIO project file or bin file by telling it to write a SerializableObject rather than a Timeline as the root object.

In terms of serialization format choice (JSON vs. XML vs. YAML) - I'm curious what the use case for the alternate formats are. Is the intention to give people options for hand-editing the files? We write .otio in JSON because it's a relatively human-readable format and there is a good chance someone far in the future would be able to hand construct a parser to interpret it. However, we hope people don't need to do that and can either rely on various applications to competently read and write .otio or they can adopt one of the C++ library's language bindings to deserialize OTIO objects into memory and serialize them out to .otio.

The key benefits of OTIO are that it has a robust open source community, first-party vendors are adding support in more and more widely used content creation applications, and it saves you from re-inventing certain timeline data models. All that said, only you know whether or not it's the right fit for you and your users.

In one final note, I would feel uncomfortable if I didn't address this statement:

Apparently top notch means of the highest quality while top level means involving people of the highest level, position or rank... So it is possible that you have an issue that you need to take care of, if you think you or this project is of the highest level...

It's fine to criticize the project, but to maintain a healthy and inclusive community we ask that you respect our code of conduct and be a bit more civil - attacking someone personally is not acceptable.

[OndrejPopp]

Dear Eric,
I will read your full explanation later.

However, I saw your last remark, and can not wonder myself why you think it is a personal attack when I think someone may have a personal issue?

Because if that can not be said, in the full context of what I have been talking about, and then an issue is raised whether someone said "top notch" or "top level"... yes... and then my response violates apparently your code of conduct, then I think this was my last contribution to this project.

Whatever technical reasons I may have further I keep those to myself.

I have given you more than enough information and you have given me nothing.

Have a nice afternoon,
Ondrej

[OndrejPopp]

Good evening Eric,
I just had a look at your code of conduct.

And so, I find bullet 3 under acceptable behaviour, or even requested behavior,

Gracefully accepting constructive criticism

And so now I think that apparently my advise towards Jean does not violate your code of conduct at all, but your attitude towards me does, more specific : obstruction and sabotage of the good intentions as protected by the above bullet point.

I will give you some more time to provide motivation about your statement towards me. But please, by quoting your code of conduct such as I do now.

And if we can not come to an agreement, then I would like to take this to the top level including all the other issues I raised.

Have a nice evening,
Ondrej