CCLAs aren't a burden for keeping track of, and some companies do use them for SGAs, too; I've gotten CCLAs signed before at previous employers or when I was an independent consultant and got to submit one for myself as the owner. The fact that some companies insist on having a CCLA (usually companies with many IP lawyers), though, does have strong parallels in what Jarek's experiences have been in getting companies to sign contracts.
On Wed, May 11, 2022 at 2:09 PM Jarek Potiuk <ja...@potiuk.com> wrote: > > One small comment. > > Just the fact that we are discussing CCLA vs. ICLA is an indication that an > average contributor who wants to enter into a relationship with a corporate > customer w/regards to OSS/Apache related work is at a complete loss. > > It means that we BADLY need a legal entity that will handle the legal side > of the relationship. > > I've added CCLA only because my lawyers advised me that my Slovakian > company that I use for my invoicing (which I solely own) should have it - > because I issue invoices by this company. > But I do not expect any of my corporate customers to sign CCLA and put my > name there if I am an independent contractor working for them, Being an > independent vendor/contractor is very different from being an employee in > this case. That is next to impossible to get CCLA with your name in it when > you are not an employee. Even if you are an employee in a big company you > are not likely to get it. So CCLA is generally out of the discussion here. > ICLA is what matters and recognition of it is (IMHO) something that should > be in a contract with any vendor. That's where I see the role of "OCC + > ASF" which could provide legal framework and support for it - to any > contributor who does not even understand what we are talking about. > > J. > > On Wed, May 11, 2022 at 8:52 PM Dave Fisher <w...@apache.org> wrote: > > > > > > > > On May 11, 2022, at 11:43 AM, Matt Sicker <boa...@gmail.com> wrote: > > > > > > A CCLA isn't sufficient for contributions at Apache, though. An ICLA > > > is always required to be a committer, for example, regardless if every > > > breath you take is copyrighted by your employer. A CCLA can be useful > > > for documenting whether a corporation has explicitly approved various > > > individuals they employ to contribute, but it's more of a comfort > > > thing. If you read the ICLA, you'll see this bit: > > > > > > You represent that you are legally entitled to grant the above > > > license. If your employer(s) has rights to intellectual property > > > that you create that includes your Contributions, you represent > > > that you have received permission to make Contributions on behalf > > > of that employer, that your employer has waived such rights for > > > your Contributions to the Foundation, or that your employer has > > > executed a separate Corporate CLA with the Foundation. > > > > > > The CCLA is optional because the ICLA already requires that you've > > > gotten approval from any owners. The CCLA can formally document this, > > > but it's already implied by the ICLA. > > > > True, but (1) I was a brand new committer and (2) it made it clear that my > > employer could NOT change their mind arbitrarily. > > > > I probably could have argued that the company that acquired my employer, > > my new employer, was bound by the CCLA … the ASF may only require an ICLA, > > but an individual may prefer that a CCLA is filed, That use case and > > language is in the ICLA BTW. > > > > > or that your employer has > > > executed a separate Corporate CLA with the Foundation. > > > > > > I’m not sure why you’re arguing this? Are CCLAs a burden to the Secretary? > > > > > > > > On Wed, May 11, 2022 at 12:54 PM Dave Fisher <w...@apache.org> wrote: > > >> > > >> When I first signed an ICLA in about 2008 I made sure that I had the > > company I worked for sign a CCLA that named individuals. This was for my > > protection otherwise my ASF work was work for hire. > > >> > > >> Later that company was acquired and my position was senior enough that > > all of my work belonged to them. > > >> > > >>> On May 11, 2022, at 10:37 AM, Matt Sicker <boa...@gmail.com> wrote: > > >>> > > >>> 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 > > >>> > > >> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > >> For additional commands, e-mail: dev-h...@community.apache.org > > >> > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > > For additional commands, e-mail: dev-h...@community.apache.org > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > For additional commands, e-mail: dev-h...@community.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
