[
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
|
Hi Guys,
sorry for sending the original email and keeping my self away of the discussions. i had a business trip last week and only have time to look back at MTJ now.
based on the emails it seems that there is no need to have the UEI plugin as EDL. just to be clear, the original ideia focus mainly on the examples plugins (which does not include the UEI one).. we would need to evaluate if we can do something like that with the UEI, since EDL mainly targets examples (that is what is on mike's blog post that i ). since but now i think that doesn't make sense to go on with the investigation.
about the example plugins, currently we have an example download that has implementation of some of MT extension points. below is a list of what is there:
- UEI importer
- JAD Editor
- Library
- Templates
do you think it make sense that MTJ release them both as EPL and EDL? as raised in the thread, the main idea would be to provide them as documentation and also as an starting point for anyone that wants to extend MTJ
:)
gep
On Mon, Oct 26, 2009 at 5:33 PM, Craig Setera
<craigjunk@xxxxxxxxxx> wrote:
FYI... I just realized that I was missing some chunks of this conversation in my email... a quick check of my spam folder shows that I've been losing a good bit of conversation over the last month from this group. I apologize if there was anything people were waiting to hear from me... if so, please resend.
On 10/26/09 2:55 PM, Christian Kurzke wrote:
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
_______________________________________________
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
