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

We haven't had much trouble using the UEIimporter of MTJ as it is for our SDK,
so we never really discussed doing changes to it to fit our needs, so for us,
the licensing hasn't been an issue.

The problems we have had with it were in combination with an internal version of our
SDK, but then we made the changes to the SDK instead to fit with MTJ, since our external
SDK version worked fine with MTJ.

I don't see any need for a change from Sony Ericsson's part,

Br Tomas


-----Original Message-----
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Christian Kurzke
Sent: torsdag den 22 oktober 2009 20:41
To: Mobile Tools for The Java Platform mailing list
Subject: Re: [dsdp-mtj-dev] Release parts of MTJ in a permissive license

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

Back to the top