Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tools-pmc] FW: [CQ 8391] Apache cordova Version: 3.0.0 and later


Thank you Wayne for trying to find a solution... I am fine with both alternates (not that it matters) and also can try to make the case to Mike. 
--
Gorkem

On Tue, Sep 9, 2014 at 3:14 PM, Wayne Beaton <wayne@xxxxxxxxxxx> wrote:
The word "bypass" is intended (I believe) to refer to bypassing the "full" IP due diligence process. It's not intended as way of opting out of the IP due diligence process, but more an acknowledgement that there are conditions under which the full IP due diligence process is impossible or impractical, and unnecessary.

Ultimately, it is up to you, the PMC to make this call. But here are some thoughts that I hope are helpful.

I don't feel that this is a "type 1" on the basis that the project is not all that useful without Cordova.

It's reasonable to think of this as a "type 2" works-with. To have it designated as such, you'd have to have take at least one version of it through the full pre-req dependency process. I wonder if it makes sense to do this with part of Cordova? e.g. carve out just the Android functionality and get full IP approval for that and then declare a works-with on everything else. I think that this is possible given the nature of how the software is distributed (e.g. you don't get the iPhone bits when you're running on Ubuntu).

I think, though, that it might be better to pursue the exempt pre-req route. In this case, I believe that getting the user to download Cordova is the desired means of acquiring the software. While the software is not strictly "already on" the users' workstation, it is completely reasonable to assume that the sort of user who would download Thym will find it completely reasonable to download some version of Cordova (this isn't on the list, but I think that you can argue that it is a reasonable interpretation). Further, because new versions are being created on a regular basis and it would be impractical for the project to try and keep pace with distributing the latest bits. In fact, there is a range of versions that the user may opt to select from and it would be wrong to restrict the user to any particular version. Reviewing any one of them is impractical; reviewing them all is effectively impossible.

Note that exempt pre-req requires approval from the EMO(ED), so you will have to make the case to Mike.

HTH,

Wayne


On 09/09/14 07:59 AM, Gorkem Ercan wrote:

On Tue, Sep 9, 2014 at 2:09 AM, David M Williams <david_williams@xxxxxxxxxx> wrote:
I think the PMC's interest is not "legal" per se, but to decide if this is a case if it is ok to " by pass" the normal, Eclipse legal process, as directed by the Board of Directors. [See note below]
(Thanks for being so open about your biases, Doug -- but not sure that strengthens your case. :)

I guess it's not clear to me why it is not submitted for legal/IP review? Like other third party code? Smells like a "let's by-bass the rules" case to me ... and I've heard of no good reason why. (I can imagine some, not all of them ill-intended, but haven't heard any reasons stated).
 

We are not trying to by-pass any rules. My original submission, because of my confidence to a project coming form Apache, was not for workswith even though I believe a workswith relation. However Sharon warned on ipzilla that because Cordova ships iOS artifacts and Eclipse is "currently unable to distribute any XCode or Apple artifacts". After this warning I had to opt for workswith because Thym never had any intention to distribute the Cordova. 
 
And, it would be an even better end-user experience, if it could be "built in" to Tyme, while leaving the door open to allow others to "play" if they want to in the future. (Same as WTP model).


Yes, it is a better end-use experience. Thym, is the only tool of its kind that allows developers to use their own Cordova engines or download a standard one. And nowadays there is no shortage of Cordova tools. IBM has worklight, MSFT has extension for VS, intel has XDK, Netbeans8 has it built-in so this is a cruical feature.  Here is a screencast from the early days of the implementation https://www.youtube.com/watch?v=xbRjDKkhIcY 



Plus, there has been no answer to my question, is there any useful function without it? If not, you are essentially forcing users to download it ... which has tons of complications for commercial adopters ... and is the opposite of "user friendly" in the "free and open" user community. Granted, "Apache license" is usually fine and more easily approved than others ... but that, and these other reason brings us back to "why not submit what you need for IP review, and see where that leads"?  Obviously, you wouldn't distribute the platforms that Cordova supports (WIndows 8, Android, etc.) ... those are the "works with" items in this case, not Cordova itself.

Yes there is functionality without it. You can still create/import a cordova project, develop your HTML, CSS and _javascript_. You can still use the config editor to manage the application and more importantly it is still possible to add Cordova plugins, using the Cordova plugin discovery wizard. 

However without a Cordova engine you can not export or run the application. 
 


I think I have contributed all I can to this discussion, I hope I've made my points, so if I'm quite for a while, it is just to give others plenty of chance to speak up.

Thanks,

= = = = =

Note: I'm basing my "interest" in the first two paragraphs of that document, at
https://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf
<quote>
The key issue we need to address is the one where projects are essentially bypassing the IP due
diligence process by requiring third party software as a prerequisite where such third party is to be
downloaded and installed separately by the user, instead of redistributing such software in their projects.
This is a concern for the Eclipse community because it is our goal to ship projects which contain
adequately reviewed IP and are, therefore, ready for commercial adoption.

Recognizing that it is probably impossible to codify a process precisely, the recommendation is that we
establish a policy framework for the Project Management Committees (PMCs) and the Eclipse
Management Organization (EMO) to use in classifying and judging each situation, and then leave the
implementation and final decision to the PMCs and the EMO.
</quote>






From:        Doug Schaefer <dschaefer@xxxxxxx>
To:        Tools PMC mailing list <tools-pmc@xxxxxxxxxxx>,
Date:        09/09/2014 01:01 AM
Subject:        Re: [tools-pmc] FW: [CQ 8391] Apache cordova Version: 3.0.0 and later
Sent by:        tools-pmc-bounces@xxxxxxxxxxx




I’m not sure what the PMC’s interest is here. There’s a legal question which I assumed was between the Eclipse IP team and the project.

At any rate, I would be perfectly fine if Thym only ever worked with Cordova and find the button to download Cordova an important feature for it’s users. Thus my +1.

But then, I’m perfectly fine if CDT redistributed the GPL GNU toolchain so I wouldn’t have to do it externally.

Doug.

From: Gorkem Ercan <gorkem.ercan@xxxxxxxxx>
Reply-To:
Tools PMC mailing list <
tools-pmc@xxxxxxxxxxx>
Date:
Monday, September 8, 2014 at 3:01 PM
To:
Tools PMC mailing list <
tools-pmc@xxxxxxxxxxx>
Subject:
Re: [tools-pmc] FW: [CQ 8391] Apache cordova Version: 3.0.0 and later





On Mon, Sep 8, 2014 at 2:29 PM, David M Williams <david_williams@xxxxxxxxxx> wrote:
I feel I'm being asked to "rubber stamp" something that hasn't been fully explained.

I made my initial comments in
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8391#c7 (where I expressed doubt that it met the sprit of the "works with" clause of
https://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf

To me, the spirit of that clause is, some Eclipse software is perfectly fine without the pre-req, but the pre-req is typically available, and if it is available, then the user gets some extra functionality. [The example of a "web browser" is given in the document. A more recent example might be the use of SWT's "GTK 3" .. if GTK 3 is available, it uses that for extra functionality, and if not, drops back to using GTK 2. And GTK is pretty much universally available on Linux distributions, and if by chance, neither are available, I believe they have some other "fallback" to use. Notice they do not simply "make GTK easier to get."]


So that leaves me with some unanswered questions:

1) is Tyme useful/usable without it? And this "Cordova" just gives them something extra?

I think, this is more like Apache Tomcat and WTP server tools relation rather than GTK. Similar to WTP does with Tomcat and other application servers , Thym also provides a download button to its users so that they can download a Cordova version from Apache and use it for testing and distributing.
 

2) It was stated "nothing is being distributed" with Tyme, but the intent was '...to make sure Thym users can get set up with Cordova
with minimal effort." I interpret this as opposite of the "works with" clause ... that it is not commonly available, so there is ?something? being distributed that makes it easier to get. What is is that something? What happens if a user does not want to get it?


Cordova is not commonly available as in GTK but as in Tomcat server. Cordova is a shell iOS, Android (or other supported platform's) application that is packed together with the HTML, _javascript_ and CSS that you have developed as your application. This allows mobile applications to be developed with HTML5 and deployed to multiple platforms.
 


I hope I don't seem I'm "holding things up" over technicalities ... but I believe it's my (our) responsibility to understand and judge these "rules" as best we can. In that spirit, I'm fully acknowledging I may simply be ignorant of what's being done and what "Cordova" is ... hence ... open and transparent discussion' :)


Thanks,






From:        
Doug Schaefer <dschaefer@xxxxxxx>
To:        
Tools PMC mailing list <tools-pmc@xxxxxxxxxxx>,
Date:        
09/04/2014 12:17 PM
Subject:        
[tools-pmc] FW: [CQ 8391] Apache cordova Version: 3.0.0 and later
Sent by:        
tools-pmc-bounces@xxxxxxxxxxx




Anyone want to deal with this? I¹m not sure why we have to vote on this.
+1 from me in any case.

On 2014-09-04, 10:02 AM, "
emo-ip-team@xxxxxxxxxxx"
<
emo-ip-team@xxxxxxxxxxx> wrote:

>
http://dev.eclipse.org/ipzilla/show_bug.cgi?id=8391
>
>
>Sharon Corbett <
sharon.corbett@xxxxxxxxxxx> changed:
>
>           What    |Removed                     |Added
>--------------------------------------------------------------------------
>--
>           Severity|triage                      |awaiting_pmc
>
>
>
>
>--- Comment #18 from Sharon Corbett <
sharon.corbett@xxxxxxxxxxx>
>2014-09-04 10:02:52 ---
>Thanks Doug;
>
>Unfortunately there actually needs to be an "open and transparent"
>discussion
>on the matter to ensure the exception meets the Eclipse Third Party
>Dependency
>Guidelines [1] followed by PMC voting on the issue.  This needs to be
>captured
>and most projects perform this via the PMC Mailing List.
>
>Typical rule of thumb is to use the standard voting rule...Five days max
>(or
>until everybody votes), minimum of 3 +1s, no -1s.
>
>The PMC Mailing URL is then provided back here in order for the IP Team to
>process the request accordingly.
>
>Can I leave this with you and/or David to initiate and provide an update
>here
>of the relevant URL when the vote has completed?
>
>Regards,
>Sharon
>
>[1]
>
https://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd
>_Party_Dependencies_Final.pdf
>
>
>
>
>
>Auto-Generated Text:  IPTeam awaiting response from PMC.
>
>
>--
>Configure CQmail:
http://dev.eclipse.org/ipzilla/userprefs.cgi?tab=email
>------- You are receiving this mail because: -------
>You are on the CC list for the CQ.
>_______________________________________________
>tools-pmc mailing list
>
tools-pmc@xxxxxxxxxxx
>To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit
>
https://dev.eclipse.org/mailman/listinfo/tools-pmc

_______________________________________________
tools-pmc mailing list

tools-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://dev.eclipse.org/mailman/listinfo/tools-pmc



_______________________________________________
tools-pmc mailing list

tools-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://dev.eclipse.org/mailman/listinfo/tools-pmc
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tools-pmc

_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tools-pmc



_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tools-pmc

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
EclipseCon
          Europe 2014

_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tools-pmc


Back to the top