On 3/12/07, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> Henri Yandell wrote:
> >
> > The reasoning is wrong. After discussion with the FSF, the ASF were
> > happy that depending on LGPL jars did not invoke any form of
> > reciprocalness, so there was no license issue to stop us using LGPL
> > code and/or distributing it.
>
> What reasoning was that?
The email that Andrus pointed to. ie) The premise is right, that we
don't ship LGPL, but the reasoning is wrong, that it's because we
can't relicense it. We're happy to ship code that we can't relicense
for many licenses (as you say below).
> The ASF distributes ASF licensed code, or code combined with code who's
> terms are less restrictive than the ASF license.
>
> In the few places that is simply not possible, or where several possible
> options exist for the user, some of our configure programs allow our code
> to link against more restrictively licensed code. But such code never
> occurs in our tarballs. If is does, -that- is an issue.
>
> > Policy comes into effect in terms of what we think our users expect.
> > Do they expect to download something from us and have a GPL jar
> > sitting in there? Definitely not. I imagine there would be an uproar
> > if someone discovered that their assumption that something was Apache
> > licensed was that hugely incorrect. Take a look at the HTTP Server
> > license btw. Our flagship product is not licensed under AL 2.0, but is
> > a combination of licenses, so this is an iceberg that people don't
> > usually see the depths of.
>
> And which code in httpd (/apr) is more restrictive than the ASL?
That would be a legal question and I am not qualified to answer it ;)
It's all cool - I was pointing out that the stuff we release is not AL
2.0 but AL 2.0 plus other licenses that we don't expect the customer
to be concerned about the details of. Thus I follow with:
> > We know that people aren't going to throw a hissy fit if they discover
> > that the product they downloaded from us also contains MIT, BSD, ASL
> > 1.1 or other AL 2.0 licences. Least it's a fair bet. What's tricky is
> > to decide what they'll think when they discover
>
> ... that the code's effective license is more restrictive than the ASL.
> There's no other yardstick.
As we get closer to the grey lines then I presume it gets more legally
opinionated. Cliff's 3rd party draft is in effect saying that CPL,
CDDL, MPL, and various others are not more restrictive (or not
substantially more restrictive?) than the AL 2.0 when in their binary
form. Some customers may disagree with that.
> > So the reason is not because of relicensing but because of what a user
> > would expect of us. Relicensing is a copyright issue afaik - if you
> > have the copyright you can relicense, if you don't you can't; in our
> > case we have a software grant that defines a superclass of licence
> > within which we can relicense.
>
> No - you entirely confused me, and I thought I finally got a handle on
> this.
Sorry, I tangented. That was off-topic for Andrus' question.
1) Linked to email saying it was relicensing was wrong.
2) Relicensing btw is a copyright issue, you can do it if you have it
(or permission from the copyright holder)
3) Btw, our software grant gives us permission to relicense within the
constraints it defines.
4) My lips are moving as I think about this - you've got as good a
handle as I have :)
> If the author, Andrus, wants to license their library under the
> user's choice of ASL or LGPL they may do so. The user who chooses the
> ASL terms is subject to purely the ASL, the user who choose the LGPL
> terms is bound solely to those terms.
Yep. Sorry, I wasn't trying to say anything about that in the above.
Dual-licenses are going to be a pain in the arse as things get more
transitive I think - you can't point at file X and say 'It's licensed
under Y'. Instead you have to look for a license file that goes with
file X. I don't know what happens if there is no license file - does
one have to distrust it as unknown or does one get to pick and choose.
Good luck Maven repository - files having different licenses based on
the path you took to get to that file is going to be lots of fun.
> As a practical matter, they could add or remove terms to have an almost-
> ASL, while they can only grant exceptions, and not impose new terms and
> still be LGPL.
If someone is dead-set on dual-licensing; MPL/GPL/LGPL would seem the
way to go simply because Mozilla are doing that. We're happy to use it
under the MPL license, others like the GPL license and I guess the
LGPL license is there for prettiness :)
> One thing Hen was dead on about - if YOU have the copyright. You must
> be the copyright owner to grant a new license that the copyright holder
> didn't initially grant.
Dumb question - is there any difference between copyright owner and
holder? Just making sure.
Hen
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
|