Bradley M. Kuhn wrote:
>
>Ben Tilly wrote:
>
> > >I believe that is correct as well.
> >
> > Is subset really the word? Should I choose to accept and redistribute
> > using the AL, I should be able to distribute under any terms I choose
>that
> > are consistent with the distribution requirements of the AL. This may
> > include adding licensing terms that are not to be found in the AL.
>
>You can never add additional licensing terms, unless the license
>specifically grants you the right to do so.
I think we are differing on semantics.
> > An example of why someone would want to do this would be if (like
>oraperl
> > did) they are distributing a version of Perl that is modified and linked
> > to other code with other restrictions. Allowing this is part of the
> > intent of the AL, and so this is an important example to keep in mind.
>
>In that case, they are not changing the terms of Perl. They are choosing
>the "AL" path of the disjunctive license for the perl code (i.e., the code
>on which they hold no copyright), and choosing their own license for the
>code they wrote.
And so the whole is distributed under more restrictive terms.
In fact I don't think that they are required to have added
their own code. Certainly the wordings I am playing with /
moving to state no such requirement.
>Since the AL allows:
>
> * distribution of the perl code without source
>
> * derived works of the perl code to be combined with works under
> some proprietary software licenses (under certain conditions).
>
>They are able to do what they do. They haven't changed the terms of the
>AL,
>they are using the terms of the AL to do something it permits.
And that is the semantic difference. The package is still
under the same old AL, but the recipient of the package may
be bound by all sorts of terms and conditions not to be
seen in the AL. (Because of the second license in effect.)
> > >It seems to me that we should ask all perl developers to trust Larry
> > >completely in matters of licensing, and thus copyright assign to him so
>he
> > >can make changes as necessary.
>
> > My proposal would leave developers with more of a say and Larry
> > with less paperwork. Since I don't think that Larry would want
> > to make any more controversial licensing changes than he has to,
>
>I still haven't seen your proposal on this issue exactly spelled out, but I
>may have missed it. It sounds like an important proposal, and probably
>deserves its own RFC, as these issues are seperate from actual license
>changes.
This proposal depends on having an AL which makes it workable.
If I can get that to a state where I don't feel the need to
tear it apart when I look at it, and a lawyer likes it, then
it will be trivial.
All that would be required is that the copyright statement that
today includes the dual licensing would say that Larry Wall
reserves the right for him or his designated maintainer to, if
there is no disagreement from any copyright holder after x days
of public consultation, re-release Perl under different licensing
terms.
Since contributing changes back to Perl under the (rewritten) AL
requires your having agreed to a contract where those changes do
not conflict with existing licenses and restrictions, and do not
impose "significant" new ones (still working on that wording),
you must have also agreed to this relicensing arrangement.
In practice this means that copyright holders still retain full
rights to reject unacceptable changes to the licensing of their
code, but Larry does not need to actually get every one to agree
to new terms.
Or at least that is my theory. I won't know whether it will fly
until I have an AL that supports it and a lawyer has looked at
that.
Cheers,
Ben
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
