<html>

  <head>

    <meta content="text/html; charset=ISO-8859-1"

      http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <pre>resending since the original message did not seem to reach you:

In Reply To: Richard Fontana

>><i> Any derived work must carry the name of the distributor, vendor

</i>>><i> or the product in its name (or a unique shorthand for it) preceded by

</i>>><i> the original unchanged name of the software and its version at the

</i>>><i> beginning. 

</i>>

> Perhaps I am misunderstanding what you mean by "carry the name", but

> are you saying I am severely restricted in what name I can give to a

> derivative work?

</pre>

    Actually not. It gives a detailed naming convention which is

    upstreamname-version-yoursuffix where yoursuffix needs to include at

    least a unique shorthand of you that should point to the name of the

    distribution, product or company. If you want to use a different

    naming scheme you need to create a new 'branch' which may require

    consent of the original authors or new copyright holders if 'free

    branching' has not been specified along with the license string.<br>

    <br>

    <pre>>><i> Modifications applied to this program may not affect the

</i>>><i> name, original version, copyright, license or any reference given to

</i>>><i> the authors such as their email addresses or their web presence and/or

</i>>><i> page in any part of the program or any files attached to the program

</i>>><i> apart from updates to these references made by the respective authors

</i>>><i> themselves.

</i>>

> This is a little unclear but I assume you mean 'preserve all copyright,

> license and attribution notices'. 

</pre>

    That`s it.<br>

    <br>

    <pre>>><i> You as a distributor need to let your contributors add

>> their names, their email and modifications with date to the changelog.

</i>>

> What if there's no changelog? And does this mean if a contributor says

> to me 'add my name etc. to the changelog' and I refuse, you

> can terminate my license?

</pre>

      If there is no changelog I would suggest that there is no need to

    add anything to it (However it I would strongly recommend the

    upstream authors to use one as many distros want to have that.).

    However the license says nothing about which changelog to use. A

    distributor could likely create his own changelog for his own

    changes.<br>

    <br>

    <pre>>><i> You must not charge for the programs under S-FSL themselves but you

</i>>><i> may require a reasonable charge for the physical reproduction of the

</i>>><i> data.

</i>>

> This goes against a bedrock principle of free software/open source that

> a distributor should not be limited to charging 'reasonable' or no fees

> as to what is distributed.</pre>

    This is roughly the same as what the Perl Artistic License requires.

    "You may charge a reasonable copying fee for any distribution of

    this package. ... You may not charge a fee for the package itself."<br>

    <br>

    <pre>>><i> If you

</i>>><i> have some work in progress you are obliged to send out bundled patches

</i>>><i> once at least every month. 

</i>>

> That is (from the perspective of open source) an unreasonable

> requirement.

>

>><i> This is to assert the availability and

</i>>><i> recognition of patches at least by the original authors; a condition

</i>>><i> which must be held even if you agree not to actively 'send' or

</i>>><i> 'forward' your patches. 

</i>>

> I don't understand this sentence, particularly given what it follows.</pre>

    Well, you may agree with the original authors to neither send them

    patches by email nor by snail mail but f.i. you can say: "Here I

    have a web page where you can see all my modifications and

    extensions. You may be notified for new changes by rss.". The

    original authors can then say "This is okay for me." and there will

    be no more proactive sending or forwarding. If you said "You need to

    purchase my program X in order to retrieve these changes." then the

    original authors may dissent. Note that this is only required when

    distributing to a closed set of people like paying customers and

    there would be no other chance for the original authors to get these

    changes.<br>

    <br>

    <pre>>><i> By distributing patches you do also consent

</i>>><i> that the original authors may incorporate your patches into future

</i>>><i> versions of this program. The patched parts of the program and the

</i>>><i> patches themselves will also become subject to this licensing and may

</i>>><i> even be used for free in other programs or in the same program under

</i>>><i> different licensing as soon as you choose to publish any kind of

</i>>><i> patch;

</i>>><i> i.e. you need to be ready to share your full intellectual property

</i>>><i> rights with the original authors whenever you choose to exchange,

>> distribute or publish any kind of patch to this program.

</i>>

> "Share your full intellectual property rights" could mean co-ownership

> of patents and trademarks as well as copyrights... 

</pre>

    Actually, yes. It is either the responsibility of any co-author not

    to use such patents or trademarks or otherwise whenever he plans to

    use them then to give at least the original authors usage rights on

    these patents. Otherwise usage of patents will be forbidden in S-FSL

    software. Usage of trademarks is discouraged for the same reasons.<br>

    <pre>> I assume what you

> have in mind is a privileged copyright license for the original authors

> (which I think is bad policy but has precedent in some open source

> licenses). <i>

</i></pre>

    Yes, that it is. I have already explained this concept in one of my

    previous mails.<br>

    <pre>> "Ready to share your full intellectual property rights" is

> at best unclear though, even with this sentence:

>

>><i> Sharing your

</i>>><i> intellectual property means that both parties - you and the original

</i>>><i> authors - obtain the full set of rights about your modifications which

</i>>><i> were initially only associated with you.  </i></pre>

    I hope this is a bit clearer now.<br>

    <br>

    <pre>>><i> If you want to develop a separate branch of this program the original

</i>>><i> authors need to consent as long as the software may be subject to

</i>>><i> further development by them; </i>

</pre>

    Well, if the original authors die and no one else was denominated as

    the future copyright holder then you need not ask anyone whether to

    branch or not. The same thing would apply if the original authors or

    copyright holders were hindered by some reason to do so for the rest

    of their lives.<br>

    <pre><i>>> if not that should be indicated by them

</i>>><i> denominating either new copyright holders with the same right as the

>> original authors or by publishing under a different license.

</i>>

> I basically don't understand this sentence, but to the extent I can

> make something out of it it is inconsistent with open source. 

</pre>

    If the original developers do not want to continue to maintain and

    develop their program they should either consign their rights to

    someone else or put it under another license like GPL or BSD.<br>

    <br>

    <pre>>><i> new copyright holders with the same right

</i></pre>

    This means that the new copyright holders will be able to act as the

    new prospective 'original authors' in any kind of way.<br>

    <br>

    <pre>>><i> Universal consent to 'free'

</i>>><i> i.e. any branching may be specified additionally at any time by the

</i>>><i> distributed application. 

</i>>

> I don't understand this sentence.</pre>

    You may state the following:<br>

    License: S-FSL with free branching<br>

    - and the original authors do no more need to consent on any new

    branch.<br>

    <br>

    <br>

    <pre>>><i> Branched versions do however

</i>>><i> need to forward and share patches including the property rights on

</i>>><i> patches with their parent branch. Branched versions can not re-publish

</i>>><i> under a different license or use patches as their own intellectual

</i>>><i> property unless explicit consent from the maintainers of the parent

>> branch is given.

</i>>

> What does it mean to 'use patches as their own intellectual property'?

</pre>

    Well I must confess this is in deed unclear. It should say here: "..

    or claim  any intellectual property rights on patches from another

    branch". It needs to be re-worked. Furthermore as you have already

    pointed out rules for branches will need to extend from patches over

    anything that can be claimed intellectual property.<br>

    <br>

    <pre>>><i> Security updates and updates against broken functionality

</i>>><i> must also be available to the public rather than just to a paying

</i>>><i> customer stock as long as they pertain to software that can either be

</i>>><i> downloaded or compiled from sources by the public and which pertain to

</i>>><i> the distribution. 

</i>>

> I am not sure I understand the second half of this sentence.

</pre>

    Is it about the definition of public?<br>

    <meta http-equiv="CONTENT-TYPE" content="text/html;

      charset=ISO-8859-1">

    <br>

    <pre>> Available to the public implies here available free of charge apart from 

> connectivity to the internet or a reasonable charge for the reproduction 

> of the data medium 

</pre>

    <title></title>

    <meta name="GENERATOR" content="LibreOffice 4.1.2.3 (Linux)">

    <style type="text/css">

        <!--

                @page { margin: 2cm }

                PRE.cjk { font-family: "WenQuanYi Micro Hei Mono", monospace }

                PRE.ctl { font-family: "FreeSans", monospace }

                P { margin-bottom: 0.21cm }

        -->

        </style>Well it should mean that if programs included into your

    distribution are part of the public part of your distribution then

    you need not exclude anyone from the provision of security updates

    and updates to broken functionality. If your distribution does not

    have a public part no such requirement is given.<br>

    (perhaps we should put it like this)<br>

    <br>

    <pre>> In general I would recommend rewriting the license to make it clearer,

</pre>

    That will happen.<br>

    Many thanks for your contribution!<br>

    <br>

    <pre>> but the current form does not seem to be an open source license.</pre>

    can you give any arguments on this?<br>

    <br>

    <br>

    <br>

    <br>

    <br>

    <br>

    <br>

    <br>

    <br>

    <br>

    <br>

  </body>

</html>