[
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,
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
