[License-discuss] Open Source Eventually License Development

[fred trotter]

Eben,
       As always I feel like I have to apologize for my language skills
when responding to you. This is so elegantly written it almost seems rude
to write "replies throughout"... nonetheless:

On Wed, Aug 14, 2013 at 5:44 PM, Eben Moglen <moglen at softwarefreedom.org>wrote:

> Whatever the truth of the adage may be, the point for us is that none
> of this has anything to do with licensing.  Fred Trotter was actually
> asking a question, to which the correct answer is: "You don't need a
> license to make something free software at a certain date in the
> future.  Giving a copy to an appropriate agent, with written
> instructions to publish under, e.g. GPLv3 or ASL 2.0 on the future
> date, is quite sufficient.  Any number of reliable intermediaries for
> such purposes exist, and would provide the service gratis."
>

Skinning cats.. this way of skinning requires a third party which has
upsides and downsides.
Does anyone else prefer the "third party approach" or have opinions on how
that would work?

I would be concerned that legit people would work with Apache Foundation,
OSI or FSF or something reasonable as the trusted third party, but then
some people would try to use their "Aunt Jenny" as the "trusted third
party"... So this would require formalization and brand control to work
effectively too...


>
> This isn't a matter for copyright licensing, because licenses are, in
> J.L. Austin's term, "performative utterances."  They are present acts
> of permission, not declarations of future intention, like testaments.
>

At least one benefit to this distinction is that the word "testament" with
its religious affiliations would make for some delightful project naming
puns ;)


> There's no point in a copyright holder writing a license that says
> "these are the terms today, and those will be my terms tomorrow."
> Unless the license is irrevocable, only the terms of present
> permission matter.  Once the software *is* free, on the other end,
> only the terms of permission then granted matter, regardless of any
> prior expression of an intention to provide different free terms.  So
> there is no legal issue of significance involved in the business model
> of postponing freedom for interim proprietary distribution.  Simple
> conveyancing is legally quite sufficient.  The business method does
> not fail because people have mumbled incorrect magic words.
>

While I must admit that lawyer-speak does strike me as series of
incantations, I am not merely discussing the issue of magic words.

This is more an issue of brand maintenance. Lets say I create license
called "Fred's Unusually Nice License" and then I convince everyone in the
investor/developer communities that this is a good way to make money and
still make Libre software in the end. But then someone writes a license
called "Franks Usual Dissonance License" as the temporary proprietary
license that goes with my FUN license. Inside the FUD license, Frank ads a
clause that says "no matter what FUN, or the target OSI/FSF license says,
this code can only be used for educational purposes... ever "or else"...
Frank would attempt to do this type of thing because he can use the
reputation that FUN has developed but still try and trap users with his
ability to script his own proprietary license and use it with FUN. I have
been burned pretty badly by people who literally rewrote sections of the
GPL to suit them and still called it "GPL" that I know that some people
will try those shenanigans.

The terms of the FUD license would contradict both the contents of FUN and
the OSI/FSF target license. This would create a very confusing situation
that ultimately damage the brand of the license. So FUN needs to say
something specific about that kind of thing not being allowed.. and very
naughty indeed... It would be nice if it could even be enforceable
language. Protecting developers and users who trusted FUN without carefully
reading FUD. Given that FUD could have lots of different stuff inside it,
it is entirely possible that people would not read it carefully enough. So
I guess a feature of the OSE license that I would like to develop is that
it would be relatively safe even from users who were just doing the "click
through"...


>
> It is simple to demonstrate from an economic perspective that the
> value of the proprietary product sold on a fixed-term delay of free
> licensing converges, after the first such period of distribution, to
> the value of one upgrade minus the cost of applying it, assuming the
> downstream user attributes absolutely no value to free licensing over
> proprietary licensing, which is in fact usually a bad assumption.
>

What if the end user has a special appreciation for "paying for free
software in a way that ensures the core developer stays in business"? That
is different than merely valuing one over the other. The whole point here
is to stop the current zero-sum game for proprietary limitations and
complete freedom where we have to make difficult choices between making
money and making Libre software. People who value freedom can learn to pay
by default. After all, if every person who benefited indirectly from the
GNU compiler would donate one cent to FSF and one cent to the OSI per year,
neither organization would have any problem paying the bills. People don't
pay because that is the norm in our development culture, this mechanism
could change that.


> This clearing price is too small to be profitable except at very high
> volumes or in other extraordinary circumstances.


These extraordinary circumstances are fairly easy to contrive.
For instance, the current natural rhythm of software development is
something like

1. Release stable version X.0
2. Create new version X.1 with lots of new untested and unstable features
3. Test, Release, Repeat as needed, incrementing minor versions
4. Stable version incremented. X+1.0 is released

Most users hop from stable version to stable version, which which keeps
switching costs very low, and making your economic assessment correct. But
under a time delay model you might shift to a development cycle like so.

1. Release version X for sale under a 9 month timer
2. Release version X.1 under a FLOSS license, totally unstable but
presently Libre
3. Test, Release, Repeat as needed incrementing minor versions for 6 months
4. Release version X+1 for sale under a 9 month timer. There is no stable
version available under FLOSS, but there are two stable versions under a
timer.
5. Users must choose between a purchasing a stable version that will be
Libre in 3 months or paying the same thing for an improved version that
will be Libre in 9 months.


>  The business model
> fails for simple economic reasons--because the competition provided
> for one's present product by the last version one has freed is almost
> always too strong to withstand--not for legal ones.
>

This assumes two things: First, that the "previous" version is stable
enough to provide good competition, which holds under current development
rhythms, which emphasize "costless good stuff for the masses", rather than
"costless good stuff for the beta testers" which can be achieved using a
different development rhythm.

The second assumption is that state in which the value of the delta between
version X and version X-1 is naturally an "extraordinary" state. I have
wanted to do a FLOSS drug database for years, but a drug database -must- be
maintained completely and version X-1 is unethical and impractical to use
at all. But because cultural the default for FLOSS is "costless for the
masses" a stable FLOSS drug database has yet to materialize. In fact, the
Open Source community has been artificially limited to working on projects
where version X-1 and X have a very small different in value because there
is no way to assure income for version X versus X-1. In short what you
argue is "extraordinary" circumstances is only "extraordinary" because of a
deeply biased sample.


> The natural history is in accord with theory on this subject.  RMS was
> correct that this was a problematic compromise, but even more
> problematic for the folks on the other side.
>

Could someone who knows the story well related what problems the "people on
the other side" had?

I understand that RMS regards this as a problematic compromise, but I am
struck be the relatively short list of things that RMS regards as a
"compromise" problematic or otherwise. Having been through USMC bootcamp I
skilled enough at recognizing and embracing an underhanded compliment, when
I know nothing better will be offered.



-- 
Fred Trotter
Blog: http://radar.oreilly.com/fredt
Twitter: https://twitter.com/fredtrotter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20130815/4e5c5522/attachment.html>