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 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 confirm. He has not
> >>>>>>done
> >>>>>>so.
> >>>>>>
> >>>>>>What seems odd to me is that if this was generated then I would
> >>>>>>have
> >>>>>>expected consistent text to have been produced by the generator.
> >>>>>>Instead we have things like:
> >>>>>>
> >>>>>>+ * $Id: BasicExtendedMetaData.java,v 1.26 2006/04/29 11:45:28
> >>>>>>emerks
> >>>>>>Exp $
> >>>>>>
> >>>>>>and
> >>>>>>
> >>>>>>+ * $Id: XSDEcoreBuilder.java,v 1.71 2006/08/15 16:04:41 emerks
> >>>>>>Exp $
> >>>>>>
> >>>>>>which correlate directly to headers found in files in the Eclipse
> >>>>>>repo. This makes the provenance of the code uncertain which is
> >>>>>>why we
> >>>>>>need clarification of what happened.
> >>>>>>
> >>>>>>--
> >>>>>>Jeremy
> >>>>>>
> >>>>>>On Mar 18, 2007, at 8:34 AM, kelvin goodson wrote:
> >>>>>>
> >>>>>>
> >>>>>>>I think you are freferring to commit r513560 .* *There was no
code
> >>>>>>>copied
> >>>>>>>from eclipse. The EMF generator puts an eclipse header in to
> >>>>>>>generated code
> >>>>>>>by default. That code was simply the result of using that
> >>>>>>>generator
> >>>>>>>against
> >>>>>>>our own schemas.
> >>>>>>>
> >>>>>>>Regards, Kelvin.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>On 17/03/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
> >>>>>>>
> >>>>>>>>Not to be a party-pooper, but what was the outcome with the code
> >>>>>>>>copied from Eclipse?
> >>>>>>>>--
> >>>>>>>>Jeremy
> >>>>>>>>
> >>>>>>>>On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>I have posted an SDO Java M3 release candidate here:
> >>>>>>>>>http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/
> >>>>>>>>><http://
>
>>>>>>>>>people.apache.org/%7Erobbinspg/M3-RC1/<http://people.apache.org/
> >>>>>>>>
> >>>>>>>>~robbinspg/M3-RC1/>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>Please take a look at this and try it out, so that I can pick
up
> >>>>>>>>>any errors
> >>>>>>>>>quickly and move towards a vote on a proper release in the
short
> >>>>>>>>
> >>>>>>>>term.
> >>>>>>>>
> >>>>>>>>>Thanks, Kelvin.
> >>>>>>>>
> >>>>>>>>
>
>>>>>>>>-----------------------------------------------------------------
> >
> >
> >>>>>>>>--
> >>>
> >>>>>>>>--
> >>>>>>>>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]
