Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dsdp-mtj-dev] Release parts of MTJ in a permissive license 
Craig, Ian, et al,
My take away from the discussions on the mailing list is that there is not enough interest to 
release the UEI SDK importer as EDL.
Seems that - if anything - we should take a second look at the APIs (and patterns) needed to implement an importer, and maybe better document / clean up some of the code on the MTJ side.
Since any API change has to be carefully weighed with regards to impacts on the backward compatibility, 
this is a long-term item.


-Christian


Ian Skerrett wrote:

Craig,

I agree that EPL should work in most cases.   There are hundreds, if not
thousands, of examples where companies build commercial products on EPL
licenses projects.

Ian


-----Original Message-----
From: Content-filter at foundation.eclipse.org
[mailto:postmaster@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Craig Setera
Sent: Sunday, October 25, 2009 11:25 AM
To: Mobile Tools for The Java Platform mailing list
Subject: Re: [dsdp-mtj-dev] Release parts of MTJ in a permissive license
Coming from the guy that originally wrote the code and has no commercial ties to MTJ, I'm not a big fan of making this change. It is quite possible that I'm being naive, but it seems to me that:
1) If an importer requires "tweaks" to the current UEI importer to work correctly for an SDK, that those tweaks should be shared with the community. 2) I see no reason that the UEI importer (with EPL license) can't be used for a company as a *conceptual* template for implementing their own importers without being concerned about EPL. I'm not a lawyer, so my #2 statement may not be realistic in the real world. When I originally switched to EPL for EclipseME it was to make it easier for companies to use EclipseME if they chose. I've always felt that GPL was too difficult to deal with, while EPL strikes a nice balance. My uninformed personal opinion is that EPL should work, but maybe I'm missing something here. 
Craig

Christian Kurzke wrote:
Please note: This is my personal opinion, and does not reflect the opinion of my employer... ;)
I somewhat concur with both, Gorkem and Dan - Changing the licensing to EDL would make it easier for companies to create "proprietary" implementations without contributing back to Eclipse, and yes, publishing sample code is a "easy way out" for writing documentation.
We need to think through the advantages and disadvantages of such a license change, and I'm curious to hear more feedback from potential "adopters".
I dont know if there are companies "out there" who would like to implement a closed source SDK importer but have struggled to do so. 
IF this is the case, and we as a project want them to use MTJ, we could
a) Improve our documentation and help them implement their closed source importer b) "give away" the UEI importer to be used by them as a template. (which would require EDL, otherwise their importer would have to be EPL) c) convince the company that they should create an open source (EPL) version of their SDK importer.
I wonder how this would affect people contributing "back" to the UEI importer? I assume that even if people create their own EPL version of an SDK importer, they would not contribute any improvements back into the UEI importer code?
On the other hand - I understand that the EDL license for the UEI importer would allow another company which has a "almost UEI" compliant SDK to use a proprietary modified UEI importer w/o giving changes back. This is probably mostly concerning, considering the UEI standard is not actively maintained, and there is a potential for incompatible extensions to the UEI standard by companies.
Again, this was really just a "testing the waters" proposal, and i would like to hear feedback from the wider community, especially from companies who are currently implementing their own SDK importers (RIM? Ericsson? S/E?).
Given that this would be a difficult process to change the license, we would need a very good reason for this. 

-Christian







Dan Murphy wrote:
I'm not a legal expert, but did some work using eclipse code that had to be modified... The legal chaps determined that under the terms of the epl my modifications had to be contributed back to eclipse... I guess this might be seen by some as giving away ip, personally I think it's right to ask that improvements are contributed back but I guess this might not be the view of all companies. 
Just my 2 pennies worth
Dan

----- Sent on the hoof from my phone ! -----
On 22 Oct 2009, at 16:26, Gorkem Ercan <gercan@xxxxxxx <mailto:gercan@xxxxxxx>> wrote:
Would not the same argument be applied to all parts of all the Eclipse projects? For instance if the most complex launch configuration implementation is junit launch configuration than should junit component be EDL as well? Is there really a way to determine if a component is not going to be someone's example code at some point.
I fear, we may actually be trying to compensate for lack of documentation, example and training material by changing the license? 

--
Gorkem
On Wed, Oct 21, 2009 at 1:24 AM, Christian Kurzke <christian@xxxxxxxxxxxx <mailto:christian@xxxxxxxxxxxx>> wrote: 

    Hi Ian, Gorkem

    The rationale behind proposing to use the EDL license for the UEI
    importer is that:

    1) It is the most "complex" SDK importer, and shows good usage of
    the APIs
    2) It may be useful for companies to use this code as a
    "template" to create their own, non EPL licenses commercial SDK
    importers.

    We as a project need to weigh the advantages:
    potentially easier implementation if SDK importers by commercial
    3rd parties, leading to more available SDKs to be used with MTJ)

    and the disadvantages:
    Commercial 3rd party implementations will not "contribute back"
    to the common project code base-line.


    -Christian



    Ian Skerrett wrote:


        Not really sure why EPL is a hindrance in this scenario?
        Doesn't EPL allow for this?
------------------------------------------------------------------------ 


        *From:* Content-filter at foundation.eclipse.org
        <http://foundation.eclipse.org>
        [mailto:postmaster@xxxxxxxxxxxxxxxxxxxxxx
        <mailto:postmaster@xxxxxxxxxxxxxxxxxxxxxx>] *On Behalf Of
        *Gustavo Eliano
        *Sent:* Tuesday, October 20, 2009 3:51 PM
        *To:* Mobile Tools for The Java Platform mailing list
        *Subject:* Re: [dsdp-mtj-dev] Release parts of MTJ in a
        permissive license

        the main idea here is to make it easier for some one to
        create its own importer. since the UEI importer is the most
        complext one it provide a lot of good ideas and good code to
        do that. if this plugin is released as EDL it would be easier
        for any company to use its code (or parts of the code)

        On Tue, Oct 20, 2009 at 2:36 PM, Gorkem Ercan <gercan@xxxxxxx
        <mailto:gercan@xxxxxxx> <mailto:gercan@xxxxxxx
        <mailto:gercan@xxxxxxx>>> wrote:

        How does EPL hinder the further enhancing of the UEI importer?
        --
        Gorkem

        On Tue, Oct 20, 2009 at 8:02 PM, Gustavo Eliano
        <gustavo.eliano@xxxxxxxxx <mailto:gustavo.eliano@xxxxxxxxx>
        <mailto:gustavo.eliano@xxxxxxxxx
        <mailto:gustavo.eliano@xxxxxxxxx>>> wrote:

           Hi MTJ,

           we had some discussion in todays call about releasing some
        parts
of MTJ in a permissive license. This would make it easier for anyone to extend MTJ. Since this year, the Eclipse foundation 
           already accept to distribute example plugins as EDL (Eclipse
           Distribution License). This is a BSD-like license, This link

<http://dev.eclipse.org/blogs/mike/2009/05/21/some-new-license-flexibility/>



           have some details about that.

           the initial proposal that came in the call was to have:
           - release all examples both as EPL and EDL
           - release the UEI importer both as EPL and EDL (still need
        to both
           check if this is possible since it is not an example)

           i really like this idea, but i would like to get a
        feedback from
           eveyone on the list to see if this make sense or not.

           :)
           gep

           _______________________________________________
           dsdp-mtj-dev mailing list
           dsdp-mtj-dev@xxxxxxxxxxx <mailto:dsdp-mtj-dev@xxxxxxxxxxx>
        <mailto:dsdp-mtj-dev@xxxxxxxxxxx
        <mailto:dsdp-mtj-dev@xxxxxxxxxxx>>

           https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev



        _______________________________________________
        dsdp-mtj-dev mailing list
        dsdp-mtj-dev@xxxxxxxxxxx <mailto:dsdp-mtj-dev@xxxxxxxxxxx>
        <mailto:dsdp-mtj-dev@xxxxxxxxxxx
        <mailto:dsdp-mtj-dev@xxxxxxxxxxx>>

        https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
------------------------------------------------------------------------ 


        _______________________________________________
        dsdp-mtj-dev mailing list
        dsdp-mtj-dev@xxxxxxxxxxx <mailto:dsdp-mtj-dev@xxxxxxxxxxx>
        https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev

    _______________________________________________
    dsdp-mtj-dev mailing list
    dsdp-mtj-dev@xxxxxxxxxxx <mailto:dsdp-mtj-dev@xxxxxxxxxxx>
    https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev


_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx <mailto:dsdp-mtj-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev

------------------------------------------------------------------------

_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev

_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev

_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev

_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev

Back to the top