[License-discuss] For Approval: Scripting Free Software License, Version 1.3.7.2 (S-FSL v1.3.7.2)

[Engel Nyst]

Elmar,

Your new version continues to ignore obvious issues raised on this
mailing list, with direct impact on its OSD compliance. Frankly, it
comes across as rude too.
I will take a little more time to pass roughly again through it, but I
doubt I'll do anything more, and please see suggestions below.

On 12/01/2013 10:24 PM, Elmar Stellnberger wrote:
> No patches that could be shipped use to exist for automatic
> derivation processes like f.i. the compilation of sources.
Unclear, and grammatically incorrect.

> By applying automatic derivations you consent that you will provide
> all makefiles or any other additional input which is required for the
> derivation process to the original authors under the same licensing
> and same terms as patches.
I seem to recognize here GPL's "all the source code needed to generate,
install, and (for an executable work) run the object code and to modify
the work, including scripts to control those activities". However, it's
very unclear, "derivation process" is undefined, the requirement is "to
the original authors" but "the same licensing" is S-FSL which is
somewhat contradictory. I suggest fully rewriting this or just use GPL.

> We suggest you to ship binaries and sources in different packages.
Not a licensing term. I suggest to drop this.

> 3. 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 can be read as simply attribution, or as badgeware. If your goal
here is that derivatives must display, in their UI, YOUR logos and
names, then it fails OSD #3 indirectly, because it attempts to stifle
competition.
I suggest rewriting with standard (known) wording for attribution, or
use a license that offers it already.

> You as a distributor need to let your contributors add their names,
> their email and modifications with date to the changelog. You may use
> the upstream changelog if present or your own one as long as it stays
> accessible upstreams.
This is mostly useless. Many open source projects don't use a manual
changelog, but that's because the log of the vcs shows all names and
contributions with a simple command. It's simple and less prone to
misses and human errors.

> Any derived work must carry the name of the distributor, vendor or
> the product in its name (or a unique shorthand for it) directly
> preceded by the original unchanged final upstream name of the
> software and its version at the beginning.

This is very unclear. "Derived work" is undefined, and this naming rule
is in contradiction with section 6. I can guess what you're actually
trying to achieve, but it's a very poor idea to include such development
policy in a license. The result is unreadable and contradictory at best,
and probably rejectable by the target Linux distributions to which your
license dictates how to name packages.

> For automatic derivations a tag concerning the derivation process or
>  its output like f.i. the machine architecture would be appropriate.
See above. I think Linux distributions know how to do their packaging.

> 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 probably fails OSD #1.

If you read carefully Artistic license (even 1.0), you'll see that it
explicitly adds that fees for support, fees for aggregate distributions,
and others, are allowed. Even so, Artistic 1.0 barely passes this
criterion (IMHO). But any less doesn't pass.

> As far as you are not a public distributor you are obliged to send a
>  copy of your patches to the original authors referred to herein as
> the authors of the first version of the program as being listed in
> the changelog or program header whenever you publish or exchange your
> patches with other people. If you have some work in progress you are
> obliged to send out bundled patches once at least every month.
This fails OSD. See previous emails as to why. I suggest to give it up.
People contribute if they want to, not because they're forced by a
license. Your only results here will be a) people won't bother with your
projects at all; b) the license is NOT Open Source.

> This is to assert the availability and recognition of patches at
> least by the original authors or branch maintainers; a condition
> which must be held even if you agree not to actively 'send' or
> 'forward' your patches.
'Send' and 'forward' undefined and unclear.

> For bundled patches you do not need to ship intermediate patches or
> dead end patches provided that the final derived work can be restored
> by applying all distributed patches to the original in an order
> indicated by the patch providers. Something is considered a dead end
> patch if it leads to a broken program, the result is not usable and
> you do not plan to continue to work on it.
This is meaningless in a license. So if a program has bugs or someone
(who?) deems it unusable, then a condition doesn't apply?
I suggest to drop all this. Write your development process separately.

> The original authors will finally have to resolve whether to
> incorporate your patches or not into future versions.
This is not a licensing term.

> Any contributor has the right to be listed with full name, patching
> date and email address in the changelog of this program.
Copyright law gives the right to any author of a work (based on another
or not alike) to have authorship recognized.

You don't need to state it in a license.

> 5. By distributing patches you do also consent that the original
> authors may incorporate your patches into future versions of this
> program.
You don't need to "consent" to such thing. The maximum the licensee
(should) need to do, is to abide to a set of conditions when they
distribute derivative works (in copyright law sense). Those conditions
may have the consequence that original authors or derivative works
authors will simply have the right to incorporate patches, thanks to the
/license/ of the derivative works.

> 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;
Under different licensing? This condition alone is off-putting, and may
make sure you'll never have any reasonable number of contributors to
your projects. I strongly suggest to reconsider and rescind this.

> 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. 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.
Unworkable under copyright law. Again, all you need is assured if the
only condition on derivative works is the license they should be
distributed under. That would allow you to achieve your goal (you can
use and incorporate that work), but in a legal and more decent way.

Writing a "license" when you don't grasp the basics of copyright law is
frankly, a very bad idea.

> The propagation of rights extends up to usage rights for patents used
> in derived works including the transferability of usage rights to
> child and parent branches;
See above.

> Trademarks used in derived works may only be used by the original
> authors to describe the origin of newly incorporated features if they
> wish to do so.
Right, but this is within the scope of the trademark license of the
derivative works authors. No need to state it in this license.

> 6. 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;
This fails OSD. See former emails.

> 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.
"Should be indicated" is not a licensing permission, condition or
obligation. It serves no purpose, other than you listing your wishes
from your project's way of working. It does not belong in a license.

Write your project's procedures and rules, not a license.

> If S-FSL 'with free branching' is explicitly specified in the license
> terms then you may choose to develop a different branch of this
> program any time you want given that your new branch serves a new
> purpose or is sufficiently different so that the original authors do
> choose not to re-integrate your branch at least for two patching
> periods.
See above. Conditioning the forking on the existence of "a new purpose"
or "original authors do choose" fails OSD #3, #7.

> Separate branches have another base name and their own versioning
> scheme.
Restrictions on name are ok, but on versioning scheme they does not seem
meaningful.

> Branched versions can not re-publish under a different license or use
> patches, patents or other intellectual property of the maintainers of
> the parent branch in a new context unless explicit consent from the
> maintainers of the parent branch is given.
If this /would/ be open source software, then anyone can use "patches"
in the contexts they need, without explicit consent from anyone.
This fails OSD #3, #7. See former emails.

> Hence the propagation of rights as described in the previous
> paragraph does automatically work in upstream direction only.
As noted, proprietary.

> The maintainers of the original product or any of its branches may
> any time transfer their rights to a new or extended group of people.
This is almost always true under the law, assuming they haven't
sold/given their rights already. Also, in some jurisdictions, copyright
assignment is not possible.

This does not belong in a license.

> The new copyright holders can thereupon act as the original authors
> or issuers of the branch called branch maintainers.
Ditto. Write your project's procedures separately.

> 8. Public distributions have the advantage of not having to ship
> patches proactively to the original authors or copyright holders.
> This does not prevent the same software including its adherent
> materials to be additionally available at cost or privately
> somewhere else as long as public availability remains guaranteed at
> a reasonable level (f.i. download of the free parts of the
> distribution within some days.).
Unclear. Also, using undefined abbreviations like "f.i." is a bad idea.
I guess it means "for instance", but I don't know, and no one should
assume it.

> A public distribution may any time also ship with adherent materials
>  at cost such as documentation, support or additional software as
> long as it remains available to the public free of charge also
> without these adherent materials.
Unclear. This seems to repeat the above.

> However there must not be any undue hindrance in obtaining the
> distribution requiring special knowledge not known by users
> technically experienced in the field of the public software shipped
> with the distribution and the software it depends on.
Again, my best guess is that you attempt to draft here some
GPL-inherited idea of preventing tricks from hiding sources. I strongly
suggest to just use GPL then.

> 9. Software under S-FSL that should either be used as or in a
> component, plug-in or add-on of 'non public' or so called
> 'additional' software or whenever software under S-FSL is required
> to run such 'non public' or 'additional' software then S-FSL imposes
> the restriction that the additional or non public software must also
>  either be made available under an OSS-compliant license and free of
>  charge to the public or that you will need to pay for the software
> under S-FSL being incorporated.
I'm not sure this is grammatically correct.

My best guess here is that you attempt, again, to draft some
understanding of GPL as preventing "use" unless the software "using" it
is available under GPL or open licenses. Your understanding is wrong in
a few points, one of which being that it refers to "non-public" (which
seems to submit private/personal/intra-organization use to obligations
to license and do so publicly). This would be incompatible with OSD. But
the sentence is almost incomprehensible. I suggest to rewrite it
completely or just use an existing license.

> 10. If any of the terms about sharing patches should be deemed
> invalid modifying the software and sharing patches shall no more be
> granted from the time of the realization of the decision of the court
> on in the given country or region; already shared and incorporated
> patches are still subject to the given terms and conditions as far as
> deemed valid; the license needs to be re-issued then in order to
> allow further modifications and sharing of patches again.
Seems grammatically incorrect. Regardless, this provision is weird. Are
you saying that your intention is make the software all-locked-down
proprietary, when some clauses are invalid? They're already invalid, by
the way, see above. But this blocks any and all distribution, and forces
anyone using this license to receive another license from upstream
(which might not exist any longer). This fails OSD, #1, #3, #7 and
probably more.

Suggestions:

1) use a real license.

This text is poorly worded, and it seems at times more like an
expression of your understanding in plain words of laws and licensing
mechanisms, than a license. Unfortunately, even that understanding is
incorrect.

This license also does not achieve your goals as stated by you in some
former emails. For example, you stated somewhere that you want
copyright privilege in order to miraculously prevent a developer from
hijacking the project. However, your license creates /exactly/ the
opportunity for a badly intended developer to shut down any competition
(they will only state it's not "new enough" or something) and mess up
the upstream project. No one can possibly resurrect it, legally and
safely, because this license keeps it under tight copyright control.

2) submit the licensing wanted (this license or your goals) to feedback
from people who work with you, publicly.

So far, everyone on more mailing lists, multiple threads, explained to
you why this is proprietary, not OSS, and nothing in it is even
addressing any new workable (OSS) goals you can't achieve with other
licenses; and you continued to ignore them and hand-wave their concerns
in this version again. If that doesn't tell you something, that's too
bad; then look around for the places where you want contributors from,
and see if anyone helps you draft it. It would allow to transform the
license so that it addresses some need of more than one company/person.


-- 

~ "Excuse me, Professor Lessig, but may I ask you to sign this CLA, so 
that we have legally your permission to distribute your CC-licensed words?"