> I may have inadvertently conflated two independent issues in my initial e-
> mail. The user who contacted me wasn't (to my knowledge) interested in
> LGPLv3 b/c of the (suggested) "increased compatibility" with GPLv3 -- that
> "increased compatibility" was what I was able to infer/deduce from reading
> overviews of "why would anyone consider using LGPLv3" sort of info that I
> found in my cursory investigation into the matter.
OK :)
> The user's specific issue seems to be in re: the stated lack of clarity in
> re: the scope of what's required to be 'reverse-engineerable' under
> LGPLv2.1. I'm near-certain from their concerns that their own
> project/product/code is closed-source/commercial. Sorry for the
confusion!
Then it's simple:
- linking to an LGPL library in binary form will not force you to (L)GPL
your own code
- modifying code in an LGPL library (e.g. they change NHibernate code) will
obligate them, when asked, to provide _these modifications_. I.o.w. not
their own code linking to NHibernate
- embedding the full LGPL sourcecode in a bigger project so that the bigger
project and the LGPL sourcecode merge has the same effect as altering the
LGPL library: you have to provide your own code under the LGPL license.
The key is 'derivate work'. Altering a dialect class and change 2
lines and enclose that dialect class in your own 1000 classes big project
doesn't make that 1000 classes big project a derivative work and doesn't
force it to inherit the license.
So if they binary link to NHibernate, or modify code in it, you've
to provide the changes made.
LGPLv3 doesn't change that at all. GPL3 (and thus LGPL3) adds:
- a more strict set of rules what 'linking' implies. Everyone except the
people inside FSF understand how stupid this rule is but instead of
realizing that for example a dynamically loaded dll which interface is
dynamically discovered at runtime does NOT mean 'linking', they continue on
that path and add a bigger set of rules to formulate what 'linking' means.
(if I recall correctly, they now also include a clause about webservices...
:/)
- a better formulated set of clauses about patent infrigment
- a set of clauses considering DRM
> That said, I've never had much clarity myself in re: comprehending what's
> really involved in changing any OSS project's license (who as the "right"
to
> do so, what is the practical effect of doing so, what happens to the code
> that "existed" under the prior license, etc.). AFAICT, there isn't really
> much clarity available around such issues (which may be why most OSS
> projects just "live with" the license they initially select "leave well
> enough alone" <g>).
Despite what licenses say, what's important is what the copyright
law says in the country you're in. Most western countries (US, CA, EU) have
more or less compatible copyright laws on THIS particular aspect: when you
create something, you own it (unless you copied it of course;)). When you
own it, you and you alone are entitled to decide:
1) who uses it
2) under which conditions
OSS licenses are about point 2) and only in the aspect of
distribution: they're not about who owns the code, as that's not
transferable by a license: you can only transferable copyright by a written
act.
So if person P writes a piece of code C and licenses that under
license L, this means:
- P owns C and can decide how to license it, and re-license it
- L decides who can use it and under which conditions.
In OSS licenses, it's about distribution, so everyone can use the
OSS licensed work, and if you distribute it again, e.g. with your own code,
you have to obey the clauses in the license of the OSS licensed work. In the
case of GPL, this means:
- if you use a GPL-ed piece of code yourself: nothing further, use it
- if you write a piece of code which uses the GPL-ed piece of code and use
it only yourself, no problem, use it
- if you write a piece of code which uses the GPL-ed piece of code and you
distribute your code, you have to obey the license of the GPL-ed piece of
code, as you can only USE it (point 1) under the condition that if you
distribute YOUR code, you have to open it in source code form (point 2)
That's the rule of thumb. The conditions apply if your work is a
'derivative work' of the GPL-ed piece of code. So using a GPL-ed ASP.NET
control in your website with 15000 pages isn't making that website a
derivate work, however this is fuzzy: every judge can decide differently.
This is also the reason why some companies find the GPL 'viral' and 'wrong'.
Does using a LGPL-ed piece of code protect you from GPL influences?
That's unclear. An example of that is the MySQL ADO.NET provider. It's
licensed under GPL3. If I use NHibernate in a commercial application,
targeting MySQL, using the GPL-ed MySQL ado.net provider and distribute that
application, what's going to happen? Is my application a derivative work of
the MySQL application? A sane person would say: "no". Well, ask MySQL, and
they'll tell you differently. Who's right? That's unclear, and I think also
the reason why you got the question, however what's odd is that they asked
about LGPL-3, which IMHO doesn't protect you from nonsense like the example
I gave above.
Sadly, asking a lawyer isn't really going to help, as lawyers too
have different opinions about this.
FB
>
> Steve Bohlen
> [email protected]
> http://blog.unhandled-exceptions.com
> http://twitter.com/sbohlen
>
>
>
> On Tue, Sep 21, 2010 at 10:24 AM, Frans Bouma <[email protected]> wrote:
>
>
> To my knowledge you can't re-license code you don't own the
copyright
> of.
> Not sure if this is a problem, but I could imagine that code which
is
> ported
> from Java has to inherit the same license.
>
> Also, IMHO GPL 3 protects better against patent trolls (and as you
> might
> know, RH settled with Firestar over a lawsuit filed by Firestar over
> a
> patent violation by Hibernate) but it's a very complicated license,
> and the
> language in it is so obscure that everyone can distillate her/his
own
> opinion from it how it should be applied.
>
> Be aware that re-licensing code will affect everyone using it.
>
> What I don't understand is that they're concerned about what to
> provide for
> reverse engineering but at the same time they're developing a GPL v3
> application? Isn't that odd, considering that a GPL-ed application
> already
> implies you should provide all code? I.o.w.: aren't they concerned
> about
> something else, i.e.: the dual license they likely want to apply,
> namely a
> commercial license as well?
>
> FB
>
>
> > I'm sure licensing choice for NH is a pretty uninteresting topic
> <g>, but
> > I've been approached by a potential NH adopter asking if we would
> ever
> > consider moving from LGPLv2.1 to LGPLv3 as part of the NH3 release
> cycle.
> >
> > As I understand it, the (general) motivator behind creating the
> LGPLv3 was
> > to provide an LGPL license version that is more compatible with
> GPLv3-
> > licensed code (e.g., if LGPLv2.1 code is linked into GPLv3 code,
> there are
> > apparently some potentially contradictory clauses between the
> LGPLv2.1 and
> > the GPLv3 that would make such a release legally conflicted).
> >
> > The user has pointed out that their legal department has expressed
> specific
> > concern re: the following text in section 6 of LGPLv2.1:
> >
> >
> >
> > "(...) you may also combine or link a 'work that uses the
> Library'
> > with the Library to produce a work containing portions of the
> Library, and
> > distribute that work under terms of your choice, provided that the
> terms
> > permit modification of the work for the customer's own use and
> reverse
> > engineering for debugging such modifications."
> >
> >
> > They have expressed some concern re: the potential ambiguity of
the
> scope
> of
> > what must be made available for reverse-engineering under this
> clause,
> > fearing that it might be interpreted as including their own
> (presumably
> > commercial) solution. They have also noted that this ambiguity
> appears to
> > have been acknowledged by the LGPL authors as the related phrase
> has been
> > modified in LGPLv3 to read:
> >
> >
> >
> > "You may convey a Combined Work under terms of your choice
> that,
> > taken together, effectively do not restrict modification of the
> portions
> of
> > the Library contained in the Combined Work and reverse engineering
> for
> > debugging such modifications (...)".
> >
> >
> >
> > I am neither a lawyer nor do I desire to become one so I cannot
> really
> offer
> > an opinion re: whether one of these clauses is more or less clear
> than the
> > other in any meaningful way. But I am wondering if anyone can
> proffer a
> > compelling reason for us NOT to move to LGPLv3 as part of the NH3
> release
> so
> > that it can be more easily used in concert with GPLv3-based
> proejcts.
> >
> >
> > What are people's opinions on this?
> >
> > Steve Bohlen
> > [email protected]
> > http://blog.unhandled-exceptions.com
> > http://twitter.com/sbohlen
>
>
>
>
