Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

C-FSL: a new license for software from elstel.org

10 views
Skip to first unread message

Elmar Stellnberger

unread,
Jan 21, 2016, 3:00:03 PM1/21/16
to
Dear Fellows of the Debian Legal List,

Currently most of the software available via my homepage
www.elstel.org is under S-FSL, a license which guarantees free usage and
certain modification rights but which is not a true open source license.
Debian packages would have been available for many such programs
including xchroot, confinedrv, bundsteg (something to print with an
inner margin) or debcheckroot (debsums like security tool). However as
non-OSS these programs are neither allowed to enter Debian repositories
nor could they attract many contributors. Some more software is in the
pipeline as well like a novellized Linux port of the CoAn automaton
simulator.
In order to improve the situation and make this software available to
a broader public I have once more designed a completely new license from
scratch: the so called 'Convertible Free Software License'. It shall
give the group of main contributors the additional right to re-license
like that is the case for the various BSD licenses. Organizations or
people who have not contributed to the development on the other hand
will be given no such additional right.
C-FSL is meant as a new true and strong but still comparably clear
and simple OSS license. It would be nice if you took the time to have a
look on it, what you think about it in general and how it would meet its
goals as expressed above.
The current version of the license is v0.8. It is still a draft
basically open for changes and has not been applied to any program yet.

Yours,
Elmar Stellnberger


P.S.: Here comes the current draft (v0.8) of the license:

CONVERTIBLE FREE SOFTWARE LICENSE
Version 0.8, 2016-01-21 , *** This is just a draft ***
copyright 2016, by Elmar Stellnberger
Everyone is permitted to copy and distribute verbatim copies of this
license document. You must not modify the license itself.
This license applies to any software containing a notice by the
copyright holder saying that it may be used under the terms of the
Convertible Free Software License. If a specific version number is
mentioned then usage rights include this version as well as any newer
version which will always be similar in spirit to this license. The term
Convertible Free Software license may be abbreviated as C-FSL.

1. Any work under this license comes completely without any warranty or
any kind of liability such as lost revenues, profits, harm or damage of
any kind even if the authors should have been advised of the possibility
of such harm or damage. It may be seen as research work and does not
claim for fitness to any particular usage purpose.

2. The term 'source code' applies to the preferred form that is used to
develop or apply changes to a work under this license referred to herein
as 'the work'. You are allowed to modify or change the source code if
you accept that the resulting changed work will become subject to this
license. As soon as you apply any change this is an implicit consent to
fully comply with this license and a consent that the work may be used
under this license.

3. It is your obligation that the changed version of your sources will
be available to the public for free. Available for free means that there
will be no undue hinderance in obtaining the given item like a
registration of the person who wants to download or obtain the given
item. Available for free also means that you must not charge for the
given item itself apart from the possibility to require a reasonable
charge for the physical reproduction of the data.

4. You are allowed to issue an 'automatic derivation process' on the
source code which will result in so called 'object code'. As soon as you
wanna share the object code with other people you are oblidged to make
all utilities and data necessary to obtain the object code either
availabel under C-FSL or any other open source license approved by
opensource.org. The given data and utilities need to be available to the
public for free.

5. When appyling changes to the source code you need to leave your name,
your email address and the date of your modifications so that other
people may contact you. We suggest to list all changes by contributors
either in a separate changelog file or in the header of the changed
file. Furthermore you need to give your changed version a 'marker' which
may be used to distinguish it from the upstream version when being
distributed to other people. The distributed product needs to be of the
form upstream name - dash upstream version - dash your marker optionally
followed by a version number under your control. The marker needs to be
unique, at least two letters in size. We suggest it to reflect the name
of your company or distribution.

6. You may choose to create a fork of a work under C-FSL by giving it a
completely different name. However you need to assert that people will
know that your fork is based on the original work. If your program has a
graphical user interface the whole C-FSL license as well as in case of a
fork a complete reference to the base product including email address
and web presence must be accesssible via the GUI. Otherwise a plain text
copy of this license as well as the aformentioned reference to the base
product where applicable need to be given and packed alongside the
distributed product. If your program has a comprehensive help, a manual
or info page and is a fork the base product needs to be fully referred
to there including a contact email and web presence. It does not apply
to quick or short command line help output as long as a more
comprehensive help page is also available.

7. Contributing to a work under C-FSL means that you will give a group
called the 'original authors' a consensus based right to re-license your
derived work so that it will be available under both licenses: the C-FSL
and the newly applied license. The original authors are the group of
people who have initially started to create a work. They shall be
mentioned at the beginning of the changelog or the file header of
changes. As soon as there is a consensus to do so by all original
authors the work may either be re-licensed, published as upstream
version without a marker or new people may be accepted and mentioned as
'original authors'.

8. No work under C-FSL shall be deemed part of an effective measure
under anti-circumvention laws like under article 11 of the WIPO
copyright treaty adopted on 1996-12-20 or any similar law. You must
assert that the right to use, modify, generate object code and
distribute any software under C-FSL will not be infringed by patent
claims or similar law. Every contributor grants by the act of
contributing to a work under C-FSL a non-exclusive, worldwide and
royalty-free patent license to any prospective contributor or user of
the given work applicable to all his 'essential patemt claims'. The
essential patent claims comprise all claims owned or controlled by the
contributor.

9. A work under C-FSL which is used as a component, plug-in, add-on of
another product, which is combined or which links against another work
needs either to be put under an open source license as approved by
opensource.org or it needs to be put under C-FSL as well. Usage of
proprietary libraries and kernel modules pose an exception to this rule.
There must be a functionally equivalent open source library for any
proprietary library which is required by a work under C-FSL in order to
run and execute. No such restriction applies to kernel modules. The term
'kernel' refers to the core of an operating system. Libraries which
provide operating system services use a well defined binary interface
but do not 'link' against the kernel. Libraries are separated components
which link against the given work or other components. The term
'linking' refers to the relocation of references or addresses when the
library is combined with another component in order to make the combined
aggregate executable or runnable. Such references are typically bound to
symbols which are part of the common interface between the library and
the component which the library is combined with at runtime.

10. This license is either governed by the Laws of Austria or by the
laws of any member state of the European Union where the first mentioned
original author lives or is a resident. Disputes shall be settled by the
nearest proper court given the home town or location of the first
original author. If any of the terms stated in this license were not in
accordance with the law of the country that governs this license all
other parts of the license shall remain valid.

jonathon

unread,
Jan 21, 2016, 4:40:04 PM1/21/16
to


On 21/01/2016 21:49, Elmar Stellnberger wrote:

> a broader public I have once more designed a completely new license from scratch:

What problem are you trying with this license, that other licenses don't
solve?

> 3. It is your obligation that the changed version of your sources will
> be available to the public for free.

Discrimination against fields of endeavour.

> 5. When applying changes to the source code you need to leave your name,
> your email address and the date of your modifications so that other
> people may contact you.

Fails the Desert Island Test

jonathon




signature.asc

Riley Baird

unread,
Jan 21, 2016, 4:50:02 PM1/21/16
to
Hi,

> In order to improve the situation and make this software available to
> a broader public I have once more designed a completely new license from
> scratch: the so called 'Convertible Free Software License'.

It's almost never a good idea to make your own license. And I know how
you feel, because I've played with the idea of doing the same thing.[1]

For one thing, there is the problem of license proliferation.

The other, more important thing is that if you are not a lawyer, you
have most likely done it incorrectly. There are probably many loopholes
in what you have written, especially given the length of your license.

Getting legal advice on drafting a license can be expensive, but in
comparison to actually enforcing the license, it is cheap. If you're
not willing to spend money on a lawyer now, you need to ask yourself
whether or not you're ever going to actually enforce the license. If
you don't plan on enforcing it, then it is worthless.

Before you do get legal advice, however, there are some DFSG problems
with this license. If you're still interested in making this license,
let me know and I'll tell you the ones that I've found.

Good luck,

Riley Baird

[1] My ideal license would mandate the American rule on costs and ensure
that the right to modify, distribute, etc. must be preserved, but there
would be no obligation to provide source code.

Elmar Stellnberger

unread,
Jan 21, 2016, 5:20:03 PM1/21/16
to
Hi Jonathon,

Am 2016-01-21 um 22:33 schrieb jonathon:
>
>
> On 21/01/2016 21:49, Elmar Stellnberger wrote:
>
>> a broader public I have once more designed a completely new license
from scratch:
>
> What problem are you trying with this license, that other licenses don't
> solve?
>

I have various issues about current licenses. Just see at what makes
this license pretty much different from other established licenses. Let
us discuss this in detail when the license should be fit for approval.

Am 2016-01-21 um 22:33 schrieb jonathon:
>
>> 3. It is your obligation that the changed version of your sources will
>> be available to the public for free.
>
> Discrimination against fields of endeavour.

There are licenses like the vim license which force developers to ship
their patches proactively to the upstream developers and thus possibly
to the public. If the vim license does not discriminate against a
certain field of endeavour this license will not do so either.

opensource.org says the following about it:

The license must not place restrictions on other software that is
distributed along with the licensed software. For example, the license
must not insist that all other programs distributed on the same medium
must be open-source software.

Do you really mean paragraph three here?

>
>> 5. When applying changes to the source code you need to leave your name,
>> your email address and the date of your modifications so that other
>> people may contact you.
>
> Fails the Desert Island Test

That statement should not really fail the desert island test as you can
write down your email address even on a desert island. After joining the
'main land' you can publish your work and your email will be functional
on the main land.

I just say that anyone who modifies it will have to leave his contact
address. I make no statement about the time frame in which somebody is
expected to answer. Likely for full compliance with the desert island
test however I will need to give the possibility for snail mail too as
not everyone may have temporary or permanent access to the internet.-
thx for the hint :) (* point 1 *)

This should be similar to the following statement in GPL
a) The work must carry prominent notices stating that you modified it,
and giving a relevant date.

I do personally believe there could be some problem with the desert
island test regarding the following statement though:

"It is your obligation that the changed version of your sources will be
available to the public for free."

I could add that it will only apply if you have no undue hinderence in
making it publicly available; i.e. you are currently not on a desert
island. (* point 2 *)

>
> jonathon
>

Regards,
Elmar

Elmar Stellnberger

unread,
Jan 21, 2016, 5:40:03 PM1/21/16
to
Dear Riley Baird,

Am 2016-01-21 um 22:44 schrieb Riley Baird:
> Hi,
>
>> In order to improve the situation and make this software available to
>> a broader public I have once more designed a completely new license from
>> scratch: the so called 'Convertible Free Software License'.
>
> It's almost never a good idea to make your own license. And I know how
> you feel, because I've played with the idea of doing the same thing.[1]
>
> For one thing, there is the problem of license proliferation.

Yes that is certainly a problem; though there are some attempts to
mitigate these issues:
* it can be used together with any other OSS compatible license.
* there should be no need for a separate library license like the LGPL
for the GPL as far as the license was designed correctly.

>
> The other, more important thing is that if you are not a lawyer, you
> have most likely done it incorrectly. There are probably many loopholes
> in what you have written, especially given the length of your license.

Well, once we should get the draft to be ready for approval I should
possibly try to ask someone (f.i. from my University) who has studied
law. I can not guarantee for it at the moment though.

>
> Getting legal advice on drafting a license can be expensive, but in
> comparison to actually enforcing the license, it is cheap. If you're
> not willing to spend money on a lawyer now, you need to ask yourself
> whether or not you're ever going to actually enforce the license. If
> you don't plan on enforcing it, then it is worthless.

One of the purposes of this license is that I know that I can use
patches / corrections / developments from other people. The second point
about it is that not everyone should be allowed to re-license (as
opposed to BSD). Ultimately I am not planning to sue anyone. Nonetheless
I would assume that if there is a license people will not obviously
violate it (Yes there may be unclear things about it where I do not win.).

>
> Before you do get legal advice, however, there are some DFSG problems
> with this license. If you're still interested in making this license,
> let me know and I'll tell you the ones that I've found.

Yes I am still interested.
What DFSG problems have you found?

(two about the desert island test should have been clarified in my last
mail for jonathon).

>
> Good luck,
>
> Riley Baird
>
> [1] My ideal license would mandate the American rule on costs and ensure
> that the right to modify, distribute, etc. must be preserved, but there
> would be no obligation to provide source code.
>

no obligation to provide source? - but then the sources are not 'open';
you must be joking?!


Regards,
Elmar

Ángel González

unread,
Jan 21, 2016, 8:10:02 PM1/21/16
to
On 21/01/16 22:33, jonathon wrote:
>> 5. When applying changes to the source code you need to leave your name,
>> your email address and the date of your modifications so that other
>> people may contact you.
> Fails the Desert Island Test
>
> jonathon
Maybe not.
a) The guy could have an email address created before getting stranded
b) Else he could use an email address @localhost

It would fail for new generations born in that island that only
programmed in paper, though :)

stres...@ruggedinbox.com

unread,
Jan 21, 2016, 8:30:02 PM1/21/16
to
> 3. It is your obligation that the changed version of your sources will
> be available to the public for free. Available for free means that there
> will be no undue hinderance in obtaining the given item like a
> registration of the person who wants to download or obtain the given
> item. Available for free also means that you must not charge for the
> given item itself apart from the possibility to require a reasonable
> charge for the physical reproduction of the data.

Disallowing selling of the source code makes this licence non-Free.
The GPL disallows selling of the source code as separate from the
binary, but it allows selling of the source code by itself or the
source code with a binary. Also, disallowing requiring registration
seems a bit over-restrictive, not sure if it would be considered
non-Free by Debian, though. And you misspelt hindrance.

> 4. You are allowed to issue an 'automatic derivation process' on the
> source code which will result in so called 'object code'. As soon as you
> wanna share the object code with other people you are oblidged to make
> all utilities and data necessary to obtain the object code either
> availabel under C-FSL or any other open source license approved by
> opensource.org. The given data and utilities need to be available to
> the public for free.

This might violate the 'License Must Not Contaminate Other Software'
part of the DFSG: 'The license must not place restrictions on other
software that is distributed along with the licensed software. For
example, the license must not insist that all other programs
distributed on the same medium must be free software.'. Also, 'wanna'
is informal, and you misspelt 'obliged' and 'available'.

> 5. When appyling changes to the source code you need to leave your name,
> your email address and the date of your modifications so that other
> people may contact you.

Requiring people to leave their name is a violation of their right to
privacy/anonymity. And requiring someone to leave his email address is
inconvenient; not everyone has an email address and they should not be
forced to have one to modify your software. Not sure if this is a
violation of the DFSG, though. Also, another typo: 'appyling'.

> If your program has a graphical user interface the whole C-FSL
> license as well as in case of a fork a complete reference to the
> base product including email address and web presence must be
> accesssible via the GUI.

What does it mean for the 'web presence' to be accessible via the GUI?
Does this mean I have to make it so people can click on the link and
it will open in the web browser, or does it just mean that I have to
give the web address? Also, another typo: 'accesssible'; and after
that, a misspelt word: 'aformentioned' (should be 'aforementioned').

> 7. Contributing to a work under C-FSL means that you will give a group
> called the 'original authors' a consensus based right to re-license
> your derived work so that it will be available under both licenses: the
> C-FSL and the newly applied license.

This might be a violation of 'Distribution of License': 'The rights
attached to the program must apply to all to whom the program is
redistributed without the need for execution of an additional license
by those parties.'. Also, I do not like the idea of someone being able
to change the licence of my derived work without my permission.

> 8. No work under C-FSL shall be deemed part of an effective measure
> under anti-circumvention laws like under article 11 of the WIPO
> copyright treaty adopted on 1996-12-20 or any similar law. You must
> assert that the right to use, modify, generate object code and
> distribute any software under C-FSL will not be infringed by patent
> claims or similar law. Every contributor grants by the act of
> contributing to a work under C-FSL a non-exclusive, worldwide and
> royalty-free patent license to any prospective contributor or user of
> the given work applicable to all his 'essential patemt claims'. The
> essential patent claims comprise all claims owned or controlled by the
> contributor.

I do not know what this means. Is it saying that the author is
required to give up any patents they have that are relevant to the
software? If it is saying that people are not allowed to use patented
techniques, then this is another thing making it non-Free, by
restricting redistribution. Another typo: 'patemt'.

> Libraries are separated components which link against the given work
> or other components.

I think this should be 'separate', not 'separated'.

> 10. This license is either governed by the Laws of Austria or by the
> laws of any member state of the European Union where the first mentioned
> original author lives or is a resident. Disputes shall be settled by the
> nearest proper court given the home town or location of the first
> original author. If any of the terms stated in this license were not in
> accordance with the law of the country that governs this license all
> other parts of the license shall remain valid.

What if none of the authors live in the EU?

Ángel González

unread,
Jan 21, 2016, 8:40:02 PM1/21/16
to
Some general feedback:
You pretty much are forcing that each time the text editor contents are
changed, a commit with that revision is immediatly published on the
internet.


> 4. You are allowed to issue an 'automatic derivation process' on the
> source code which will result in so called 'object code'. As soon as
> you wanna share the object code with other people you are oblidged to
> make all utilities and data necessary to obtain the object code either
> availabel under C-FSL or any other open source license approved by
> opensource.org. The given data and utilities need to be available to
> the public for free.
This means a propietary compiler cannot be used with these programs
(even if the source code are eg. standard C89).


> 5. When appyling changes to the source code you need to leave your
> name, your email address and the date of your modifications so that
> other people may contact you. We suggest to list all changes by
> contributors either in a separate changelog file or in the header of
> the changed file.
You should allow anonymous contributions, or contributing under a pen name.
See also https://en.wikipedia.org/wiki/Nymwars

Also IMHO it should allow collapsing several entries of the same author,
or even summarising the whole changelog (if the original authors only
mentioned author names, for instance).

> Furthermore you need to give your changed version a 'marker' which may
> be used to distinguish it from the upstream version when being
> distributed to other people. The distributed product needs to be of
> the form upstream name - dash upstream version - dash your marker
> optionally followed by a version number under your control. The marker
> needs to be unique, at least two letters in size. We suggest it to
> reflect the name of your company or distribution.

What about the fork of a fork of a fork?
IMHO it should be possible to replace the marker of the intermediate
company, without having to append to the version or use different name.


> 6. You may choose to create a fork of a work under C-FSL by giving it
> a completely different name. However you need to assert that people
> will know that your fork is based on the original work. If your
> program has a graphical user interface the whole C-FSL license as well
> as in case of a fork a complete reference to the base product
> including email address and web presence must be accesssible via the
> GUI. Otherwise a plain text copy of this license as well as the
> aformentioned reference to the base product where applicable need to
> be given and packed alongside the distributed product. If your program
> has a comprehensive help, a manual or info page and is a fork the base
> product needs to be fully referred to there including a contact email
> and web presence. It does not apply to quick or short command line
> help output as long as a more comprehensive help page is also available.

What if the original author prefers a simple: «This file is licensed
under C-FSL, see http://c-fsl.license/legal»?
Asking not to _remove_ license banners would be better.


> 7. Contributing to a work under C-FSL means that you will give a group
> called the 'original authors' a consensus based right to re-license
> your derived work so that it will be available under both licenses:
> the C-FSL and the newly applied license. The original authors are the
> group of people who have initially started to create a work. They
> shall be mentioned at the beginning of the changelog or the file
> header of changes. As soon as there is a consensus to do so by all
> original authors the work may either be re-licensed, published as
> upstream version without a marker or new people may be accepted and
> mentioned as 'original authors'.
This will probably lead to some ambiguity.

> 8. No work under C-FSL shall be deemed part of an effective measure
> under anti-circumvention laws like under article 11 of the WIPO
> copyright treaty adopted on 1996-12-20 or any similar law. You must
> assert that the right to use, modify, generate object code and
> distribute any software under C-FSL will not be infringed by patent
> claims or similar law. Every contributor grants by the act of
> contributing to a work under C-FSL a non-exclusive, worldwide and
> royalty-free patent license to any prospective contributor or user of
> the given work applicable to all his 'essential patemt claims'. The
> essential patent claims comprise all claims owned or controlled by the
> contributor.
"patemt"

> 9. A work under C-FSL which is used as a component, plug-in, add-on of
> another product, which is combined or which links against another work
> needs either to be put under an open source license as approved by
> opensource.org or it needs to be put under C-FSL as well.
I think you got it backwards? Did you mean "A work which is used as a
component, plug-in, add-on of a product under C-FSL"?

> Usage of proprietary libraries and kernel modules pose an exception to
> this rule. There must be a functionally equivalent open source library
> for any proprietary library which is required by a work under C-FSL in
> order to run and execute. No such restriction applies to kernel
> modules. The term 'kernel' refers to the core of an operating system.
> Libraries which provide operating system services use a well defined
> binary interface but do not 'link' against the kernel. Libraries are
> separated components which link against the given work or other
> components. The term 'linking' refers to the relocation of references
> or addresses when the library is combined with another component in
> order to make the combined aggregate executable or runnable. Such
> references are typically bound to symbols which are part of the common
> interface between the library and the component which the library is
> combined with at runtime.

This should be rewritten in a more clear way.

Also, despite the apparent spirit of the license, it probably isn't
allowing linking against eg. the libc of a propietary OS when there
isn't a free license implementing the syscalls for that OS.

stres...@ruggedinbox.com

unread,
Jan 21, 2016, 8:50:03 PM1/21/16
to
> Also, I do not like the idea of someone being able
> to change the licence of my derived work without my permission.

Actually, I changed my mind about this. I do think it is fine to allow
people to re-licence my derived work, I just do not think that it
should only be the original authors that get to do it.

Ben Finney

unread,
Jan 21, 2016, 10:40:02 PM1/21/16
to
Elmar Stellnberger <este...@elstel.org> writes:

> I have various issues about current licenses. Just see at what makes
> this license pretty much different from other established licenses.
> Let us discuss this in detail when the license should be fit for
> approval.

Please do not compound the already widespread problem of license
proliferation.

If you actually want recipients of your software to exercise software
freedom, do everyone (including yourself!) a big favour, by choosing an
existing well-understood widely-implemented free software license.

What's more, this is not the forum for discussing your own invented
license text. This forum is a service to the Debian project primarily,
and that cause is best served by strongly *discouraging* license
proliferation.

--
\ “I like to fill my bathtub up with water, then turn the shower |
`\ on and pretend I'm in a submarine that's been hit.” —Steven |
_o__) Wright |
Ben Finney

Riley Baird

unread,
Jan 22, 2016, 3:10:02 AM1/22/16
to
> > For one thing, there is the problem of license proliferation.
>
> Yes that is certainly a problem; though there are some attempts to
> mitigate these issues:
> * it can be used together with any other OSS compatible license.

For copyleft licenses, it can't, because those licenses would also have
to state that they can be used with yours.

> Ultimately I am not planning to sue anyone. Nonetheless
> I would assume that if there is a license people will not obviously
> violate it (Yes there may be unclear things about it where I do not win.).

If you're going to be relying on people's good intentions, a copyright
license isn't the best solution. A better solution would be to put the
work into the public domain, detail how you would like the work to be
used and make a request that people follow your intentions.

Francesco Poli

unread,
Jan 22, 2016, 1:50:03 PM1/22/16
to
On Fri, 22 Jan 2016 14:33:42 +1100 Ben Finney wrote:

> Elmar Stellnberger <este...@elstel.org> writes:
>
> > I have various issues about current licenses. Just see at what makes
> > this license pretty much different from other established licenses.
> > Let us discuss this in detail when the license should be fit for
> > approval.
>
> Please do not compound the already widespread problem of license
> proliferation.
>
> If you actually want recipients of your software to exercise software
> freedom, do everyone (including yourself!) a big favour, by choosing an
> existing well-understood widely-implemented free software license.
>
> What's more, this is not the forum for discussing your own invented
> license text. This forum is a service to the Debian project primarily,
> and that cause is best served by strongly *discouraging* license
> proliferation.

I would just like to say that I fully agree with Ben's comment: license
proliferation should be avoided in (almost) all cases.

What's worse in the present case is that the proposed license is
definitely non-free and has countless issues...

Hence, I can do nothing but reiterate Ben's recommendation: please
adopt an existing well-known and widely-used free software license!


--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE

Charles Plessy

unread,
Jan 23, 2016, 8:20:02 PM1/23/16
to
Le Thu, Jan 21, 2016 at 10:49:51PM +0100, Elmar Stellnberger a écrit :
>
> In order to improve the situation and make this software available to a
> broader public I have once more designed a completely new license from
> scratch: the so called 'Convertible Free Software License'. It shall give
> the group of main contributors the additional right to re-license like that
> is the case for the various BSD licenses. Organizations or people who have
> not contributed to the development on the other hand will be given no such
> additional right.

Dear Elmar,

I just wanted to add to the advice of not writing new licenses, that part of
the problem that you are trying to address can be solved by requiring a
contributor agreement before merging contributions into your software's main
line. See for instance <https://owncloud.org/contribute/agreement/>.

Have a nice Sunday,

--
Charles Plessy
Tsurumi, Kanagawa, Japan

Anthony DeRobertis

unread,
Jan 29, 2016, 5:10:02 AM1/29/16
to
On 01/21/2016 05:09 PM, Elmar Stellnberger wrote:
> There are licenses like the vim license which force developers to ship
> their patches proactively to the upstream developers and thus possibly
> to the public. If the vim license does not discriminate against a
> certain field of endeavour this license will not do so either.

The vim license doesn't require that. It gives you five different
choices of how to distribute modified versions, you're describing option
(a). Option (c) is to distribute as original + patches. Option (e) is to
use GPLv2+.

[And I concur with everyone else telling you not to write your own license.]

Elmar Stellnberger

unread,
Jan 29, 2016, 5:10:02 AM1/29/16
to
I mean the original ancient vim license of the times before GPLv2+.

Andrew Shadura

unread,
Jan 29, 2016, 5:50:02 AM1/29/16
to
On 29 January 2016 at 11:04, Elmar Stellnberger <este...@elstel.org> wrote:
> I mean the original ancient vim license of the times before GPLv2+.

But as you see they moved on from that. And for good reasons.

--
Cheers,
Andrew
0 new messages