<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<pre>In Reply to Engel Nyst:
>><i> 5. By granting a group of developers to work on a new 'branch' other
</i>>><i> people can acquire similar responsibility and rights to work on an
</i>>><i> affiliated project. Free branching may be specified in addition to the
</i>>><i> license terms: "This program is licensed under S-FSL v1.3.x and may be
</i>>><i> branched for free.".
</i>>
> Regarding 4) and 5), I think that copyright control to the extent you
> want, even if it were possible, contradicts free redistribution (OSD
> #1), derived works (OSD #3) and distribution of license (OSD #7), at
> least. (likely more)
</pre>
Concerning issues #1, #3 and #7:<br>
<div id="persons-or-groups" title="persons-or-groups">
<div id="free-redistribution" title="free-redistribution">
<pre>| 1. Free Redistribution</pre>
<pre>| The license shall not restrict any party from selling or giving
| away the software as a component of an aggregate software distribution
| containing programs from several different sources. The license shall
| not require a royalty or other fee for such sale.
</pre>
</div>
<p>It does at least not forbid any part from selling or giving
away the software. There are just different rules for public and
non public distributors. Yes, the license is compatible and can
be shipped with several different sources. The license does not
require any fee for the sale, distribution or any additional
service. It just forbids to charge for the software itself as
f.i. the Perl Artistic License does.<br>
4. Does not seem to be affected as it is not about distribution<br>
5. You do not need to develop a separate branch if you do not
want to. This is just an additional option if you prefer another
naming scheme. However #4 says that there may be such naming
conventions.<br>
<br>
</p>
<div id="derived-works" title="derived-works">
<pre>| 3. Derived Works</pre>
<pre>| The license must allow modifications and derived works, and must
| allow them to be distributed under the same terms as the license of the
| original software.</pre>
</div>
<p>Yes, it allows derived works. Yes, they will be S-FSL, too;
i.e. the same terms will apply.<br>
</p>
<div id="distribution-of-license" title="distribution-of-license">
<pre>| 7. Distribution of License </pre>
<pre>| The rights attached to the program must apply to all to whom the
| program is redistributed without the need for execution of an additional
| license by those parties.</pre>
</div>
<p>All rights attached with the program are again applicable
without any discrimination to people or groups of persons. Who
would need an additional license?</p>
<p>Please argue in detail! What point of the license does
contradict which OSD criterium? Why do you think so? Give
reasons.<br>
<br>
</p>
<pre>> If a new branch has to be "affiliated", in the sense that special
> permission has to be given for someone to fork the software, it's not
> open source.
>
> Please note, free as in free distribution or free software means free of
> the need to come back to someone and ask for more permissions. Free from
> the need to ask for (another) permission at all, in order to exercise a
> set of rights. The license should give those permissions already. Your
> goals and license seem to confuse it with an "I may allow you free of
> charge, but I keep control over whether I allow you to in the first
> place". That's not an open source license.
</pre>
<p>No, to me it does not. It is not in the OSI criteria and I have
already explained on what I believe matters for open source. The
drop-to-the-community and forget it approach may be something to
dispose unused software; yet it just points to certain quality
issues and should not be considered a virtue.<br>
</p>
</div>
<br>
<br>
<br>
</body>
</html>