Re: tomboy-ng package with non standard license.

[David Bannon]

OK, thats great, I thank you and the other people who contributed to
this outcome very sincerely. It was a lot harder that I expected and I
have learnt quite a lot !

And, of course, I know 'it' is not over yet !

Thanks Folks .

David

On 16/11/20 8:37 pm, Paul Wise wrote:
> On Mon, 2020-11-16 at 15:52 +1100, David Bannon wrote:
>
>> Hunspell to Pascal Bindings, the saga continues
>>
>> OK, I have now separated out the Hunspell 'bindings' from my hunspell
>> unit. 
> Excellent, I think that concludes the legal proportion of the saga :)
>



signature.asc
Description: OpenPGP digital signature

Re: tomboy-ng package with non standard license.

[Paul Wise]

On Mon, 2020-11-16 at 15:52 +1100, David Bannon wrote:

> Hunspell to Pascal Bindings, the saga continues
> 
> OK, I have now separated out the Hunspell 'bindings' from my hunspell
> unit. 

Excellent, I think that concludes the legal proportion of the saga :)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: tomboy-ng package with non standard license.

[David Bannon]

Hunspell to Pascal Bindings, the saga continues

OK, I have now separated out the Hunspell 'bindings' from my hunspell
unit. 

The bindings file consists nothing more that the Hunspell license
statement and a handful of slightly rearranged function prototypes from
hunspell.h. This file is completely subject to the Hunspell license as I
don't consider I have added anything to its content.

The binding file is 'included' into the actual hunspell.pas Object
Pascal file that builds the hunspell Object Pascal unit. hunspell.pas
has exactly the same BSD Clear license most of the tomboy-ng code now has.

So, I now refer you to -

The updated copyright file -
https://github.com/tomboy-notes/tomboy-ng/blob/master/debian/copyright

The bindings file -
https://github.com/tomboy-notes/tomboy-ng/blob/master/source/hunspell.inc

The hunspell unit -
https://github.com/tomboy-notes/tomboy-ng/blob/master/source/hunspell.pas


Incidentally, I have also 'published' the hunspell pascal binding file
(and the hunspell pascal unit) in a stand alone git repository,
https://github.com/davidbannon/hunspell4pas, and removed the unlicensed
code from the Lazarus wiki, pointing instead to the github page. This
should prevent other Lazarus users from making the same mistake.

Thanks for your help.

David






signature.asc
Description: OpenPGP digital signature

Re: tomboy-ng package with non standard license.

[David Bannon]

Hunspell to Pascal Bindings

Given that I only need five functions from this library, in reality, all
I would do is read through the .h file and write the necessary code
directly.  I need (ie prefer) it to be a Class, so the output from h2pas
would require a measure of rewriting anyway.

(h2pas delivers the equivalent of C code, I want the equivalent of C++
code, Object Pascal)

I have just had a quick look at the hunspell.h file, its a 30 minute job
of copy and paste, changing the C syntax to Pascal and rearranging into
a class. I would put just the bindings into a hunspell.inc Pascal
Include file to keep the "hunspell.h inspired" content away from my own
code that actually accesses it.  Will be five short lines, maybe a few
more if I can understand the other functions (that I am not using)
sufficiently.

I consider this all very artificial, if anyone is to ask me to prove I
was not guided by the original hunspell.pas file, I cannot ! I have read
and am quite familiar with the original 2013 hunspell.pas file, I will
clearly be guided by what I know is in there, its not, in any way, a
Clean Room write. In fact, in the past, I have looked at how its done in
the original hunspell.pas file to see how to do something else, similar
but unrelated.

But it will end up with the hunspell license (unchanged). The only
hunspell code I will look at is the hunspell.h file, I won't be making
any changes to it but need to point to it on Hunspell's github page. And
add the somewhat wordy license statement to my debian/copyright file.
Both will appear on my tomboy-ng github page.

It may be appropriate to make the binding inc file (and some of my
spelling code) available in a stand alone repo to avoid other FreePascal
users going down the path I have.

This will all happen when time permits.

David





On 12/11/20 11:06 am, Paul Wise wrote:
> On Thu, 2020-11-12 at 09:25 +1100, David Bannon wrote:
>
>> Are there any further thoughts on this topic ? 
> It sounds like FreePascal wiki user Graham created parts of the
> spelling.pas file, is presumably the copyright holder (unless their
> employer owns it), released it without specifying a license, which
> means it was "all rights reserved" and then various other people
> modified and re-released it, in violation of copyright law (since they
> presumably did not have a license to do so) and eventually it ended up
> in the tomboy-ng project, also in violation of copyright law.
>
> There is the additional wrinkle that hunspell is licensed under the MPL
> and GPL licenses, presumably the header Graham started with was under
> the same licenses and what Graham released was clearly a derivative
> work of the hunspell headers, with the additional work copyright by
> Graham, so the result would have to comply with one of those licenses,
> but as far as I can tell, Graham stripped the licenses off and also did
> not include the "source code", in violation of both of these licenses.
>
> I think the solution here would be for you to strip out the code you
> copied from Graham and other's work and then repeat the h2pas process,
> bearing in mind the requirements of both the GPL and the MPL, the
> important ones here are to preserve the license, preserve copyright
> holder information and to preserve the "source code".
>
> What the source code is for this work depends on how you would modify
> the hunspell Pascal bindings. If (for example when updating to a new
> hunspell API) you modify the bindings by updating the C headers and
> then re-running h2pas, then you need to preserve the C headers in your
> source code alongside spelling.pas but if you would only ever modify
> the bindings by editing spelling.pas directly, then you can discard the
> C headers but you still need to use the same licenses in the hunspell
> bindings. In the latter case it would be a good idea to keep the
> bindings in a separate file so it can have a separate license header.
>



signature.asc
Description: OpenPGP digital signature

Re: tomboy-ng package with non standard license.

[Paul Wise]

On Thu, 2020-11-12 at 09:25 +1100, David Bannon wrote:

> Are there any further thoughts on this topic ? 

It sounds like FreePascal wiki user Graham created parts of the
spelling.pas file, is presumably the copyright holder (unless their
employer owns it), released it without specifying a license, which
means it was "all rights reserved" and then various other people
modified and re-released it, in violation of copyright law (since they
presumably did not have a license to do so) and eventually it ended up
in the tomboy-ng project, also in violation of copyright law.

There is the additional wrinkle that hunspell is licensed under the MPL
and GPL licenses, presumably the header Graham started with was under
the same licenses and what Graham released was clearly a derivative
work of the hunspell headers, with the additional work copyright by
Graham, so the result would have to comply with one of those licenses,
but as far as I can tell, Graham stripped the licenses off and also did
not include the "source code", in violation of both of these licenses.

I think the solution here would be for you to strip out the code you
copied from Graham and other's work and then repeat the h2pas process,
bearing in mind the requirements of both the GPL and the MPL, the
important ones here are to preserve the license, preserve copyright
holder information and to preserve the "source code".

What the source code is for this work depends on how you would modify
the hunspell Pascal bindings. If (for example when updating to a new
hunspell API) you modify the bindings by updating the C headers and
then re-running h2pas, then you need to preserve the C headers in your
source code alongside spelling.pas but if you would only ever modify
the bindings by editing spelling.pas directly, then you can discard the
C headers but you still need to use the same licenses in the hunspell
bindings. In the latter case it would be a good idea to keep the
bindings in a separate file so it can have a separate license header.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: tomboy-ng package with non standard license.

[David Bannon]

Are there any further thoughts on this topic ? 

I would really like to either get on with it or advise my users its not
possible.

David


-  Message dated 2020/11/02 --


On 2/11/20 11:19 am, Paul Wise wrote:
> The KControls README and issues shows there are several users, but of
> course it is unlikely they would want their software in Debian.

I get the impression that most KControls users are Windows Delphi users,
not likely to seek out Debian.  And as note previously, the KControls
license was unacceptable to Debian.  I have been maintaining the KMemo
page page on freepascal wiki,  neither than nor the KControls page has
seen many other contributors. Sad.


> Since the hunspell library headers can change over time, adding support
> for new functions, constants etc, that sounds like something that
> should be generated at build time rather than copied into the source,


Hunspell have a pretty honest backwards compatible policy, a good thing
because Macs seem to arrive, "out of the box" with a very old version.
So, its not in my interest to follow the newest version.  Thats one of
the things you need to observe when building cross platform. Can be very
frustrating.


> can Lazarus convert the installed headers into .pas at build time? Or

No, its an iterative process, you do a run, manually edit the .h files
(actually a copy of them) and try again, I have done it with other
libraries, not hard by tedious. And in this case, no benefit.


> easily support other spelling libraries like nuspell too.

Spelling is optional (to configure), relatively difficult for Windows
users, Mac users can be divided in those who consider it trivial and
those who would not even consider it.  Most Linux systems have hunspell
'out of the box' so, for now, I am happy to leave it there. But things
can change.

Davo

Re: tomboy-ng package with non standard license.

[David Bannon]

On 2/11/20 11:19 am, Paul Wise wrote:
>
> The KControls README and issues shows there are several users, but of
> course it is unlikely they would want their software in Debian.

I get the impression that most KControls users are Windows Delphi users,
not likely to seek out Debian.  And as note previously, the KControls
license was unacceptable to Debian.  I have been maintaining the KMemo
page page on freepascal wiki,  neither than nor the KControls page has
seen many other contributors. Sad.


> Since the hunspell library headers can change over time, adding support
> for new functions, constants etc, that sounds like something that
> should be generated at build time rather than copied into the source,


Hunspell have a pretty honest backwards compatible policy, a good thing
because Macs seem to arrive, "out of the box" with a very old version.
So, its not in my interest to follow the newest version.  Thats one of
the things you need to observe when building cross platform. Can be very
frustrating.


> can Lazarus convert the installed headers into .pas at build time? Or

No, its an iterative process, you do a run, manually edit the .h files
(actually a copy of them) and try again, I have done it with other
libraries, not hard by tedious. And in this case, no benefit.


> easily support other spelling libraries like nuspell too.

Spelling is optional (to configure), relatively difficult for Windows
users, Mac users can be divided in those who consider it trivial and
those who would not even consider it.  Most Linux systems have hunspell
'out of the box' so, for now, I am happy to leave it there. But things
can change.

Davo

Re: tomboy-ng package with non standard license.

[Paul Wise]

On Sun, 2020-11-01 at 18:17 +1100, David Bannon wrote:

> It is possible to build C style Libraries with FeePascal units but it
> not efficient with time, space or performance in practice.

Thanks for the info. 

> also wanting to use KControls but there is not.

The KControls README and issues shows there are several users, but of
course it is unlikely they would want their software in Debian.

https://github.com/kryslt/KControls#important-info-for-contributors

   ... the package is already heavily used by me and others!

https://github.com/kryslt/KControls/issues

BTW: Debian's information about "vendoring" or embedded copies is here:

https://wiki.debian.org/EmbeddedCopies

> Just the bindings to the hunspell library.  Every Lazarus install
> includes a tool, h2pas, that will generate such a set of bindings from
> the relevant .h files with little effort. As such, I would not expect
> anyone to claim copyright to the result.

Since the hunspell library headers can change over time, adding support
for new functions, constants etc, that sounds like something that
should be generated at build time rather than copied into the source,
can Lazarus convert the installed headers into .pas at build time? Or
does the generated .pas file need editing in order to work properly?
Generating the bindings at build time that would enable you to more
easily support other spelling libraries like nuspell too.

https://nuspell.github.io/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: tomboy-ng package with non standard license.

[David Bannon]

On 30/10/20 9:17 pm, Paul Wise wrote:
> On Fri, Oct 30, 2020 at 7:24 AM David Bannon wrote:
>
>>  of necessity, the source package contains some third party code called 
>> KControls, 
> I'd like to hear more about what "of necessity" means.

This has been discussed at some length, I really don't know why I have
not created an article on the subject on the FreePascal Wiki. Firstly, I
do recognize that the way it works is different from what a lot of
people are used to. Its not really inherent in the Language itself but
it is most certainly inherent in how we work with the Free Pascal and
Lazarus tool kit.

It is possible to build C style Libraries with FeePascal units but it
not efficient with time, space or performance in practice.  People who
make  Units for others to use almost always distribute the source.
Lazarus, the IDE, has built in tools that import such source based
units, there is an excellent tool, the Online Package Manager in the IDE
that lets you install one of several hundred (?) such units with a
couple of clicks.  When you do so, the Package is compiled but so too is
the whole IDE !  When you are using it, you can browse directly from
your own source into the source of an 'external' package, even make
changes as you go.

Free Pascal people believe that code needs to be not just free but
accessible too !

That said, it would be possible to make KControls into a Library but it
will be a lot of work, work that I am not willing to undertake, it would
make for a much bigger install and would probably make for a slower
application.  I guess it would be a different situation if there were
someone else out there also wanting to use KControls but there is not.

The Free Pascal Compiler and linker are quite efficient, my application
is about 5Meg when stripped.  It replaces the original Tomboy Notes,
that was also about 5Meg (from memory) but that depends on the huge Mono
runtime !  tomboy-ng is, for most operating systems, just that 5Meg.

As you suggest, it would be possible to build a stand alone deb for
KControls source. (But I am not using all of KControls, only KMemo,
maybe a quarter of the whole package).   I really cannot imagine where a
standalone KControls deb would put the source so that a later installed
tomboy-ng source deb would find it at compile time. Something that
fragile and hard to maintain is not something I would be interested in
doing.


>> source/spelling.pas, has some code that is, again, pascal libary
>> bindings, this time to hunspell. This code has been pasted in several
>> forums etc, over a number of years without attribution. As such, I
>> consider it public domain. It makes up only a small part of the file. I
>> have therefore stamped that file too as BSD Clear.
> As far as I know the public domain doesn't work this way. Code that is
> floating around is still under copyright (since that lasts a long time
> by default), people are just ignoring that fact and pretending they
> are allowed to use it. In some jurisdictions it is possible to
> explicitly release code into the public domain but in many that isn't
> possible. The CC0 license was created as a way to release things into
> the public domain where possible and give a very permissive license
> where that is not possible.
>
> https://creativecommons.org/share-your-work/public-domain/cc0
>
> Which part of the file are you talking about here?


Just the bindings to the hunspell library.  Every Lazarus install
includes a tool, h2pas, that will generate such a set of bindings from
the relevant .h files with little effort. As such, I would not expect
anyone to claim copyright to the result.

Earliest reference I can find is
https://forum.lazarus.freepascal.org/index.php?topic=20401.0 where
FreePascal wiki user Graham posted what was, I suspect, an early
version.  The forum rules state -

"You also agree not to post any copyrighted material unless you own
the copyright or you have written consent from the owner of the
copyrighted material"

Graham's snippit contains the binding and some pretty standard, template
stuff.

Further reference to current usage is here -
https://wiki.freepascal.org/spelling


David

Re: tomboy-ng package with non standard license.

[Paul Wise]

On Fri, Oct 30, 2020 at 7:24 AM David Bannon wrote:

> OK folks, reminding Paul, Daniel, Tobias and Philipp of the discussion
> that took place over the last couple of months about getting tomboy-ng
> into the Debian repos.  The issue at that stage was that, of necessity,
> the source package contains some third party code called KControls, the
> license of which was deemed to be unsuitable for Debian.

I'd like to hear more about what "of necessity" means.

I assume it is related to the comment on the static linking wiki page
about FreePascal. Normally I would assume that static linking doesn't
mean embedded code copies, but perhaps it also means that FreePascal
doesn't support the concept of static libraries like C does (.a
files)? In that case, the solution would be something like what the
Rust/Golang packages in Debian do, .deb packages that contain source
code, which other packages can then build-dep on and use the source
code from.

https://wiki.debian.org/StaticLinking#FreePascal

OTOH, from my research it seems like FreePascal supports writing a
dynamic library in Pascal and loading it from a Pascal or non-Pascal
programs at runtime.

https://wiki.freepascal.org/macOS_Dynamic_Libraries
https://wiki.freepascal.org/shared_library

> TK has completely changed the license to now be the BSD 3-Clause Clear
> License. All (relevant) files are so marked.  I have changed the license
> of my code to match (to simplify things).

Excellent outcome, thanks for all your work on this.

> source/libnotify.pas (bindings to libnotify) is GPL2, thats documented
> in debian/copyright, this is, I believe a non-issue.

Correct.

> source/spelling.pas, has some code that is, again, pascal libary
> bindings, this time to hunspell. This code has been pasted in several
> forums etc, over a number of years without attribution. As such, I
> consider it public domain. It makes up only a small part of the file. I
> have therefore stamped that file too as BSD Clear.

As far as I know the public domain doesn't work this way. Code that is
floating around is still under copyright (since that lasts a long time
by default), people are just ignoring that fact and pretending they
are allowed to use it. In some jurisdictions it is possible to
explicitly release code into the public domain but in many that isn't
possible. The CC0 license was created as a way to release things into
the public domain where possible and give a very permissive license
where that is not possible.

https://creativecommons.org/share-your-work/public-domain/cc0

Which part of the file are you talking about here?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: tomboy-ng package with non standard license.

[David Bannon]

OK folks, reminding Paul, Daniel, Tobias and Philipp of the discussion
that took place over the last couple of months about getting tomboy-ng
into the Debian repos.  The issue at that stage was that, of necessity,
the source package contains some third party code called KControls, the
license of which was deemed to be unsuitable for Debian.

TK has completely changed the license to now be the BSD 3-Clause Clear
License. All (relevant) files are so marked.  I have changed the license
of my code to match (to simplify things).

There is two remaining matters in 'my' code. Firstly,
source/libnotify.pas (bindings to libnotify) is GPL2, thats documented
in debian/copyright, this is, I believe a non-issue. Secondly,
source/spelling.pas, has some code that is, again, pascal libary
bindings, this time to hunspell. This code has been pasted in several
forums etc, over a number of years without attribution. As such, I
consider it public domain. It makes up only a small part of the file. I
have therefore stamped that file too as BSD Clear.

So, in my (uneducated) opinion, licensing issues are behind us.  Your
thoughts would be appreciated.

https://github.com/tomboy-notes/tomboy-ng

I have to say I am very grateful for the help and coaching I have had
through this process, very !

Davo



On 12/9/20 11:29 am, Paul Wise wrote:
>
> This license contains an implicit permission to modify, but it would
> be much better to make it explicit. If you are going to go to the
> trouble of asking upstream to get permission from all the copyright
> holders to change the license, it would be much better to just switch
> to a standard license (GPL, MIT or BSD) though.
>

Re: tomboy-ng package with non standard license.

[Paul Wise]

On Fri, 2020-09-25 at 09:10 +1000, David Bannon wrote:

> However, I don't believe it will help. I think TK is concerned about
> conventional licenses allowing someone to remove his name from the
> package, ship it as its own. Near as I can tell, thats permitted if some
> changes are made. Happened to me...

FTR, conventional Free Software licenses don't allow removal of
information about copyright holders. BSD 3-clause license requires
(clause 1) retaining info about copyright holders, so does the Apache
2.0 license (clause 4a) and the GNU GPLv3 (clause 4).

So I don't know enough about your situation, but I doubt that what
happened to you was allowed by the license. Of course, enforcing the
license against violators is costly in modern societies, especially if
they are have more economic power than you.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: tomboy-ng package with non standard license.

[Tobias Frost]

On Fri, Sep 25, 2020 at 09:10:23AM +1000, David Bannon wrote:
> I thank you for that Tobias, a positive move !
> 
> However, I don't believe it will help. I think TK is concerned about
> conventional licenses allowing someone to remove his name from the
> package, ship it as its own. Near as I can tell, thats permitted if some
> changes are made. Happened to me...
> 
> It comes down to what you are actually copyrigth-ing, the syntax, the
> overall structure, solving a problem in a particular way ..
> 
> I accept that, believe in the open source world, thats how it should be.
> TK does not.
> 
> Thanks for you help.

That's something: https://github.com/kryslt/KControls/issues/29

David, probably now would be the perfect moment to provide TK with an PR
to change e.g to BSD and CC0 the remaining ones…

Cheers,

--
tobi

Re: tomboy-ng package with non standard license.

[David Bannon]

I thank you for that Tobias, a positive move !

However, I don't believe it will help. I think TK is concerned about
conventional licenses allowing someone to remove his name from the
package, ship it as its own. Near as I can tell, thats permitted if some
changes are made. Happened to me...

It comes down to what you are actually copyrigth-ing, the syntax, the
overall structure, solving a problem in a particular way ..

I accept that, believe in the open source world, thats how it should be.
TK does not.

Thanks for you help.

Davo

On 24/9/20 7:12 pm, Tobias Frost wrote:
> Hi David,
>
> I just responded to the ticket in github:
>
> Let me briefly chime in… I was interacting on the debian-legal thread about
> this topic:
>
>   @kryslt it would be very helpful if you could confirm that your 
> interpreation
>   of you license also expliclitly allows modification and distribution. 
>
>   Custom licenses are always problematic, because of the know reasons 
> (wetted by
>   layers*, compatiblities with other licenses, license proliferation…), 
> so may I
>   suggest that you look into some standard licensing and either change it 
> towards
>   or possible just dual-license it?  Looking at the license you have 
> currently,
>   may I suggest you look into BSD-3-clause?
>   (https://choosealicense.com/licenses/bsd-3-clause-clear/) (If this is 
> OK for
>   you, I'd be very happy to provide an PR to change the license headers.)
>
>   You write in your README that all files without notice are public 
> domain.
>   Please note that PublicDomain is not a thing world wide.  For example, 
> here in
>   Germany, a author _cannot_ legally waive its own copyright, so would 
> you mind
>   to change this sentence to "If there is none, the code is licensed 
> under CC0."?
>   (https://choosealicense.com/licenses/cc0-1.0/ ) It's the PublicDomain
>   equivalent, but written to be legally ok worldwide.
>
>   (There is a nice chart at https://choosealicense.com/appendix/ I find 
> very
>   helpful)
>
>   * IANAL, but I think your liability clause is too short and "forgets" 
> some
> case… See the BSD-3
>
>   Thanks for considering! And sorry for possibly annoying you. License 
> stuff is
>   unfortunatly boring, but required. We'd like to see your work in Debian 
> through
>   tomboy-ng, but the license could be a blocking point. I hope you can 
> help
>   untangling it…
>
>   Cheers.  tobi (with his Debian Developer hat on)
>
> Lets see if that helps.
>
> On Thu, Sep 24, 2020 at 09:37:57AM +1000, David Bannon wrote:
>> Hi Folks, time we resolved this question about tomboy-ng and its use of
>> the KControls build time library.  Its now ten days since I wrote to TK,
>> the kcontrols author, asking if he would consider a more liberal
>> license. I have not had an answer and think we can assume I won't get one.
>>
>> The known facts -
>>
>> tomboy-ng needs the kcontrols source files at build time. Such src
>> libraries normally target an IDE and are unsuited to standalone debian
>> packaging. So a sunset of kcontrols needs to be shipped with the
>> tomboy-ng SRC package.
>>
>> kcontrols has a license that while not preventing changes or
>> redistribution, it does not explicitly grant permission to do so.
>>
>> TK has clearly, on the public record  stated that my proposed use of
>> kcontrols is acceptable. This was in answer to a question that stated I
>> would use a subset of kcontrols and distribute in a debian SRC package.
>> https://github.com/kryslt/KControls/issues/27 - "It is acceptable, thank
>> you for asking."
>>
>> TK still maintains kcontrols but has made it clear he does not have the
>> time to make changes he finds unnecessary.
>> tomboy-ng could use an alternative to kcontrols but this would break its
>> cross platform commitment. This would gravely affect existing users.
>>
>> My question to the debian legal team is "Given TK's clear statement that
>> the proposed use is acceptable, but noting the shortcomings in its
>> license, would you recommend I abandon this project or not ?"
> (You won't get an authoritive answer here, as this is ftp-masters realm)
> IMHO the license is border line, and it would be much better if the rights
> we care about are explicitly granted. 
>

Re: tomboy-ng package with non standard license.

[Tobias Frost]

Hi David,

I just responded to the ticket in github:

Let me briefly chime in… I was interacting on the debian-legal thread about
this topic:

@kryslt it would be very helpful if you could confirm that your 
interpreation
of you license also expliclitly allows modification and distribution. 

Custom licenses are always problematic, because of the know reasons 
(wetted by
layers*, compatiblities with other licenses, license proliferation…), 
so may I
suggest that you look into some standard licensing and either change it 
towards
or possible just dual-license it?  Looking at the license you have 
currently,
may I suggest you look into BSD-3-clause?
(https://choosealicense.com/licenses/bsd-3-clause-clear/) (If this is 
OK for
you, I'd be very happy to provide an PR to change the license headers.)

You write in your README that all files without notice are public 
domain.
Please note that PublicDomain is not a thing world wide.  For example, 
here in
Germany, a author _cannot_ legally waive its own copyright, so would 
you mind
to change this sentence to "If there is none, the code is licensed 
under CC0."?
(https://choosealicense.com/licenses/cc0-1.0/ ) It's the PublicDomain
equivalent, but written to be legally ok worldwide.

(There is a nice chart at https://choosealicense.com/appendix/ I find 
very
helpful)

* IANAL, but I think your liability clause is too short and "forgets" 
some
  case… See the BSD-3

Thanks for considering! And sorry for possibly annoying you. License 
stuff is
unfortunatly boring, but required. We'd like to see your work in Debian 
through
tomboy-ng, but the license could be a blocking point. I hope you can 
help
untangling it…

Cheers.  tobi (with his Debian Developer hat on)

Lets see if that helps.

On Thu, Sep 24, 2020 at 09:37:57AM +1000, David Bannon wrote:
> Hi Folks, time we resolved this question about tomboy-ng and its use of
> the KControls build time library.  Its now ten days since I wrote to TK,
> the kcontrols author, asking if he would consider a more liberal
> license. I have not had an answer and think we can assume I won't get one.
> 
> The known facts -
> 
> tomboy-ng needs the kcontrols source files at build time. Such src
> libraries normally target an IDE and are unsuited to standalone debian
> packaging. So a sunset of kcontrols needs to be shipped with the
> tomboy-ng SRC package.
> 
> kcontrols has a license that while not preventing changes or
> redistribution, it does not explicitly grant permission to do so.
> 
> TK has clearly, on the public record  stated that my proposed use of
> kcontrols is acceptable. This was in answer to a question that stated I
> would use a subset of kcontrols and distribute in a debian SRC package.
> https://github.com/kryslt/KControls/issues/27 - "It is acceptable, thank
> you for asking."
> 
> TK still maintains kcontrols but has made it clear he does not have the
> time to make changes he finds unnecessary.

> tomboy-ng could use an alternative to kcontrols but this would break its
> cross platform commitment. This would gravely affect existing users.
> 
> My question to the debian legal team is "Given TK's clear statement that
> the proposed use is acceptable, but noting the shortcomings in its
> license, would you recommend I abandon this project or not ?"

(You won't get an authoritive answer here, as this is ftp-masters realm)
IMHO the license is border line, and it would be much better if the rights
we care about are explicitly granted. 

-- 
tobi
 
> David
> 
> 
> 

Re: tomboy-ng package with non standard license.

[David Bannon]

Hi Folks, time we resolved this question about tomboy-ng and its use of
the KControls build time library.  Its now ten days since I wrote to TK,
the kcontrols author, asking if he would consider a more liberal
license. I have not had an answer and think we can assume I won't get one.

The known facts -

tomboy-ng needs the kcontrols source files at build time. Such src
libraries normally target an IDE and are unsuited to standalone debian
packaging. So a sunset of kcontrols needs to be shipped with the
tomboy-ng SRC package.

kcontrols has a license that while not preventing changes or
redistribution, it does not explicitly grant permission to do so.

TK has clearly, on the public record  stated that my proposed use of
kcontrols is acceptable. This was in answer to a question that stated I
would use a subset of kcontrols and distribute in a debian SRC package.
https://github.com/kryslt/KControls/issues/27 - "It is acceptable, thank
you for asking."

TK still maintains kcontrols but has made it clear he does not have the
time to make changes he finds unnecessary.

tomboy-ng could use an alternative to kcontrols but this would break its
cross platform commitment. This would gravely affect existing users.

My question to the debian legal team is "Given TK's clear statement that
the proposed use is acceptable, but noting the shortcomings in its
license, would you recommend I abandon this project or not ?"

David

Re: tomboy-ng package with non standard license.

[David Bannon]

On 20/9/20 10:46 pm, Tobias Frost wrote:
> Did you ask him if this record can be made public? Maybe that alone could
> solve it; depending on the exact content, of course.

Yes, I included a link to TK's reply in my first email to this list, its
in an 'issue' on KControls github page and therefore intended to be
public, the question was asked in the context of resolving this problem.
The answer was clear.

https://github.com/kryslt/KControls/issues/27

David

Re: tomboy-ng package with non standard license.

[Tobias Frost]

On Sat, Sep 19, 2020 at 10:12:02AM +1000, David Bannon wrote:
> Hi Folks, just to inform you I have not, yet given up on this project.
> 
> I have written to TK, the author or KControls, some five days ago now. I
> outlined your concerns about the KControls license and included, with
> vague attribution, a few quotes. And asked would he consider a new, more
> conventional license.
> 
> So far I have not had an answer, that may be because he considers it
> does not need an additional answer, he has already said, on record, that
> he considers my proposed use to be acceptable. I have noticed, in the
> past, he often ignores questions he considers silly !

Did you ask him if this record can be made public? Maybe that alone could
solve it; depending on the exact content, of course.
 
> I will however give him some more time before I abandon the project.
> 
> Remaining hopeful.
> 
> David
> 
> 
> On 14/9/20 5:21 pm, Tobias Frost wrote:
> > On Mon, Sep 14, 2020 at 11:49:10AM +1000, David Bannon wrote:
> >
> > Chiming in…
> >
> >> *** Daniel's Issues
> >>
> >>> Also, based on Daniel Hakimi's mail, it sounds like the KControls
> >>> author may have illegally changed the license, since there is no
> >>> indication in the commit message that they got approval from all the
> >>> copyright holders and looking at the git history there are a couple of
> >>> other contributors other than Tomas Krysl, but OTOH their contributions
> >>> don't appear to be large so maybe they aren't copyrightable.
> > Right, (though IANAL and that might be not gloablly the case)
> > (I did not check the changes if they are minor or not though)
> >  
> >> Daniel's message is a interesting one. I have sent TK a few 'patches',
> >> one or two line bug fixes, that were quietly applied without
> >> acknowledgement.  I would not, in any way, expect to be classed as an
> >> author on the basis of those patches.
> >>
> >> If Daniel is referring to earlier work than that, well, I cannot
> >> comment. TK used to have a blog that offered support and elicited
> >> suggestions/bug reports/patches. From memory, it stated that any
> >> contribution to the blog implied assigning ownership. I certainly
> >> regarded it as working like that.
> > Is this archived e.g on the WayBackMachine?
> >
> >> And, no Daniel, the email discussion I had with TK about the license
> >> occurred just before the KControls moved to github. While I have the
> >> emails on record, they were sent in confidence and I intend to respect
> >> that confidence.
> > Can you ask if those mails can be released? Private mails won't help
> > in the matter, only whati's in the public can be referred to.
> >  
> >> Daniel, I agree, life would be a lot easier if everyone used standard,
> >> acceptable licenses. However, sadly, they do not.
> > Sorry, did not follow too closely this thread but, have you asked them?
> >
> > I see an additional problem with the license: Beside being implicit only
> > on modifcations, it is the same way implicit when it comes to distribution.
> > Making those explicit permission would help; Especially distribution, 
> > because
> > without, you can not even go to non-free.*
> >
> > It would really help the case if upstream switches to some well-known 
> > license.
> >
> >> I personally think I am definitely using kcontrols in a manner approved
> >> by TK and doing so mostly consistent with its stated license. However,
> >> if its felt by your good selves that TK himself is not in a position to
> >> determine license issues, then its a deal breaker. If you think the
> >> current model is untenable, please say so, I need to advise my end
> >> users, who are requesting the Debian incorporation, of this fact.
> > IMHO we usually trust upstreams; unless we do have reasons not
> > to trust upstream…
> > On the other side. cooporation from upstream would help to dismiss those
> > concerns.
> >
> 

Re: tomboy-ng package with non standard license.

[David Bannon]

Hi Folks, just to inform you I have not, yet given up on this project.

I have written to TK, the author or KControls, some five days ago now. I
outlined your concerns about the KControls license and included, with
vague attribution, a few quotes. And asked would he consider a new, more
conventional license.

So far I have not had an answer, that may be because he considers it
does not need an additional answer, he has already said, on record, that
he considers my proposed use to be acceptable. I have noticed, in the
past, he often ignores questions he considers silly !

I will however give him some more time before I abandon the project.

Remaining hopeful.

David


On 14/9/20 5:21 pm, Tobias Frost wrote:
> On Mon, Sep 14, 2020 at 11:49:10AM +1000, David Bannon wrote:
>
> Chiming in…
>
>> *** Daniel's Issues
>>
>>> Also, based on Daniel Hakimi's mail, it sounds like the KControls
>>> author may have illegally changed the license, since there is no
>>> indication in the commit message that they got approval from all the
>>> copyright holders and looking at the git history there are a couple of
>>> other contributors other than Tomas Krysl, but OTOH their contributions
>>> don't appear to be large so maybe they aren't copyrightable.
> Right, (though IANAL and that might be not gloablly the case)
> (I did not check the changes if they are minor or not though)
>  
>> Daniel's message is a interesting one. I have sent TK a few 'patches',
>> one or two line bug fixes, that were quietly applied without
>> acknowledgement.  I would not, in any way, expect to be classed as an
>> author on the basis of those patches.
>>
>> If Daniel is referring to earlier work than that, well, I cannot
>> comment. TK used to have a blog that offered support and elicited
>> suggestions/bug reports/patches. From memory, it stated that any
>> contribution to the blog implied assigning ownership. I certainly
>> regarded it as working like that.
> Is this archived e.g on the WayBackMachine?
>
>> And, no Daniel, the email discussion I had with TK about the license
>> occurred just before the KControls moved to github. While I have the
>> emails on record, they were sent in confidence and I intend to respect
>> that confidence.
> Can you ask if those mails can be released? Private mails won't help
> in the matter, only whati's in the public can be referred to.
>  
>> Daniel, I agree, life would be a lot easier if everyone used standard,
>> acceptable licenses. However, sadly, they do not.
> Sorry, did not follow too closely this thread but, have you asked them?
>
> I see an additional problem with the license: Beside being implicit only
> on modifcations, it is the same way implicit when it comes to distribution.
> Making those explicit permission would help; Especially distribution, because
> without, you can not even go to non-free.*
>
> It would really help the case if upstream switches to some well-known license.
>
>> I personally think I am definitely using kcontrols in a manner approved
>> by TK and doing so mostly consistent with its stated license. However,
>> if its felt by your good selves that TK himself is not in a position to
>> determine license issues, then its a deal breaker. If you think the
>> current model is untenable, please say so, I need to advise my end
>> users, who are requesting the Debian incorporation, of this fact.
> IMHO we usually trust upstreams; unless we do have reasons not
> to trust upstream…
> On the other side. cooporation from upstream would help to dismiss those
> concerns.
>

Re: tomboy-ng package with non standard license.

[Tobias Frost]

On Mon, Sep 14, 2020 at 11:49:10AM +1000, David Bannon wrote:

Chiming in…

> *** Daniel's Issues
> 
> > Also, based on Daniel Hakimi's mail, it sounds like the KControls
> > author may have illegally changed the license, since there is no
> > indication in the commit message that they got approval from all the
> > copyright holders and looking at the git history there are a couple of
> > other contributors other than Tomas Krysl, but OTOH their contributions
> > don't appear to be large so maybe they aren't copyrightable.

Right, (though IANAL and that might be not gloablly the case)
(I did not check the changes if they are minor or not though)
 
> Daniel's message is a interesting one. I have sent TK a few 'patches',
> one or two line bug fixes, that were quietly applied without
> acknowledgement.  I would not, in any way, expect to be classed as an
> author on the basis of those patches.
> 
> If Daniel is referring to earlier work than that, well, I cannot
> comment. TK used to have a blog that offered support and elicited
> suggestions/bug reports/patches. From memory, it stated that any
> contribution to the blog implied assigning ownership. I certainly
> regarded it as working like that.

Is this archived e.g on the WayBackMachine?

> 
> And, no Daniel, the email discussion I had with TK about the license
> occurred just before the KControls moved to github. While I have the
> emails on record, they were sent in confidence and I intend to respect
> that confidence.

Can you ask if those mails can be released? Private mails won't help
in the matter, only whati's in the public can be referred to.
 
> Daniel, I agree, life would be a lot easier if everyone used standard,
> acceptable licenses. However, sadly, they do not.

Sorry, did not follow too closely this thread but, have you asked them?

I see an additional problem with the license: Beside being implicit only
on modifcations, it is the same way implicit when it comes to distribution.
Making those explicit permission would help; Especially distribution, because
without, you can not even go to non-free.*

It would really help the case if upstream switches to some well-known license.

> 
> I personally think I am definitely using kcontrols in a manner approved
> by TK and doing so mostly consistent with its stated license. However,
> if its felt by your good selves that TK himself is not in a position to
> determine license issues, then its a deal breaker. If you think the
> current model is untenable, please say so, I need to advise my end
> users, who are requesting the Debian incorporation, of this fact.

IMHO we usually trust upstreams; unless we do have reasons not
to trust upstream…
On the other side. cooporation from upstream would help to dismiss those
concerns.

-- 
tobi

Re: tomboy-ng package with non standard license.

[David Bannon]

Thanks both Paul and Daniel (hoping it is appropriate to respond with
one message...)


On 13/9/20 12:54 pm, Paul Wise wrote:
> IIRC the Lazarus IDE has a way to do command-line builds, this came up 

Might be a terminology issue. Lazarus is an IDE that ultimately calls
the Free Pascal Compiler, FPC. When it does so, its usually linking the
Lazarus Component Library, LCL. 

So, to build on the command line, you need call only FPC and link in
LCL.  There also are some tools within the Lazarus toolkit, lazbuild in
particular, that will build using the Lazarus project file but even then
it is not using Lazarus itself. Using lazbuild does not solve any of the
problems being discussed.

So, any command line build of a Lazarus project does not use Lazarus
itself.  All builds use FPC which is, of course, a command line
application. I considered a pure FPC build was a more Debian consistent
model that using lazbuild.

In the case of KControls, the package to install into the IDE is some 5
meg bytes, 80% of that is not needed for a command line build.


> Is TomboyReborn the same thing as tomboy-ng?

I did not know that tomboy-reborn has approached Debian. Its a fork of
my code after its 'author' was refused permission to submit very raw
code to to my release branch during the final stage of a release cycle. 
My license, of course permits that fork. I would not personally work
with that person, we had some serious communication problems,
particularly about quality, cross platform and use of github branches.



> Do we need multiple Tomboy rewrites in Debian?

tomboy-ng is cross platform and has a proven track record with end user
support. It has a user base. And working scripts that build a working
Debian Source Package. You choose.


> There are such
> unclear licenses in packages in Debian, but usually they come with a
> clarification via email about the intent of the clauses.

Did you note that TK indicated, in
https://github.com/kryslt/KControls/issues/27 that he considered my
proposed usage appropriate ? Is that what you mean about email
clarification ? Should I mention that in the copyright file ?


*** Daniel's Issues

> Also, based on Daniel Hakimi's mail, it sounds like the KControls
> author may have illegally changed the license, since there is no
> indication in the commit message that they got approval from all the
> copyright holders and looking at the git history there are a couple of
> other contributors other than Tomas Krysl, but OTOH their contributions
> don't appear to be large so maybe they aren't copyrightable.

Daniel's message is a interesting one. I have sent TK a few 'patches',
one or two line bug fixes, that were quietly applied without
acknowledgement.  I would not, in any way, expect to be classed as an
author on the basis of those patches.

If Daniel is referring to earlier work than that, well, I cannot
comment. TK used to have a blog that offered support and elicited
suggestions/bug reports/patches. From memory, it stated that any
contribution to the blog implied assigning ownership. I certainly
regarded it as working like that.

And, no Daniel, the email discussion I had with TK about the license
occurred just before the KControls moved to github. While I have the
emails on record, they were sent in confidence and I intend to respect
that confidence.

Daniel, I agree, life would be a lot easier if everyone used standard,
acceptable licenses. However, sadly, they do not.


I personally think I am definitely using kcontrols in a manner approved
by TK and doing so mostly consistent with its stated license. However,
if its felt by your good selves that TK himself is not in a position to
determine license issues, then its a deal breaker. If you think the
current model is untenable, please say so, I need to advise my end
users, who are requesting the Debian incorporation, of this fact.

David





signature.asc
Description: OpenPGP digital signature

Re: tomboy-ng package with non standard license.

[Paul Wise]

On Sat, 2020-09-12 at 15:44 +1000, David Bannon wrote:

> Yes, I understand that. However, LCL Packages usually have no existence
> outside the Lazarus IDE.

IIRC the Lazarus IDE has a way to do command-line builds, this came up
in the TomboyReborn RFS #964087.

Is TomboyReborn the same thing as tomboy-ng?
Do we need multiple Tomboy rewrites in Debian?

> Sorry, unsure of what you mean here.

Depending on how you read it (strictly or with implications), the
license either does or does not allow modifications (DFSG item 3). A
license that depends on how you read it is an unclear license. An
unclear license is dangerous since you cannot know what the author
meant to allow. If you cannot know what the author meant then you
cannot be sure you are allowed to do what the unclear parts say. If you
think you are allowed to modify the code but the author does not and
then you modify the code, the author could sue. Personally I would be
fairly uncomfortable with relying on such a license. There are such
unclear licenses in packages in Debian, but usually they come with a
clarification via email about the intent of the clauses.

https://www.debian.org/social_contract#guidelines

In a recent case of this sort of thing that I discovered, I concluded
that the license was intended to cover modification, but only after one
of RedHat's lawyers clarified how they dealt with this case.

https://bugs.debian.org/963103
https://lists.debian.org/msgid-search/a8259f8fb4348c790076ffcaf8721ecba7c714a3.ca...@debian.org
https://lists.debian.org/msgid-search/caktje6gyyvhyvo0rvo-4bslcoofr2zn3e-0sgmtegr7+j7w...@mail.gmail.com

Also, based on Daniel Hakimi's mail, it sounds like the KControls
author may have illegally changed the license, since there is no
indication in the commit message that they got approval from all the
copyright holders and looking at the git history there are a couple of
other contributors other than Tomas Krysl, but OTOH their contributions
don't appear to be large so maybe they aren't copyrightable.

> Paul, I wonder if we can talk about the "should"s and the "must"s ? I
> really have no control over TK's license. If its unacceptable, then
> thats what it is. At some time in the future, its just possible i will
> use RichMemo instead but until then, this approach is the only one open
> to me. 

When it comes to unclear licenses, there is no should vs must, there is
only a murky zone where you cannot know anything correctly. Which way
to go really depends on the interpretation of the person reading the
license. I'm not a member of the Debian ftp-master team so I cannot
really predict which way they will go as the reject FAQ does not
mention unclear licenses.

https://ftp-master.debian.org/REJECT-FAQ.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: tomboy-ng package with non standard license.

[Daniel Hakimi]

Is this  the conversation
they had about the license? It doesn't seem very robust...

First of all, did they even have the authority to modify the license? Were
there contributors? Did the contributors sign a CLA that allowed the
license to be changed in this way? Or was it just the package maintainer
deciding to change the license? Or, does the package just have a single
author?

Second of all, nobody seems to have explained why they aren't using a
standard license. They removed the clause about modifications, but the new
license still doesn't clarify whether modifications are allowed or not.
Very confusing.

They do mention modified code, so I agree that this probably does imply a
permission to modify... But I always find it so annoying when developers
are hostile to any clear and straightforward licensing practice.

Regards,

Daniel J. Hakimi
B.S. Philosophy, RPI 2012
B.S. Computer Science, RPI 2012
J.D. Cardozo Law 2015


On Sat, Sep 12, 2020 at 2:03 AM David Bannon 
wrote:

> Thank you Paul, I am afraid I am a still a little unsure however.
>
>
> On 12/9/20 11:29 am, Paul Wise wrote:
> > Dependencies should be packaged separately, not copied into the
> > package that depends on them.
>
> Yes, I understand that. However, LCL Packages usually have no existence
> outside the Lazarus IDE. The IDE has built in tools to fetch and install
> such packages and most Lazarus based applications are built from within
> the IDE. However, that will not work with the Debian build system. It
> would not be possible to make a general purpose KControls Debian
> package, the Lazarus IDE uses a 'pull' model for its packages, it will
> not accept a 'push'. Packages need to be installed in user space,
> normally, on Linux, this is in a configuration dependent hidden
> directory in $HOME.
>
> Alternatively, if I was to make a Debian KControls package intended only
> for command line building of my specific app, and thats what it would
> have to be, I am quite sure it would be judged as inappropriate. I would
> need to 'invent' a specific place to put the files and then when
> building tomboy-ng, would look for them in that place. Thats wrong !
>
>
> >> This code is distributed as a freeware. You are free to use it as part
> of your application for any purpose including freeware, commercial and
> shareware applications. The origin of this source code must not be
>  misrepresented; you must not claim your authorship. All redistributions
> of the original or modified source code must retain the original copyright
> notice. The Author accepts no liability for any damage that may result
> from using this code.
> > This license contains an implicit permission to modify, but it would
> > be much better to make it explicit. If you are going to go to the
> > trouble of asking upstream to get permission from all the copyright
> > holders to change the license, it would be much better to just switch
> > to a standard license (GPL, MIT or BSD) though.
>
> Sorry, unsure of what you mean here. I don't intend asking upstream to
> change its license. Its unlikely I will get TK (the KControls author) to
> change the KControls license. When he first moved to Github, we
> discussed the license extensively, his original license would,
> unintentionally, have prevented it use. What we have now is the best we
> can hope for. Or do you mean I should change my license (that applies to
> my app, tomboy-ng) to make it somehow more compatible ?
>
>
> Paul, I wonder if we can talk about the "should"s and the "must"s ? I
> really have no control over TK's license. If its unacceptable, then
> thats what it is. At some time in the future, its just possible i will
> use RichMemo instead but until then, this approach is the only one open
> to me.
>
>
> David
>
>
>
>

Re: tomboy-ng package with non standard license.

[David Bannon]

Thank you Paul, I am afraid I am a still a little unsure however.


On 12/9/20 11:29 am, Paul Wise wrote:
> Dependencies should be packaged separately, not copied into the
> package that depends on them.

Yes, I understand that. However, LCL Packages usually have no existence
outside the Lazarus IDE. The IDE has built in tools to fetch and install
such packages and most Lazarus based applications are built from within
the IDE. However, that will not work with the Debian build system. It
would not be possible to make a general purpose KControls Debian
package, the Lazarus IDE uses a 'pull' model for its packages, it will
not accept a 'push'. Packages need to be installed in user space,
normally, on Linux, this is in a configuration dependent hidden
directory in $HOME.

Alternatively, if I was to make a Debian KControls package intended only
for command line building of my specific app, and thats what it would
have to be, I am quite sure it would be judged as inappropriate. I would
need to 'invent' a specific place to put the files and then when
building tomboy-ng, would look for them in that place. Thats wrong !


>> This code is distributed as a freeware. You are free to use it as part  of 
>> your application for any purpose including freeware, commercial and  
>> shareware applications. The origin of this source code must not be   
>> misrepresented; you must not claim your authorship. All redistributions  of 
>> the original or modified source code must retain the original copyright  
>> notice. The Author accepts no liability for any damage that may result  from 
>> using this code.
> This license contains an implicit permission to modify, but it would
> be much better to make it explicit. If you are going to go to the
> trouble of asking upstream to get permission from all the copyright
> holders to change the license, it would be much better to just switch
> to a standard license (GPL, MIT or BSD) though.

Sorry, unsure of what you mean here. I don't intend asking upstream to
change its license. Its unlikely I will get TK (the KControls author) to
change the KControls license. When he first moved to Github, we
discussed the license extensively, his original license would,
unintentionally, have prevented it use. What we have now is the best we
can hope for. Or do you mean I should change my license (that applies to
my app, tomboy-ng) to make it somehow more compatible ?


Paul, I wonder if we can talk about the "should"s and the "must"s ? I
really have no control over TK's license. If its unacceptable, then
thats what it is. At some time in the future, its just possible i will
use RichMemo instead but until then, this approach is the only one open
to me. 


David

Re: tomboy-ng package with non standard license.

[Paul Wise]

On Sat, Sep 12, 2020 at 1:21 AM David Bannon wrote:

> Unusually, I will be adding code from another repository into the Debian 
> Source package.

Dependencies should be packaged separately, not copied into the
package that depends on them.

> This code is distributed as a freeware. You are free to use it as part  of 
> your application for any purpose including freeware, commercial and  
> shareware applications. The origin of this source code must not be   
> misrepresented; you must not claim your authorship. All redistributions  of 
> the original or modified source code must retain the original copyright  
> notice. The Author accepts no liability for any damage that may result  from 
> using this code.

This license contains an implicit permission to modify, but it would
be much better to make it explicit. If you are going to go to the
trouble of asking upstream to get permission from all the copyright
holders to change the license, it would be much better to just switch
to a standard license (GPL, MIT or BSD) though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise