[License-discuss] Open Source Eventually License Development

Wed Aug 14 17:45:34 UTC 2013

Sorry for accidental sending...

The time delayed license should of course be an osi approved one, and
preferably one of the commonly used ones: gpl, bsd, and so on... The
licenses are what they are and there isn't much to discuss there, you just
pick one.

How you intend to write your proprietary license is then outside the osi
mandate to support, and off topic for this list.

Henrik
On 14 Aug 2013 20:40, "Henrik Ingo" <henrik.ingo at avoinelama.fi> wrote:

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