Unusually, I will be adding code from another repository into the Debian Source package.
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 yourauthorship. 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.
Dependencies should be packaged separately, not copied into the
package that depends on them.
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 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
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.
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 !
of your application for any purpose including freeware, commercial and shareware applications. The origin of this source code must not beThis code is distributed as a freeware. You are free to use it as part
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
<div><br></div><div>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.<br></div><div><br></div><div>Regards,<br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div><br></div><div>Daniel J. Hakimi</div><div>B.S. Philosophy, RPI 2012</div><div>B.S. Computer Science,
Yes, I understand that. However, LCL Packages usually have no existence outside the Lazarus IDE.
Sorry, unsure of what you mean here.
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.
IIRC the Lazarus IDE has a way to do command-line builds, this came up
Is TomboyReborn the same thing as tomboy-ng?
Do we need multiple Tomboy rewrites in Debian?
There are such
unclear licenses in packages in Debian, but usually they come with a clarification via email about the intent of the clauses.
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 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.
On Mon, Sep 14, 2020 at 11:49:10AM +1000, David Bannon wrote:
Chiming in…
*** Daniel's IssuesRight, (though IANAL and that might be not gloablly the case)
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.
(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',Is this archived e.g on the WayBackMachine?
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 licenseCan you ask if those mails can be released? Private mails won't help
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.
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,Sorry, did not follow too closely this thread but, have you asked them?
acceptable licenses. However, sadly, they do not.
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 approvedIMHO we usually trust upstreams; unless we do have reasons not
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.
to trust upstream…
On the other side. cooporation from upstream would help to dismiss those concerns.
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 IssuesRight, (though IANAL and that might be not gloablly the case)
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.
(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',Is this archived e.g on the WayBackMachine?
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 licenseCan you ask if those mails can be released? Private mails won't help
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.
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,Sorry, did not follow too closely this thread but, have you asked them?
acceptable licenses. However, sadly, they do not.
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 approvedIMHO we usually trust upstreams; unless we do have reasons not
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.
to trust upstream…
On the other side. cooporation from upstream would help to dismiss those concerns.
Did you ask him if this record can be made public? Maybe that alone could solve it; depending on the exact content, of course.
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
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(You won't get an authoritive answer here, as this is ftp-masters realm)
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 ?"
IMHO the license is border line, and it would be much better if the rights
we care about are explicitly granted.
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.
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...
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.
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).
source/libnotify.pas (bindings to libnotify) is GPL2, thats documented
in debian/copyright, this is, I believe a non-issue.
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.
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.
source/spelling.pas, has some code that is, again, pascal libaryAs 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
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.
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?
It is possible to build C style Libraries with FeePascal units but it
not efficient with time, space or performance in practice.
also wanting to use KControls but there is not.
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.
The KControls README and issues shows there are several users, but of
course it is unlikely they would want their software in Debian.
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
easily support other spelling libraries like nuspell too.
The KControls README and issues shows there are several users, but of
course it is unlikely they would want their software in Debian.
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
easily support other spelling libraries like nuspell too.
Are there any further thoughts on this topic ?
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.
Hunspell to Pascal Bindings, the saga continues....
OK, I have now separated out the Hunspell 'bindings' from my hunspell
unit.
On Mon, 2020-11-16 at 15:52 +1100, David Bannon wrote:
Hunspell to Pascal Bindings, the saga continues....Excellent, I think that concludes the legal proportion of the saga :)
OK, I have now separated out the Hunspell 'bindings' from my hunspell
unit.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 293 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 225:44:03 |
| Calls: | 6,624 |
| Calls today: | 6 |
| Files: | 12,171 |
| Messages: | 5,318,605 |