SDO IP Issues, was: SDO Java M3 Release Candidate RC1
On Mar 19, 2007, at 11:45 AM, Frank Budinsky wrote: Hmm, this seems like an example of where "legal red tape" may be getting in the way of the "spirit of reuse". One man's "spirit of reuse" is another's copyright infringement. This is not something to take lightly. EPL is very specific: When the Program is made available in source code form: a) it must be made available under this Agreement; and b) a copy of this Agreement must be included with each copy of the Program. Distributing EPL code in source form under the Apache License is a violation of these EPL terms. Period. To distribute this code under the Apache License it needs to be relicensed by the copyright owner. This is not an ongoing contribution as covered by a CCLA but a grant of software written elsewhere to the Foundation. There is a process for this, handled by the Incubator: http://incubator.apache.org/ip-clearance/index.html Another alternative might be to distribute the code in binary form. This would involve making the "necessary change" elsewhere (say at Eclipse), releasing that derivative under the EPL in binary form. Tuscany would then be able to redistribute that code in its binary form. That's a suggestion - you probably want to talk to a lawyer and I would suggest running it past [EMAIL PROTECTED] Here's the general problem: 1) We need to override a base class' behavior to do something "slightly different". 2) Looking at the base class, we notice that it requires a tiny change in the middle of a medium to large sized method. We request a slight refactoring of the base (EMF) code, which they agree to fix in their next version. 3) We can't move to the next version yet, so we add a copy of the method (with the change) in our subclass and then proceed as if it was already in the base class. Note that we really don't want to do this in the first place because if we later forget to remove the override and EMF fixes some other bug in the same method, we won't ever pick up the fix. Unfortunately, however, we have no choice in the short term other than to rewrite the whole method, but since it's intricately tied to the rest of the base class implementation it really couldn't be much different. We could rewrite the entire class, but that completely defeats the purpose of reuse. Does anybody know how this kind of "necessary copying" is addressed? I also wonder where is the fine line between providing a "changed method" vs "a copied method with a change" in a subclass? For example, what if one of the copied methods was only 3 lines and we changed one of them? Is that still a copy? Thanks, Frank. Jeremy Boynes <[EMAIL PROTECTED]> wrote on 03/19/2007 10:27:52 AM: The original code here is EPL (I assume), which Apache projects can include in binary form but not in source form. See here for details: http://www.apache.org/legal/3party.html We need to remove the original code from the repo. After that, there are two options: * Have the IP owner (I presume this is IBM code) relicense it under AL and contribute via the IP Clearance process * Do an alternative implementation, best done by someone who has not seen the Eclipse code -- Jeremy On Mar 19, 2007, at 7:01 AM, Frank Budinsky wrote: We may be talking about two different things here. Regarding the two EMF classes: BasicExtendedMetaData and XSDEcoreBuilder, here's what we did. Both of these classes (in EMF) create metadata (Types and Properties) scattered in various places in the classes. Unfortunately, for us, it does it using those evil singletons: EcoreFactory.eINSTANCE.createXXX (). We asked the EMF team if they could switch this to the IOC pattern, so we could inject our SDO specific metadata factories. They said they would, but can't before EMF version 2.3 which is Java 5 dependent. Since we won't (can't) move to EMF 2.3, our interim solution was to create subclasses in Tuscany, BaseSDOExtendedMetaData and BaseSDOXSDEcoreBuilder, which override the methods that create metadata. The subclasses contain copies of the base method, only using a factory instance variable instead of the singleton. For example: class BaseSDOXSDEcoreBuilder extends XSDEcoreBuilder { protected EcoreFactory ecoreFactory; void someXSDEcoreBuilderMethod() { bla ... bla ... bla ... // replaced this line: someVariable = EcoreFactory.eINSTANCE.createXXX(); someVariable = ecoreFactory.createXXX(); bla ... bla ... bla .. } ... etc. } So, the question is, what kind of license do we need in these two Tuscany classes? 1. Apache. 2. Apache + Eclipse 3. Other? Currently, I think we just have #1. If anyone can provide guidance on this, it would be much appreciated. Thanks, Frank. Jeremy Boynes <[EMAIL PROTECTED]> wrote on 03/18/2007 12:33:25 PM: Those are the ones. You said before that you thought this might be generated but that you were sure Frank would conf
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
Jeremy Boynes <[EMAIL PROTECTED]> wrote on 03/19/2007 06:14:58 PM: > On Mar 19, 2007, at 11:45 AM, Frank Budinsky wrote: > > > Hmm, this seems like an example of where "legal red tape" may be > > getting > > in the way of the "spirit of reuse". > > One man's "spirit of reuse" is another's copyright infringement. This > is not something to take lightly. I'm sure that's true. Nobody's taking this lightly. In this particular case, however, both parties, the EMF contributors at Eclipse, and the Tuscany consumers (us) here at Apache agree that this is not a case of copyright infringement. So, it seems to me that a light-weight process for dealing with this kind of scenario is needed. If need be, we'll pull out this code temporarily, but I'd prefer to see some sensible way to deal with it without doing that. I'm also still looking for an answer to my question from below: I also wonder where is the fine line between providing a "changed method" vs "a copied method with a change" in a subclass? According to the strict interpretation of the two licenses, you really can't do much with EPL code at Apache. Something as trivial as overriding a base method that looks like this: void foo() { x = 3; bar(); } to set x to 4 instead of 3: void foo() { x = 4; bar(); } could be considered copyright infringement. If not, then where is the fine line? Thanks, Frank. > > EPL is very specific: >When the Program is made available in source code form: > a) it must be made available under this Agreement; and > b) a copy of this Agreement must be included with each copy of > the Program. > > Distributing EPL code in source form under the Apache License is a > violation of these EPL terms. Period. > > To distribute this code under the Apache License it needs to be > relicensed by the copyright owner. This is not an ongoing > contribution as covered by a CCLA but a grant of software written > elsewhere to the Foundation. There is a process for this, handled by > the Incubator: >http://incubator.apache.org/ip-clearance/index.html > > Another alternative might be to distribute the code in binary form. > This would involve making the "necessary change" elsewhere (say at > Eclipse), releasing that derivative under the EPL in binary form. > Tuscany would then be able to redistribute that code in its binary > form. That's a suggestion - you probably want to talk to a lawyer and > I would suggest running it past [EMAIL PROTECTED] > > > Here's the general problem: > > > > 1) We need to override a base class' behavior to do something > > "slightly > > different". > > 2) Looking at the base class, we notice that it requires a tiny > > change in > > the middle of a medium to large sized method. We request a slight > > refactoring of the base (EMF) code, which they agree to fix in > > their next > > version. > > 3) We can't move to the next version yet, so we add a copy of the > > method > > (with the change) in our subclass and then proceed as if it was > > already in > > the base class. > > > > Note that we really don't want to do this in the first place > > because if we > > later forget to remove the override and EMF fixes some other bug in > > the > > same method, we won't ever pick up the fix. Unfortunately, however, we > > have no choice in the short term other than to rewrite the whole > > method, > > but since it's intricately tied to the rest of the base class > > implementation it really couldn't be much different. We could > > rewrite the > > entire class, but that completely defeats the purpose of reuse. > > > > Does anybody know how this kind of "necessary copying" is addressed? I > > also wonder where is the fine line between providing a "changed > > method" vs > > "a copied method with a change" in a subclass? For example, what if > > one of > > the copied methods was only 3 lines and we changed one of them? Is > > that > > still a copy? > > > > Thanks, > > Frank. > > > > Jeremy Boynes <[EMAIL PROTECTED]> wrote on 03/19/2007 10:27:52 AM: > > > >> The original code here is EPL (I assume), which Apache projects can > >> include in binary form but not in source form. See here for details: > >>http://www.apache.org/legal/3party.html > >> > >> We need to remove the original code from the repo. After that, there > >> are two options: > >> * Have the IP owner (I presume this is IBM code) relicense it under > >> AL and contribute > >>via the IP Clearance process > >> * Do an alternative implementation, best done by someone who has not > >> seen the Eclipse code > >> > >> -- > >> Jeremy > >> > >> On Mar 19, 2007, at 7:01 AM, Frank Budinsky wrote: > >> > >>> We may be talking about two different things here. > >>> > >>> Regarding the two EMF classes: BasicExtendedMetaData and > >>> XSDEcoreBuilder, > >>> here's what we did. > >>> > >>> Both of these classes (in EMF) create metadata (Types and > >>> Properties) > >>> scattered in various places in the class
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
Frank, Standard disclaimer: I am not a lawyer and I am not qualified to give legal interpretations. However, I have heard many lawyers give talks on copyright :-) Based on this, I'd expect that the "new" method would need to follow standard legal guidelines for defence against a claim of copyright infringement. In the particlular case you have given, I don't think this would be a problem. But it is the nature of this beast that no precise formula could be given for where the line is. None of this would apply if the copyright holder had given permission to Apache to include their code and derivative works under the Apache license. Simon Frank Budinsky wrote: Jeremy Boynes <[EMAIL PROTECTED]> wrote on 03/19/2007 06:14:58 PM: On Mar 19, 2007, at 11:45 AM, Frank Budinsky wrote: Hmm, this seems like an example of where "legal red tape" may be getting in the way of the "spirit of reuse". One man's "spirit of reuse" is another's copyright infringement. This is not something to take lightly. I'm sure that's true. Nobody's taking this lightly. In this particular case, however, both parties, the EMF contributors at Eclipse, and the Tuscany consumers (us) here at Apache agree that this is not a case of copyright infringement. So, it seems to me that a light-weight process for dealing with this kind of scenario is needed. If need be, we'll pull out this code temporarily, but I'd prefer to see some sensible way to deal with it without doing that. I'm also still looking for an answer to my question from below: I also wonder where is the fine line between providing a "changed method" vs "a copied method with a change" in a subclass? According to the strict interpretation of the two licenses, you really can't do much with EPL code at Apache. Something as trivial as overriding a base method that looks like this: void foo() { x = 3; bar(); } to set x to 4 instead of 3: void foo() { x = 4; bar(); } could be considered copyright infringement. If not, then where is the fine line? Thanks, Frank. EPL is very specific: When the Program is made available in source code form: a) it must be made available under this Agreement; and b) a copy of this Agreement must be included with each copy of the Program. Distributing EPL code in source form under the Apache License is a violation of these EPL terms. Period. To distribute this code under the Apache License it needs to be relicensed by the copyright owner. This is not an ongoing contribution as covered by a CCLA but a grant of software written elsewhere to the Foundation. There is a process for this, handled by the Incubator: http://incubator.apache.org/ip-clearance/index.html Another alternative might be to distribute the code in binary form. This would involve making the "necessary change" elsewhere (say at Eclipse), releasing that derivative under the EPL in binary form. Tuscany would then be able to redistribute that code in its binary form. That's a suggestion - you probably want to talk to a lawyer and I would suggest running it past [EMAIL PROTECTED] Here's the general problem: 1) We need to override a base class' behavior to do something "slightly different". 2) Looking at the base class, we notice that it requires a tiny change in the middle of a medium to large sized method. We request a slight refactoring of the base (EMF) code, which they agree to fix in their next version. 3) We can't move to the next version yet, so we add a copy of the method (with the change) in our subclass and then proceed as if it was already in the base class. Note that we really don't want to do this in the first place because if we later forget to remove the override and EMF fixes some other bug in the same method, we won't ever pick up the fix. Unfortunately, however, we have no choice in the short term other than to rewrite the whole method, but since it's intricately tied to the rest of the base class implementation it really couldn't be much different. We could rewrite the entire class, but that completely defeats the purpose of reuse. Does anybody know how this kind of "necessary copying" is addressed? I also wonder where is the fine line between providing a "changed method" vs "a copied method with a change" in a subclass? For example, what if one of the copied methods was only 3 lines and we changed one of them? Is that still a copy? Thanks, Frank. Jeremy Boynes <[EMAIL PROTECTED]> wrote on 03/19/2007 10:27:52 AM: The original code here is EPL (I assume), which Apache projects can include in binary form but not in source form. See here for details: http://www.apache.org/legal/3party.html We need to remove the original code from the repo. After that, there are two options: * Have the IP owner (I presume this is IBM code) relicense it under AL and contribute via the IP Clearance process * Do an alternative implementation, best done by someone who has not seen the Ecli
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
I've confirmed that IBM, the copyright holder, gives permission to Apache to reuse the two EMF files in question. I've opened TUSCANY-1185 to contribute the two base classes, provided in an attachment. Jeremy, let me know if this is good enough for you, or if you still want me to remove the Tuscany subclasses and resubmit them. Frank. Simon Nash <[EMAIL PROTECTED]> wrote on 03/20/2007 08:37:21 AM: > Frank, > Standard disclaimer: I am not a lawyer and I am not qualified to give > legal interpretations. However, I have heard many lawyers give talks > on copyright :-) Based on this, I'd expect that the "new" method would > need to follow standard legal guidelines for defence against a claim > of copyright infringement. In the particlular case you have given, > I don't think this would be a problem. But it is the nature of this > beast that no precise formula could be given for where the line is. > > None of this would apply if the copyright holder had given permission > to Apache to include their code and derivative works under the Apache > license. > >Simon > > Frank Budinsky wrote: > > > Jeremy Boynes <[EMAIL PROTECTED]> wrote on 03/19/2007 06:14:58 PM: > > > > > >>On Mar 19, 2007, at 11:45 AM, Frank Budinsky wrote: > >> > >> > >>>Hmm, this seems like an example of where "legal red tape" may be > >>>getting > >>>in the way of the "spirit of reuse". > >> > >>One man's "spirit of reuse" is another's copyright infringement. This > >>is not something to take lightly. > > > > > > I'm sure that's true. Nobody's taking this lightly. > > > > In this particular case, however, both parties, the EMF contributors at > > Eclipse, and the Tuscany consumers (us) here at Apache agree that this is > > not a case of copyright infringement. So, it seems to me that a > > light-weight process for dealing with this kind of scenario is needed. If > > need be, we'll pull out this code temporarily, but I'd prefer to see some > > sensible way to deal with it without doing that. > > > > I'm also still looking for an answer to my question from below: I also > > wonder where is the fine line between providing a "changed method" vs "a > > copied method with a change" in a subclass? > > > > According to the strict interpretation of the two licenses, you really > > can't do much with EPL code at Apache. Something as trivial as overriding > > a base method that looks like this: > > > > void foo() { > > x = 3; > > bar(); > > } > > > > to set x to 4 instead of 3: > > > > void foo() { > > x = 4; > > bar(); > > } > > > > could be considered copyright infringement. If not, then where is the fine > > line? > > > > Thanks, > > Frank. > > > > > >>EPL is very specific: > >> When the Program is made available in source code form: > >> a) it must be made available under this Agreement; and > >> b) a copy of this Agreement must be included with each copy of > >>the Program. > >> > >>Distributing EPL code in source form under the Apache License is a > >>violation of these EPL terms. Period. > >> > >>To distribute this code under the Apache License it needs to be > >>relicensed by the copyright owner. This is not an ongoing > >>contribution as covered by a CCLA but a grant of software written > >>elsewhere to the Foundation. There is a process for this, handled by > >>the Incubator: > >> http://incubator.apache.org/ip-clearance/index.html > >> > >>Another alternative might be to distribute the code in binary form. > >>This would involve making the "necessary change" elsewhere (say at > >>Eclipse), releasing that derivative under the EPL in binary form. > >>Tuscany would then be able to redistribute that code in its binary > >>form. That's a suggestion - you probably want to talk to a lawyer and > >>I would suggest running it past [EMAIL PROTECTED] > >> > >> > >>>Here's the general problem: > >>> > >>>1) We need to override a base class' behavior to do something > >>>"slightly > >>>different". > >>>2) Looking at the base class, we notice that it requires a tiny > >>>change in > >>>the middle of a medium to large sized method. We request a slight > >>>refactoring of the base (EMF) code, which they agree to fix in > >>>their next > >>>version. > >>>3) We can't move to the next version yet, so we add a copy of the > >>>method > >>>(with the change) in our subclass and then proceed as if it was > >>>already in > >>>the base class. > >>> > >>>Note that we really don't want to do this in the first place > >>>because if we > >>>later forget to remove the override and EMF fixes some other bug in > >>>the > >>>same method, we won't ever pick up the fix. Unfortunately, however, we > >>>have no choice in the short term other than to rewrite the whole > >>>method, > >>>but since it's intricately tied to the rest of the base class > >>>implementation it really couldn't be much different. We could > >>>rewrite the > >>>entire class, but that completely defeats the purpose
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
On Mar 20, 2007, at 1:11 PM, Frank Budinsky wrote: I've confirmed that IBM, the copyright holder, gives permission to Apache to reuse the two EMF files in question. Thanks for confirming this. I've opened TUSCANY-1185 to contribute the two base classes, provided in an attachment. Jeremy, let me know if this is good enough for you, or if you still want me to remove the Tuscany subclasses and resubmit them. I can't ack this for the ASF - that has to be done by an Officer as described in the IP Clearance process. They would probably want something official from IBM (Software Grant). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
Jeremy, I don't understand your last comment: > I can't ack this for the ASF - that has to be done by an Officer as > described in the IP Clearance process. They would probably want > something official from IBM (Software Grant). By attaching the two files to the JIRA, and selecting the "Grant license to ASF ..." button, I (on behalf of IBM) am contributing the classes. If I didn't have the right to do that, I would obviously be personally liable. How is this contribution different from any other contributed source files? What I was specifically asking is whether there is some stringent timeline issue that I still need to deal with? The code had been in SVN before the license was officially granted. Thanks, Frank. Jeremy Boynes <[EMAIL PROTECTED]> wrote on 03/21/2007 12:41:29 PM: > On Mar 20, 2007, at 1:11 PM, Frank Budinsky wrote: > > > I've confirmed that IBM, the copyright holder, gives permission to > > Apache > > to reuse the two EMF files in question. > > Thanks for confirming this. > > > > > I've opened TUSCANY-1185 to contribute the two base classes, > > provided in > > an attachment. > > > > Jeremy, let me know if this is good enough for you, or if you still > > want > > me to remove the Tuscany subclasses and resubmit them. > > I can't ack this for the ASF - that has to be done by an Officer as > described in the IP Clearance process. They would probably want > something official from IBM (Software Grant). > > -- > Jeremy > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
On Mar 21, 2007, at 10:27 AM, Frank Budinsky wrote: Jeremy, I don't understand your last comment: I can't ack this for the ASF - that has to be done by an Officer as described in the IP Clearance process. They would probably want something official from IBM (Software Grant). By attaching the two files to the JIRA, and selecting the "Grant license to ASF ..." button, I (on behalf of IBM) am contributing the classes. If I didn't have the right to do that, I would obviously be personally liable. How is this contribution different from any other contributed source files? It isn't. And Apache has a IP Clearance process for handling them. Please don't shoot the messenger. What I was specifically asking is whether there is some stringent timeline issue that I still need to deal with? The code had been in SVN before the license was officially granted. The big one is that we can't release this code until this resolved. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
I believe this issue is resolved. I spent a good part of the last two days chasing this down with the Lawyers to alleviate Jeremy's concern. Does anyone other than Jeremy believe that this issue is not already resolved? If so, can you please explain exactly what else I need to do? Thanks, Frank. Jeremy Boynes <[EMAIL PROTECTED]> 03/21/2007 01:56 PM Please respond to tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org cc Subject Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1 On Mar 21, 2007, at 10:27 AM, Frank Budinsky wrote: > Jeremy, I don't understand your last comment: > >> I can't ack this for the ASF - that has to be done by an Officer as >> described in the IP Clearance process. They would probably want >> something official from IBM (Software Grant). > > By attaching the two files to the JIRA, and selecting the "Grant > license > to ASF ..." button, I (on behalf of IBM) am contributing the > classes. If I > didn't have the right to do that, I would obviously be personally > liable. > How is this contribution different from any other contributed source > files? It isn't. And Apache has a IP Clearance process for handling them. Please don't shoot the messenger. > > What I was specifically asking is whether there is some stringent > timeline > issue that I still need to deal with? The code had been in SVN > before the > license was officially granted. The big one is that we can't release this code until this resolved. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
I'd recommend asking a question on [EMAIL PROTECTED] They would give you all necessary guidance needed. On 3/21/07, Frank Budinsky <[EMAIL PROTECTED]> wrote: I believe this issue is resolved. I spent a good part of the last two days chasing this down with the Lawyers to alleviate Jeremy's concern. Does anyone other than Jeremy believe that this issue is not already resolved? If so, can you please explain exactly what else I need to do? Thanks, Frank. Jeremy Boynes <[EMAIL PROTECTED]> 03/21/2007 01:56 PM Please respond to tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org cc Subject Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1 On Mar 21, 2007, at 10:27 AM, Frank Budinsky wrote: > Jeremy, I don't understand your last comment: > >> I can't ack this for the ASF - that has to be done by an Officer as >> described in the IP Clearance process. They would probably want >> something official from IBM (Software Grant). > > By attaching the two files to the JIRA, and selecting the "Grant > license > to ASF ..." button, I (on behalf of IBM) am contributing the > classes. If I > didn't have the right to do that, I would obviously be personally > liable. > How is this contribution different from any other contributed source > files? It isn't. And Apache has a IP Clearance process for handling them. Please don't shoot the messenger. > > What I was specifically asking is whether there is some stringent > timeline > issue that I still need to deal with? The code had been in SVN > before the > license was officially granted. The big one is that we can't release this code until this resolved. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende http://people.apache.org/~lresende
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
I think it may not be completely clear to everyone yet why this code does not have to follow the IP clearance process as described at: http://incubator.apache.org/ip-clearance/ From that link it doesn't seem completely clear when you need to follow the IP clearance process or when a code attached to a JIRA can be treated just as any other patch from a community member. Is the question whether or not these two classes "represents a substantial contribution"? ...ant On 3/21/07, Frank Budinsky <[EMAIL PROTECTED]> wrote: I believe this issue is resolved. I spent a good part of the last two days chasing this down with the Lawyers to alleviate Jeremy's concern. Does anyone other than Jeremy believe that this issue is not already resolved? If so, can you please explain exactly what else I need to do? Thanks, Frank. Jeremy Boynes <[EMAIL PROTECTED]> 03/21/2007 01:56 PM Please respond to tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org cc Subject Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1 On Mar 21, 2007, at 10:27 AM, Frank Budinsky wrote: > Jeremy, I don't understand your last comment: > >> I can't ack this for the ASF - that has to be done by an Officer as >> described in the IP Clearance process. They would probably want >> something official from IBM (Software Grant). > > By attaching the two files to the JIRA, and selecting the "Grant > license > to ASF ..." button, I (on behalf of IBM) am contributing the > classes. If I > didn't have the right to do that, I would obviously be personally > liable. > How is this contribution different from any other contributed source > files? It isn't. And Apache has a IP Clearance process for handling them. Please don't shoot the messenger. > > What I was specifically asking is whether there is some stringent > timeline > issue that I still need to deal with? The code had been in SVN > before the > license was officially granted. The big one is that we can't release this code until this resolved. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
Ant, perhaps that is the question. I certainly don't think this is a substantial contribution, but who can confirm that? Frank. "ant elder" <[EMAIL PROTECTED]> wrote on 03/21/2007 02:53:10 PM: > I think it may not be completely clear to everyone yet why this code does > not have to follow the IP clearance process as described at: > http://incubator.apache.org/ip-clearance/ > > From that link it doesn't seem completely clear when you need to follow the > IP clearance process or when a code attached to a JIRA can be treated just > as any other patch from a community member. Is the question whether or not > these two classes "represents a substantial contribution"? > >...ant > > On 3/21/07, Frank Budinsky <[EMAIL PROTECTED]> wrote: > > > > I believe this issue is resolved. I spent a good part of the last two days > > chasing this down with the Lawyers to alleviate Jeremy's concern. > > > > Does anyone other than Jeremy believe that this issue is not already > > resolved? If so, can you please explain exactly what else I need to do? > > > > Thanks, > > Frank. > > > > > > > > > > Jeremy Boynes <[EMAIL PROTECTED]> > > 03/21/2007 01:56 PM > > Please respond to > > tuscany-dev@ws.apache.org > > > > > > To > > tuscany-dev@ws.apache.org > > cc > > > > Subject > > Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1 > > > > > > > > > > > > > > On Mar 21, 2007, at 10:27 AM, Frank Budinsky wrote: > > > > > Jeremy, I don't understand your last comment: > > > > > >> I can't ack this for the ASF - that has to be done by an Officer as > > >> described in the IP Clearance process. They would probably want > > >> something official from IBM (Software Grant). > > > > > > By attaching the two files to the JIRA, and selecting the "Grant > > > license > > > to ASF ..." button, I (on behalf of IBM) am contributing the > > > classes. If I > > > didn't have the right to do that, I would obviously be personally > > > liable. > > > How is this contribution different from any other contributed source > > > files? > > > > It isn't. And Apache has a IP Clearance process for handling them. > > Please don't shoot the messenger. > > > > > > > > What I was specifically asking is whether there is some stringent > > > timeline > > > issue that I still need to deal with? The code had been in SVN > > > before the > > > license was officially granted. > > > > The big one is that we can't release this code until this resolved. > > -- > > Jeremy > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
On 3/21/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Mar 20, 2007, at 1:11 PM, Frank Budinsky wrote: > I've confirmed that IBM, the copyright holder, gives permission to > Apache > to reuse the two EMF files in question. Thanks for confirming this. > > I've opened TUSCANY-1185 to contribute the two base classes, > provided in > an attachment. > > Jeremy, let me know if this is good enough for you, or if you still > want > me to remove the Tuscany subclasses and resubmit them. I can't ack this for the ASF - that has to be done by an Officer as described in the IP Clearance process. They would probably want something official from IBM (Software Grant). I am a director of the ASF. Apparently the original copyright holder desires to contribute the same code to two different places under two different licenses. They are certainly within their rights to do so. The contribution under the other license isn't particularly relevant to me. Now, concerning the contribution which is presumably being made in good faith under the ASF license to the Tuscany project, I see no ASF wide legal or policy issue here, which means that the only remaining issue a technical one, namely whether or not tuscany wishes to accept this code. Now, if anybody has any reason to believe that the assertion of authorship is false (i.e., if there are Eclipse CVS or SVN logs which show contributions by others), then the issue is an entirely different one... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
Thank goodness, common sense applies :-) Now we can proceed with the release candidate. Thanks, Frank. [EMAIL PROTECTED] wrote on 03/21/2007 05:27:35 PM: > On 3/21/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > > On Mar 20, 2007, at 1:11 PM, Frank Budinsky wrote: > > > > > I've confirmed that IBM, the copyright holder, gives permission to > > > Apache > > > to reuse the two EMF files in question. > > > > Thanks for confirming this. > > > > > > > > I've opened TUSCANY-1185 to contribute the two base classes, > > > provided in > > > an attachment. > > > > > > Jeremy, let me know if this is good enough for you, or if you still > > > want > > > me to remove the Tuscany subclasses and resubmit them. > > > > I can't ack this for the ASF - that has to be done by an Officer as > > described in the IP Clearance process. They would probably want > > something official from IBM (Software Grant). > > I am a director of the ASF. > > Apparently the original copyright holder desires to contribute the > same code to two different places under two different licenses. They > are certainly within their rights to do so. The contribution under > the other license isn't particularly relevant to me. Now, concerning > the contribution which is presumably being made in good faith under > the ASF license to the Tuscany project, I see no ASF wide legal or > policy issue here, which means that the only remaining issue a > technical one, namely whether or not tuscany wishes to accept this > code. > > Now, if anybody has any reason to believe that the assertion of > authorship is false (i.e., if there are Eclipse CVS or SVN logs which > show contributions by others), then the issue is an entirely different > one... > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1 (IBMers involved with EMF code)
Frank, Were you the only IBM employee involved in the contribution of this code that is common to Apache Tuscany and to Eclipse EMF? If not, who were the other IBM employees? If it accurate to categorize the code as "common to Apache Tuscany and to Eclipse EMF"? or would you prefer a different description? This will answer a question for the "enhanced pedigree review" of the Tuscany code so that we can ship SOA Feature Pack Iteration 1. Regards, Paul Golick P. O. Box 12195, Dept. 6HSA (503 D224) 3039 Cornwallis Rd. Research Triangle Park, NC 27709-2195 office phone: 919-543-7177 cell phone: 919-943-2578 home phone: 919-493-3570 e-mail: [EMAIL PROTECTED] Frank Budinsky <[EMAIL PROTECTED]> 2007-03-22 09:01 AM Please respond to tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org cc Subject Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1 Thank goodness, common sense applies :-) Now we can proceed with the release candidate. Thanks, Frank. [EMAIL PROTECTED] wrote on 03/21/2007 05:27:35 PM: > On 3/21/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > > On Mar 20, 2007, at 1:11 PM, Frank Budinsky wrote: > > > > > I've confirmed that IBM, the copyright holder, gives permission to > > > Apache > > > to reuse the two EMF files in question. > > > > Thanks for confirming this. > > > > > > > > I've opened TUSCANY-1185 to contribute the two base classes, > > > provided in > > > an attachment. > > > > > > Jeremy, let me know if this is good enough for you, or if you still > > > want > > > me to remove the Tuscany subclasses and resubmit them. > > > > I can't ack this for the ASF - that has to be done by an Officer as > > described in the IP Clearance process. They would probably want > > something official from IBM (Software Grant). > > I am a director of the ASF. > > Apparently the original copyright holder desires to contribute the > same code to two different places under two different licenses. They > are certainly within their rights to do so. The contribution under > the other license isn't particularly relevant to me. Now, concerning > the contribution which is presumably being made in good faith under > the ASF license to the Tuscany project, I see no ASF wide legal or > policy issue here, which means that the only remaining issue a > technical one, namely whether or not tuscany wishes to accept this > code. > > Now, if anybody has any reason to believe that the assertion of > authorship is false (i.e., if there are Eclipse CVS or SVN logs which > show contributions by others), then the issue is an entirely different > one... > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1 (IBMers involved with EMF code)
Paul Golick <[EMAIL PROTECTED]> wrote on 04/02/2007 01:23:21 PM: [snip] > Is it accurate to categorize the code as "common to Apache Tuscany and to > Eclipse EMF"? or would you prefer a different description? We won't have exactly the same code in both projects. The two EMF classes, described below, are "code that IBM has contributed to both Eclipse EMF and Apache Tuscany". Thanks, Frank. [snip] > Frank Budinsky <[EMAIL PROTECTED]> > 2007-03-22 09:01 AM > Please respond to > tuscany-dev@ws.apache.org > > > To > tuscany-dev@ws.apache.org > cc > > Subject > Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1 > > > > > > > Thank goodness, common sense applies :-) > > Now we can proceed with the release candidate. > > Thanks, > Frank. > > [EMAIL PROTECTED] wrote on 03/21/2007 05:27:35 PM: > > > On 3/21/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > > > On Mar 20, 2007, at 1:11 PM, Frank Budinsky wrote: > > > > > > > I've confirmed that IBM, the copyright holder, gives permission to > > > > Apache > > > > to reuse the two EMF files in question. > > > > > > Thanks for confirming this. > > > > > > > > > > > I've opened TUSCANY-1185 to contribute the two base classes, > > > > provided in > > > > an attachment. > > > > > > > > Jeremy, let me know if this is good enough for you, or if you still > > > > want > > > > me to remove the Tuscany subclasses and resubmit them. > > > > > > I can't ack this for the ASF - that has to be done by an Officer as > > > described in the IP Clearance process. They would probably want > > > something official from IBM (Software Grant). > > > > I am a director of the ASF. > > > > Apparently the original copyright holder desires to contribute the > > same code to two different places under two different licenses. They > > are certainly within their rights to do so. The contribution under > > the other license isn't particularly relevant to me. Now, concerning > > the contribution which is presumably being made in good faith under > > the ASF license to the Tuscany project, I see no ASF wide legal or > > policy issue here, which means that the only remaining issue a > > technical one, namely whether or not tuscany wishes to accept this > > code. > > > > Now, if anybody has any reason to believe that the assertion of > > authorship is false (i.e., if there are Eclipse CVS or SVN logs which > > show contributions by others), then the issue is an entirely different > > one... > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]