RPSL pre-discussion

[Rob Lanphier]

Hi Larry,

Thanks for the thorough review and subsequent conversation, and sorry for
the delayed reply.  Your mail has really helped us think through all of
the implications of our license. You have a lot of good ideas that we are
planning to implement. Here's the point-by-point response to your review
comments. We are working on the version 1.0 of this license, incorporating
this response, and hope to release it soon.

Assigning letters to bullet points to make them easier to reference.

On Mon, 5 Aug 2002, Lawrence E. Rosen wrote:
 > Here are some comments on the RPSL:
 >
 > [AA] Your license would be more useful generally if you changed the first
 > sentence ["This License applies to any program or other work which
 > RealNetworks, Inc. ("RealNetworks") makes publicly available and which
 > contains a notice placed by RealNetworks identifying..."] to read "This
 > License applies to any program or other work which contains a notice
 > identifying...."  Why shouldn't other companies be allowed to use the
 > RPSL?  Then, define "Licensor" and let the license be general purpose.

We can more generically refer to the Licensor throughout this license.
We'll implement this change in version 1.0.

 > [BB] Section 1.1 is rather limiting.  I'm particularly saddened [:-)] by
 > the exclusion from the list of the Jabber Open Source License, which I
 > wrote to be clearer and more understandable than the MPL 1.1.  Why did
 > you exclude the Common Public License, the IBM Public License, and
 > several others?  Is there a characteristic of the approved licenses that
 > you're trying to identify?  Why would it not be up to the licensee to
 > ensure license compatibility?

Good point.  We're trying to ensure that compatible licenses have
reciprocity clauses. We're not sure what the best way of handling this is;
reciprocal licenses are tough to craft, so this clause would start looking
like a license in and of itself. We are planning to increase the number of
pre-approved compatible licensers and will post them to our Web site.

 > [CC.1] To make section 1.2 more general, 1.2(a) should refer to patent
 > grants  from the *Licensor*.

We're assuming this is because of point AA, correct? If so, we are working
toward making the license more generic.

 > [CC.2] It also seems the grant in (a)(i) is too narrow,
 > since you want to permit people to use those patent rights to create
 > derivative works.  Otherwise, the grant is largely useless in the open
 > source community.  Here's how I write that in the Open Software License:
 >
 >    Licensor hereby grants You a world-wide, royalty-free,
 >    non-exclusive, perpetual, non-sublicenseable license,
 >    under patent claims owned or controlled by the Licensor
 >    that are embodied in the Original Work as furnished by
 >    the Licensor ("Licensed Claims"), to make, use, sell
 >    and offer for sale the Original Work.  Licensor hereby
 >    grants You a world-wide, royalty-free, non-exclusive,
 >    perpetual, non-sublicenseable license under the
 >    Licensed Claims to make, use, sell and offer for
 >    sale Derivative Works.

Are you stating that this should be defined in section 1.2?  Section 1.2 is
a definition, not a grant of any sort.  Section (a)(i) is imply a
description of which patents we are licensing.

We're assuming that you are referring to the actual grant in section 2. We
tried to be careful in scoping out the patent grant in the clearest
possible manner. As you know, many open source licenses, including the GPL,
do not even include patent grants from the original licensor. The GPL only
includes a patent grant for modifications by licensees. We were simply
trying to be explicit about the patent grant.

We can only definitively grant a licensing on the technology we provide,
and looked at the APSL for guidance on this.  Nonetheless, we're very open
to ensuring the community has reasonable rights to use and innovate on this
technology, including the creation of derivative works.

 > [DD] Section 1.2(b) appears to grant patent rights from the licensee
 > ("You") even when he/she doesn't deploy his Modifications.  That's not
 > fair.    Perhaps I don't understand what you mean by "in the case where
 > You are the grantor of rights...."  It also suffers from the same
 > deficiencies as I noted in 1.2(a).

1.2(b) is simply a definition, there's no patent grant there.

 > [EE] In section 1.3, to be a Contributor, doesn't the person also have to
 > Deploy his contributions?  Simply because I modify a program for my own
 > personal use, I may not intend to give those modifications to you or
 > anyone else.

When we use "Contributor", we're referring to a third-party from whom we've
already received modifications, and we're describing what rights "You" get
from those Contributor(s).  It's probably not useful to read that
definition out of context.  Is there a particular use of "Contributor" that
is still confusing?

 > [FF] In section 1.6, I am troubled by the inclusion of the concepts of
 > "containing" and "combination" in the definition of Derivative Work.
 > These may make the definition so broad as to bring under its scope the
 > packaging of your program with other programs not meant to be covered by
 > this license.  The concept of "Derivative Work" is is one of the most
 > difficult to get across in any open source license; even the GPL fails
 > to make that clear.  I fear you haven't quite gotten it right either.

We agree that this is a hard thing to define.  We are wide open to wording
changes that achieve the reciprocal purpose of this language.

 > [GG] I very much like the definition of Externally Deploy in section 1.7.
 > It is succint and clear.  I'm going to try to incorporate that concept
 > into my licenses.  [I have since received some feedback that is critical
 > of restricting such deployment in an open source license.  Maybe we
 > should just watch the commentary in license-discuss and both of us try
 > to decide how far we can go on this.]

Great!  I've been watching the feedback on this.  I'm not sure if it's
possible to narrow the definition in a way that doesn't enable an ASP to be
a freeloader (not contributing changes to the community), but perhaps some
ideas will show up there. The main point is, public use of the code should
trigger reciprocity. Given that the code is free, this seems completely fair.

 > [HH] I'm trying to reconcile your definition of Modifications in section
 > 1.9 with the earlier definition of Derivative Work.  Do you mean those
 > to be two ways to define the same concept?

No, these are different concepts.  One can make Modifications to Covered
Code to create more Covered Code. One can combine Covered Code with other
code (either Covered Code or non-Covered Code) to create a Derivative
Work.  The rules under which non-Covered Code fall depend on how the
combination is accomplished.

 > [II] In section 1.10, once again, I note the reference to RealNetworks
 > rather than Licensor, which limits the general applicability of this
 > license.

I take it this relates back to AA. We're working on this.

 > [JJ] In section 1.12, you refer to forming "larger applications
including
 > Derivative Works."  What is a "larger application?"  Is it different
 > from a Derivative Work?  How does it fit within the definition in
 > section 1.6?

Yeah, that is a problem, and we're trying to clear that up.  I think we'll
just eliminate "larger application" and "larger work" from this document
entirely.

 > [KK] The last sentence of 1.13 is unclear.  Are you referring to "all
 > cases" of Runtime Linking?  And do you mean to say that one can't use a
 > combination of runtime linking and static linking?

You're right, this is confusing.  We should probably rephrase this to say
"In all cases, in order to be considered Runtime Linking, the accessing
software must access any Interfaces in the software application in question
solely during the execution of the program, as opposed to any form of
static linking of the accessing software to the to the software application
in question". This is necessarily a complex definition, and if there's an
easier (but sufficiently precise) way of doing this, we're all ears. The
whole intent of this language is to enable use of the code with other
applications that are licensed under other compatible licenses.

 > [LL] In the first sentence of 2, you imply that downloading or using
 > Covered Code is tantamount to acceptance of the License.  I'm aware of
 > no court that has ever made such a broad statement.  The issue of
 > license acceptance deserves a section of its own.  Here's how I
 > addressed it in the Open Software License:
 >
 >    Nothing else but this License (or another
 >    written agreement between Licensor and You)
 >    grants You permission to create Derivative
 >    Works based upon the Original Work, and any
 >    attempt to do so except under the terms of
 >    this License (or another written agreement
 >    between Licensor and You) is expressly
 >    prohibited by U.S. copyright law, the
 >    equivalent laws of other countries, and by
 >    international treaty.  Therefore, by
 >    exercising any of the rights granted to You
 >    in Section 1 herein, You indicate Your
 >    acceptance of this License and all of its
 >    terms and conditions.
 >
 > This is similar to what the GPL says.  I'm not sure that solves the
 > problem either, but at least it expresses what the court seemed to hold
 > in the Sun v. Microsoft case.

This gets to the heart of the click-wrap discussion also on this list.  In
general, we'll be making the software available via click-thru agreement.
We'll have to discuss this item more. Our paramount concern is ensuring
that all users are bound by the same terms.

 > [MM] In section 2, do you expect the license to be sublicenseable?  If so,
 > how will you deal with the privity issue?  If not, then you must make it
 > clear that all licensees obtain their license to the Original Code
 > (including both copyright and patent licenses) from the Licensor.
 > Hardly anyone wants their patents licenses to be sublicenseable.

We don't expect the license to be sublicenseable.  We'll try to clarify that.

 > [NN] The grant-back patent license in section 3 may be too broad.
 > [NN.1]For one
 > thing, as I noted earlier, there should be no grant-back license for
 > patent rights except for *deployed* modifications.  Merely making a
 > modification for personal use doesn't not require a grant-back.

We are looking at the scope of the patent grant-back.

 > [NN.2] Second,
 > this grant-back is worded as a sublicenseable patent license, which is
 > generally unacceptable to companies that want to retain privity with all
 > licensees to enforce their own patents.

Hmmm....we'll take a look at that.

 > [OO] Once again, in section 4, you subtly modify the definition of a
 > Derivative Work by using the word "combining" and then introducing the
 > new concept of "integrated product."  Then you use the phrase "larger
 > works" which is perhaps the same as "larger applications" from 1.12.
 > Mere "aggregation" doesn't do it, but "integration" seems to.  I'm no
 > longer sure just what you intend by the term Derivative Work!  This is a
 > complicated problem that would probably benefit from us talking directly
 > rather than me trying to write my thoughts out in email.

Agreed, using both "larger works" and "Derivative Works" is confusing.
We're going to chop "larger works" out of our vocabulary for future versions.

 > [PP] The last sentence of section 5 raises difficult problems with the GPL
 > and LGPL.  Take a look at section 7 of the GPL, in particular.  Rather
 > than reserve for yourself "sole discretion" to decide the scope of your
 > patent licenses, it would be best to define that scope up front.
 > Certainly you can grant a broader license in the future.

The scope that we *know* we can grant patent rights for is for the actual
code we provide. We're not prohibiting modifications, only informing that
our patent grant doesn't explicitly extend beyond the scope of the code we
provide.

 > [QQ] How is the licensee supposed to obtain a [sub]licensee's "agreement"
 > to the Additional Terms described in section 6?  What if he doesn't?
 > Why do you care?

This is for someone selling a warranty above and beyond what we offer.  We
want to make it clear that they are doing that themselves, and not doing it
on our behalf (thus, we don't want to get sucked into their business deal).

Same condition exists in the APSL.

 > [RR] Does the last sentence of section 7 mean that someone can't create a
 > derivative work and license it under a license that is merely
 > "compatible" with this license?  No derivative works licensed under the
 > GPL, for example?  Is this still compatible with section 4.2?

"Covered Code" is either code provided by RealNetworks, or Modifications to
RealNetworks' code.  In either case, these Modifications are strictly
covered under RPSL.  So, to answer your question, no one has the right to
relicense Covered Code under a different license. We are no different from
the GPL and many other licenses in this regard.

 > [SS] In section 8, why can't RealNetworks provide a warranty that it owns
 > the copyrights to the Original Code?  If it cannot, is your licensee
 > accepting a risk he/she shouldn't accept?

It's very typical for free software to provide no warranty whatsoever.

 > [SS.1] Here's how I wrote the warranty in the OSL:
 >
 >    LICENSOR WARRANTS THAT THE COPYRIGHT IN AND TO
 >    THE ORIGINAL WORK IS OWNED BY THE LICENSOR OR THAT
 >    THE ORIGINAL WORK IS DISTRIBUTED BY LICENSOR UNDER
 >    A VALID CURRENT LICENSE FROM THE COPYRIGHT OWNER.
 >    EXCEPT AS EXPRESSLY STATED IN THE IMMEDIATELY
 >    PRECEEDING SENTENCE, THE ORIGINAL WORK IS PROVIDED
 >    UNDER THIS LICENSE ON AN "AS IS" BASIS, WITHOUT
 >    WARRANTY, EITHER EXPRESS OR IMPLIED, INCLUDING,
 >    WITHOUT LIMITATION, THE WARRANTY OF NON-INFRINGEMENT
 >    AND WARRANTIES THAT THE ORIGINAL WORK IS MERCHANTABLE
 >    OR FIT FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
 >    TO THE QUALITY OF THE ORIGINAL WORK IS WITH YOU.
 >    THIS DISCLAIMER OF WARRANTY CONSTITUTES AN ESSENTIAL
 >    PART OF THIS LICENSE....

See above.

 > [TT] A further point in section 8:  Why would you need to provide any
 > warranty statement at all for the Covered Code (as opposed to the
 > Original Code) when you're not the one creating or distributing it?
 > Your license should extend simply to the Original Code.  If someone
 > creates a derivative work, that person may be required to license that
 > derivative work under the same license, but then he/she is the licensor
 > of his/her own "Original Code."  That's one reason that I like it better
 > when a license imposes reciprocity obligations and uses the term
 > "Licensor" rather than have it always appear to be "RealNetworks" that
 > is doing the licensing.

We're looking at changing this to "Licensor".

 > [UU] Is a liquidated damages amount of $10.00 (in section 9) going to be
 > acceptable in every jurisdiction?

I hope so.  We certainly can't afford to take on any liabililty for a
product RealNetworks is providing completely free-of-charge.

 > [VV] Why a section 10 when section 5 seems to say the same thing?

We're generally looking to shorten/simplify the license, and this may be
one way of doing that.

 > [WW] Section 11 is an example of a provision that is only needed because
 > you've made the license to derivative works extend from you to the
 > licensee.  That is not a clean reciprocal license.  You (RealNetworks)
 > should only license your original work, and then require creators of
 > derivative works to license their own works under the same license in
 > whey THEY, not you, are the "Licensor."  That's another reason to not
 > have RealNetworks be the name of the licensor in this license.

We're going to try to make this license more generic.

 > [XX] In section 12.1(a), "becoming aware" is a lot different "are told by
 > us."  I'm not sure I'd ever agree to an automatic termination provision
 > where my own subjective awareness became a subject of discovery.

...the lesson here is "don't breach". :)  This clause is in the APSL, and
is more generous than section 4 of the GPL (which terminates immediately
upon breach, whether or not you are aware).

 > [YY] I'm not fond of section 12.1(d).  That's a free license for you to
 > infringe any of your licensee's patents.  I am willing to live with a
 > defensive termination provision that takes effect if your licensee sues
 > you for infringement of any patent relating to the Original Work.

That's a mighty big loophole you are trying to sign us up for.  APSL and
the IBM Public License have similar clauses.

Basically, we reserve broad defensive rights, because someone may accept
our open source license, and turn around and sue us for our alleged use of
their patent. This clause is not a license to any of our licensees'
patents, it's simply a statement that we will not provide a free patent
license to anyone that would sue us for patent infringement. This is
completely reasonable.

 > [ZZ] Section 12.2 finally deals with the complex issue of sublicensing, but
 > in an almost off-hand way.  Why should you permit sublicensing at all?
 > Refer to my comments on sections 2 and 6, above.

We'll look at the sublicensing issue.

 > [AAA] What makes you think that a court would enforce the last sentence of
 > section 13.4 in this unexecuted license?  I suggest you exercise a
 > degree of caution in drafting this license that would be appropriate if
 > the court will construe the language against RealNetworks.

We're planning on using a click-wrap.

 > [BBB] Minor point: In 13.5(a), should the phrase be "shall be enforced"
 > rather than "will be enforced"?  Similarly, should it be "shall continue
 > in full force and effect?"

We feel that "will" and "shall" are synonymous.

 > [CCC] The severability provision in 13.5(b) is a little harsh.  If a court
 > rules against you, I could understand your halting any further
 > distribution or licensing of the Original Code.  But to require your
 > users to discontinue any use and destroy all copies is quite draconian.

This is to prevent unlicensed use in areas where the law doesn't protect
our interests.

 > [DDD] Section 13.7 is problematic.  If your Original Code cannot be exported
 > to certain nations because of Dept. of State or DOD restrictions, you
 > may simply have to include a notice separate from the license.  OSI has
 > long held that article 5 of the Open Source Definition ["No
 > Discrimination Against Persons or Groups"] prevents such explicit
 > restrictions on export.  Here's the relevant portion of the commentary
 > to OSD #5:
 >
 >    Some countries, including the United States,
 >    have export restrictions for certain types of
 >    software. An OSD-conformant license may warn
 >    licensees of applicable restrictions and remind
 >    them that they are obliged to obey the law;
 >    however, it may not incorporate such restrictions
 >    itself.

We'll modify this to be OSD conformant.

 > [EEE] Is the notice in section 13.8 regarding parties from Quebec requesting
 > that this license be drafted in English in fact true.  Which license has
 > requested anything?

I'm not sure what your question means.  "The parties" request the license
is in English.  Seeing as how that's the only language the license is
written in, it's a darn good thing.  :)

 > [FFF] The "please obtain a copy of the License ... and read it before using"
 > language of Exhibit A has been deemed by some courts to be insufficient
 > to bind anyone to the license.  It is merely an invitation, with no
 > assurance that anyone has actually done so.

Interesting.  We certainly aren't going to go out with that boilerplate.
I'm not sure it makes sense to include the full license on every source file.

Whew, made it through!  :)  Thanks again for the incredibly detailed review
of the license.  We'll be folding many of these comments into the next
revision.

Thanks
Rob



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