<p dir="ltr">Hi fred</p>
<p dir="ltr">I think what you are asking for guidance on, is outside the mandate of osi, and fsf too. The time delayed license should of </p>
<div class="gmail_quote">On 14 Aug 2013 19:24, "fred trotter" <<a href="mailto:fred.trotter@gmail.com">fred.trotter@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
       I am sending this to both FSF and OSI people. Please tolerate<br>
my use of the various terms interchangeably, I know the various rules<br>
but I am talking to two different communities, if at all possible<br>
please permit me to skip the "I don't like your choice of terms"<br>
lecture.<br>
<br>
       I have just returned from OSCON, where I gave an Ignite talk on<br>
Open Source Eventually, which is yet-another-fine time ransom license<br>
that converts to FLOSS. While there I had several meetings with Monty<br>
Widenius about his Business Source concept. He and I have tentatively<br>
agreed to merge our efforts. I was also advised by Simon Phipps and<br>
Deborah Bryant to investigate the history of the concept here on the<br>
mailing list, which I have done. I have seen the history with<br>
GhostScript, the thread on delay-able open source licenses from Qian<br>
Hong and the recent and original discussions about TGGPL from zooko.<br>
With that historical context in mind, let me outline my aim.<br>
<br>
First, no ransom license of any type should ever be OSI approved as an<br>
Open Source license or be FSF approved as a Free Software License.<br>
Ransom licenses are proprietary until they are Open Source or<br>
Free/Libre. I am not going to ask you to compromise the core values of<br>
our community by putting lipstick on a pig.<br>
<br>
Second, despite this, both OSI and FSF should consider having a<br>
position, either formally or informally on these licenses. We need to<br>
standardize on one specific license text that is "known good" for this<br>
type of business approach to avoid license proliferation. Real world<br>
FOSS users would be better served by having a standard license, than<br>
having lots of slight variations because:<br>
<br>
* All of the promotors of this concept are writing different licenses,<br>
so we are again facing a license proliferation problem.<br>
* Poorly written or understood versions of this license could "taint"<br>
the release of subsequently released FLOSS software.<br>
* Automated license compliance systems will have a difficult time<br>
evaluating licenses that always have different data (dates) embedded<br>
in the license text.<br>
* Companies using the delayed method should have the option to choose<br>
from the menu of OSI/FSF/CC licenses as the "target" licenses<br>
* The license should support different "proprietary intents", such as<br>
Monty's aim to favor small business with costless versions, or zooko's<br>
idea of creating a "proprietary community". No version of these<br>
proprietary intents should be able to mar the conversion of the<br>
license to a FOSS license at the specified conversion date.<br>
* Users should be able to trust that they have the right to perform<br>
the conversion to FOSS themselves and should not be in a position to<br>
pay for software with the mere promise of a subsequent and separate<br>
release.<br>
* Companies who are using this method should have a limit to the<br>
maximum time they can delay a release, because 20 years would be just<br>
as bad as a software patent.<br>
* The licensing methods should be compatible with automated compliance software.<br>
* The licensing methods should be compatible with current file<br>
conventions "README, LICENSE, COPYRIGHT etc etc"<br>
* The license should work for hardware, bioware and "other" things,<br>
not just software.<br>
* end users should be mostly protected from any obvious misuse of the license<br>
<br>
With that in mind, I would like to propose the following process to<br>
develop this idea further.<br>
<br>
First, I would like for the OSI and FSF people on this list to<br>
consider some kind of new status for a license, like "OSI tolerated"<br>
or "OSI Not Open Source But It Doesn't Suck" , or "Not Free Software<br>
but tolerated for this purpose" or something like. Some way to clearly<br>
mark this as "the standard way of time delaying a FOSS release" but<br>
not actually "OSI/FSF Approved".<br>
<br>
Second I would like for interested parties to join me developing the<br>
license on GitHub.<br>
<a href="https://github.com/ftrotter/OSE" target="_blank">https://github.com/ftrotter/OSE</a><br>
<br>
At this stage, I am accepting issue creation and will be using that to<br>
remove obvious bugs from the text. If a git pull feels comfortable to<br>
you, that works too. I will of course require copyright assignment for<br>
text modifications.<br>
Once the basic license no longer sucks I will setup a co-ment instance<br>
for public comment.<br>
Finally I might be able to get NOD (my employer) to actually pay for a<br>
legal review once everything is done.<br>
<br>
We will be releasing data sets under the resulting license as soon as<br>
it is ready.<br>
<br>
Remember, I am not specifically advocating for the "Time Ransom<br>
License" approach. I remain somewhat uncomfortable with the approach.<br>
However, I am somewhat more uncomfortable not being able to make a<br>
living making Libre Software. There are enough people doing this that<br>
unless we sort something formal out, an FLOSS project is going to be<br>
put in a situation where it relied on copyrights to revert to Open<br>
Source or Free/Libre Software Licenses and that either did not happen<br>
or happened in an unreliable manner. If you are uncomfortable with<br>
this business model, then it is even more important that you<br>
participate with specific criticism. Some issues will be endemic to<br>
approach, but many issues might be avoided with careful crafting of<br>
the language. If we are careful we will get something that an Open<br>
Source or Free Software community can rely on.<br>
<br>
Feel free to submit an issue on github, but if you prefer to submit<br>
your issues with a "reply all" I will convert them to github issues<br>
and address them in the license (or acknowledge that I will be unable<br>
to address them)<br>
Please do take a second actually read the license and its README.md<br>
file on github, I have spent some time actually thinking the various<br>
issues through and I need comment on what is actually missing from our<br>
actual license, and not a merely a theoretical discussion as such.<br>
<br>
IANAL and as per normal if someone else can point me to a project with<br>
similar scope and aims I will be happy to withdraw my project (I am<br>
sure Monty would do the same, assuming his aims were met)...<br>
<br>
Thanks,<br>
-FT<br>
<br>
<br>
--<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>
_______________________________________________<br>
License-discuss mailing list<br>
<a href="mailto:License-discuss@opensource.org">License-discuss@opensource.org</a><br>
<a href="http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss" target="_blank">http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss</a><br>
</blockquote></div>