[License-review] For Approval: Scripting Free Software License, Version 1.3.5 (S-FSL v1.3.5)

[Elmar Stellnberger]

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

In Reply To: Richard Fontana
>>/  Any derived work must carry the name of the distributor, vendor
/>>/  or the product in its name (or a unique shorthand for it) preceded by
/>>/  the original unchanged name of the software and its version at the
/>>/  beginning.
/>
> 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?

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.

>>/  Modifications applied to this program may not affect the
/>>/  name, original version, copyright, license or any reference given to
/>>/  the authors such as their email addresses or their web presence and/or
/>>/  page in any part of the program or any files attached to the program
/>>/  apart from updates to these references made by the respective authors
/>>/  themselves.
/>
> This is a little unclear but I assume you mean 'preserve all copyright,
> license and attribution notices'.

That`s it.

>>/  You as a distributor need to let your contributors add
/>>/  their names, their email and modifications with date to the changelog.
/>
> 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?

   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.

>>/  You must not charge for the programs under S-FSL themselves but you
/>>/  may require a reasonable charge for the physical reproduction of the
/>>/  data.
/>
> 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.

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."

>>/  If you
/>>/  have some work in progress you are obliged to send out bundled patches
/>>/  once at least every month.
/>
> That is (from the perspective of open source) an unreasonable
> requirement.
>
>>/  This is to assert the availability and
/>>/  recognition of patches at least by the original authors; a condition
/>>/  which must be held even if you agree not to actively 'send' or
/>>/  'forward' your patches.
/>
> I don't understand this sentence, particularly given what it follows.

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.

>>/  By distributing patches you do also consent
/>>/  that the original authors may incorporate your patches into future
/>>/  versions of this program. The patched parts of the program and the
/>>/  patches themselves will also become subject to this licensing and may
/>>/  even be used for free in other programs or in the same program under
/>>/  different licensing as soon as you choose to publish any kind of
/>>/  patch;
/>>/  i.e. you need to be ready to share your full intellectual property
/>>/  rights with the original authors whenever you choose to exchange,
/>>/  distribute or publish any kind of patch to this program.
/>
> "Share your full intellectual property rights" could mean co-ownership
> of patents and trademarks as well as copyrights...

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.

> 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)./
/

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

> "Ready to share your full intellectual property rights" is
> at best unclear though, even with this sentence:
>
>>/  Sharing your
/>>/  intellectual property means that both parties - you and the original
/>>/  authors - obtain the full set of rights about your modifications which
/>>/  were initially only associated with you./

I hope this is a bit clearer now.

>>/  If you want to develop a separate branch of this program the original
/>>/  authors need to consent as long as the software may be subject to
/>>/  further development by them;/

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.

/>> if not that should be indicated by them
/>>/  denominating either new copyright holders with the same right as the
/>>/  original authors or by publishing under a different license.
/>
> I basically don't understand this sentence, but to the extent I can
> make something out of it it is inconsistent with open source.

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.

>>/  new copyright holders with the same right
/

This means that the new copyright holders will be able to act as the new 
prospective 'original authors' in any kind of way.

>>/  Universal consent to 'free'
/>>/  i.e. any branching may be specified additionally at any time by the
/>>/  distributed application.
/>
> I don't understand this sentence.

You may state the following:
License: S-FSL with free branching
- and the original authors do no more need to consent on any new branch.


>>/  Branched versions do however
/>>/  need to forward and share patches including the property rights on
/>>/  patches with their parent branch. Branched versions can not re-publish
/>>/  under a different license or use patches as their own intellectual
/>>/  property unless explicit consent from the maintainers of the parent
/>>/  branch is given.
/>
> What does it mean to 'use patches as their own intellectual property'?

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.

>>/  Security updates and updates against broken functionality
/>>/  must also be available to the public rather than just to a paying
/>>/  customer stock as long as they pertain to software that can either be
/>>/  downloaded or compiled from sources by the public and which pertain to
/>>/  the distribution.
/>
> I am not sure I understand the second half of this sentence.

Is it about the definition of public?

> 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

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.
(perhaps we should put it like this)

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

That will happen.
Many thanks for your contribution!

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

can you give any arguments on this?











-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20131107/94a9f689/attachment.html>