Eben,<div> 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:<br><br><div class="gmail_quote">
On Wed, Aug 14, 2013 at 5:44 PM, Eben Moglen <span dir="ltr"><<a href="mailto:moglen@softwarefreedom.org" target="_blank">moglen@softwarefreedom.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Whatever the truth of the adage may be, the point for us is that none<br>
of this has anything to do with licensing. Fred Trotter was actually<br>
asking a question, to which the correct answer is: "You don't need a<br>
license to make something free software at a certain date in the<br>
future. Giving a copy to an appropriate agent, with written<br>
instructions to publish under, e.g. GPLv3 or ASL 2.0 on the future<br>
date, is quite sufficient. Any number of reliable intermediaries for<br>
such purposes exist, and would provide the service gratis."<br></blockquote><div><br></div><div>Skinning cats.. this way of skinning requires a third party which has upsides and downsides.</div><div>Does anyone else prefer the "third party approach" or have opinions on how that would work?</div>
<div><br></div><div>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...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This isn't a matter for copyright licensing, because licenses are, in<br>
J.L. Austin's term, "performative utterances." They are present acts<br>
of permission, not declarations of future intention, like testaments.<br></blockquote><div><br></div><div>At least one benefit to this distinction is that the word "testament" with its religious affiliations would make for some delightful project naming puns ;) </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There's no point in a copyright holder writing a license that says<br>
"these are the terms today, and those will be my terms tomorrow."<br>
Unless the license is irrevocable, only the terms of present<br>
permission matter. Once the software *is* free, on the other end,<br>
only the terms of permission then granted matter, regardless of any<br>
prior expression of an intention to provide different free terms. So<br>
there is no legal issue of significance involved in the business model<br>
of postponing freedom for interim proprietary distribution. Simple<br>
conveyancing is legally quite sufficient. The business method does<br>
not fail because people have mumbled incorrect magic words.<br></blockquote><div><br></div><div>While I must admit that lawyer-speak does strike me as series of incantations, I am not merely discussing the issue of magic words. </div>
<div><br></div><div>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. </div>
<div><br></div><div>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"...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It is simple to demonstrate from an economic perspective that the<br>
value of the proprietary product sold on a fixed-term delay of free<br>
licensing converges, after the first such period of distribution, to<br>
the value of one upgrade minus the cost of applying it, assuming the<br>
downstream user attributes absolutely no value to free licensing over<br>
proprietary licensing, which is in fact usually a bad assumption.<br></blockquote><div><br></div><div>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. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This clearing price is too small to be profitable except at very high<br>
volumes or in other extraordinary circumstances. </blockquote><div><br></div><div>These extraordinary circumstances are fairly easy to contrive. </div><div>For instance, the current natural rhythm of software development is something like</div>
<div><br></div><div>1. Release stable version X.0 </div><div>2. Create new version X.1 with lots of new untested and unstable features</div><div>3. Test, Release, Repeat as needed, incrementing minor versions</div><div>4. Stable version incremented. X+1.0 is released</div>
<div><br></div><div>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.</div>
<div><br></div><div>1. Release version X for sale under a 9 month timer</div><div>2. Release version X.1 under a FLOSS license, totally unstable but presently Libre</div><div>3. Test, Release, Repeat as needed incrementing minor versions for 6 months</div>
<div>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. </div><div>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. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> The business model<br>
fails for simple economic reasons--because the competition provided<br>
for one's present product by the last version one has freed is almost<br>
always too strong to withstand--not for legal ones.<br></blockquote><div><br></div><div>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. </div>
<div><br></div><div>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. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The natural history is in accord with theory on this subject. RMS was<br>
correct that this was a problematic compromise, but even more<br>
problematic for the folks on the other side.<br></blockquote><div><br></div><div>Could someone who knows the story well related what problems the "people on the other side" had?</div><div><br></div><div>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.</div>
<div><br></div><div><br></div><div><br></div></div>-- <br>Fred Trotter<br>Blog: <a href="http://radar.oreilly.com/fredt" target="_blank">http://radar.oreilly.com/fredt</a><br>Twitter: <a href="https://twitter.com/fredtrotter" target="_blank">https://twitter.com/fredtrotter</a><br>
</div>