Procedure for using an approved license

[Rod Dixon, J.D., LL.M.]

Mitchell, I think you are connecting, but disagreeing that the premise you
raise should result in the conclusion made.  Yes, courts disagree about the
meaning of derivative work in certain contexts, but the statute is clear in
other circumstances that the use of  "modification" is not. As I see it, the
question is whether the use of the term "modification" clarifies an issue or
makes matters worse.  It is irresponsible to ignore legal terms of art in
drafting a legal instrument, and hope that all is well.  The MPL is not the
only open source license that uses the term "modification" imprecisely.

I think "modification" is used in a less precise manner than derivative work
in some open source licenses and, therefore, the use of the term is not
helpful. (It is often used in a broader and narrower sense than derivative
work).  There is also the questionable premise that a software license may
lawfully extinguish the floor and ceiling of derivative works...i.e. under
copyright law some "modifications" need no permission from the copyright
holder because they are fair uses, other "modifications" need no permission
from the copyright holder because they are transformative and somewhere
between those two extremes you'll find derivative works.  To the extent that
a software license uses the term "modification" to tread on the shoulders of
transformative works or to control what is or may be viewed as fair uses,
the license increases the likelihood that its terms may be deemed
troublesome - - to say the least. As I mentioned in a prior message, the OSD
Model Code will recommend that open source licenses substitute the term
"modification" with "derivative work" when appropriate, and that drafters be
very circumspect concerning the use of the term "modification."

Rod

Rod Dixon
Visiting Assistant Professor of Law
Rutgers University Law School - Camden
rod at cyberspaces.org
http://www.cyberspaces.org/dixon/
My papers on the Social Science Research Network (SSRN) are available
through the following url: http://papers.ssrn.com/author=240132


> We're not connecting here.  My point is that
> "derivative work" as used in the copyright statute is
> an unclear term.  And that the definition of
> derivative work varies among jurisdictions.  And that
> the MPL does not, as Larry suggests, use a "derivative
> work" standard for precisely that reason.
>
> I have limited connectivey for the next few days, so
> may drop in and out of this discussion.
>
> Mitchell
> --- "Lawrence E. Rosen" <lrosen at rosenlaw.com> wrote:
> > > From: Rod Dixon [mailto:rod at cyberspaces.org]
> > > there is a lot being said here. To clarify one
> > point at a
> > > time, the use of "derivative work" should be in
> > the copyright
> > > law sense, not an unusual meaning gleamed from a
> > > license...whether it is the MPL or any other
> > license. In this
> > > respect, the issue is relatively simple; namely,
> > did the
> > > copyright holder grant the right to create the
> > work and did
> > > he or she grant the right to distribute the work.
> >
> > Thanks, Rod, for your clarification.  We attorneys
> > have a responsibility
> > to our community to be precise in our definitions,
> > at least with
> > reference to terms of art such as "derivative work."
> >
> > Mitchell is correct in suggesting that some
> > licensors may want the
> > reciprocity obligation (to publish source code) to
> > apply to more than --
> > or to less than -- derivative works.  The GPL
> > authors, for example, seem
> > to want to include works that link together in some
> > ways; they are
> > entitled to do so as long as they define their terms
> > clearly and so long
> > as their definitions are consistent with the
> > copyright law that governs
> > their license.  The MPL, by contrast, wants to limit
> > the reciprocity
> > obligation on a file-by-file basis, also a
> > legitimate objective for a
> > license as long as the term "file" is clearly
> > defined.
> >
> > In drafting the OSL, I tried to steer clear of
> > terminology that was
> > technology-specific and to use terms of art from
> > copyright law wherever
> > possible.  I did not want to clutter the concept of
> > derivative works
> > with terms such as "larger work" or "work based on
> > the work" or "file."
> > When I wanted a specific software concept, however,
> > such as "Source
> > Code" or "External Deployment," to inform the
> > application of the
> > copyright law to this license, I tried to define it
> > clearly.
> >
> > Perhaps Mitchell, in the next version of the MPL,
> > will be able to define
> > more clearly what she intends to encompass by the
> > "derivative work"
> > reciprocity provision in that license.  That will
> > help projects to
> > decide which license to adopt for their software.
> > Perhaps, too, we
> > should work together to define that term precisely
> > for our needs and use
> > an agreed definition in both the OSL and the MPL?
> >
> > As for the current version of the OSL, I thought it
> > best to let the
> > courts clear up the concept of derivative works in
> > the edge cases, since
> > they will anyway if someone litigates this in an
> > important case.  I have
> > written an article explaining my own views of how
> > that will turn out; it
> > will appear in my Linux Journal column in a few
> > months.
> >
> > /Larry
> >
> > --
> > license-discuss archive is at
> http://crynwr.com/cgi-bin/ezmlm-cgi?3
>
>
> =====
>
>
> __________________________________________________
> Do you Yahoo!?
> Y! Web Hosting - Let the expert host your web site
> http://webhosting.yahoo.com/
> --
> license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3