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?"
_______________________________________________
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
