Hi David, thank you,
I just realize that what I wrote regarding storing in git may have been misleading; while I wrote it I had in mind not 3rd party code but our
own source code related to build and test, so it may have been irrelevant to this discussion.
I fully agree that 3rd party binaries should not be stored in git , but distributed separately. So I believe we are in agreement here.
Let’s examine Cygwin then.
I see two questions here : 1) the relation between Titan and Cygwin, and 2) whether Titan, or any other open source code built on Cygwin could be used in
commercial projects.
The relation between Titan and Cygwin could be a “prerequisite” or a “works-with” type of dependency , or –as you suggest- no dependency at all.
I might need your help here to see clearly; BTW this relation between Titan and Cygwin is exactly the same as between Titan and any Linux platform ; and no,
I did not list Linux among dependencies. The reason I have listed Cygwin was exactly to provoke this kind of discussion before things would get more confusing.
Titan is a build system in itself, and the assumption below regarding giving directions Is accurate and I have no specific marketing reason to keep Cygwin
listed. If we can agree that listing Cygwin is unnecessary, I have no problem with removing the CQ. I suppose the same goes for MinGW then. Please confirm this would be an acceptable resolution.
As for 2) Red Hat offers a clear, unambiguous answer:
http://www.redhat.com/services/custom/cygwin/
A Cygwin License Contract provides you with:
·
the ability to distribute your applications without being bound by the GPL. You are not required to provide your applications in open source code form.
·
a license to distribute unlimited quantities of Cygwin libraries with your applications
So if one pays for a license contract, can keep applications developed on Cygwin in close source, commercial or whatever.
These are the terms currently we are using Cygwin within our company, based on a License contract we are paying for.
Best regards
Elemer
From: tools-pmc-bounces@xxxxxxxxxxx [mailto:tools-pmc-bounces@xxxxxxxxxxx]
On Behalf Of David M Williams
Sent: Tuesday, October 28, 2014 2:18 PM
To: Tools PMC mailing list
Subject: Re: [tools-pmc] Titan's list of "works with" exceptions to full IP review
1. Sounds good.
2. Is correct
[4]. ( libxml2, libpcap, sqlite) sound fine, I think we (me and Doug) stated our agreement there.
That leaves 2 issue to resolve, I believe.
3. Cygwin. To clarify, if I was vague before, my reading of the the "license" in the CQ is that the result could not be used in commercial (closed source) projects -- only open source. You can
tell me I'm wrong, but, since Eclipse explicitly tries to be "commercial product friendly", I think it is a valid point to raise. I realize *you* may only be interested in "Titan", but in general, Eclipse projects are to be extensible and usable in commercial
(closed source) products. So, that's why I don't want to rubber stamp that as "works with".
But, there may be larger, yet easier, question here. You say "if the user prefers Cygwin, he/she will have to install it and compile Titan on it.". So? Users
could install and compile Titan with anything they want, I would assume. What business of it is yours, exactly?
I say it so "confrontationaly" just to illustrate I must be missing your point. I doubt you are going to list every compiler users might decide to use, so what's so special about Cygwin? I thought
it was somehow more integral to your own build process? Is that not true? Or, perhaps I simple misunderstand the nature of Titan? Is Titan an "application" or is it a "build system" itself? If the latter, and you just want to be able to "give directions" for
Windows, I'd see no problem with you saying "these are directions for Cygwin, but you can use what ever Windows compiler you would like". If you simply wanted to "list it" -- such as for "marketing reasons" -- I'm not sure that needs any sort of "exception".
The exceptions are for things your project plans to use. Right? (Though, it is a good idea not to list things with a conflicting license, I think that is a separate issue that the "works with" issue.)
[5]. Storing in Git. Yes, cool, and good idea. I used to store JVM's in CVS for proper reproducibility over a 10-20 year time frame ... but ... not at the Eclipse Foundation. I'm afraid it is against
"Eclipse Foundation rules" with respect to "works with" items. That it is considered a form of "distribution". The related "works with" documents are pretty explicit about that, as I recall. Do you agree with that? And you were asking for an "exception to
*that* rule"? If so, since it was a board directive, then I think it's the board that would have to grant to the exception, not the PMC. But, if they happened to ask me, I would advise against it :) Too confusing to users to know "what's being distributed
from Eclipse" and "what they get and use at their own risk".
Please correct all the misconceptions I have expressed.
Thanks,
From: Elemér Lelik <elemer.lelik@xxxxxxxxxxxx>
To: Tools PMC mailing list <tools-pmc@xxxxxxxxxxx>,
Date: 10/28/2014 04:41 AM
Subject: Re: [tools-pmc] Titan's list of "works with" exceptions to full IP review
Sent by: tools-pmc-bounces@xxxxxxxxxxx
Hi David,
OK , let me try to revisit these issues, but first some clarifications might be needed:
Although I understand your separation below into “git repository” and “build machine”, our practice is that both the source code for the binary to be produced and all the code needed
to build and test it resides in git , and in the same repository, but in different directories ; this permits us to develop the code itself and tests in parallel ; and we would prefer if possible to keep the same code structure in the final git repository.
Of course, your separation makes sense from IP point of view as this is the criteria of which part of the code makes it into the final binaries.
And yes, as you mentioned, understanding and clarifying the fine division between e.g. “works with” and exempt prerequisite” dependencies is not easy, especially as there seems
to be no consensus among the group itself taking decisions.
But back to your issues:
1. And then beyond that, it seemed like there were a few requests for which I said there was no good reason not to have full review (which I mentioned in my one by one reviews) ... and, granted,
I was the only one who commented .... but ... one comment is more than zero, and is all "we" have to go on.
Based on your observations, I have submitted the source code for a number of dependencies to be reviewed and to be included eventually in Orbit.
8771 ant-contrib 1.0b2-as "works with" exception to full IP review unmodified binary source code submitted for IP review
8776 antlr 4.1.3 -as "works with" exception to full IP review unmodified binary source code submitted for IP review
8777 jung2 2.0.1 - as "works with" exception to full IP review unmodified binary source code submitted for IP review
8778 JExcel 2.6.12 -as "works with" exception to full IP review unmodified binary source code submitted for IP review
8779 commons-collections 4.01- as "works with" exception to full IP review unmodified binary source code submitted for IP review
2.
I am waiting for is clarification on which are literally only required during build and test time
Again, bison and flex are used indirectly, to generate the appropriate syntaxes , which then will be included in the final compilation
8767 bison 3.0.2 - as "works with" exception to full IP review unmodified binary build dependency only (source generated by bison to be compiled into the
project)
8768 flex 2.5.39- as "works with" exception to full IP review unmodified binary build dependency only (source generated by flex to be compiled into the
project)
Of the above, ant-contrib is used only during building the Java plug-ins.
3. I know for "Cygwin" Doug and myself had reservations about it ..
The Titan binary can be compiled against a number of platforms, Solaris, Linux, and Cygwin among others. It appears that there are users who prefer to work with Cygwin and we don’t
want to remove this possibility. On the other hand we don’t intend to distribute
any part of Cygwin, nor in source , neither in binary form: if the user prefers Cygwin, he/she will have to install it and compile Titan on it. In our interpretation the quoted
exception should cover this by far and we heard no counterarguments only a generic and vague fear of Cygwin tainting the code.
For libxml2, libpcap, sqlite I believe we have clarified that these are generic Linux libraries present in mainstream Linux distributions; I have even been rebuked for submitting
them as dependencies.
If you consider them as superfluous , please let me know.
I agree this project reached an impasse, not in the least due to disagreements among you guys; please help us moving it forward; we rely on your expertise and professionalism.
If 2016 is the date targeted, than maybe we should consider taking this project elsewhere. There are a number of potential users awaiting the code and asking us daily what’s going
on.
Thank you and best regards
Elemer
From:
tools-pmc-bounces@xxxxxxxxxxx [mailto:tools-pmc-bounces@xxxxxxxxxxx]
On Behalf Of David M Williams
Sent: Monday, October 27, 2014 3:26 PM
To: Tools PMC mailing list
Subject: [tools-pmc] Titan's list of "works with" exceptions to full IP review
To answer the dozen of posts, with 1, I'll say what I am waiting for is clarification on which are literally only required during build and test time, combined with an explicit agreement from project
these will exist only on build machine, not in a Git repository ... seemed to be some confusion (in my mind) on "what was what" and "what the project understood" about "works with" status. When I requested something similar, it was "pooh-pooh'd by Wayne" as
"taking more work" ... and so there it sits ... in impasse. I think it's hard for the project to "know what to do" when "the PMC and EMO disagree" ... and if the EMO wants to "take over" ... well ... I don't really know what to say about that.
Of course, I've been thinking "I should do that summary soon" ... as soon as I get some free time ... you know, like, 2016 :)
And then beyond that, it seemed like there were a few requests for which I said there was no good reason not to have full review (which I mentioned in my one by one reviews) ... and, granted, I was the only one who commented .... but ... one comment is more
than zero, and is all "we" have to go on.
I know for "Cygwin" Doug and myself had reservations about it ... even though Mike M. did not ... that should be handled as an explicit case of "EMO overriding the PMC" if Cygwin is really required ... if not really required, I'd drop the request if I was Titan.
Sorry I've not had time to summarize my (and others responses) ... but, it seems that anyone with the need, could do that?
Sorry to be brief, but, I have to run ... and wanted to make some response.
From: emo-ip-team@xxxxxxxxxxx
To: tools-pmc@xxxxxxxxxxx,
Date: 10/27/2014 08:03 AM
Subject: [tools-pmc] [CQ 8768] flex 2.5.39- as "works with" exception to full IP review
Sent by: tools-pmc-bounces@xxxxxxxxxxx
http://dev.eclipse.org/ipzilla/show_bug.cgi?id=8768
--- Comment #5 from Elemer Lelik <elemer.lelik@xxxxxxxxxxxx> 2014-10-27 08:03:49 ---
Hey guys,
is there any additional info you expect from us regarding this CQ?
Thank you and regards
Elemer
--
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