Re: subsets of licenses and copyright holders (was Re: I think the AL needs a rewrite)
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.
Re: subsets of licenses and copyright holders (was Re: I think the AL needs a rewrite)
> Bradley M . Kuhn <[EMAIL PROTECTED]> writes: > >I don't think this is completely out the question, either. I was actually > >planning on writing an RFC that proposes that all contributions to the core > >be copyright assigned to Larry. Nick Ing-Simmons wrote: > Well if that becomes a requirement I will have to stop contributing from > work at least, as I have not the mental energy required to extract such a > thing from the corporate entity. That is a problem, indeed. It's a hard issue, and not easily solved. We, as developers (I think) really *want* to give Larry full control over Perl, even with our code. Yet legally, that's darn hard to do with copyright assignment. *Sigh* -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
Re: subsets of licenses and copyright holders (was Re: I think the AL needs a rewrite)
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. > 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. 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. > > >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. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
subsets of licenses and copyright holders (was Re: I think the AL needs a rewrite)
Bradley M . Kuhn <[EMAIL PROTECTED]> writes: > >I don't think this is completely out the question, either. I was actually >planning on writing an RFC that proposes that all contributions to the core >be copyright assigned to Larry. Well if that becomes a requirement I will have to stop contributing from work at least, as I have not the mental energy required to extract such a thing from the corporate entity. I would happily sign such a thing personally, but who knows what my contract with TI actually _is_ - I know I don't - so such a thing may not be binding. -- Nick Ing-Simmons <[EMAIL PROTECTED]> Via, but not speaking for: Texas Instruments Ltd.
Re: subsets of licenses and copyright holders (was Re: I think the AL needs a rewrite)
Bradley M. Kuhn wrote: > >Russ Allbery wrote: > > Chris Nandor <[EMAIL PROTECTED]> writes: > > > > > The Package must ALWAYS be distributed under the same licensing terms >as > > > the original. Unless it is public domain or you are the copyright > > > holder, you cannot change the licensing terms. > > > > Not true, as far as I know. I believe that in general, you can >distribute > > under any complying *subset* of the licensing terms. > >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. 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. [...] > > It's quite possible that a major contributor to Perl could come along > > later, disagree with something Larry gave someone permission to do, and > > insist that they stop or remove their contributions to Perl from the >code > > that they're using. In fact there have been changes to the AL over the years which could cause exactly this kind of disagreement. Hopefully it will not, but... >I don't think this is completely out the question, either. I was actually >planning on writing an RFC that proposes that all contributions to the core >be copyright assigned to Larry. I agree that something needs to be done, but I have an alternate proposal which I think could give Larry a license with this flexibility without facing the paperwork of actually assigning copyrights etc. Given the nature of the Perl community and key developers, I think that reducing legal paperwork to a bare minimum is a significant consideration. The legal issues should be cleanly taken care of, but without evident fuss. >I figured that would be a controversial proposal, but it does avert the >problems that Russ brings up. It would only become controversial once people realize how much work it is. :-) >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, the overall effect should be the same. Additionally if it works, IMO it would provide a cleaner template for other projects that want to use an AL arrangement. 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.
subsets of licenses and copyright holders (was Re: I think the AL needs a rewrite)
Russ Allbery wrote: > Chris Nandor <[EMAIL PROTECTED]> writes: > > > The Package must ALWAYS be distributed under the same licensing terms as > > the original. Unless it is public domain or you are the copyright > > holder, you cannot change the licensing terms. > > Not true, as far as I know. I believe that in general, you can distribute > under any complying *subset* of the licensing terms. I believe that is correct as well. > > No, Larry is the Copyright Holder: > > Like it or not, Larry hasn't required copyright assignments and therefore > no longer holds full legal title to all of Perl. This will, in any sane > universe, never actually cause problems, but it does mean that this idea > of getting a private agreement with the copyright holder is nebulous at > best. I agree with this as well. > It's quite possible that a major contributor to Perl could come along > later, disagree with something Larry gave someone permission to do, and > insist that they stop or remove their contributions to Perl from the code > that they're using. I don't think this is completely out the question, either. I was actually planning on writing an RFC that proposes that all contributions to the core be copyright assigned to Larry. I figured that would be a controversial proposal, but it does avert the problems that Russ brings up. 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. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
