Re: RPSL and DFSG-compliance
Brandon,
My apologies if I've come out as brash or arrogant. I'm not the type to
mince words, and I hope the level of candor that I'm trying to bring to
the conversation is at least somewhat appreciated.
The reason why this conversation has been revived is because a
non-RealNetworks volunteer (Thomas Maurer) has stepped forward to
maintain Debian packages for the all of the Helix open source efforts.
I've been trying to be supportive of his efforts, while at the same time
trying to live within the time and resource constraints that I'm under
right now.
Without Thomas's involvement, I would not have chosen this time to even
discuss the RPSL or other licensing options with respect to the Helix
DNA Server and Helix DNA Producer. In retrospect, I maybe should have
encouraged Thomas to hold off until a better time for us rather than
sending him into a situation where we (RealNetworks) aren't in a
position to provide support he deserves.
However, now that the discussion is open, I feel obligated to respond to
at least some points here.
On Mon, 2004-08-02 at 11:47, Branden Robinson wrote:
> On Mon, Jul 26, 2004 at 11:44:32AM -0700, Rob Lanphier wrote:
> > I would really like someone to map one of the cited problems with the
> > RPSL to a stated requirement in the DFSG.
>
> Debian's committment to Free Software does not stop at the DFSG. The "G"
> in Debian Free Software Guidelines means "Guidelines".
>
> As the DFSG FAQ[1] puts it:
>
> 9. Q: How can I tell if a license is a free software license, by Debian's
> standards?
>
> A: The process involves human judgement. The DFSG is an attempt to
> articulate our criteria. But the DFSG is not a contract. This means
> that if you think you've found a "loophole" in the DFSG then you don't
> quite understand how this works. The DFSG is a potentially imperfect
> attempt to express what "freeness" in software means to Debian. It is
> not something whose letter we argue about. It is not a law. Rather, it
> is a set of guidelines.
>
> > We might be willing to engage in a conversation about changing the RPSL,
> > but not in an environment where it is clearly subject to the whims of
> > whoever happens to be discussing the issues on the list.
>
> This is a straw-man argument. It is also inflammatory and insulting to the
> subscribers of the debian-legal mailing list, some of whom have been
> participating in license discussions and negotiations for years to the
> mutual satisfaction of the parties involved.
>
> Is this the sort of example you really want to set for Debian's future
> communications with Real Networks?
You've accused me of setting up a strawman, without providing a
characterization that you feel is more accurate. Just because there are
examples of the process working for some in the past, that doesn't mean
it'll work for us. If you aren't interested in working with us, then I
guess we are at an impasse for now. I hope to convince you that we're
more important than that, but I'm not going to have time in the
immediate future to work under the current guidelines as I understand
them.
The process as it exists now is not at all unlike the IETF working group
process. The main difference is that, while the debian-legal list
functions like an IETF working group list at first, there's not a clean
process for getting to closure.
I highly recommend the following process improvement, which I think
satisfies the consensus-oriented, egalitarian ethic of Debian, but
allows for more efficient interaction with outside parties.
Elect or devise a procedure to appoint a debian-legal working group
chair. The chair's responsibility would be:
1. Identify and acknowledge new licensing issues as they come up.
2. Guide discussion to constructive conclusion.
3. Approve summary statements of licenses. The actual summary
statement may be authored by anyone (including and probably often the
party wishing to get the license approved), but the chair would be
responsible for ensuring that the summary is an accurate and complete
statement of the current consensus on the list.
4. Appeals on the accuracy of the license statement can be made to the
Debian project leader.
5. After an approved summary statement is issued (and if the license is
deemed "non-DFSG compliant"), the chair may represent the Debian project
in further (possibly private) conversations with the party representing
the license. While the chair would not be at liberty to change the
official position as described in the summary statement, they would be
free to speculate and advise on what compromises might be acceptable,
and to make public recommendations on alterations to the official
position as a result of said conversations.
I recommend looking at RFC 2418 for further ideas on how to structure
such rules:
http://www.ietf.org/rfc/rfc2418
Not everything is applicable, but with the right sets of checks and
balances, I don't believe that there would be any compromise in the
Debian project ideals.
Perhaps there is already such a process in place, in which case, I
apologize for wasting everyone's time here. However, my understanding
is that there isn't such a process.
The process doesn't even have to be fast; just well-defined and
respectful of the time commitment of all parties involved. If such a
process were defined, then I (and other representatives of corporate
contributors) would have a clear sense of when to involve our corporate
counsel. In my proposal, the main involvement would be after the
summary statement is issued.
> > I would love to work with the Debian project on making sure RPSL is
> > Debian-free. However, it makes it really difficult to engage the
> > RealNetworks Legal department when there's a lot of discussion about
> > personal tastes, but no mapping back to DFSG clauses. That just makes
> > everyone here believe that there will be an endless stream of
> > manufactured excuses as to why future versions of the RPSL will also not
> > be considered Debian-free.
>
> It sounds to me like you're constructing a self-fulfilling prophecy. Why
> do you suppose that the Debian community is predisposed to reject the RPSL?
> What do you know that we don't? Is the RPSL *designed* to undermine user's
> freedoms, yet sneak into Debian main because it passes the DFSG via some
> sort of simplistic checklist analysis? If not, what have you to fear?
Now you have set up a strawman: we don't like this process, ergo we
must have something to fear. Not at all; we want to solve any problems
efficiently, but in a way that doesn't force us to give up things that
we need to sustain our business.
We've heard a long list of grievances with the RPSL 1.0, and it's
difficult to tease out which ones are showstoppers, and which ones are
"nice to haves".
RPSL is designed to be what we feel is a fair bargain between
RealNetworks and the F/OSS community. There are at least some community
members who believe that we have struck a fair balance (e.g. the OSI
board, who approved the RPSL, after we made specific changes to RPSL 0.9
necessary to comply with the OSD).
We agreed to license the Helix Player under the GPL, with help from Red
Hat and Novell, since that's the most important piece of our technology
for broad adoption, and is the least risky to our existing business.
However, we are very concerned with forking, and thus, if we find that
patches aren't given back in a way that can be incorporated into our
mainline codebase, it may cause us to cease making future contributions
under GPL (thus making the licensing incompatibility between our version
and the forked version of our code symmetric).
In a few months, we may be more comfortable with our GPL decision, and
may release all of our currently RPSL'd code under GPL (including Helix
DNA Server and Helix DNA Producer). However, there's not a pressing
business need at this point, so that probably won't happen in the near
future. If someone were to step forward with a compelling business case
> As a licensor I think you have some important questions to ask yourself;
> you need not share the answers with the Debian Project, but doing so may
> help us to understand your position, and if your desires are compatible
> with the aims of free software, why they are.
>
> * What do you want to allow?
In a nutshell, those things outlined here:
http://www.opensource.org/docs/definition.php
Additionally, we're looking for whatever is necessary to achieve broad
adoption of the Helix platform.
> * What do you want to prohibit?
You'll need to read the license for that. However, tangible differences
between RPSL and GPL are noted below:
* License-incompatible forking. Our business model is predicated on
dual-licensing of the source code. RPSL insures that we can continue to
reincorporate outside modifications into our dual-licensed codebase.
* Use, modification, or distribution by parties that wish to bring
patent lawsuits against us.
> * Upon which laws do you ground each of your prohibitions (copyright,
> patent, trademark, trade secret, etc.)?
All of the above.
> * Why are existing licenses insufficient?
> + Does the MIT/X11 license[2] permit things you want to prohibit?
> + Does the GNU GPL[3] prohibit things you want to allow?
GPL is the closest to meeting our needs, but doesn't include the
prohibitions above. We believe in the right to fork, but not in such a
way as to make remerging difficult/impossible on licensing grounds
alone. Pure GPL projects don't have this problem, but dual-licensed
projects do.
Dual-licensing is an increasingly important business model for open
source developers (e.g. MySQL, Trolltech, RealNetworks). While
license-incompatible forking hasn't yet become a huge issue for any
dual-licensed product that I'm aware, it remains a risk, and a potential
disincentive to companies who might have otherwise joined us in using
the model.
> * Is it important that works under your license be shipped as part of
> Debian's OS?
Important but not critical, at this stage.
> * If a work under your license is accepted as Free by the Debian Project,
> but something causes it not to be shipped in the Debian OS[4], would you
> regard that as a failure?
Suboptimal, but not an all-out failure.
> [1] http://people.debian.org/~bap/dfsg-faq.html
> [2] http://www.opensource.org/licenses/mit-license.php
> [3] http://www.gnu.org/copyleft/gpl.html
>
> [4] Reasons for this include but are not limited to:
> A) no one is available to maintain the package
> B) the package is of insufficient quality to be included; e.g. violates
> Debian Policy (for instance, ships executables in /usr/share/man)
> C) the package is too buggy to be included; e.g., has a horrendous bug
> such as the package preinst script running "rm -rf /"
> D) the package is accused of infringing a third party's patent, and we
> know of a litigitous patent holder who claims to own the patents and
> sends nastygrams ordering people to desist and/or pay royalties
> E) the software's functionity is outlawed by some jurisdiction that is
> important to the Debian Project, such as the United States or
> European Union;
> F) the software itself is enjoined from distribution in some
> jurisdiction important to the Debian Project, such as the states in
> the U.S. Federal 2nd Circuit
>
> Lest one accuse me of producing makeweight arguments, none of the above
> are hypothetical reasons for a package's exclusion from Debian OS
> release (or from distribution by Debian altogether). Apart from my
> specific examples of a policy violation and horrendous bug, all have
> been seen in practice.
Understood. As stated, the reason why this issue has been revived is
that the new .deb maintainer for Helix has resolved or well on his way
to resolving A and B above, and we don't believe C-F are problems with
Helix.
I'm heading into a particularly busy stretch, so I'm once again not
going to have a lot of time to work on this issue. I'll try to
participate, but I apologize in advance if I drop off of this thread
entirely. I'm going to work with Thomas on an interim solution which is
acceptable to him until such a time as we can participate in this
discussion in a more constructive manner.
Certainly, the Debian project doesn't need to even seriously consider
recommendations I make above. However, I make these recommendations in
an effort to document what I feel is a typical corporate contributor
looking to make a significant contribution to Debian.
Rob
--
Rob Lanphier, Development Support Manager - RealNetworks
Helix Community: http://helixcommunity.org
Development Support:
http://www.realnetworks.com/products/support/devsupport
Reply to: