You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Todd Lipcon <to...@apache.org> on 2015/12/14 21:18:59 UTC
SGA Alterations
Hi folks,
I'm working with our legal counsel on the SGA for Kudu and Impala entering
the incubator. He requested a few small clarifications to the SGA text
which he feels are important before we can sign the SGA.
Could you please review the changes in the attached doc and let us know if
this will be OK from the ASF side?
Thanks
-Todd
Re: SGA Alterations
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 14.12.2015, at 18:18, Todd Lipcon <to...@apache.org> wrote:
>
> Could you please review the changes in the attached doc and let us know if this will be OK from the ASF side?
I don't speak officially, but the following change to me also looks like a breaker.
"2. Licensor represents that, to Licensor's present knowledge, **and with no investigation**, Licensor is legally entitled to grant the above license."
People submitting an SGA should have done their due diligence to make sure they are entitled to grant the license. Stating that "no investigation" was performed sound to me like "here you have the code, but actually I have no idea if I can actually give it to you and I don't care really too much either".
Cheers,
-- Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: SGA Alterations
Posted by Todd Lipcon <to...@cloudera.com>.
Thanks, Roy and others, for your work looking at the suggestions and
explaining the reasoning. I've conferred with our executives and our GC and
managed to get the existing SGA executed. Will be submitting it later this
afternoon.
-Todd
On Thu, Dec 17, 2015 at 12:59 PM, Roy T. Fielding <fi...@gbiv.com> wrote:
> On Dec 15, 2015, at 1:52 PM, Todd Lipcon <to...@apache.org> wrote:
>
> Hi Jim,
>
> Here's the response from our attorney:
>
>>
>> - The change in the first Whereas clause indicates that we are granting a
>> “license,” not conveying ownership / title. The word used “contribute” has
>> no meaning in the copyright act. Congress drafted the copyright act and
>> included the word “license” not “contribute”. So it should be clarified.
>> Clearing this ambiguity helps Apache so that its “license” rights are
>> certain.
>>
>
> Irrelevant -- whereas clauses are for communicating background information.
>
> - Paragraph 1: “now” is inserted because Cloudera cannot grant a
>> license to a patent not yet owned or issued. By using language contrary to
>> the patent act, it could have the effect of rendering the actual grant
>> faulty. Apache would not benefit from that. The word “now” should be
>> included so its clear that it applies to patents currently owned and issued.
>>
>
> Bullshit! That isn't true. Licensing falls under the general category of
> agreements, not just the patent act,
> and it is certainly possible to agree to do something in the future even
> if it can't be done today.
> Otherwise, all those jokes about first-born sons wouldn't have been
> invented.
>
> The suggested change would fail to accomplish the goals of the license. An
> inventor has a year
> to submit a patent and the PTO may spend up to 20 years examining it
> before the patent itself is granted
> and thereafter "owned". The goal of our license is to prevent submarine
> submission of code for us to make
> popular while the owner waits for such a patent to be granted, which would
> allow them to sue anyone
> who makes use of their contribution after *we* made it popular.
>
> - Paragraph 2 indicates that the grant is made w/o investigation
>> and based on knowledge. This is not a “hedge”. This language makes it
>> consistent with the warranty exclusion included in the agreement. Without
>> this clarification, the warranty exclusion could be seen as being at odds
>> with the grant. Apache does not benefit from this ambiguity.
>>
>
> We are not interested in such an exclusion. It is users of Apache
> software that benefit from honest
> contributions of code.
>
> - Paragraph 2 indicates that the statement is made as of the
>> Effective Date. There is no obligation to monitor future developments or
>> future actions. Again, such a prospective obligation would be inconsistent
>> with the warranty exclusion. Without this, the conflict could be read
>> against the drafter (Apache), and it would not benefit them from this
>> result.
>
> I also add that by making the agreement more accurate, more consistent
>> with law and less internally ambiguous it makes these types of reviews and
>> discussions less common. The Apache person indicates that others have
>> sought to have changes made, but Apache consistently says "no". I think
>> Apache benefits from having a more readily acceptable agreement. This
>> could speed their process without introducing any risk.
>
>
> There is no conflict. At worst, reading it against Apache would have the
> suggested effect
> because there is no other date provided. Not specifying a date means the
> same agreement can
> be used or understood to apply to each contribution over time.
>
> At best, the suggested change allows a deliberately disingenuous company
> to make a "grant"
> to the ASF during a patent application process and, later, after the
> patent is granted, enforce
> their patent while saying the grant was not a deceptive practice because
> of the effective date.
>
> He also suggested that speaking directly with a licensing attorney on the
> ASF side might be easier than going through us non-lawyers as
> intermediaries :)
>
>
> I am not surprised, since it avoids the people with the most experience.
>
> ....Roy
>
>
--
Todd Lipcon
Software Engineer, Cloudera
Re: SGA Alterations
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
> On Dec 15, 2015, at 1:52 PM, Todd Lipcon <to...@apache.org> wrote:
>
> Hi Jim,
>
> Here's the response from our attorney:
>
> - The change in the first Whereas clause indicates that we are granting a “license,” not conveying ownership / title. The word used “contribute” has no meaning in the copyright act. Congress drafted the copyright act and included the word “license” not “contribute”. So it should be clarified. Clearing this ambiguity helps Apache so that its “license” rights are certain.
Irrelevant -- whereas clauses are for communicating background information.
> - Paragraph 1: “now” is inserted because Cloudera cannot grant a license to a patent not yet owned or issued. By using language contrary to the patent act, it could have the effect of rendering the actual grant faulty. Apache would not benefit from that. The word “now” should be included so its clear that it applies to patents currently owned and issued.
Bullshit! That isn't true. Licensing falls under the general category of agreements, not just the patent act,
and it is certainly possible to agree to do something in the future even if it can't be done today.
Otherwise, all those jokes about first-born sons wouldn't have been invented.
The suggested change would fail to accomplish the goals of the license. An inventor has a year
to submit a patent and the PTO may spend up to 20 years examining it before the patent itself is granted
and thereafter "owned". The goal of our license is to prevent submarine submission of code for us to make
popular while the owner waits for such a patent to be granted, which would allow them to sue anyone
who makes use of their contribution after *we* made it popular.
> - Paragraph 2 indicates that the grant is made w/o investigation and based on knowledge. This is not a “hedge”. This language makes it consistent with the warranty exclusion included in the agreement. Without this clarification, the warranty exclusion could be seen as being at odds with the grant. Apache does not benefit from this ambiguity.
We are not interested in such an exclusion. It is users of Apache software that benefit from honest
contributions of code.
> - Paragraph 2 indicates that the statement is made as of the Effective Date. There is no obligation to monitor future developments or future actions. Again, such a prospective obligation would be inconsistent with the warranty exclusion. Without this, the conflict could be read against the drafter (Apache), and it would not benefit them from this result.
> I also add that by making the agreement more accurate, more consistent with law and less internally ambiguous it makes these types of reviews and discussions less common. The Apache person indicates that others have sought to have changes made, but Apache consistently says "no". I think Apache benefits from having a more readily acceptable agreement. This could speed their process without introducing any risk.
There is no conflict. At worst, reading it against Apache would have the suggested effect
because there is no other date provided. Not specifying a date means the same agreement can
be used or understood to apply to each contribution over time.
At best, the suggested change allows a deliberately disingenuous company to make a "grant"
to the ASF during a patent application process and, later, after the patent is granted, enforce
their patent while saying the grant was not a deceptive practice because of the effective date.
> He also suggested that speaking directly with a licensing attorney on the ASF side might be easier than going through us non-lawyers as intermediaries :)
I am not surprised, since it avoids the people with the most experience.
....Roy
Re: SGA Alterations
Posted by Richard Fontana <rf...@redhat.com>.
On Wed, Dec 16, 2015 at 09:12:01AM +0100, Philippe Ombredanne wrote:
> On Tue, Dec 15, 2015 at 10:52 PM, Todd Lipcon <to...@apache.org> wrote:
> >> - Paragraph 1: “now” is inserted because Cloudera cannot grant a
> >> license to a patent not yet owned or issued.
A commitment to grant licenses or covenants covering future-acquired
patents is actually fairly common.
> >> By using language contrary to
> >> the patent act, it could have the effect of rendering the actual grant
> >> faulty. Apache would not benefit from that. The word “now” should be
> >> included so its clear that it applies to patents currently owned and issued.
The ASF should note that this would be a fairly significant change (or
rather ambiguity-resolution) in favor of the patent-holding company.
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: SGA Alterations
Posted by Philippe Ombredanne <po...@nexb.com>.
On Wed, Dec 16, 2015 at 7:56 PM, Todd Lipcon <to...@cloudera.com> wrote:
[....]
> IANAL so I'm not going to try to pass my interpretation of legalese. I'll
> answer your questions though outside the context of the agreement in
> question.
>
>> Cloudera has patents filed but not yet granted that apply to the domain.
>> Cloudera has patents for sure [1].
>
> Yes, this is true. We have some patents under application and/or pending for
> parts of Kudu. I'm not sure about Impala, but likely to be the same.
>
>> Therefore it cannot make any patent grant for now to Apache under the
>> SGA because
>> the patents have not been granted yet.
>
> That's how I understood the feedback from our counsel -- that the current
> language tries to grant rights to something which can't be granted until the
> patent is actually granted, and hence needs an 'effective date'.
>
>> If the future, if these patents are effectively granted to Cloudera,
>> then using Impala or Kudu
>> would imply using these patents, but no grants would have been made to
>> Apache and therefore
>> to its users?
>
> Given that the patents have bearing on code contributed under the Apache
> license (all of the source code files have the Apache license already since
> these projects are already open source), my understanding is that the patent
> license is already covered by the language. Thus, the SGA is already a
> "belt-and-suspenders" measure.
>
> For example, I as a Cloudera employee have applied for other patents on code
> I contributed to HBase and HDFS in the past. No special SGA was required for
> those since the contributions were under the Apache license.
>
>> If any of this is vaguely true my head is spinning and I cannot fathom
>> the implication whether or not
>> the SGA is used as-is or amended.
>
> That's why I'm trying my best to get our lawyer in touch with another
> lawyer. I don't mean any disrespect to the hard-working volunteers on the
> legal-discuss list, but this kind of stuff is above our heads, and should be
> discussed by people who are licensed IP attorneys to make sure we don't miss
> anything on either end.
>
> I also want to clarify one thing: it seems like some folks on the list are
> trying to attribute some kind of malice or "trickery" to the request here.
> Cloudera is not new to the ASF. We've contributed several other projects via
> the incubator in the past, have 8 or so Apache members on staff, etc.
[...]
Todd:
Thank you ++ for your detailed reply. It levies any concerns I could have had.
And clearly I can see no trickery there based on your explanation.
But heck I am like you a coder and not a lawyer: mama always told me in
my crib that you could not trust what a lawyer says [1], so your plain English
coder-to-coder clarifications have been welcomed.
[1] https://bandoenginlove.files.wordpress.com/2012/07/the-lawyer-is-lying.jpg
--
Winkingly
Philippe Ombredanne
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: SGA Alterations
Posted by Todd Lipcon <to...@cloudera.com>.
On Wed, Dec 16, 2015 at 11:12 AM, Alex Harui <ah...@adobe.com> wrote:
> Todd,
>
> If Cloudera signed SGAs in the past, why do they want changes before
> signing this one?
>
My guess is either:
a) we had SGAs signed by contributing engineers or managers but not
reviewed by legal counsel
or
b) we hadn't hired a general counsel at the time in which we signed the
SGAs. Our current GC is probably being more careful than we were in the
past given that we're a much larger company (>~10x larger since we
contributed Sqoop for example)
I looked in the foundation/ SVN repo and couldn't find where previously
submitted SGAs are stored. Otherwise I could probably figure out which of
the above applies.
-Todd
>
> -Alex
>
> From: Todd Lipcon <to...@cloudera.com>
> Reply-To: "legal-discuss@apache.org" <le...@apache.org>
> Date: Wednesday, December 16, 2015 at 10:56 AM
> To: legal discuss <le...@apache.org>
> Cc: Jim Jagielski <ji...@jagunet.com>
> Subject: Re: SGA Alterations
>
> On Wed, Dec 16, 2015 at 12:12 AM, Philippe Ombredanne <
> pombredanne@nexb.com> wrote:
>
>>
>> Todd:
>> Just to make sure I understand the gist of this, would this
>> reformulation be more or less correct?
>>
>
> IANAL so I'm not going to try to pass my interpretation of legalese. I'll
> answer your questions though outside the context of the agreement in
> question.
>
>
>>
>> Cloudera has patents filed but not yet granted that apply to the domain.
>> Cloudera has patents for sure [1].
>>
>
> Yes, this is true. We have some patents under application and/or pending
> for parts of Kudu. I'm not sure about Impala, but likely to be the same.
>
>
>>
>> Therefore it cannot make any patent grant for now to Apache under the
>> SGA because
>> the patents have not been granted yet.
>>
>>
> That's how I understood the feedback from our counsel -- that the current
> language tries to grant rights to something which can't be granted until
> the patent is actually granted, and hence needs an 'effective date'.
>
>
>> If the future, if these patents are effectively granted to Cloudera,
>> then using Impala or Kudu
>> would imply using these patents, but no grants would have been made to
>> Apache and therefore
>> to its users?
>>
>
> Given that the patents have bearing on code contributed under the Apache
> license (all of the source code files have the Apache license already since
> these projects are already open source), my understanding is that the
> patent license is already covered by the language. Thus, the SGA is already
> a "belt-and-suspenders" measure.
>
> For example, I as a Cloudera employee have applied for other patents on
> code I contributed to HBase and HDFS in the past. No special SGA was
> required for those since the contributions were under the Apache license.
>
>
>>
>> If any of this is vaguely true my head is spinning and I cannot fathom
>> the implication whether or not
>> the SGA is used as-is or amended.
>>
>
> That's why I'm trying my best to get our lawyer in touch with another
> lawyer. I don't mean any disrespect to the hard-working volunteers on the
> legal-discuss list, but this kind of stuff is above our heads, and should
> be discussed by people who are licensed IP attorneys to make sure we don't
> miss anything on either end.
>
> I also want to clarify one thing: it seems like some folks on the list are
> trying to attribute some kind of malice or "trickery" to the request here.
> Cloudera is not new to the ASF. We've contributed several other projects
> via the incubator in the past, have 8 or so Apache members on staff, etc.
> I'm just currently trying to find a workable solution between three
> parties: (a) our legal counsel who is uncomfortable with the current
> wording, (b) our company's decision to contribute new projects to the ASF,
> and (c) the ASF itself who prefers not to change the SGA. My guess is that
> 'b' is the least likely to change (we are committed to contributing these
> projects to the ASF). So, I either have to convince our counsel that the
> current SGA is fine, convince our executives to sign the SGA against our
> counsel's advice, or convince the ASF to allow the modifications. I'll work
> each of these avenues in parallel.
>
> If the general consensus is that the SGA is _not_ required for the code
> import, I'm happy to move on with the incubation process while continuing
> to sort this out in the background. But, would like to have some more
> confirmation that this is the case instead of just one Member's opinion
> which conflicts with the online policies posted on the incubator site.
>
> -Todd
>
--
Todd Lipcon
Software Engineer, Cloudera
Re: SGA Alterations
Posted by Alex Harui <ah...@adobe.com>.
Todd,
If Cloudera signed SGAs in the past, why do they want changes before signing this one?
-Alex
From: Todd Lipcon <to...@cloudera.com>>
Reply-To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Date: Wednesday, December 16, 2015 at 10:56 AM
To: legal discuss <le...@apache.org>>
Cc: Jim Jagielski <ji...@jagunet.com>>
Subject: Re: SGA Alterations
On Wed, Dec 16, 2015 at 12:12 AM, Philippe Ombredanne <po...@nexb.com>> wrote:
Todd:
Just to make sure I understand the gist of this, would this
reformulation be more or less correct?
IANAL so I'm not going to try to pass my interpretation of legalese. I'll answer your questions though outside the context of the agreement in question.
Cloudera has patents filed but not yet granted that apply to the domain.
Cloudera has patents for sure [1].
Yes, this is true. We have some patents under application and/or pending for parts of Kudu. I'm not sure about Impala, but likely to be the same.
Therefore it cannot make any patent grant for now to Apache under the
SGA because
the patents have not been granted yet.
That's how I understood the feedback from our counsel -- that the current language tries to grant rights to something which can't be granted until the patent is actually granted, and hence needs an 'effective date'.
If the future, if these patents are effectively granted to Cloudera,
then using Impala or Kudu
would imply using these patents, but no grants would have been made to
Apache and therefore
to its users?
Given that the patents have bearing on code contributed under the Apache license (all of the source code files have the Apache license already since these projects are already open source), my understanding is that the patent license is already covered by the language. Thus, the SGA is already a "belt-and-suspenders" measure.
For example, I as a Cloudera employee have applied for other patents on code I contributed to HBase and HDFS in the past. No special SGA was required for those since the contributions were under the Apache license.
If any of this is vaguely true my head is spinning and I cannot fathom
the implication whether or not
the SGA is used as-is or amended.
That's why I'm trying my best to get our lawyer in touch with another lawyer. I don't mean any disrespect to the hard-working volunteers on the legal-discuss list, but this kind of stuff is above our heads, and should be discussed by people who are licensed IP attorneys to make sure we don't miss anything on either end.
I also want to clarify one thing: it seems like some folks on the list are trying to attribute some kind of malice or "trickery" to the request here. Cloudera is not new to the ASF. We've contributed several other projects via the incubator in the past, have 8 or so Apache members on staff, etc. I'm just currently trying to find a workable solution between three parties: (a) our legal counsel who is uncomfortable with the current wording, (b) our company's decision to contribute new projects to the ASF, and (c) the ASF itself who prefers not to change the SGA. My guess is that 'b' is the least likely to change (we are committed to contributing these projects to the ASF). So, I either have to convince our counsel that the current SGA is fine, convince our executives to sign the SGA against our counsel's advice, or convince the ASF to allow the modifications. I'll work each of these avenues in parallel.
If the general consensus is that the SGA is _not_ required for the code import, I'm happy to move on with the incubation process while continuing to sort this out in the background. But, would like to have some more confirmation that this is the case instead of just one Member's opinion which conflicts with the online policies posted on the incubator site.
-Todd
Re: SGA Alterations
Posted by Jim Jagielski <ji...@apache.org>.
> On Dec 16, 2015, at 1:56 PM, Todd Lipcon <to...@cloudera.com> wrote:
>
>
> I also want to clarify one thing: it seems like some folks on the list are trying to attribute some kind of malice or "trickery" to the request here. Cloudera is not new to the ASF.
Not at all... the term 'hedge' is not judgmental at all and that
is the only phrase that I saw that you could be referring to.
However, it must also be mentioned that your counsel is also, even
when improving upon a generic agreement, also has your best
interests at heart and would hardly suggest things that, all
else being equal, would decrease what is beneficial for Cloudera;
at the worst, it would be a null loss/gain. But that is far from
trickery or malice.
As you state, the changes are along the lines of
providing clarification, but these clarifications are
to the primary benefit of Cloudera, as noted by rfontana.
I trust Richard's PoV and advice whole-heartedly. As such,
I think that the ASF must deny the request for these changes
and for any consideration of us signing the modified SGA.
--
Jim Jagielski, VP Legal Affairs
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: SGA Alterations
Posted by Todd Lipcon <to...@cloudera.com>.
On Wed, Dec 16, 2015 at 12:12 AM, Philippe Ombredanne <po...@nexb.com>
wrote:
>
> Todd:
> Just to make sure I understand the gist of this, would this
> reformulation be more or less correct?
>
IANAL so I'm not going to try to pass my interpretation of legalese. I'll
answer your questions though outside the context of the agreement in
question.
>
> Cloudera has patents filed but not yet granted that apply to the domain.
> Cloudera has patents for sure [1].
>
Yes, this is true. We have some patents under application and/or pending
for parts of Kudu. I'm not sure about Impala, but likely to be the same.
>
> Therefore it cannot make any patent grant for now to Apache under the
> SGA because
> the patents have not been granted yet.
>
>
That's how I understood the feedback from our counsel -- that the current
language tries to grant rights to something which can't be granted until
the patent is actually granted, and hence needs an 'effective date'.
> If the future, if these patents are effectively granted to Cloudera,
> then using Impala or Kudu
> would imply using these patents, but no grants would have been made to
> Apache and therefore
> to its users?
>
Given that the patents have bearing on code contributed under the Apache
license (all of the source code files have the Apache license already since
these projects are already open source), my understanding is that the
patent license is already covered by the language. Thus, the SGA is already
a "belt-and-suspenders" measure.
For example, I as a Cloudera employee have applied for other patents on
code I contributed to HBase and HDFS in the past. No special SGA was
required for those since the contributions were under the Apache license.
>
> If any of this is vaguely true my head is spinning and I cannot fathom
> the implication whether or not
> the SGA is used as-is or amended.
>
That's why I'm trying my best to get our lawyer in touch with another
lawyer. I don't mean any disrespect to the hard-working volunteers on the
legal-discuss list, but this kind of stuff is above our heads, and should
be discussed by people who are licensed IP attorneys to make sure we don't
miss anything on either end.
I also want to clarify one thing: it seems like some folks on the list are
trying to attribute some kind of malice or "trickery" to the request here.
Cloudera is not new to the ASF. We've contributed several other projects
via the incubator in the past, have 8 or so Apache members on staff, etc.
I'm just currently trying to find a workable solution between three
parties: (a) our legal counsel who is uncomfortable with the current
wording, (b) our company's decision to contribute new projects to the ASF,
and (c) the ASF itself who prefers not to change the SGA. My guess is that
'b' is the least likely to change (we are committed to contributing these
projects to the ASF). So, I either have to convince our counsel that the
current SGA is fine, convince our executives to sign the SGA against our
counsel's advice, or convince the ASF to allow the modifications. I'll work
each of these avenues in parallel.
If the general consensus is that the SGA is _not_ required for the code
import, I'm happy to move on with the incubation process while continuing
to sort this out in the background. But, would like to have some more
confirmation that this is the case instead of just one Member's opinion
which conflicts with the online policies posted on the incubator site.
-Todd
Re: SGA Alterations
Posted by Philippe Ombredanne <po...@nexb.com>.
On Tue, Dec 15, 2015 at 10:52 PM, Todd Lipcon <to...@apache.org> wrote:
> Hi Jim,
>
> Here's the response from our attorney:
>>
>>
>> - The change in the first Whereas clause indicates that we are granting a
>> “license,” not conveying ownership / title. The word used “contribute” has
>> no meaning in the copyright act. Congress drafted the copyright act and
>> included the word “license” not “contribute”. So it should be clarified.
>> Clearing this ambiguity helps Apache so that its “license” rights are
>> certain.
>> - Paragraph 1: “now” is inserted because Cloudera cannot grant a
>> license to a patent not yet owned or issued. By using language contrary to
>> the patent act, it could have the effect of rendering the actual grant
>> faulty. Apache would not benefit from that. The word “now” should be
>> included so its clear that it applies to patents currently owned and issued.
>> - Paragraph 2 indicates that the grant is made w/o investigation
>> and based on knowledge. This is not a “hedge”. This language makes it
>> consistent with the warranty exclusion included in the agreement. Without
>> this clarification, the warranty exclusion could be seen as being at odds
>> with the grant. Apache does not benefit from this ambiguity.
>> - Paragraph 2 indicates that the statement is made as of the
>> Effective Date. There is no obligation to monitor future developments or
>> future actions. Again, such a prospective obligation would be inconsistent
>> with the warranty exclusion. Without this, the conflict could be read
>> against the drafter (Apache), and it would not benefit them from this
>> result.
>>
>> I also add that by making the agreement more accurate, more consistent
>> with law and less internally ambiguous it makes these types of reviews and
>> discussions less common. The Apache person indicates that others have
>> sought to have changes made, but Apache consistently says "no". I think
>> Apache benefits from having a more readily acceptable agreement. This could
>> speed their process without introducing any risk.
>
>
> He also suggested that speaking directly with a licensing attorney on the
> ASF side might be easier than going through us non-lawyers as intermediaries
> :)
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
Todd:
Just to make sure I understand the gist of this, would this
reformulation be more or less correct?
Cloudera has patents filed but not yet granted that apply to the domain.
Cloudera has patents for sure [1].
Therefore it cannot make any patent grant for now to Apache under the
SGA because
the patents have not been granted yet.
If the future, if these patents are effectively granted to Cloudera,
then using Impala or Kudu
would imply using these patents, but no grants would have been made to
Apache and therefore
to its users?
If any of this is vaguely true my head is spinning and I cannot fathom
the implication whether or not
the SGA is used as-is or amended.
[1] http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=0&f=S&l=50&d=PTXT&RS=cloudera&Refine=Refine+Search&Query=cloudera
--
Cordially
Philippe Ombredanne
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: SGA Alterations
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Dec 15, 2015 at 8:14 PM, Todd Lipcon <to...@cloudera.com> wrote:
>...
> According to my first emails back and forth with him, he seemed unwilling
> to sign as is. And it's my understanding that the SGA blocks the initial
> code import, right?
>
The Incubator docs say you need an SGA first, but I think that is wrong. We
used to deal with IP clearance *during* the podling's life, not before. And
it seems some process monkey went and changed the doc.
*Especially* because Kudu (and Impala) are already open source. No harm in
copying those to our repository to work upon.
Cheers,
-g
Re: SGA Alterations
Posted by Todd Lipcon <to...@cloudera.com>.
On Tue, Dec 15, 2015 at 10:37 PM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:
> On Tue, Dec 15, 2015 at 8:14 PM, Todd Lipcon <to...@cloudera.com> wrote:
>
>> On Tue, Dec 15, 2015 at 6:04 PM, Marvin Humphrey <ma...@rectangular.com>
>> wrote:
>>
>>> On Tue, Dec 15, 2015 at 5:21 PM, Todd Lipcon <to...@cloudera.com> wrote:
>>>
>>> > So, should I await an introduction to some attorney representing the
>>> ASF?
>>> > What's the next step to close this out in either direction?
>>>
>>> The contribution of ideas from Cloudera's counsel is welcome. However,
>>> if the SGA were to be modified, it is not something that will be
>>> closed out right away. Were you thinking that the Kudu podling is
>>> blocked until this is resolved?
>>>
>>
>> According to my first emails back and forth with him, he seemed unwilling
>> to sign as is. And it's my understanding that the SGA blocks the initial
>> code import, right?
>>
>> That doesn't mean, of course, that I couldn't try to push back further
>> (either directly or via other executives), but was hoping we could at least
>> have the discussion first.
>>
>
> 'The executive' is Jim Jagielski, VP Legal, whom you are already conversing
> with. There are other board members (including Jim) whom you could try to
> route around by, but that will land you back where you started.
>
Sorry, maybe my text above wasn't clear: I mean that I can push back
directly on our lawyer, or push back on him via Cloudera executives. His
duty of course is to advise our executive team on what's legally prudent,
but maybe in this case we can elect to overrule his advice. I'll check on
that on our side.
>
> Not withstanding Greg's observations, it is highly unlikely that
> 'clarifications
> and edits' are going to be adopted in the short timeframe of a current
> import.
> Just ask about the adoption timeframe of either the current grant
> agreement,
> or CCLA/ICLA, or AL 2.0 process.
>
Sure, though I would think that small edits to an existing agreement are
substantially easier to approve than an entirely new agreement or license
version. I've seen two teams of lawyers iron out these sorts of changes in
40+ page legal transactions in a couple weeks. Small changes in an IP
document ought not take months.
> If the donation cannot happen under the current SGA, I suggest you put a
> pause, full stop, on trying to participate in the ASF under your own terms.
> Many have tried, and most have failed.
>
Well, I'd be remiss if I didn't add myself to the list of those who have
tried before moving on. As noted above, it's our GC's duty to advise us on
the best way to proceed, and right now his advice is that he would like to
talk to a *lawyer* representing the ASF. Of course I respect the opinions
of the board and other Apache long-timers, but best I know they are all
computer scientists, not lawyers.
I'm still hoping to hear who that lawyer might be. If it's a matter of
paying for some lawyer's time, perhaps I could arrange for us to sponsor
that.
-Todd
--
Todd Lipcon
Software Engineer, Cloudera
Re: SGA Alterations
Posted by Ted Dunning <te...@gmail.com>.
Changing the SGA is not really just a negotiation between two parties.
There are lots of companies who care about the content of the SGA and might
like to comment.
On Tue, Dec 15, 2015 at 10:37 PM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:
> On Tue, Dec 15, 2015 at 8:14 PM, Todd Lipcon <to...@cloudera.com> wrote:
>
>> On Tue, Dec 15, 2015 at 6:04 PM, Marvin Humphrey <ma...@rectangular.com>
>> wrote:
>>
>>> On Tue, Dec 15, 2015 at 5:21 PM, Todd Lipcon <to...@cloudera.com> wrote:
>>>
>>> > So, should I await an introduction to some attorney representing the
>>> ASF?
>>> > What's the next step to close this out in either direction?
>>>
>>> The contribution of ideas from Cloudera's counsel is welcome. However,
>>> if the SGA were to be modified, it is not something that will be
>>> closed out right away. Were you thinking that the Kudu podling is
>>> blocked until this is resolved?
>>>
>>
>> According to my first emails back and forth with him, he seemed unwilling
>> to sign as is. And it's my understanding that the SGA blocks the initial
>> code import, right?
>>
>> That doesn't mean, of course, that I couldn't try to push back further
>> (either directly or via other executives), but was hoping we could at least
>> have the discussion first.
>>
>
> 'The executive' is Jim Jagielski, VP Legal, whom you are already conversing
> with. There are other board members (including Jim) whom you could try to
> route around by, but that will land you back where you started.
>
> Not withstanding Greg's observations, it is highly unlikely that
> 'clarifications
> and edits' are going to be adopted in the short timeframe of a current
> import.
> Just ask about the adoption timeframe of either the current grant
> agreement,
> or CCLA/ICLA, or AL 2.0 process. These things are measured by both paid
> and non-staff pro-bono donation of effort and time, and not on our
> calendar.
>
> If the donation cannot happen under the current SGA, I suggest you put a
> pause, full stop, on trying to participate in the ASF under your own terms.
> Many have tried, and most have failed.
>
> Wish you well, and hope this can all be resolved to everyone's
> satisfaction.
>
> Cheers,
>
> Bill
>
Re: SGA Alterations
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Dec 15, 2015 at 8:14 PM, Todd Lipcon <to...@cloudera.com> wrote:
> On Tue, Dec 15, 2015 at 6:04 PM, Marvin Humphrey <ma...@rectangular.com>
> wrote:
>
>> On Tue, Dec 15, 2015 at 5:21 PM, Todd Lipcon <to...@cloudera.com> wrote:
>>
>> > So, should I await an introduction to some attorney representing the
>> ASF?
>> > What's the next step to close this out in either direction?
>>
>> The contribution of ideas from Cloudera's counsel is welcome. However,
>> if the SGA were to be modified, it is not something that will be
>> closed out right away. Were you thinking that the Kudu podling is
>> blocked until this is resolved?
>>
>
> According to my first emails back and forth with him, he seemed unwilling
> to sign as is. And it's my understanding that the SGA blocks the initial
> code import, right?
>
> That doesn't mean, of course, that I couldn't try to push back further
> (either directly or via other executives), but was hoping we could at least
> have the discussion first.
>
'The executive' is Jim Jagielski, VP Legal, whom you are already conversing
with. There are other board members (including Jim) whom you could try to
route around by, but that will land you back where you started.
Not withstanding Greg's observations, it is highly unlikely that
'clarifications
and edits' are going to be adopted in the short timeframe of a current
import.
Just ask about the adoption timeframe of either the current grant agreement,
or CCLA/ICLA, or AL 2.0 process. These things are measured by both paid
and non-staff pro-bono donation of effort and time, and not on our calendar.
If the donation cannot happen under the current SGA, I suggest you put a
pause, full stop, on trying to participate in the ASF under your own terms.
Many have tried, and most have failed.
Wish you well, and hope this can all be resolved to everyone's satisfaction.
Cheers,
Bill
Re: SGA Alterations
Posted by Todd Lipcon <to...@cloudera.com>.
On Tue, Dec 15, 2015 at 6:04 PM, Marvin Humphrey <ma...@rectangular.com>
wrote:
> On Tue, Dec 15, 2015 at 5:21 PM, Todd Lipcon <to...@cloudera.com> wrote:
>
> > So, should I await an introduction to some attorney representing the ASF?
> > What's the next step to close this out in either direction?
>
> The contribution of ideas from Cloudera's counsel is welcome. However,
> if the SGA were to be modified, it is not something that will be
> closed out right away. Were you thinking that the Kudu podling is
> blocked until this is resolved?
>
According to my first emails back and forth with him, he seemed unwilling
to sign as is. And it's my understanding that the SGA blocks the initial
code import, right?
That doesn't mean, of course, that I couldn't try to push back further
(either directly or via other executives), but was hoping we could at least
have the discussion first.
-Todd
Re: SGA Alterations
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Dec 15, 2015 at 5:21 PM, Todd Lipcon <to...@cloudera.com> wrote:
> So, should I await an introduction to some attorney representing the ASF?
> What's the next step to close this out in either direction?
The contribution of ideas from Cloudera's counsel is welcome. However,
if the SGA were to be modified, it is not something that will be
closed out right away. Were you thinking that the Kudu podling is
blocked until this is resolved?
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: SGA Alterations
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Dec 15, 2015, at 8:21 PM, Todd Lipcon <to...@cloudera.com> wrote:
>
> On Tue, Dec 15, 2015 at 2:26 PM, Mattmann, Chris A (3980) <ch...@jpl.nasa.gov> wrote:
> +1 speaking directly is fine.
>
> Todd, I would have to concur policy wise with statements made by
> Jim and Marvin so far. Doug should be able to comment on this too
> being at Cloudera and should know that we haven’t changed our SGA
> in the past for specific instances like this and there doesn’t
> seem to warrant doing so in Kudu’s case TBH looking at this.
>
> Sure, and in fact I think Cloudera probably even signed a few of the SGAs as is in the past. But, as noted elsewhere in the thread, the goal isn't to have a special SGA only for Kudu, but rather to make some improvements that would apply for all future SGAs as well. Assuming, of course, that the ASF's counsel agrees with ours that these are in fact _improvements_. Hard for me to say, as IANAL :)
>
> So, should I await an introduction to some attorney representing the ASF? What's the next step to close this out in either direction?
There are 2 issues happening concurrently: The first seems to be
that we are awaiting a SGA for Kudu; the 2nd seems to be a
general desire from one of Cloudera's counsel to improve the
SGA.
These need to be unbound.
Even assuming that our legal counsel agrees with these improvements,
it is not a fait accompli that the ASF will change our SGA; normally
when we start "fixing" our agreements we usually create new ones to
not only fold in those improvements but also other new things
as well. What I am saying is that even if after we arrange a
chat between Cloudera and our pro bono counsel, I would not "hold
my breath" waiting for a revised SGA.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: SGA Alterations
Posted by Todd Lipcon <to...@cloudera.com>.
On Tue, Dec 15, 2015 at 2:26 PM, Mattmann, Chris A (3980) <
chris.a.mattmann@jpl.nasa.gov> wrote:
> +1 speaking directly is fine.
>
> Todd, I would have to concur policy wise with statements made by
> Jim and Marvin so far. Doug should be able to comment on this too
> being at Cloudera and should know that we haven’t changed our SGA
> in the past for specific instances like this and there doesn’t
> seem to warrant doing so in Kudu’s case TBH looking at this.
>
Sure, and in fact I think Cloudera probably even signed a few of the SGAs
as is in the past. But, as noted elsewhere in the thread, the goal isn't to
have a special SGA only for Kudu, but rather to make some improvements that
would apply for all future SGAs as well. Assuming, of course, that the
ASF's counsel agrees with ours that these are in fact _improvements_. Hard
for me to say, as IANAL :)
So, should I await an introduction to some attorney representing the ASF?
What's the next step to close this out in either direction?
-Todd
Re: SGA Alterations
Posted by "Mattmann, Chris A (3980)" <ch...@jpl.nasa.gov>.
+1 speaking directly is fine.
Todd, I would have to concur policy wise with statements made by
Jim and Marvin so far. Doug should be able to comment on this too
being at Cloudera and should know that we haven’t changed our SGA
in the past for specific instances like this and there doesn’t
seem to warrant doing so in Kudu’s case TBH looking at this.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: <to...@cloudera.com> on behalf of Todd Lipcon <to...@apache.org>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Tuesday, December 15, 2015 at 1:52 PM
To: Jim Jagielski <ji...@jagunet.com>
Cc: legal discuss <le...@apache.org>
Subject: Re: SGA Alterations
>Hi Jim,
>
>
>Here's the response from our attorney:
>
>
>- The change in the first Whereas clause indicates that we are granting a
>“license,” not conveying ownership / title. The word used “contribute”
>has no meaning in the copyright act. Congress drafted the copyright act
>and included the word “license” not “contribute”.
> So it should be clarified. Clearing this ambiguity helps Apache so that
>its “license” rights are certain.
>- Paragraph 1: “now” is inserted because Cloudera cannot grant
>a license to a patent not yet owned or issued. By using language
>contrary to the patent act, it could have the effect of rendering the
>actual grant faulty. Apache would not benefit from
> that. The word “now” should be included so its clear that it applies to
>patents currently owned and issued.
>- Paragraph 2 indicates that the grant is made w/o investigation
>and based on knowledge. This is not a “hedge”. This language makes it
>consistent with the warranty exclusion included in the agreement.
>Without this clarification, the warranty exclusion
> could be seen as being at odds with the grant. Apache does not benefit
>from this ambiguity.
>- Paragraph 2 indicates that the statement is made as of the
>Effective Date. There is no obligation to monitor future developments or
>future actions. Again, such a prospective obligation would be
>inconsistent with the warranty exclusion. Without
> this, the conflict could be read against the drafter (Apache), and it
>would not benefit them from this result.
>
>
>I also add that by making the agreement more accurate, more consistent
>with law and less internally ambiguous it makes these types of reviews
>and discussions less common. The Apache person indicates that others
>have sought to have changes made, but Apache
> consistently says "no". I think Apache benefits from having a more
>readily acceptable agreement. This could speed their process without
>introducing any risk.
>
>
>
>
>He also suggested that speaking directly with a licensing attorney on the
>ASF side might be easier than going through us non-lawyers as
>intermediaries :)
>
>
>-Todd
>
>
>On Tue, Dec 15, 2015 at 1:04 PM, Jim Jagielski
><ji...@jagunet.com> wrote:
>
>Thank you for the inquiry. As has been mentioned, all previous attempts
>and requests for "revised" SGAs have been rejected, but I will have the
>below reviewed.
>
>Off the top of my head, however, I think that the changes
>to section 2 will not be acceptable, since it results in
>the ASF assuming, from what I can see, additional risk beyond
>what is current; it looks like the person donating the code
>is "hedging" something.
>
>What, if I may ask, is the root cause for this suggested change?
>You mention that they are "general improvements" but what, exactly,
>is the issue these changes are designed to resolve?
>
>> On Dec 14, 2015, at 3:18 PM, Todd Lipcon <to...@apache.org> wrote:
>>
>> Hi folks,
>>
>> I'm working with our legal counsel on the SGA for Kudu and Impala
>>entering the incubator. He requested a few small clarifications to the
>>SGA text which he feels are important before we can sign the SGA.
>>
>> Could you please review the changes in the attached doc and let us know
>>if this will be OK from the ASF side?
>>
>> Thanks
>> -Todd
>>
>
>
>> <Kudu Contribution Agreement 12102015.docx>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail:
>legal-discuss-help@apache.org <ma...@apache.org>
>
>
>
>
>
>
>
>
>
>
>--
>Todd Lipcon
>Software Engineer, Cloudera
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: SGA Alterations
Posted by Todd Lipcon <to...@apache.org>.
Hi Jim,
Here's the response from our attorney:
>
> - The change in the first Whereas clause indicates that we are granting a
> “license,” not conveying ownership / title. The word used “contribute” has
> no meaning in the copyright act. Congress drafted the copyright act and
> included the word “license” not “contribute”. So it should be clarified.
> Clearing this ambiguity helps Apache so that its “license” rights are
> certain.
> - Paragraph 1: “now” is inserted because Cloudera cannot grant a
> license to a patent not yet owned or issued. By using language contrary to
> the patent act, it could have the effect of rendering the actual grant
> faulty. Apache would not benefit from that. The word “now” should be
> included so its clear that it applies to patents currently owned and issued.
> - Paragraph 2 indicates that the grant is made w/o investigation
> and based on knowledge. This is not a “hedge”. This language makes it
> consistent with the warranty exclusion included in the agreement. Without
> this clarification, the warranty exclusion could be seen as being at odds
> with the grant. Apache does not benefit from this ambiguity.
> - Paragraph 2 indicates that the statement is made as of the
> Effective Date. There is no obligation to monitor future developments or
> future actions. Again, such a prospective obligation would be inconsistent
> with the warranty exclusion. Without this, the conflict could be read
> against the drafter (Apache), and it would not benefit them from this
> result.
I also add that by making the agreement more accurate, more consistent with
> law and less internally ambiguous it makes these types of reviews and
> discussions less common. The Apache person indicates that others have
> sought to have changes made, but Apache consistently says "no". I think
> Apache benefits from having a more readily acceptable agreement. This
> could speed their process without introducing any risk.
He also suggested that speaking directly with a licensing attorney on the
ASF side might be easier than going through us non-lawyers as
intermediaries :)
-Todd
On Tue, Dec 15, 2015 at 1:04 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> Thank you for the inquiry. As has been mentioned, all previous attempts
> and requests for "revised" SGAs have been rejected, but I will have the
> below reviewed.
>
> Off the top of my head, however, I think that the changes
> to section 2 will not be acceptable, since it results in
> the ASF assuming, from what I can see, additional risk beyond
> what is current; it looks like the person donating the code
> is "hedging" something.
>
> What, if I may ask, is the root cause for this suggested change?
> You mention that they are "general improvements" but what, exactly,
> is the issue these changes are designed to resolve?
>
> > On Dec 14, 2015, at 3:18 PM, Todd Lipcon <to...@apache.org> wrote:
> >
> > Hi folks,
> >
> > I'm working with our legal counsel on the SGA for Kudu and Impala
> entering the incubator. He requested a few small clarifications to the SGA
> text which he feels are important before we can sign the SGA.
> >
> > Could you please review the changes in the attached doc and let us know
> if this will be OK from the ASF side?
> >
> > Thanks
> > -Todd
> >
> > <Kudu Contribution Agreement 12102015.docx>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
>
>
--
Todd Lipcon
Software Engineer, Cloudera
Re: SGA Alterations
Posted by Jim Jagielski <ji...@jaguNET.com>.
Thank you for the inquiry. As has been mentioned, all previous attempts
and requests for "revised" SGAs have been rejected, but I will have the
below reviewed.
Off the top of my head, however, I think that the changes
to section 2 will not be acceptable, since it results in
the ASF assuming, from what I can see, additional risk beyond
what is current; it looks like the person donating the code
is "hedging" something.
What, if I may ask, is the root cause for this suggested change?
You mention that they are "general improvements" but what, exactly,
is the issue these changes are designed to resolve?
> On Dec 14, 2015, at 3:18 PM, Todd Lipcon <to...@apache.org> wrote:
>
> Hi folks,
>
> I'm working with our legal counsel on the SGA for Kudu and Impala entering the incubator. He requested a few small clarifications to the SGA text which he feels are important before we can sign the SGA.
>
> Could you please review the changes in the attached doc and let us know if this will be OK from the ASF side?
>
> Thanks
> -Todd
>
> <Kudu Contribution Agreement 12102015.docx>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: SGA Alterations
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Dec 14, 2015 at 11:09 PM, Todd Lipcon <to...@apache.org> wrote:
> Our counsel responded to this that the changes he is suggesting are
> general improvements that should apply to all such agreements, not
> something particular to these contributions. The current agreement lacks
> some precision that he is hoping to address -- the fact that it's been good
> enough for others in the past isn't necessarily a good reason not to
> improve it for the future. Perhaps I can connect him directly with someone
> from DLAP?
>
We have multiple counsel. It'll get routed appropriately.
Regarding the content of the changes, I believe the "now" addition to the
language about patent rights may be an issue. I kinda recall past
discussion around language tense, w.r.t patents rights. (in ALv2, I think)
I think the "as of Effective Date" may be a breaker. If somebody discovers
a problem 3 years from now, we'd prefer to be advised. ... now, maybe that
is unrealistic. Just pointing out the big change made in that paragraph.
Cheers,
-g
Re: SGA Alterations
Posted by Todd Lipcon <to...@apache.org>.
Our counsel responded to this that the changes he is suggesting are general
improvements that should apply to all such agreements, not something
particular to these contributions. The current agreement lacks some
precision that he is hoping to address -- the fact that it's been good
enough for others in the past isn't necessarily a good reason not to
improve it for the future. Perhaps I can connect him directly with someone
from DLAP?
Todd
On Dec 14, 2015 7:07 PM, "Marvin Humphrey" <ma...@rectangular.com> wrote:
> On Mon, Dec 14, 2015 at 12:18 PM, Todd Lipcon <to...@apache.org> wrote:
> > Hi folks,
> >
> > I'm working with our legal counsel on the SGA for Kudu and Impala
> entering
> > the incubator. He requested a few small clarifications to the SGA text
> which
> > he feels are important before we can sign the SGA.
> >
> > Could you please review the changes in the attached doc and let us know
> if
> > this will be OK from the ASF side?
>
> In the past, Apache has received various requests to modify our CLAs and
> SGAs.
>
> http://s.apache.org/NPw
> http://s.apache.org/30F
> https://issues.apache.org/jira/browse/LEGAL-100
>
> None of these requests have been accepted, and I would be very
> surprised if that were to change now.
>
> Looking through the modifications, the motivation seems to be adding
> additional hedging language around "Licensor represents that, to
> Licensor's knowledge,". I am unaware of anything that would make the
> Kudu grant from other similar grants we have received, though --
> implying that if we were to make these mods for Kudu, the SGA form
> ought to be updated. But the SGA's existing language has been
> acceptable to many previous grantors.
>
> I don't see why either special accommodations for Kudu or a generally
> applicable SGA form update would be warranted.
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: SGA Alterations
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Dec 14, 2015 at 12:18 PM, Todd Lipcon <to...@apache.org> wrote:
> Hi folks,
>
> I'm working with our legal counsel on the SGA for Kudu and Impala entering
> the incubator. He requested a few small clarifications to the SGA text which
> he feels are important before we can sign the SGA.
>
> Could you please review the changes in the attached doc and let us know if
> this will be OK from the ASF side?
In the past, Apache has received various requests to modify our CLAs and SGAs.
http://s.apache.org/NPw
http://s.apache.org/30F
https://issues.apache.org/jira/browse/LEGAL-100
None of these requests have been accepted, and I would be very
surprised if that were to change now.
Looking through the modifications, the motivation seems to be adding
additional hedging language around "Licensor represents that, to
Licensor's knowledge,". I am unaware of anything that would make the
Kudu grant from other similar grants we have received, though --
implying that if we were to make these mods for Kudu, the SGA form
ought to be updated. But the SGA's existing language has been
acceptable to many previous grantors.
I don't see why either special accommodations for Kudu or a generally
applicable SGA form update would be warranted.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org