[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[eclipse.org-architecture-council] [Bug 246945] 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
Mike Milinkovich <mike.milinkovich@xxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mike.milinkovich@xxxxxxxxxxx
--- Comment #1 from Mike Milinkovich <mike.milinkovich@xxxxxxxxxxx> 2008-09-11 05:54:00 -0400 ---
You correctly mention that CQ's are required for these types of dependencies.
Perhaps not all readers are aware that this requirement is driven by a formal
Board-approved policy on how to deal with third party package dependencies. It
doesn't address the license compatibility issue, but any "best practices"
conversation will need to take the full policy into account.
Please see
http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf
I am very interested in how this conversation develops. There are quite a few
different things that we are looking at within the EMO and the Board which are
all partial solutions. But I definitely agree that dynamic assembly is becoming
more and more important and we need to figure this out. Unfortunately, the
legal frameworks we have to conform with are evolving at least one order of
magnitude slower than the technical ones :-(
I guess what I am saying is that we understand that this is an important issue
that must be solved. But it is going to take time and some serious legal and
process work to get there.
P.S. Is LGPL the major source of the problem?
--
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.