Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[] [Bug 246945] Best Practices for interfacing with libs that are not EPL compatible  
Product/Component: Community / Architecture Council

Doug Schaefer <doug.schaefer@xxxxxxxxxxxxx> changed:

           What    |Removed                     |Added
                 CC|                            |doug.schaefer@xxxxxxxxxxxxx

--- Comment #6 from Doug Schaefer <doug.schaefer@xxxxxxxxxxxxx>  2008-09-11 12:06:13 -0400 ---
I'd like to point out that if LGPL was an issue, you'd see no commercial
software for Linux. The GNU libc is LGPL and every piece of software that runs
on Linux depends on it. GTK is LGPL, the list goes on. Every Eclipse vendor
that ships on Linux already has dependencies on LGPL. I think the question
asked here, though, is what of those dependencies aren't as obvious as GTK,

The CDT has long had external dependencies on GPLed programs for its exemplary
tools integrations for build and debug. Our community understands it, and
actually expects it. And a number of commercial vendors, Wind River included,
ship complete product based on EPLed Eclipse bits, and GPLed tools bits on the
same media. At the end of the day, it makes a great product, and the
communities creating those bits benefit from contributions from the vendors
that do that.

I wanted to replicated the same on the Windows side in open source. But since I
can't ship *GPL bits from Eclipse, I do it from SourceForge. And that works
fine, but does make it hard to find.

So yes, while maintaining the sanctity of EPL for all things Eclipse is great
for certain Eclipse board members, it has damaged our ability to create
complete open source Eclipse-based solutions. I think it has hurt our growth,
but it is what it is.

Configure bugmail:
------- 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