[eclipse.org-architecture-council] [Bug 246945] New: Best Practices for

[bugzilla-daemon@xxxxxxxxxxx]

https://bugs.eclipse.org/bugs/show_bug.cgi?id=246945  
Product/Component: Community / Architecture Council
           Summary: Best Practices for interfacing with libs that are not
                    EPL compatible
           Product: Community
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Architecture Council
        AssignedTo: eclipse.org-architecture-council@xxxxxxxxxxx
        ReportedBy: martin.oberhuber@xxxxxxxxxxxxx
                CC: slewis@xxxxxxxxxxxxx, d_a_carver@xxxxxxxxx, eclipse.org-
                    architecture-council@xxxxxxxxxxx


A number of projects would like to integrate with external libraries under
licenses not compatible with the EPL (LGPL, ...). What can be done in order to
help end-users come up with a working environment easily?

Clearly, 
* The LGPL library must be installed from a source hosted outside Eclipse
* A CQ must be filed indicating the dependency as "works-with" or "requires"

But how can end-users or other clients be instructed to get the complete
environment going? Could some P2 distribution technology help here? 

What is a proper means of announcing the "outside Eclipse" site? - ECF and
Subversive projects have separate update sites hosted outside Eclipse, but as
more and more projects are involved this gets confusing. Technology like antlr
and emfatic are also affected.

Perhaps there should be an "EPL-clean" update site for Eclipse Galileo hosted
on Eclipse.org, but also an independent "Various Open Source" update site
hosted elsewhere, which would reference both EPL and non-compatible licenses?
would that be allowed?


-- 
Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.