Chris Nandor wrote:
>
>At 12:22 -0400 2000.09.11, Ben Tilly wrote:
> >> >2. Freely Available is too vague. Is it freely available if
> >> > I release my changes in a form with a copyright notice
> >> > saying (like Sun does) that you need to submit all of your
> >> > changes to my changes back to me? (Under the definition in
> >> > the AL, yes.)
> >>
> >>If you can asnwer that question, then how can you say it is too vague?
> >>
> >Because vagueness has led to being overly permissive.
>
>That does not answer my question. You say it is too vague, but then go on
>to assert what it means. It is not vague. "Freely Available" is very
>specifically defined. There is nothing vague about it.
I proposed, and Tom Christiansen for one agreed, that the
point of allowing modifications that are made freely
available is that they are then available for Larry to
consider adding to the standard version. I don't think that
the current language has captured that concept, and the
result is a bug.
Similarly when someone gives me a spec for a computer program
but was not able to say precisely enough what they meant, the
resulting program may be very precisely specified, but there
probably are bugs (from their point of view) due to things
not being specified precisely enough. (Well I try to notice
things like that and ask questions until they know what they
want, but still you get the point.)
> >Take a look at how Microsoft "released" the changes that they
> >made to Kerebos. Would releasing a changed version of Perl
> >under a BS license like that violate the understood spirit of
> >what the AL is supposed to protect? To my understanding it
> >would.
>
>"Freely Available" in the Artistic License is never once used to refer to
>the Package, but is only used to refer to modifications to the Package. So
>yes, that would violate the license, in letter and spirit.
>
Releasing a patch to Perl in the same way that their changed
spec was released would satisfy section 3a. Accompanying
the changed version with a self-extracting zip that comes
with a BS copyright notice could satisfy section 4b. Are we
going to be happy about this?
The license has now been satisfied in letter but the spirit
has been mutilated and damaged. The possibility of that is
a bug in the license.
>
[...]
> >If the consultant is an employee of a consulting firm I do
> >not know whether that argument would fly.
>
>Yes, it would. It is a work for hire. The consulting firm itself would
>not have any rights to the work, only the organization hiring the
>consuntalts would.
>
Likely, but I would want to check with a lawyer. (Which
you are not.)
>
[...]
> >If you distribute two versions together, one of which is the
> >standard, you have indeed done "...at least ONE of the
> >following..." and therefore your distribution is legal.
>
>Not if they are released in the same "distribution." That is, they must be
>discrete distributions, or else it is not the Standard Version anymore.
>
*sigh*
I may distribute a Standard Version under 4a. So I do.
I may aggregate distributed software under 5. So I will.
I aggregate a modified version. Under 4a I am allowed to
distribute this because I am going to distribute a Standard
Version. (Nowhere does it say that the Standard Version
used to satisfy section 4a must be the version that you are
actually shipping under the permission in section 4!)
I am now shipping two versions of the software. Guess what
I am going to make my default install?
>
> >Of course not. But if your distribution INCLUDES the Standard
> >Version then by my reading the distribution is legal.
>
>As long as they are discrete entities, yes. I don't understand the problem
>there. But that does not include your scenario, where you think you are
>installing perl, but are installing something else. That simply is not
>allowed by the language of the license, by the definitions of Standard
>Version and Package.
>
The license talks about distribution, not installation.
>
> >"distribute a Standard Version". You are doing that.
>
>No, because in this case the Package HAS been modified, through addition.
>That's the point.
>
Under section 5 that is explicitly allowed. But you are
not allowed to advertise the package as your own. (Even
better! You can argue that you were not allowed to
clarify the changes made since you could not figure out
how to do that without potentially running afoul of
claiming it as your own!)
>
> >If it went to court I would not want to bet on your interpretation
> >winning over mine.
>
>Mine follows the actual words of the license, though. So I wouldn't be
>worried.
>
I disagree.
[...]
> >>What abuse of 3a? If you distribute under section 3, you must make
> >>prominent what modifications you've made. How can that be abused?
> >>
> >See Sun's Community Source License. By reading the changes
> >you are bound by a nasty license giving them rights to
> >demand all sorts of crap from you. Should distribution of
> >machine readible modifications with such a license attached to
> >decoding and reading them (which could, incidentally, make you
> >ineligible to contribute back to Perl) be acceptable?
>
>Of course. If you want copyleft, you know where to find it ...
>
If you want a BSD license, you know where to find it...
The idea of the AL is to provide the bare minimum in
the way of rules needed for Larry to be able to retain
artistic control. The current license does not
succeed in that idea.
As far as I am concerned, the moment that Larry or
someone who knows Larry's mood indicates that he
doesn't mind giving up artistic control the idea of a
BSD license will be on the table for Perl. But when
faced with the issue before he tried to write a new
license rather than use a BSD one. Barring further
notice, I take that as a sign that he *does* want to
retain artistic control. As long as he wants that, a
BSD license (which he could have chosen before but
rejected) is not a good fit.
>
> >Does it
> >interfere with the original author's artistic control?
>
>Of course not. The author does not assert artistic control over
>third-party modifications released separately from any distribution of the
>Package, which is what 3a covers.
>
>
> >> >5) I think that 4b is too dangerous. Both Microsoft and Sun
> >> > have played licencing games where you can see but not touch.
> >> > Machine readable source that is combined with restrictive
> >> > licensing does not meet the intent. The purpose of this
> >> > section is to allow ports. (eg Macperl.) I think this
> >> > should have added that it must be distributed on the same
> >> > licensing terms as the original.
> >>
> >>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. I am not sure what your point
>is,
> >>maybe I am missing it.
> >>
> >If I modify Perl I am now a copyright holder on my modifications
> >and I can distribute the alternate version with a license of my
> >choosing on my bits.
>
>The entire Package is still subject to the original license. You cannot
>change that.
>
No?
I can put my modifications under Sun's Community Source
License, and now I can meet my modification obligations under
item 3a, and my distribution arrangements under 4b.
As long as I meet my obligations under the AL there is no
requirement that I use the AL license.
If this seems strange to you, may I remind you that there
are licenses (eg the BSD) which have as their main point
that you should be able to ship modified versions under
practically any license you want.
>
> >All software comes with an implicit warranty that must be
> >explicitly disclaimed. Which is why virtually all software
> >comes with an explicit disclaimer.
>
>But you are not allowed to, legally, use the software if you don't agree to
>the warranty. So if you use it, you agree to the license, and you have a
>warranty. If you don't use it, the lack of warranty is irrelevant. Anyone
>who claimed in court that they refused the license and were suing because
>of the implied warranty which was never disclaimed would open himself up to
>immediate countersuit on illegal use of the software. It just isn't a
>problem.
>
Please quote that chapter and verse.
Under copyright law if I own a copy of the software I can
use it. Look up fair use.
Most commercial licenses get around this by not letting you
own your copy (instead it is leased). But the Artistic
license doesn't say you cannot own it, so you can own your
copy of Perl. That copy is yours.
In another post you ask why lawyers need to be involved.
Well it is because of things like this. Your not knowing
what fair use is leads to your assuming that someone has
to agree to terms when they don't.
Incidentally this is why the BSD license has no need to
expressly allow people to run it, and why the GPL is able
to leave running the software outside of its scope yet
still assert that running it is not restricted.
>
> >>At 10:52 -0400 2000.09.11, Ben Tilly wrote in "Can we ignore
>licensing?":
[...]
> >Sorry, section 5. Which says you cannot charge for the package.
> >And cannot charge an "unreasonable fee".
>
>Do you mean selling perl, by itself, on a CD? I thought you meant perl
>with other things on a CD, which is a different issue. Well, if someone is
>stupid enough to buy it, then that's their problem. I can kinda see your
>point, though I am not sure of your interpretation of the copyright law,
>but it is irrelevant, since with the advent of the Internet, anyone who
>pays an exorbitant amount for a CD with just perl on it deserves what he
>gets.
>
In fact I think that item could be dropped entirely. If
someone can figure out how to charge for what is available
for free, the more power to them.
As for my interpretation, do a search for "doctrine of first
sale".
(On a tangent. Anyone who does not know what "fair use" and
"doctrine of first sale" are has no business drawing up a
copyright statement.)
>
[...]
> >Copyright Holder is well-defined under law, and Perl may not
> >arbitrarily redefine it.
>
>Yes, it can. It can define anything in any way it wants to, as long as it
>is up front about it. Think macros. Whenever you see Copyright Holder in
>the AL, it means "whoever is named in the copyright or copyrights for the
>collection of files distributed by the Copyright Holder, and derivatives of
>that collection of files created through textual modification." Hm, I
>guess that is kinda recursive, but it still works. :-) There is no legal
>problem with the AL defining the term. It would be perfectly legal for me
>to have "Legal Document" defined at the top of my license as "any document
>written on legal size paper." As lon as I define it up front, it is OK.
>
Believe whatever you want. It won't hold up.
In particular sections 3d and 4d are effectively meaningless.
You may need to make alternate arrangements to modify and
distribute under other terms. But that doesn't mean that
Larry has the power to make them.
In fact he clearly does not. And will not unless the AL has
goodies added allowing him to.
>
> >In addition Author says:
> >
> > Larry Wall <[EMAIL PROTECTED]>, with the help of oodles of
> > other folks.
> >
> >Under copyright law all of those oodles of other folks have
> >copyrights on the code and Larry cannot legally speak for
> >them.
>
>The Artistic License deals with the Package as a whole, not to its
>individual pieces, which may in some cases have separate licensing terms.
>If you are going to contact the Copyright Holder under the provisions of
>sections 3d and 4d, it would only be in reference to the Package as a
>whole, for which the stated Copyright Holder has complete authority to
>rule. If you don't like it, you should not allow the Copyright Holder to
>include your code in their distribution. There is an implicit agreement
>there.
You may believe that there is an implicit agreement there
but I would like to see the judge who would agree with
you on that one.
Regards,
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.
