Small point of clarification: only the ICLA matters at Apache since contributions are made by individuals. The CCLA is provided for companies so perplexed by this concept that they feel the need for more paperwork.
On Wed, May 11, 2022 at 4:36 AM Jarek Potiuk <ja...@potiuk.com> wrote: > > > > > > > I guess my point about this is, that small startups usually have problems > > of getting contracts. > > > > I can't count the occasions, where I generated leads at a conference. > > After the conference, when we were discussing moving forward, 95% of all of > > these died because the customers can't do business with such small > > companies. > > > > > This is also my assessment of where the problem is. I think building > relationships and finding customers in an OSS world is relatively easy if > you are transparent, honest, do your job well and you are open to speak, > you make sure you stand out of the crowd and you are generally proud of > what you do (yes Chris - those all things are about you too :D). > > It's turning them into a regular invoice paid every month is where the > difficulty is. > > However I think we need to really understand where the "can't do business" > comes from. My view on this: > > 1) The businesses have established procurement processes and you have to > "fit" - in most cases there are a number of conditions: > - you have to "be on the list" of the approved vendors > - in many you have to sign certain agreements that you do not "child > labour", "bribery" etc. and similar thing (basically because public > companies have to report that their vendors are "ok" to the auditors > - in many cases the business have to have someone to "sue" in case > there is a damage or have some other indemnification in place - (what if > the vendor does harm to our customers and we get sued) > - there is also a check who is the beneficiary owner (money laundering) > W1-BEN forms in US when you have "individuals" > - also - and this is more important recently - there is a check if your > company does not fall into any of the sanctions imposed by the political > decisions > - there are a number of legal requirements (TAX Id registrations etc.) > > Having an entity that is "known" to the customer and "big" and can provide > such guarantees is crucial otherwise it's a big effort to pass that step. > Here Both "Support Inc." and "Open Collective + ASF as fiscal host" - if we > can think about the two models, would likely work well. The "burden" of > verifying those is shifted to OpenCollective and ASF joint effort and I > think it should be feasible to put both OC and ASF as "accepted vendor > combo" for most big players. And for each player it would have to be done > once to enable all projects basically. > > 2) We also have to remember that people who we contact as potential > customers often are not familiar with those processes - and even if they > "want" to work with you - this might be the first time they approach it and > it can take them MONTHS to get it sorted out. > I can - again - give a very good example. I mentioned "contract" > negotiations before - and it is an interesting one. The prospective > customer people really wants to work with me. I really love what they do > and I have great contact there who is willing to take on all the complexity > of managing the OSS <> Company relations between me and the company - we > are also friends and worked together on a number of initiatives in the > project (successfully) and we both want to work together. And the manager > of my friend and his manager are fully supportive. And ~ 2 months ago the > joint statement was "we really want to start working together basically > next week". We still have no contract signed today. We know the price, we > know how much time I will focus on with the customer, we know what the > needs of the customer are. We know big parts of it will end up as good > community contributions. EVERYTHING is in place. But they never ever had a > contract with someone like me. I have a requirement that the contract from > the customer is explicit about my ICLA (and my self-owned company CCLA) and > this is with the lawyers of the company now. > > Here - this is something that 1) will make easier - because (hopefully) we > could work out a template contract and having bigger entity (whether > Support Inc or OC + ASF Combo) we could probably have some established > "service" with all the documents prepared, and all the answers given and > even some guidance to our "partners" at the corporates on how they can > clear their processes faster. But there is one caveat (see point 3) as our > relation is a bit different. > > 3) The 2) might take much longer mostly because we - OSS contributors - > have a different type of relationship than regular vendors. For most of the > vendors, big businesses have some expectations that we cannot meet and we > fall into "legalities" and contract signing. > > There are two kinds of those: > > * we cannot guarantee that whatever the customer wants will be fulfilled > when we contribute to ASF projects. Most big players look at such a > relation from "I pay - I demand" and most of the internal audits will have > a hard time on accepting a contract where there is no "deliverable" that > the company can "demand to complete". I found this extremely hard to > negotiate in the past. Usually it ends up with some kind of "blurry" > statement which can be interpreted differently and both parties (usually > mostly vendors) have to accept the risk that if the other party wants - > they can "exercise" some statements "But you have not delivered this - you > promised it in contract". Bue t over the last few years I actually managed > to convince some of the parties I work with to put some explicit statements > that "the work is subject to community rules ..." and I am for one - super > happy with the contracts I have now - because it does not put an obligation > on me that I cannot fulfill > > * and there is the bigger problem about IP. Basically for pretty much all > the customer <-> vendor relationships almost by default you have that "all > the IP produced during the relation belongs to us". Which is - IMHO against > the Apache Way and against the ICLA and CCLA that we have with ASF. When > you develop a code in the ASF you contribute it to ASF as an individual. > This is a bit blurry in the current approach because (at least this is how > I understand it) ICLA governs my individual contributions, while CCLA > governs contributions of your employees. But when you have a 3d-party > vendor (And I am not a lawyer so I might be wrong about this) - even if the > CCLA is signed with the ASF by the customer, it does not automatically > apply to a vendor <> customer relationship. So if I sign a standard > agreement that customer "usually" signs with the vendor - all the IP > belongs to the customer - and I cannot legally contribute it to ASF without > explicit permission for every contribution by the customer. Which is > definitely wrong and puts me under a huge legal risk if I actually > contribute some code that was created during that relationship - because > the customer might claim I should not do it. This is actually why I have > not signed the contract with the new customer yet - because the contract I > got from them (as opposed to my proposal) did not contain explicit > mentioning of the ICLA/CCLA I personally and my own company has signed with > the ASF and that the code contributed this way does not belong to the > customer. > > Here I think "Support Inc." is at disadvantage over the OCC + ASF combo. > The problem is, that if "Support Inc." will be "just another company" - > there will be no way it could negotiate either the "demand" or the "IP" > part with the big customers IMHO. They will treat it as a "regular" vendor > and will expect it to provide the usual "all code belongs to us" and > "deliverables you have to fulfill". Surely the "Support Inc," **could** > agree to that and have different agreement with the contributors, but that > would be an enormous business/legal risk to take that on (and it would not > be transparent and well, even possibly dishonest - promising something you > are not able to promise and claiming that the code belongs to you where it > does not). But with the OCC + ASF combo, there is a chance that the same > negotiations I did with my customers and the same "explicitness" in > contract might be agreed to. That needs some legal/contract etc. work, but > it has a chance to scale well - because unlike "projects scope" those > provisions would be identical for all projects participating. And if the > OCC + ASF combo would also become "known" and signs similar agreements with > one or two big players, transferring it to the next players might become > easier and make a "snowball" effect. The nice thing about it is that it has > "special" status - without - I think breaching the bylaws and approach of > ASF when it comes to non-profit status. > > Now - we can see those three approaches I think: > > 1) ASF does all the work, establish the payment structure and invoicing but > also starts being the intermediary of the project <> customer relationship > - this is not possible due to non-profit status of ASF as I see it and as > has been said multiple times > > 2) Support Inc. is established - but it can't be endorsed and it's hard to > say how it can have "special" status that would make the negotiations with > the customers on the demands and IP > > 3) OCC (or other similar) + ASF as "fiscal host" combo - this has at least > a chance (subject to legal review and by-laws and likely some > interpretations) of providing the right legal + accounting framework > (fiscal host) while out-sourcing the customer <> contributor relationship > to OCC but keeping the "reputation" and "special status" allowing to build > a scalable and repeatable framework for multiple projects to tap in. > > Of course - maybe it's just "legal optimization" and trying to shuffle > things around, and maybe it does not have a "legal ground" - because there > might be some "implicit responsibilities" that the ASF might not want to > take in such a combo. But at least from the first glance it looks like it > might work. > > > J. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
