|[eclipse.org-architecture-council] [Bug 246945] New: Best Practices for interfacing with libs that are not EPL compatible|
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.
Back to the top