Slack Archive

If companies just want to use tech that someone else writes, then copyleft is no big deal. All of us use GPL'ed stuff in linux all the time, without giving it a second thought. But if companies want to contribute to tech that is copylefted, it's a whole different analysis.
Very good point, I had a chance to work with companies which are on both side means they are interested in contributing to the source code, as well as companies which just consume it (most of them obviously are on the consuming side).

Consuming part is not an issue as you mentioned. The problem is with contribution to the code. Practically speaking this is not easy thing to do, you can't just get random dev throw him into that space and hope that he would do right things. Just starting with 150 pages of whitepaper is high enough barrier for most. I think we can agree that having specific skill set is required and a lot of time to chew what Sam produced.

My point is that I don't see any big tech throwing resources here until they would see direct benefits. It is rather smaller companies or units which are interested into "let's see if we can create better future". They tried that with blockchain they would try it with KERI. Basically early adopters or believers where they can see benefits of having infrastructure like that.

In first stage where we are the biggest concern are startups and VC founded entities who under pressure of delivery won't have time to build it right and would do a lot of short cuts, in consequence which we could end up in the situation where they (intentionally - to gain competitive advantage, or unintentionally - just lack of time) would postpone to contribute back. This would lead to forks and lack of interoperability. When the technology would be at certain stage it would be necessary to bring it to the enterprise level where "big tech" companies comes in. We saw how IBM treated Indy or Fabric in that regards. Having this extra security would help community and smaller players to compete with them and benefit from their involvement when that would happen.

Are we still designing KERI and CESR?
I would say that we still are at the design level, Sam is doing amazing work to flesh all that all but we still observing some core changes in both keri and cesr. It is clear that without Sam this won't be possible and I would love to provide him all necessary resources to let him continue solving those problems and get stable spec, I think we are close enough but still lots of work is needed. The reason for it that we need to test it in practice to see how it would work, we are on PoC level where we would find out what else is missing. At least that is my judgment.

Speaking just for Provenant, I think we might be able to use EUPL-licensed code and run the risk that the copyleft provision in the license would never be enforced against higher levels of our software stack.
Understand completely and happy to assure you about that from our side and/or if needed put mentioned paragraph in place.

Robert cited a line from the license that says that if no other legal jurisdiction is identified, Belgium law applies. The "if" in the line is the problem, and it actually makes my point.
This is interesting point as well which actually not sure how applies to other licenses. I didn't saw many licences which specify what is applicable law of that license. Since we are decentralized community would it be always the person from first commit? Author jurisdiction?

I like that with EUPL that is explicit. you know exactly what to expect.
I agree with the point that EUPL didn't do it well by not specifying "derivation work" clearly without references to any other law framework. As this would make it super explicit and clear. We are planning to contribute that to the next version of EUPL to make sure that this would be cover, until then we need to bound it under EU law or explicitly specify that as you requested.

Since behind cesorx and keriox we have HCF as a author, we are under Belgium law (we are based in CH). Even that we have multiple contributors. We specifically wanted to have one entity behind it since it makes it easier for compliance and regulation. As you may know even if you have license and you would not specify copyrights this would fail any check in legal department). Not knowing who is behind it (as one entity) is the worst thing which you can have in enterprise. This was one of the reason why DIF changed their policy about individual contributes and similar activities we observe in ecosystem.

Furthermore, encryption registration with the BIS is required for the export of "mass market encryption commodities, software and components with encryption exceeding 64 bits" (75 FR 36494).


I needed to deal with that recently by just uploading an app to the apple store. No idea if that applies to open source a we build it here. Happy to hear someone opinion if he already checked that.

Would you be open to adding such a sentence to the license in your codebase,
Definitely, we already checking that with our lawyers what we can do in that regards to assure that this interpretation is as we stated. We do not aim to block adoption by any mean.