bugFree UCS Outline Fonts - Bugs: bug #53349, Please clarify license for...

 
 

bug #53349: Please clarify license for non-font files and copyright holders

Submitter:  Fabian Greffrath <fabiangreffrath>
Submitted:  Thu 15 Mar 2018 11:40:15 AM UTC
   
 
Category:  documentation Severity:  3 - Normal
Item Group:  legal/licensing/policy Status:  Postponed
Privacy:  Public Assigned to:  Stevan_White
Open/Closed:  Open Release:  * development
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 10 May 2018 09:39:33 PM UTC, comment #20: 

Hi fabian,

I changed the statement in the README file so that it isn't outright wrong. 

I'm still open to discussion on the wider topic.  For the time being, I'm only fixing bugs, such as that incorrect copyright statement.

Thanks for your help!

Steve White <Stevan_White>
Group administrator
Wed 09 May 2018 10:10:51 PM UTC, comment #19: 

Sorry for the pause Fabian,
Yes I saw you were right about the README file.  I've just been busy with other things, and this just got buried.  I'll look at it tomorrow.

Steve White <Stevan_White>
Group administrator
Tue 08 May 2018 08:20:00 PM UTC, comment #18: 

So, will there be any further clarifications to the README file or do we consider this issue fixed?

Fabian Greffrath <fabiangreffrath>
Mon 16 Apr 2018 03:46:35 PM UTC, comment #17: 

Hi Steve,

> The copyright line currently in the README file is the copyright for the README file, nothing else


erm, this is how it currently reads:

"
All files in the GNU FreeFont distribution are
Copyright 2002, 2003, 2005, 2008, 2009, 2010, 2012, 2018 GNU Freefont contributors.
"

> It's not clear to me at what point README files took on the responsibility for explaining the copyrights of all the package files


I don't say it is the README file's responsibility to explain the copyrights, but if it already started doing so, it should do it properly. This is similar to stating a license without naming a copyright holder at all (which is where this issue started). Now it states a license and a sole copyright holder which doesn't match what's actually in the package.

> "some files in the package are copyright bla bla, while others are bla bla bla, see individual files for details"


I'd be perfectly fine with this! This is more or less the non-explicit version of the information which I will have to provide in detail in the debian/copyright file.

 - Fabian

Fabian Greffrath <fabiangreffrath>
Sun 15 Apr 2018 08:08:00 PM UTC, comment #16: 

Hi Fabian,

As far as I'm concerned, we're still discussing the question.

That's a little different from what I imagined you meant: I thought you wanted a statement for each different copyright line in all the files.
It's somewhat less objectionable with just a couple extra lines that don't mirror exact information in other files.

The copyright line currently in the README file is the copyright for the README file, nothing else. It's not clear to me at what point README files took on the responsibility for explaining the copyrights of all the package files,and it's also unclear to me whom and how it helps.

If I can be convinced of a good reason for such efforts, and I could be persuaded to explicitly state in the README something like: "some files in the package are copyright bla bla, while others are bla bla bla, see individual files for details" without stating explicitly the copyright dates (which vary from file to file).  This would have less dependency on the exact information in all the other files.

Generally speaking, the importance of copyright statements is a little hazy.  In the event of a legal conflict, they might serve to clarify something, but it isn't as though material that is missing them isn't copyrighted -- as I'm sure you know, by U.S. law, the creator of any material has copyright for a limited period of time, regardless of a copyright statement.

Thanks!

Steve White <Stevan_White>
Group administrator
Sun 15 Apr 2018 06:32:17 PM UTC, comment #15: 

I expect the README file to contain accurate information that covers the entire project. As it currently reads, the README file leaves the impression that "GNU Freefont contributors" is the only copyright holder - which doesn't match with the information embedded into the build scripts.

I don't mean this on a per-file basis, but would simply add the following two lines to the copyright holders section in the README file:

2009-2012, Stevan White
2011, Emmanuel Vallois

I don't know if this is legally relevant, it is just that I think it feels "more right". If you still disagree, please feel free to close this bug report, I won't object.

Fabian Greffrath <fabiangreffrath>
Sun 15 Apr 2018 10:36:19 AM UTC, comment #14: 

Hi,

I'm not sure what exactly you expect in the README file.

It sounds like exactly the same thing as with the debian/copyright file we were discussing: that each separately-copyrighted file should be listed, together with its copyright information.  I object to that on the same grounds.  The right place for the copyright information is in the file itself.

Please explain.

Steve White <Stevan_White>
Group administrator
Sat 14 Apr 2018 08:18:12 PM UTC, comment #13: 


> But do let me know if you see anything outright wrong with the licenses


No, nothing wrong, but - even at the risk of repeating myself now - I'd appreciate if the general copyright statement in the README file would match (i.e. add) the copyright information embedded in the build scripts.

Fabian Greffrath <fabiangreffrath>
Tue 10 Apr 2018 08:31:33 PM UTC, comment #12: 

Hi,

I'm shelving the debian/copyright file for now -- this is a feature that is harder to implement than I thought, while we're supposed to be in a feature freeze.

We'll think about it again later.

Thanks!

(But do let me know if you see anything outright wrong with the licenses!)

Steve White <Stevan_White>
Group administrator
Mon 09 Apr 2018 01:12:17 PM UTC, comment #11: 

Hi Steve,

> to allow referencing "all files except"? Or to override a wildcard for a single file


you can achieve this by adding a more specific Files-paragraph after a more general one, e.g.

Files: *
Copyright: whoever
License: license-1

Files: *-but-foo
Copyright: whoever else
License: license-2

>  I regard debian/copyright as a standard-in-progress


No, really not, the debian/copyright file is there almost as long as the Debian package format exists. Its sole requirement is to document the copyright holders and licenses for all the files shipped in the package. The machine-readable format that you are refering to is an - admittedly new, but entirely optional - addition to this standard. Nevertheless, it is part of a released policy document.

However, it is entirely my job as the Debian package maintainer to keep this file correct and up-to-date. If you agree to maintain it upstream as well, that's highly appreciated, but let's please keep the information consistent across the code base then.

> The GPL is standard, and its text should already be among the project files, to reduplicate it is pointless and error-prone.


That's why only the GPL blurb is added to the copyright file, not the entire license text.

Check here for an example:
https://anonscm.debian.org/cgit/collab-maint/dh-make.git/tree/lib/licenses/gpl3

Cheers,

 - Fabian

Fabian Greffrath <fabiangreffrath>
Mon 09 Apr 2018 11:06:21 AM UTC, comment #10: 

Hi Fabian,

I've fixed one issue, combining the file name endings for the built font files.

Is there a nice logic in the debian/copyright file, to allow referencing "all files except"?  Or to override a wildcard for a single file?

I'm not keen on duplicating the GPL in this file.  I regard debian/copyright as a standard-in-progress, and this requirement as  problematic.  The GPL is standard, and its text should already be among the project files, to reduplicate it is pointless and error-prone.  They need to fix this problem.


Steve White <Stevan_White>
Group administrator
Mon 09 Apr 2018 10:45:20 AM UTC, comment #9: 

Hi Steve,

the added clarification is a vast improvement, thank you very much for this!

Regarding the debian/copyright file, it will be very helpful, but let me please add some remarks:

1) I would combine the three stanzas for the binary font files into one paragraph and let it start with

Files: /.ttf
 */*.otf
 */*.woff

2) The actual "License:" paragraphs are missing which contain the verbatim license text (or at least the license header blurb and a reference to the full text). This may feel a bit redundant, as this information is already given in the top-level README file, but is required by the standard.

3) Finally, there are now copyright holders listed in both the README file and the debian/copyright file, but unfortunately, they do not match the copyright holders documented in the code itself, e.g. the files in the tools directory.

Try " grep -ir coypright tools/" and you will find more copyright holders (i.e. mostly yourself) than stated in the README and debian/coypright documents.

If you expect a patch for fixing these issues, please let me know!

 - Fabian

Fabian Greffrath <fabiangreffrath>
Sat 07 Apr 2018 09:59:31 AM UTC, comment #8: 

Hi Fabian,

I made some alterations to the README file.  Besides the big new "clarification", which was the longstanding issue, I added a header that emphasizes that the "font exception" clause refers only to the  font files built with the project -- in case it isn't obvious enough.

I also commited a debian/ directory.  Have a look and see if I got it right.

I'm really not thrilled with the debian product name being displayed in such a major place in this project. (Nothing against debian -- I use a debian-based system myself.)  Directories ought to be named for what they contain, rather than after the geniuses who invented them.

Steve White <Stevan_White>
Group administrator
Thu 05 Apr 2018 03:20:20 PM UTC, comment #7: 

There has been progress on the longstanding licensing issue.
I mean to go forward on that soon, and I will take your recommendations into account. The current delay is due to my personal organizational challenges.

Steve White <Stevan_White>
Group administrator
Thu 05 Apr 2018 03:13:59 PM UTC, comment #6: 

Hi Steve,

is there any progress on this issue?

Fabian Greffrath <fabiangreffrath>
Sat 17 Mar 2018 11:57:43 AM UTC, comment #5: 


> That would already be a vast improvement.


Oh, and please do explicitly add copyright holders (and years) so it is clear who actually grants the license(s).

Fabian Greffrath <fabiangreffrath>
Sat 17 Mar 2018 11:45:27 AM UTC, comment #4: 

Hi Steve,

> As to the machine-readable license document -- I see the specification only came out in late December last year


the specification is now part of the Debian Policy document and this has been revised in Dec 2017. The spec itself is as old as Feb 2012 when it was first formulated as a draft:

http://dep.debian.net/deps/dep5/

For the time being, I'd be happy if the README file could just clearly state that e.g. the project as a whole is licensed under the GPL-3+ and that the Font exception additionally applies to all the font files in the sfd/ directory. That would already be a vast improvement.

Thank you!

 - Fabian

Fabian Greffrath <fabiangreffrath>
Sat 17 Mar 2018 11:18:02 AM UTC, comment #3: 

Hi Fabian,

I agree that it's reasonable to explain directly to what files in the distribution the font exception pertains, and the README is a good place to do that.  (Even though the point should be obvious with a moment's thought.)

As it happens, a lot of discussion regarding the wording of the license has transpired in the past year, and we're considering how to encorporate that at this time.  So your suggestion is timely.

As to the machine-readable license document -- I see the specification only came out in late December last year.  This is brand spanking new.  It doesn't strike me as a bad thing, but it is a bit soon to jump on the bandwaggon, while we're in a feature freeze.

Could you make that a separate feature request?

Steve White <Stevan_White>
Group administrator
Thu 15 Mar 2018 06:53:27 PM UTC, comment #2: 

Hi Steve,

> The font exception has nothing to do with the files in the tools directory as far as I can see. It has only to do with the imbedding of the fonts themselves in documents. The tools themselves are GPL 3.0+ licensed software


that's the point, this doesn't get clear from the statement in the README file. If you state the license in such a central document, you should probably make clear which license applies to which part of the distribution. The paragraph in question, though, begins with "GNU FreeFont is free software..." and then follows the GPL-3+ with Font exception.

> Where do we learn exactly what needs to be stated in which files of a distribution?


It would help a lot if you could document copyright holders and license for (groups of) files in a machine-readable format as proposed by Debian here:

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

For this projects this would probably result in something like this:

"
Files: *
Copyright: 2009-2012, Stevan White
 2011, Emmanuel Vallois
License: GPL-3+
 GNU FreeFont is free software; you can redistribute it and/or modify it
 under the terms of the GNU General Public License as published by the
 Free Software Foundation; either version 3 of the License, or (at your option)
 any later version.
 .
 The fonts are distributed in the hope that they will be useful, but
 WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
 or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 for more details.
 .
 You should have received a copy of the GNU General Public License along
 with this program; if not, write to the Free Software Foundation, Inc.,
 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.

Files: sfd/*
Copyright: Copyright 2002-2012, GNU Freefont contributors
License: GPL-3+ with Font exception
 As a special exception, if you create a document which uses this font, and
 embed this font or unaltered portions of this font into the document, this
 font does not by itself cause the resulting document to be covered by the
 GNU General Public License. This exception does not however invalidate any
 other reasons why the document might be covered by the GNU General Public
 License. If you modify this font, you may extend this exception to your
 version of the font, but you are not obligated to do so.  If you do not
 wish to do so, delete this exception statement from your version.
"

Fabian Greffrath <fabiangreffrath>
Thu 15 Mar 2018 05:56:32 PM UTC, comment #1: 

Hi Fabian,

The font exception has nothing to do with the files in the tools directory as far as I can see.  It has only to do with the imbedding of the fonts themselves in documents.  The tools themselves are GPL 3.0+ licensed software -- they should not undergo any imbedding, and even if they did, the font exception should not apply to them.  I'm not sure what you're getting at here.

Where do we learn exactly what needs to be stated in which files of a distribution?

Thanks!


Steve White <Stevan_White>
Group administrator
Thu 15 Mar 2018 11:40:15 AM UTC, original submission:  

Hi there,

the GNU FreeFont release is currently accompanied by a README file which states that the license for the project is the GPL-3+ with font exception. There are a few issues with this statement:

- While GPL-3+ with font exception is probably the license for all the files in the sfd/ directory, most of the files in e.g. the tools/ directory merely state that the license is GPL-3+. Please get this right in the README file.

- There is no copyright holder given in the README file, neither for the font files in the sfd/ directory nor for the additional code and documentation in the other directories. Please add the names of the copyright holders to the README file.

Thank you very much!

 - Fabian

Fabian Greffrath <fabiangreffrath>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by Stevan_White (Posted a comment)
  • -email is unavailable- added by fabiangreffrath (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-04-10 Stevan_White StatusFix posted Postponed
    2018-04-07 Stevan_White StatusProceeding Fix posted
    2018-03-17 Stevan_White StatusNeed info Proceeding
        Release2012-05-03 development
    2018-03-15 Stevan_White StatusNone Need info
        Assigned toNone Stevan_White

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code