Re: [tools-pmc] Titan's list of "works with" exceptions to full IP revie

[David M Williams <david_williams@xxxxxxxxxx>]

Thanks for the further clarifications,
Elemér. 

> I
fully agree that 3rd party binaries should not be stored in
git , but distributed separately.   So I believe we are in agreement
here.

Probably in agreement ... but, be careful
with that word "distributed" ... as "we" don't want
to "distribute" them at all (for "works with"). Perhaps
"obtainable" is the right word. Such as "can be obtained
from all major Linux distributors, such as RedHat, Debian, Ubuntu, ...
".

As for the general issue -- Wayne, or
IP Staff ... or, other Tools PMC members? ... can chime in here, too, but
I think instead of "works with", you simply need to "abstract
out" the essential part of the directions to be able to describe in
general terms. For example, "Users of Titan must have a xxx level
of a C++ compiler available for their platform, for example, A, B, or C,
or others that meat the following general requirements: X,Y,Z ... and have
the following libraries available L,M,N". [And, you might have a footnote,
eventually, that mentions that "users or adopters should pay attention
to what ever license comes with their compiler and tools, and be sure it
is compatible with EPL, and be sure it meets the licensing needs of their
eventual, intended product to be distributed" ... or something like
that, but that footnote is really just "business as usual", as
far as I'm concerned. 

I think the key, for us on PMC, is knowing
better "what's required at runtime" ... and if you *are* building
binaries for distribution, then we'd have to know that "build-only
and test-only" pieces you plan to have on the "build.eclipse.org"
machine to create those binaries.  (Do you ever "build a binary
for distribution? Or, perhaps some part of it is, even though users/adopters
then has to do "more builds" to end up with something useful?
-- sorry we on PMC need to be educated so much ... but, just think of us
as your first naive users :) ... who would need this level of explanation
too]. 

= = = = 

And, I think your quote about Cygwin
sort of "proves my point" ... If "I" has an adopter,
have to obtain/pay for a license from another 3rd party to be able to freely
distribute source/applications (especially free from GPL) that I built
with Titan, then ... it's not exactly "free" any more. And, that's
not to say an adopter might not choose to do that ... but, I think that
disqualifies it as a "works with" dependency.  Put another
way, *you and your company* might have that license with RedHat, but doubt
that "the Eclipse Foundation" does, nor would "all possible
future committers on Titan" so sounds to me if *you* (as an Eclipse
project) provided a "Titan binary" built with Cygwin, it would
have to say "you must purchase a license from RedHat before you can
use this free from GPL constraints" ... then, that sounds a little
too constraining, to me, for a "works with" dependency. But,
I'm no lawyer, and there could be other interpretations, or perhaps other
options, for which I am not aware. (For example, perhaps "The Eclipse
Foundation" could negotiate an agreement with RedHat, providing a
general "exception" in their license specifically for EPL, or
something?). 

= = = = 
So, where does this leave us with respect
to CQs such as CQ 8763 libxml2 -- is that a "runtime" dependency,
you still need a "works with" exception for? 
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.


Sorry I missed your "rebuked"
comment earlier. And, apologies, if it was me that came across that way.
But, no rebuke intended, and you are doing the right thing by submitting
them as "works with" CQs. And if it was someone else on this
list that came across that way ... someone we all know and love ... then
I know his "rebuke" was aimed at "the system" ... not
you ... you are doing a good job of "living with the system/processes
you were handed". 


= = = = 
I'll mark these three as PMC approved
"works with" -- and you agree they will exist only on the build
machine (or ... you might not even need that ... just "on developers
machines, and then the developer "checks in" (commits) the generated
code? Pros and cons to "regenerating every build" vs. "committing
generated code to git" ... perhaps worth a seperate note, if that's
an issues, since this one is getting wording as it is.
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. 
[Technical aside: again can continue
in separate note if needed, but I thought Apache Ant stopped distributing
a separate "ant-contrib" -- but, if you need someone to execute

/shared/common/apache-ant-1.9.4/fetch.xml

then open a "cross-project bug",
and I'd be game. and then just list ant as a "build time" dependency?
Who doesn't? -- i.e. probably no one does, even though it is commonly used
during builds! :) ]


 =
= = = = = 
Sound like these are distributed with
Java code, and you will change these to have reviewed. Thanks. 

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 

 =
= = = = = 

Let us know if/when we miss anything.
(Honest, we are here to help :) 




From:      
 Elemér Lelik <elemer.lelik@xxxxxxxxxxxx>
To:      
 Tools PMC mailing list
<tools-pmc@xxxxxxxxxxx>, 
Date:      
 10/31/2014 03:57 AM
Subject:    
   Re: [tools-pmc]
Titan's list of "works with" exceptions      
 to        full    
   IP        review
Sent by:    
   tools-pmc-bounces@xxxxxxxxxxx

---

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
_______________________________________________
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