[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