Gwyn Evans wrote:
Hmm, now after the obligatory IANAL, I think we need to be careful not
to go overboard here. There's the
official word here (http://www.gnu.org/licenses/l
<http://www.gnu.org/licenses/lgpl-java.html> gpl-java.html
<http://www.gnu.org/licenses/lgpl-java.html>), which says
"If you distribute a Java application that imports LGPL libraries,
it's easy to comply with the LGPL. Your application's license needs to
allow users to modify the library, and reverse engineer your code to
debug these modifications. This doesn't mean you need to provide source
code or any details about the internals of your application. Of course,
some changes the users may make to the library may break the interface,
rendering the library unable to work with your application. You don't
need to worry about that -- people who modify the library are
responsible for making it work.
When you distribute the library with your application (or on its
own), you need to include source code for the library. But if your
application instead requires users to obtain the library on their own,
you don't need to provide source code for the library.
The only difference between Java and C from the LGPL's perspective
is that Java is an object-oriented language, supporting inheritence. The
LGPL contains no special provisions for inheritance, because none are
needed. Inheritance creates derivative works in the same way as
traditional linking, and the LGPL permits this type of derivative work
in the same way as it permits ordinary function calls. "
Now the problem is (IMO) that there's been so much hot-air about the
LGPL that there is a fear of it or anything using it, so we might need
to take account of that, but not to the extent of handicapping ourselves
I agree with you on this point. Regardless if it is correct or incorrect
to not trust LGPL (for commercial purposes), I think we need to take into
account a lot of companies don't trust LGPL.
So, while I don't want to handicap ourselves, I certainly don't want to
handicap our users.
- Do all these users/organizations that avoid anything that has LGPL
somewhere in it really avoid Sun's JDK/JREs, for instance, as that has
some LGPL code in the linux build, at a minimum?
As I already have said in my response to John, there is a big difference
in only *using* LGPL (linked) code or actually derive from it.
Now, if you were going to link to the embedded LGPL code inside the JDK
things would become different.
So, I'd say that if we can avoid it in the core/extensions without too
much work, then OK, but not to go overboard...
Agreed.
But I want to express that embedding code based on a "foreign" license like
LGPL (as Wicket is ASL 2.0) should be done with care and understanding of
the possible consequences for the team itself (like providing a copy of the
LGPL license with the Wicket extensions) *and* our users.
Ate
/Gwyn
On 02/09/05, Ate Douma <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
> Well, I'm not a fan of licensing stuff either and INAL etc.
> But, I think it *is* of utmost importance, especially for framework
projects like Wicket.
>
> I would advise all the team members to read and follow the recent
(this week) discussion
> started on the ServerSide about this exact subject:
> http://www.theserverside.com/news/thread.tss?thread_id=36156
>
> This thread is already massive and contains besides very interesting
and valuable opinions
> also a lot of rubbish as usually.
> As I said, INAL, but the one thing that's very clear to me from that
discussion is that
> choosing the appropriate license *and* complying to it is not to be
taken lightly and can
> be tricky to say the least.
> Using LGPL licensed code especially is very dangerous in my book,
because everyone seems
> to have a different interpretation of it.
> Maybe the LGPL is crystal clear in legal terms in the end, but as
long as so many people
> disagree about what it really means, I don't trust it...
>
> Most notably in the discussion on the ServerSide is the unexpected
trick Rickard Öberg is
> now playing on JBoss by declaring all his original work within the
JBoss codebase (which is
> a massive amount) to be GPL from now on:
> http://www.theserverside.com/news/thread.tss?thread_id=36156#182919
>
> Checkout section 3) of the LGPL for a clarification.
> This might end up as being nonsense and of no consequence, and maybe not.
> I really don't know but I love to find out how this will work out.
>
> Anyways, for Wicket, I didn't know yet it already depends (and
contains) LGPL code.
> Turns out the DatePicker embeds and uses the calendar javascript
library from
> http://dynarch.com/mishoo/calendar.epl.
>
> First of all, as result of that, I think we need to distribute the
LGPL license with the
> Wicket extension library as required by section 1) of the license.
> Not complying with that is a violation of the LGPL.
>
> Furthermore, (and this one is very important to me as Apache
committer) this also means usage
> of the Wicket extensions is no longer possible for Apache projects as
the ASF doesn't allow any
> LGPL binding. While this is a restriction only from the ASF itself
and not purely based on
> the ASL 2.0 license of Wicket (it *is* allowed to bind to LGPL if you
want), many companies
> won't allow using the Wicket extensions anymore because they don't
trust LGPL either.
>
> I've worked myself on a commercial project which didn't allow any
LGPL based or linked software
> because they didn't trust that license and couldn't be sure about the
consequences.
> Reading the discussion on theServerSide again reinforced that I have
to agree on that assessment.
>
> So, I think I need to make my position clear on this matter.
> Binding Wicket extensions to LGPL (as it already does) makes it
useless to me and many others.
> And binding Wicket core to LGPL would make the whole framework
useless to me and many others.
>
> I do think it is important to be very careful about all this. Some
choices can end up to have
> irreversible consequences and in my view seriously endanger the
acceptance of Wicket...
>
> Eelco Hillenius wrote:
> > Yeah, I don't know. I allways hated the licencing stuff. Wish there
> > were just two licences. However, we allready depend on some LGPL
> > licences and I have seen a lot of other Apache 2 style projects do
> > that too. I can't imagine this becomming an actual problem. But if
> > someone would be so kind to explain the details/ in-outs that would be
> > nice.
> >
> > It would really suck if when you choose for Apache 2, you couldn't use
> > LPGL at all, and if you choose LGPL, you couldn't use Apache 2 at all.
> > I'm pretty sure I speak for 95% percent of the programmers if I say
> > I'm really not that into the details; as a customer I want to know
> > whether I can ship it with commercial projects, and - maybe - whether
> > I can ajust the source and ship it.
> >
> >
> > Eelco
> >
> >
> > On 9/2/05, Igor Vaynberg <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
> >
> >>If the license is such a big issue why not just keep this project
as contrib
> >>instead of extension, that way the license doesn't really matter.
> >>-Igor
> >>
> >>
> >>
> >>>-----Original Message-----
> >>>From: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> >>>[mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>] On Behalf Of
> >>>Ate Douma
> >>>Sent: Thursday, September 01, 2005 12:38 PM
> >>>To: [email protected]
<mailto:[email protected]>
> >>>Subject: Re: [Wicket-user] Integrating FCKeditor
> >>>
> >>>Nick Heudecker wrote:
> >>>
> >>>>I'm looking to integrate a JavaScript WYSIWYG editor into Wicket,
> >>>>similar to DatePicker. FCKeditor is LGPL, so I don't think
> >>>
> >>>there's a
> >>>
> >>>>licensing problem. Any thoughts or advice before I start
> >>>
> >>>doing this?
> >>>I have no opinion (yet) on the technical merits of FCKeditor
> >>>or any other editor.
> >>>But, I'm not in favor of introducing LGPL as Wicket is under
> >>>the Apache 2.0 license.
> >>>LGPL really cannot be seen as comparable nor compatible to
> >>>the Apache 2.0 license and in my opinion introducing it now
> >>>might harm acceptability of Wicket in the end.
> >>>
> >>>There are other options with more compatible licenses,
> >>>although I don't know if they match FCKeditor on features and
> >>>technical quality.
> >>>
> >>>For one, there is kupu which has a BSD-style license.
> >>>I haven't used or worked with it myself, but I know others
> >>>have embedded it very successfully in several CMS engines,
> >>>like Zope, Apache Lenya and recently Apache Graffito which
> >>>uses it for editing html documents within a JSR-168 compliant
portlet.
> >>>
> >>>If you are interested: http://kupu.oscom.org/ Online docs are
> >>>available from their subversion repository:
> >>> http://codespeak.net/svn/kupu/trunk/kupu/doc/
> >>>
> >>>Regards,
> >>>
> >>>Ate
> >>>
> >>>
> >>>
> >>>-------------------------------------------------------
> >>>SF.Net email is Sponsored by the Better Software Conference &
> >>>EXPO September 19-22, 2005 * San Francisco, CA * Development
> >>>Lifecycle Practices Agile & Plan-Driven Development *
> >>>Managing Projects & Teams * Testing & QA Security * Process
> >>>Improvement & Measurement * http://www.sqe.com/bsce5sf
> >>>_______________________________________________
> >>>Wicket-user mailing list
> >>>[email protected]
<mailto:[email protected]>
> >>>https://lists.sourceforge.net/lists/listinfo/wicket-user
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>SF.Net email is Sponsored by the Better Software Conference & EXPO
> >>September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
> >>Agile & Plan-Driven Development * Managing Projects & Teams *
Testing & QA
> >>Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf <http://www.sqe.com/bsce5sf>
> >>_______________________________________________
> >>Wicket-user mailing list
> >>[email protected]
<mailto:[email protected]>
> >> https://lists.sourceforge.net/lists/listinfo/wicket-user
> >>
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
> > Agile & Plan-Driven Development * Managing Projects & Teams *
Testing & QA
> > Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
> > _______________________________________________
> > Wicket-user mailing list
> > [email protected]
<mailto:[email protected]>
> > https://lists.sourceforge.net/lists/listinfo/wicket-user
<https://lists.sourceforge.net/lists/listinfo/wicket-user>
> >
> >
> >
> >
>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Wicket-user mailing list
> [email protected]
<mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
