Proposal: Modification of the Hack license #271
Comments
|
From my comment in the debian-legal mailing list thread:
|
|
Response from Francesco Poli on debian-legal mailing list:
|
|
It's great that you are moving towards a documented build with a open buildpath using fontmake and relevant libraries. I still think (and strongly advocate) that you should not call your project-specific (mix of) license(s) "Hack Open Font License". It's rather bad form to grab mindshare with this name collision. It's bound to create confusion with the OFL. IOW call it whatever you like that does not contain "open font license". You need to be aware that debian-legal is a mailing-list and that their members will not be able to give you the official Debian decision: the ftpmasters decide what actually goes into the archive or not. |
|
@n7s Thank you very much for weighing in Nicolas. I greatly appreciate it.
We will remove "Open Font License" from the license name if the Hack specific portion of the license remains following these conversations (otherwise the entire Hack specific license naming scheme will go away altogether). Removal of the co-licensed structure and reversion to the Bitstream Vera license is under consideration. Given your background and expertise in font licensing, I would be interested in your input and feedback on this issue. SIL indicates the following as benefits of reserved font names and the first three very much apply to our project (particularly 2&3 which are derived issues from 1):
As for the last element, it is not that we do not encourage forks/derivative projects and contributions back upstream, it is simply that this license structure is not intended to promote or encourage this. I'd be interested in your thoughts on the downside of elimination of a reserved font name and experience with any of those downsides. I believe that the Google Fonts project mandates RFN removal for any font that is included in their collection so there are definitely a large number of open source fonts (including those that use SIL OFL) without RFN's. If the perceived problems in that list above are not widespread and therefore largely irrelevant then this is not an issue. I am hoping to use this thread to avoid trading one set of problems for another, or at the very least balancing these problems so as to achieve the more optimal set for all.
Thank you very much for this feedback. I approached them simply for feedback at the urging of a user and because it was a potential source for further information from individuals who might be better versed in font licensing and the DFSG than our project authors are. I invite anyone who has knowledge / experience / expertise in this area to weigh in. We are trying to probe this issue from the standpoint of all stakeholders. Thanks again. |
|
@davelab6 Dave, can you remind me of the specific issue and regions involved with the public domain contribution of changes made by the DejaVu project to the Bitstream Vera Sans Mono project? As I recall there were legal concerns with redistribution in some European countries that resulted from this decision. Since those contributions are a permanent part of our upstream source, the public domain issue will remain and I am wondering if there is any downside to simply using the same approach for our own contributions here. That is, we eliminate the Hack "Open Font License" co-licensure approach, revert to the Bitstream Vera license with public domain contributions to the upstream source by both the DejaVu group and our group. |
|
I'll add in this thread as another reserved font name consideration, that the transition to an automated build from UFO source was in part to encourage and better support derivative fonts that are built with open source tooling so that downstream projects can take advantage of a simple approach to rebuild modified versions of the typeface using the same approach (including the manual hinting adjustments and table fixes) that we will be using upstream. I've received communication from a number of interested individuals who would like to maintain the association with the Hack upstream by naming their derivative with a string added to "Hack" (e.g. "Hack Code", "Hack Ligature"). Our current license language prevents this and I would favor an approach that, if we maintain a reserved font name, the reserved name is simply "Hack" and not any name containing "Hack". I feel that derived extensions of the upstream name should be permitted. They establish a relationship with the upstream source yet distinguish the project as a downstream derivative which can be desirable. We are currently trying to define and lay on paper what defines "Hack" to the authors of the project so that we can better distinguish for ourselves and potential contributors what is acceptable in the upstream and what is more appropriate downstream. This is a large part of the next major release of the typeface. |
|
I'm back from vacation and I've now read the discussion here and on the debian-legal mailing list. I understand the QA issues that led @chrissimpkins to use the RFN clause. I can think of a couple of intermediate solutions that could allow the distribution of 3rd party builds of the font, but I admit I can't tell how legally sound they are. One possibility is to bind the RFN to the UFO sources, that is: allow redistribution of the font under the Hack name if it has been built from the pristine upstream UFO files, regardless of the build process. If this is still too loose, a minimum version of the build tools could be specified, so the font isn't built with outdated tools. Personally I would prefer the RFN clause to be dropped entirely. I agree with Francesco Poli when he says that license restrictions shouldn't be used to overcome technical issues. |
@paride I reviewed the Debian documentation links that you added to our source build IR thread. Are you defined as a "Debian Developer" for the Hack package or is it necessary to use the mentee/sponsor relationship for this package? I am trying to get at how we receive a more 'formal' recommendation about licensing requirements from the Debian project. I am not a huge fan of an approach that leads to license modifications, in part with an intent to help you address these issues for source builds, then a new package proposal to whoever the approving body is on the Debian side without knowledge of whether the changes (1) address the problem that you identified; (2) create new problems. What I am looking for is a suggestion for any license modifications that will definitely meet DFSG standards so that we can weigh them in order to arrive at a decision about how to approach the license modifications. Here is my take on the DFSG: Free RedistributionThe license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale. Met in current license Source CodeThe program must include source code, and must allow distribution in source code as well as compiled form. Met in current license Derived WorksThe license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. Met in current license Integrity of The Author's Source CodeThe license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software. (This is a compromise. The Debian group encourages all authors not to restrict any files, source or binary, from being modified.) This is likely the area of contention with RFN, the need to 'explicitly permit distribution of software from modified source code' may be something that we need to draft into a new license? It sounds as though RFN is acceptable according to this language 'The license may require derived works to carry a different name or version number from the original software. ' No Discrimination Against Persons or GroupsThe license must not discriminate against any person or group of persons. There is no language in the current license suggesting that this is problematic No Discrimination Against Fields of EndeavorThe license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research. There is no language in the current license suggesting that this is problematic Distribution of LicenseThe rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties. There is no language in the current license suggesting that this is problematic License Must Not Be Specific to DebianThe rights attached to the program must not depend on the program's being part of a Debian system. If the program is extracted from Debian and used or distributed without Debian but otherwise within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the Debian system. There is no language in the current license suggesting that this is problematic License Must Not Contaminate Other SoftwareThe license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be free software. There is no language in the current license suggesting that this is problematic Example LicensesThe "GPL", "BSD", and "Artistic" licenses are examples of licenses that we consider "free". Thoughts about the next step for Debian? |
|
Best approach when you want "assurance" from Debian regarding licensing interpretation is to present the issue to the debian-legal mailinglist. People in Debian may still disagree, but pointing to a prior discussion in the debian-legal list is helpful to avoid recurring uncertainty. Obviously if you want something bullt proof then the only way is to bring it to court. And bring it to court in lots of varying jurisdictions wordwide. But I highly doubt you need that :-) |
|
My point is: You can discuss the issue here, but beware that you then only get comments from those in Debian who happen to know about this discussion AND care enough to register with Github and contribute here. When in Rome, do as the romans... |
|
@jonassmedegaard at your suggestion, this has already been done: #271 (comment) The sum total information back from that list is included in this thread as copy/paste information. Here is the first message in the thread archive: https://lists.debian.org/debian-legal/2017/08/msg00005.html |
|
@chrissimpkins I'm not a Debian Developer, so I had to find a sponsor in order to have the package uploaded to the package archive. The sponsor was @fabiangreffrath, let's see if we can get his opinion. Another Debian Developer that cares about Debian fonts and that I find very careful and well informed when it comes to licensing issues is @pabs3. I also wrote an email to the pkg-fonts-devel mailing list (the mailing list of the team maintaining font packages in Debian), pointing to this thread. I'll keep you posted. |
|
@paride Sounds great. Let's see if they have any feedback. Thanks Paride! |
|
@spstarr are there any build from source licensing issues for Fedora that we need to address as part of this conversation? |
|
There is some feedback in the thread here:
https://lists.debian.org/msgid-search/edf6d92a-e614-4c46-ad1b-c735e1798b2f@Spark
I agree with the comments from Francesco Poli.
Some more comments and questions:
I would avoid using the reserved font name clause from SIL OFL.
I'd suggest dropping item 3 of the license (copied from SIL OFL
AFAICT), it would be non-free if it wasn't trivial to work around it
and thereby render it meaningless.
…--
bye,
pabs
http://bonedaddy.net/pabs3/
|
|
@pabs3 thank you very much for your feedback Paul. This is very helpful. Based upon those suggestions here is what I am under the impression that you suggest for the Hack portion of the license (i.e. in addition to the Bitstream Vera license): DEFINITIONS"Author" refers to any designer, engineer, programmer, technical writer or other person who contributed to the Font Software. PERMISSION AND CONDITIONSPermission is hereby granted, free of charge, to any person obtaining a copy of the fonts accompanying this license ("Fonts") and associated source code, documentation, and binary files (the "Font Software"), to reproduce and distribute the modifications to the Bitstream Vera Font Software, including without limitation the rights to use, study, copy, merge, embed, modify, redistribute, and/or sell modified or unmodified copies of the Font Software, and to permit persons to whom the Font Software is furnished to do so, subject to the following conditions: (1) The above copyright notice and this permission notice shall be included in all modified and unmodified copies of the Font Software typefaces. These notices can be included either as stand-alone text files, human-readable headers or in the appropriate machine-readable metadata fields within text or binary files as long as those fields can be easily viewed by the user. TERMINATIONThis license becomes null and void if any of the above conditions are not met. |
|
@pabs3 With the removal of item 2, is there any concern about the language in the text above and the requirement that "The license must explicitly permit distribution of software built from modified source code." that is contained in the DFSG? Item 2 included the following text that was an explicit declaration of the types of modifications that were part of the reserved font name issue. "The Font Software may be modified, altered, or added to, and in particular the designs of glyphs or characters in the Fonts may be modified and additional glyphs or characters may be added to the Fonts, only if the fonts are renamed to names not containing the word "Hack"." The license does maintain this line which seems to me to support that requirement: "including without limitation the rights to use, study, copy, merge, embed, modify, redistribute, and/or sell modified or unmodified copies of the Font Software" |
|
@chrissimpkins I defer to Tom 'spot' Callaway on licensing. |
|
@spstarr be willing to poke him to see if he would be willing to provide feedback as we prepare a new license? yours is the only other package that intends to build from source as far as I know at the moment |
|
The new Hack license looks almost OK to me, except that it basically is
now a custom license that is almost equivalent to the more well
understood MIT and BSD licenses. License proliferation is a practice
that has long been understood to be a bad idea.
If you don't want to switch, some comments:
The term "Author" is no longer used in the license, so you can now
remove that from the definitions section and then remove the empty
definitions section.
I would suggest removing the mention of Bitstream Vera in it, unless
there is a good reason to do so.
The permissions given don't seem to apply to the "Fonts", only to the
"Font Software". You may want to fix that by changing to the more
generic term "the work".
The termination section isn't needed because that is simply how
copyright law works. Everything is restricted by default and if the
license isn't complied with then no permissions are conferred.
…--
bye,
pabs
http://bonedaddy.net/pabs3/
|
|
I would love to switch, but we are bound by the upstream Bitstream Vera license and must maintain this with the project. That has been the source of the problems or we would have gone with an accepted free license from the get go. One of the tasks in the "addendum" to the Bitstream Vera license is how to indicate acceptable practices with the modifications from the original Bitstream source. DejaVu used a phrase like that "modifications to the Bitstream..." to indicate that their modifications were committed to the public domain. This was how I chose to approach our (further downstream) changes. This has the effect of (1) limiting downstreams due to licensing issues such as those raised here; (2) creating a long sequence of co-licensure statements as the downstream line lengthens. I do not know how to approach those issues. Are you suggesting that adding MIT or BSD as a co-license approach to the Bitstream license would be acceptable in place of the entire "Hack Open Font License" + "Bitstream Vera License"? This would be a good solution if this is possible.
👍 |
|
I would like to see this dealt with as MIT + some addendum to cover Bitstream Vera's bits (pun intended). From a user's perspective, I don't have to think about what MIT means, so I can go straight ahead to the addendum. |
|
Thanks for the feedback @burodepeper. I am not opposed to this move, the question is whether the two licenses jive with each other. I have never used MIT in a co-licensure setting. This would amount to MIT covering Hack changes to Bitstream licensed upstream with public domain DVSM contributions. It is still complex. Is it better? Will investigate a bit more and leave open for anyone else who might have insight. Notably, @burodepeper your suggestion appears to be in support of dropping the reserved font name. This is correct? |
|
I will be at typecon this week so I'll see if the folks from Monotype there
could shed any light on the viability of option a.
https://youtu.be/eDhXgoFUy2w
…On Aug 24, 2017 8:59 AM, "Chris Simpkins" ***@***.***> wrote:
@davelab6 <https://github.com/davelab6> thanks! was worth a try. I did
try to contact Monotype at one point and was bounced around, didn't get
anywhere.
Sounds like we may need to get drawing!
Thanks Dave.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#271 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAP9y83V7Q_5fXfcTNaiQKkKg4KeoUXqks5sbXOtgaJpZM4O5Mah>
.
|
|
Thanks Dave! Let us know if you come up with any contacts there who know about Bitstream licensing. Would love to see if they would be willing to consider changes. |
|
For anyone who has an understanding of copyright laws: What are the legal consequences of taking my name out of the copyright for the Hack portion of the licensing and converting this to something along the lines of "Authors" or "Project Authors" or "Source Foundry Authors". A Github organization is not, as far as I know, a valid legal entity to hold copyright. How would such a change influence downstream licensing issues for derivatives and licensing question resolution for Hack? If a name has to be associated with the copyright, could this be something along the lines of "Christopher Simpkins and Authors"? I am the only copyright holder in the license but that is not appropriate given the contributions of all other project authors. The reason that this hasn't changed to date is that I don't understand how this works legally for issues with resolution of license concerns (now and well into the future). I have essentially used this as a "primary contact" for these issues. |
|
IANAL. AIUI, these notices are just window dressing; they aren't required
for copyrights to adhere to works that are subject to copyrights, and
making notices that aren't accurate doesn't diminish anyone's copyrights or
standing.
|
Interesting. That argues for completely eliminating the copyright statement in these licenses if it serves no purpose. |
|
The notices are still useful because they are documentation of the
copyright status of the files and are often transferred along with the
files when another project copies or forks them.
Some folks even advocate keeping per-file copyright and license info:
http://lu.is/blog/2012/03/17/on-the-importance-of-per-file-license-information/
…--
bye,
pabs
http://bonedaddy.net/pabs3/
|
IANAL, AFAIUI there must be someone to grant the license, i.e. the copyright holder. |
|
@pabs3 @fabiangreffrath Thank you both for your input!
👍
This was my understanding too, that this must be a legal entity (not necessarily a human as you imply with 'someone' but something with a legal basis as copyright holder (e.g. business, organization, human). There will be a lawyer out there who understands this. Is anyone aware of pro bono legal services that are available to libre open source projects by any of the free software organizations out there? |
|
For all future contributors here, we will take it as a given that you are not a lawyer/do not have any specific legal expertise in this area unless you specify that you are and do. No need to qualify your comments with this caveat. I understand that these are opinions and not legal recommendations. Please feel free to weigh in freely with your own opinions and understanding of these issues. The conversation has been very helpful. |
|
Software Freedom Conservancy comes to mind, but I think you have to be
a member project or have an agreement with them to get legal advice.
…--
bye,
pabs
http://bonedaddy.net/pabs3/
|
|
Thank you! That appears to be correct. And you do appear to need to be a member project. Here is what they say:
Will look into this in more detail. |
|
Ian Jackson on the debian-legal mailing list:
|
|
@texhex any comments before we make a decision about this? |
|
Proposed new license (MIT + Bitstream Vera) that will take effect as of the version 3.0 release of Hack: LicenseThe work in the Hack project is Copyright 2017 Source Foundry Authors and licensed under the MIT License The work in the DejaVu project was committed to the public domain. Bitstream Vera Sans Mono Copyright 2003 Bitstream Inc. and licensed under the Bitstream Vera License with Reserved Font Names "Bitstream" and "Vera" MIT LicenseCopyright (c) 2017 Source Foundry Authors Permission is hereby granted, free of charge, to any person obtaining a copy The above copyright notice and this permission notice shall be included in all THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR BITSTREAM VERA LICENSECopyright (c) 2003 by Bitstream, Inc. All Rights Reserved. Bitstream Vera is a trademark of Bitstream, Inc. Permission is hereby granted, free of charge, to any person obtaining a copy of the fonts accompanying this license ("Fonts") and associated documentation files (the "Font Software"), to reproduce and distribute the Font Software, including without limitation the rights to use, copy, merge, publish, distribute, and/or sell copies of the Font Software, and to permit persons to whom the Font Software is furnished to do so, subject to the following conditions: The above copyright and trademark notices and this permission notice shall be included in all copies of one or more of the Font Software typefaces. The Font Software may be modified, altered, or added to, and in particular the designs of glyphs or characters in the Fonts may be modified and additional glyphs or characters may be added to the Fonts, only if the fonts are renamed to names not containing either the words "Bitstream" or the word "Vera". This License becomes null and void to the extent applicable to Fonts or Font Software that has been modified and is distributed under the "Bitstream Vera" names. The Font Software may be sold as part of a larger software package but no copy of one or more of the Font Software typefaces may be sold by itself. THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL BITSTREAM OR THE GNOME FOUNDATION BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM OTHER DEALINGS IN THE FONT SOFTWARE. Except as contained in this notice, the names of Gnome, the Gnome Foundation, and Bitstream Inc., shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Font Software without prior written authorization from the Gnome Foundation or Bitstream Inc., respectively. For further information, contact: fonts at gnome dot org. |
|
The above license proposal addresses:
The new license does not address:
|
|
Thanks to all who weighed in here and on the debian-legal list. I really appreciate all of your feedback and assistance! Feel free to post additional comments if there are any concerns about the proposed license in #271 (comment) |
|
I don't get it, why not use only the Vera license?
…On Sep 5, 2017 2:10 AM, "Chris Simpkins" ***@***.***> wrote:
Thanks to all who weighed in here and on the debian-legal list. I really
appreciate all of your feedback and assistance!
Feel free to post additional comments if there are any concerns about the
proposed license in #271 (comment)
<#271 (comment)>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#271 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAP9y2miUGiZxyqpr_I7OSPMdmSmC1cMks5sfJ-agaJpZM4O5Mah>
.
|
|
Does that not imply that our changes to BSV source are committed to public domain? My understanding (from conversation with you) is that this is a problem? |
|
@davelab6 I think that the definitions contained in the Bitstream license are going to be the issue Dave. From the Bitstream license:
It only covers "Fonts" and the "documentation files" in the repository. I read "documentation" as actual documentation (e.g. text files to support use of software) and not other source/script files. I read "Fonts" as font binaries and font source. My opinion is that it would be useful to provide a general explicit license that applies to all other software contained in the repo that were additions made as part of this project. MIT expands the "Fonts" definition to "Software" which seems more appropriate for the contents of the repository. They both contain the term "Documentation". Is anyone aware if the intent with the "Documentation" definition in OSS is to license actual documentation files (as in text that is intended to be read to support use/installs/testing/modifications/etc) and not associated "software" that is part of the licensed project? |
|
hehehe okay, its a fair point; the definition of "associated documentation
files" as "Font Software" stinks :)
What I meant was that your contributions would be under BSVL, not Public
Domain; the only PD parts would be those inherited from DJV.
|
|
Got it! Thanks again for weighing in. This conversation has been really helpful! |
|
License updated in source, LICENSE.md, and README.md files as of 0f109a2 |
|
@paride Paride, any updates on where things stand with the Debian package for Hack? Are there still outstanding build dependencies that remain under review? |
|
@chrissimpkins fontmake is finally landing in Debian, it's in the final queue for inclusion (https://ftp-master.debian.org/new.html). I think it's a matter of days, then I'll start working at building and packaging Hack 3. |
|
@paride Just leave me a note when the package is ready for uploading. ;) |
|
@paride fantastic news!! thanks for all of your help with this Paride and Fabian. I now understand the extent of work involved by maintainers and many others to make this happen. It is greatly appreciated. Glad to hear that the changes here made this possible for Debian based distros. Let me know if I can do anything else on our end. |
The Hack license structure has led to a number of concerns that have been filed in issue reports on this repository. The most recent of these was raised by the Hack package maintainer on the Debian Linux distro in this thread: #255 (comment) .
In response to @paride's concerns (and at the prompting of @jonassmedegaard), I reached out to the Debian debian-legal mailing list for clarification vs the Debian Free Software Guidelines. This conversation is being archived in the debian-legal mailing list here: https://lists.debian.org/debian-legal/ and I will try to update with salient points as I can in this thread so that this conversation does not require subscription to the Debian mailing list for any interested users.
I want to be very transparent with discussions about these reasonably complicated (to me) legal issues with font licensure given the nature of this project and the history of licenses used in our upstream source. I certainly do not, and I suspect that project contributors to date do not, possess expertise across the legal interactions with the license structure in place and other legal/guideline/regulatory issues that exist out there across modification, redistribution, and end user applications X all platforms X all corporation/organization policies X all countries.
I'd like to open up this thread to hold a conversation about how we can try to create something better here (will not be perfect, see constraints below), and perhaps gain some insight into the problems that exist with FLOSS licensing of downstream font forks which might serve other FLOSS typeface projects, including all forks of Hack, down the road.
Hack Source Background
The Hack project is a fork of previous typeface projects. It includes all of the Bitstream Vera Sans Mono glyphs and select glyph sets from the DejaVu Sans Mono project (which is itself a fork of Bitstream Vera Sans Mono).
Bitstream Vera Sans Mono was licensed under the Bitstream Vera license. Bitstream is a defunct company. The Bitstream Vera license still maintains Bitstream Inc as the copyright holder for this license.
DejaVu Sans Mono modifications to the Bitstream Vera typeface were committed to the public domain. Though this sounds permissive and "benign", @davelab6 informs me that this leads to certain use restrictions in some countries and based upon my understanding of the conversation plays a role in the lack of inclusion of DJVSM in the Google Fonts project.
Source changes to these upstream projects are documented in our CHANGELOG.md document.
Hack License Background
The Hack license is available for review here: https://github.com/source-foundry/Hack/blob/master/LICENSE.md
The Hack license comes in three parts. The Bitstream Vera license must be maintained based upon the language and includes reserved font names for "Bitstream" and "Vera" along with other stipulations.
We acknowledge the public domain contributions of the DejaVu group in the statement:
The Hack Open Font License was drafted in an attempt to include language similar to the SIL OFL. In this co-license structure we maintain the reserved font name of "Hack". At the request of a representative from the SIL team, we did not use the commonly used SIL OFL for co-licensure. This is the source of some of the problems that have recently come up and further issues that we have identified to be unintended consequences in the future. I am sure that we have not identified all potential problems on the project developer/redistributor/end user sides of this chain.
On behalf of the project authors here, I believe that I speak for all when I say that we want to support the principles of libre open software development so that you can run, copy, distribute, study, change and improve the software:
Please help us to understand how we can accomplish these goals in light of the above constraints. We are open to license modifications with these goals in mind.
Further Reading for Interested Users
These provide background on a range of issues/considerations across font licensing for FLOSS and commercial closed source projects for those interested.
cc: @burodepeper @texhex
TODO:
The text was updated successfully, but these errors were encountered: