Hi Paul,

On Mon, Jan 08, 2024 at 12:54:25PM +0800, Paul Wise wrote:
> On Fri, 2024-01-05 at 22:31 -0800, Ross Vandegrift wrote:
> > Imagine I take some code from a freely licensed reference implementation and
> > customize it.  The result is a derived work.  But this embedding isn't
> > removable - the reference implementation shouldn't accept changes to 
> > integrate
> > it into a specific project.
> The reference implementation should be flexible enough to work as a
> library imported/loaded/linked by any project that wants to use it.

Perhaps - but some people provide code without having any interest in the
implementation details that users might run into.  Still, that code might be
useful to use & distribute.

This is one of many ways Debian and upstream might have different or
conflicting goals.

> > It'd be reasonable to include the original license and copyright statements.
> Right.
> > If I do, Debian requires packagers to describe the license and copyright on
> > those embedded license/copyright files.  And I'm puzzled about how to do 
> > that
> > best.
> Same as for any other file in the source package, list in the
> debian/copyright which files have which copyrights and licenses.

Heh, right - the problem is executing that. :)  Folks typically take care to
document the copyright on code, not so often licenses (the FSF licenses being
the exception, they are clear).

> > (I realize not much hangs on this - but cme/licensecheck raised the issue to
> > me.  I can ignore it, but also got curious and tried to figure out what to 
> > do.)
> What issue did it print? Which package/code is this about BTW?

src:efl is a pastice of original work, dervied code, and vendored copies.  The
situation I asked about is somewhat simplified from real ones.  Here's two
harder cases than what the wiki considers:


  This is a Zlib license statement for code derived from another project.  This
  copy has been rewritten from C++ -> C.  So the changes wouldn't be appropriate
  for the upstream project.

  What license and copyright holders can I write for this file?  The text is
  derived from the Zlib license, but I also don't know who wrote that.

  This is from an included copy of musl's fnmatch algorithm.  I think EFL
  includes this for portability, to ensure that the same fnmatch is used on
  Linux, BSD, and Windows.  Even if that's not needed in Debian, I don't think I
  can link to musl and glibc.

Interestingly, base-files (which contains /usr/share/common-licenses) doesn't
contain any copyright information for some of it's licenses.  It also doesn't
use dep5 copyright, and so probably not licensechcek/cme.  So no one is being
bugged to document who holds the copyright to the MPL-1.1.


[1] - src:efl has those too.  I'm recently trying to remove a libunbreak copy
      in the static_libs directory.

Attachment: signature.asc
Description: PGP signature

Reply via email to