> 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
