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

Engel Nyst engel.nyst at gmail.com
Tue Nov 12 23:00:06 UTC 2013


I will point out two more misunderstandings you make on copyright (and 
trademarks, patents) in your license and rationale. Please consider 
previous disclaimers apply.

"Intellectual property".
I will keep short and polite. The concept and your usage of it in the 
license confuse badly copyright law with trademark law, and rights 
granted by a copyright license with apparent reasons related in reality 
to trademarks use.

You can trademark the name of your project, company, suite. Then make a 
trademark policy for the use of names, for the products that satisfy 
your team of initial developers. Make the names refer to the projects of 
your team, with the rules you want and build the level/kind of 
reputation you'll want and be able to for those *names*.

This has practically nothing to do with copyright over the work, and 
rights granted under copyright law, nor with the right to make 
derivative works and distribute them. You can ask derivatives to change 
name, but your license makes more rules that belong in a trademark 
policy (and development process).

Note that trademark policy should refer to correct identification of the 
projects, I would not recommend to make over-broad rules that interfere 
with copyright licensing.

Your users can then identify your project unambiguously, and your 
developers are responsible for maintenance of the project under those 
names. That gives you the responsibility you're talking about. IMO, this 
is a social issue and one of development process in your project, more 
than a trademark issue, but you can also use legal tools for it.

It will save confusion from you and your users, if you use the 
appropriate legal tool on your *names use*, trademark law. Not copyright.

On 11/10/2013 04:41 PM, Elmar Stellnberger wrote:>
 >> > 6. The license should be compatible with the usage of patents and
 >> > trademarks without unloading that burden to the end user.
 >>
 >> I don't think it is. "Branched versions can not [...] use patents
 >> [...] in a new context unless explicit consent from the maintainers
 >> of the parent branch is given."
 >> Should I understand that consent has not been given for patents,
 >> thus the user cannot know if the maintainers have given it, or if
 >> the context is new enough for the maintainers' liking, or if they
 >> can branch on their own without being sued by the maintainers for
 >> patents?
 >
 >    Well the things with patents is that if the owner of a patent
 > wants to contribute his patent to S-FSL software then he needs to
 > give the original authors usage rights on his patent. It does however
 > not mean to contribute the patent to the community which would make
 > it at best worthless for the patent owner. However code that is
 > already being used by the community that contains a patent may still
 > be maintained. It needs permission to use the same patent in 'another
 > context'. The original authors may be restricted to give you. You can
 > not simply write new code that involves patents held by the original
 > authors, you need to ask for permission to do so.

This fails OSD. Look from the perspective of the recipient of the code. 
Let us say I work on various projects, libraries, scripts under open 
source licenses.

You're saying that if I "branch" or even rewrite an algorithm that was 
implemented under your license or under OSS licenses that "patch" code 
under your license, then you *intently* expose me to patent lawsuits.
(and you try to extend that to other OSS licenses)

That's not an open source license. And, it's among the riskier I've 
heard of. At least state up-front it's proprietary and tell people they 
have no guarantees from it. Tell them that if they read that algorithm 
and want to use that knowledge, then they're exposed intently to lawsuits.

Your license hides the lack of permission for patents use in a license 
you claim to be open source. It is not.





More information about the License-review mailing list