search

source-foundry / Hack

A typeface designed for source code
http://sourcefoundry.org/hack/
Other
16.46k stars 615 forks source link

Proposal: Modification of the Hack license #271

Closed chrissimpkins closed 7 years ago

chrissimpkins commented 7 years ago

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: https://github.com/source-foundry/Hack/issues/255#issuecomment-316414866 .

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:

DejaVu modifications of the original Bitstream Vera Sans Mono typeface have been committed to the public domain.

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:

chrissimpkins commented 7 years ago

From my comment in the debian-legal mailing list thread:

The impetus for the reserved font name issue is simply QA.  We perform a great deal of manual testing prior to releases that cannot be fully automated in the current era of font development software.  The exact build process that we use is the one that we have validated and want to support.  One of my worries if we loosen this requirement (i.e. fully remove the reserved font name) is that we will be approached on the repository about all build issues assuming that we will be able to troubleshoot the issue for teams that elect to build with a different approach.  There are numerous other ways to compile the fonts out there and the OpenType tables as well as the hinting on the fonts can, and in many cases likely will, change for those who do not appreciate these issues.  It is a  downside in the typeface software development area that is in need of repair.  But it is a reality that we face.

chrissimpkins commented 7 years ago

Response from Francesco Poli on debian-legal mailing list:

[...] Downstream open source project font licensing from the days prior to SIL OFL (and to some degree even after that period) is a bit of a quagmire.

Hello, I agree that font licensing is a quagmire.

Well, I even go further and personally think that it is a real mess: I wish more fonts were simply released under the terms of wide-spread and well understood licenses (such as the Expat/MIT license or the GNU GPL v2 + font exception)... Doing so would spare a good number of headaches to many people!

Item 2 is where the reserved font name declaration is located. I have been considering modification of the language here to permit forks to use “Hack” in the name, but not “Hack” alone for a forked typeface.

Personally speaking, I would encourage you to at least relax this restriction (or, even better, to drop it entirely). That way, only one name (or no name) would be forbidden for derivative fonts and everything would be simpler...

It is a  downside in the typeface software development area that is in need of repair.  But it is a reality that we face.

I personally think that technical issues should not be worked around by imposing licensing restrictions. If typeface development tools need to be improved in order to get better QA, then I hope they can be enhanced from a technical point of view. In the meanwhile, licensing restrictions should not be introduced to compensate for technical limitations. This is my personal opinion. I hope this helps. Bye.

n7s commented 7 years ago

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.

chrissimpkins commented 7 years ago

@n7s Thank you very much for weighing in Nicolas. I greatly appreciate it.

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".

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):

  • Avoids collisions - it greatly reduces the likelihood that a Modified Version would get confused with the Original Version, whether by an end user, someone bundling the font into a separate app or collection, or an application attempting to render a document that specifies a particular font.
  • Protects authors - it requires any font that bears the RFNs retain the functionality and quality of the Original Version.
  • Minimizes support - it enables authors to adequately support their fonts without the burden of troubleshooting fonts bearing the same name that might have been poorly modified.
  • Encourages derivatives - it encourages separately-named branches to exist and be properly identified so that new, interesting enhancements can get reviewed and eventually merged back into the main project.

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.

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.

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.

chrissimpkins commented 7 years ago

@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.

chrissimpkins commented 7 years ago

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.

paride commented 7 years ago

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.

chrissimpkins commented 7 years ago

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 Redistribution

The 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 Code

The program must include source code, and must allow distribution in source code as well as compiled form.

Met in current license

Derived Works

The 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 Code

The 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 Groups

The 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 Endeavor

The 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 License

The 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 Debian

The 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 Software

The 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 Licenses

The "GPL", "BSD", and "Artistic" licenses are examples of licenses that we consider "free".

Thoughts about the next step for Debian?

jonassmedegaard commented 7 years ago

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 :-)

jonassmedegaard commented 7 years ago

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...

chrissimpkins commented 7 years ago

@jonassmedegaard at your suggestion, this has already been done: https://github.com/source-foundry/Hack/issues/271#issuecomment-322834035

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

paride commented 7 years ago

@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.

chrissimpkins commented 7 years ago

@paride Sounds great. Let's see if they have any feedback. Thanks Paride!

chrissimpkins commented 7 years ago

@spstarr are there any build from source licensing issues for Fedora that we need to address as part of this conversation?

pabs3 commented 7 years ago

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/

chrissimpkins commented 7 years ago

@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 CONDITIONS

Permission 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.

TERMINATION

This license becomes null and void if any of the above conditions are not met.

chrissimpkins commented 7 years ago

@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"

spstarr commented 7 years ago

@chrissimpkins I defer to Tom 'spot' Callaway on licensing.

chrissimpkins commented 7 years ago

@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

pabs3 commented 7 years ago

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/

chrissimpkins commented 7 years ago

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.

almost OK

👍

burodepeper commented 7 years ago

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.

chrissimpkins commented 7 years ago

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?

chrissimpkins commented 7 years ago

@davelab6 would a change in our license away from Hack Open Font license with reserved font name + public domain DVSM + Bitstream Vera license

to

MIT license (for Hack changes - no more reserved font name for Hack) + public domain DVSM + Bitstream Vera license

get us any closer to consideration for a Google Fonts release? Based upon our previous conversations I don't believe that this will be the case but figured worth a try. My understanding was that public domain DVSM work is a red line, and possibly Bitstream and Vera RFN?

davelab6 commented 7 years ago

Nope, won't make a difference. The only things that can work will be to either (a) work with Monotype to get vera rereleased under ofl with an rfn on vera, then find the owners of all the dejavu parts that were contributed under "public domain"and get them to of those parts, and same for all the hack parts; and then have it all under ofl with no rfn on the name used; or (b) get a blank file and get drawing, and make a new design that is fresh.

There's already a proprietary font that started from dissatisfaction with the proportionally spaced Vera Sans and went down the (b) path.

On Aug 23, 2017 7:10 PM, "Chris Simpkins" notifications@github.com wrote:

@davelab6 https://github.com/davelab6 would a change in our license away from Hack Open Font license with reserved font name + public domain DVSM + Bitstream Vera license

to

MIT license (for Hack changes - no more reserved font name for Hack) + public domain DVSM + Bitstream Vera license

get us any closer to consideration for a Google Fonts release? Based upon our previous conversations I don't believe that this will be the case but figured worth a try. My understanding was that public domain DVSM work is a red line, and possibly Bitstream and Vera RFN?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/source-foundry/Hack/issues/271#issuecomment-324487851, or mute the thread https://github.com/notifications/unsubscribe-auth/AAP9y6bE31S9Qii-GS9CncsLUN-DiHYsks5sbLFSgaJpZM4O5Mah .

chrissimpkins commented 7 years ago

@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.

davelab6 commented 7 years ago

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" notifications@github.com 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 https://github.com/source-foundry/Hack/issues/271#issuecomment-324627513, or mute the thread https://github.com/notifications/unsubscribe-auth/AAP9y83V7Q_5fXfcTNaiQKkKg4KeoUXqks5sbXOtgaJpZM4O5Mah .

chrissimpkins commented 7 years ago

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.

chrissimpkins commented 7 years ago

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.

davelab6 commented 7 years ago

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.

chrissimpkins commented 7 years ago

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.

pabs3 commented 7 years ago

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/

fabiangreffrath commented 7 years ago

Interesting. That argues for completely eliminating the copyright statement in these licenses if it serves no purpose.

IANAL, AFAIUI there must be someone to grant the license, i.e. the copyright holder.

chrissimpkins commented 7 years ago

@pabs3 @fabiangreffrath Thank you both for your input!

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.

👍

there must be someone to grant the license, i.e. the copyright holder.

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?

chrissimpkins commented 7 years ago

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.

pabs3 commented 7 years ago

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/

chrissimpkins commented 7 years ago

@pabs3

Thank you! That appears to be correct. And you do appear to need to be a member project. Here is what they say:

Since projects, upon joining, become organizationally part of Conservancy, Conservancy can provide basic legal services to its member projects through Conservancy's own General Counsel, outside counsel, and pro-bono attorneys. For example, Conservancy assists its projects in handling issues related to trademark registration, trademark policy development and licensing, trademark enforcement, copyright licensing and enforcement, and non-profit governance questions and issues.

Will look into this in more detail.

chrissimpkins commented 7 years ago

Ian Jackson on the debian-legal mailing list:

From Debian's point of view, the licence you provide is adequate for us to be able to include the fonts in Debian. However, the reserved font name restriction would almost certainly mean that we would have to rename the fonts.

Debian has a long history of dealing with upstreams who restrict the ability of Debian to distribute a modified version under the usual name. For example, for many years, Debian's Firefox package was called `iceweasel' (and all the Firefox branding was removed), because the Mozilla Foundation (who own the trademark "Firefox") insisted on prior approval of all changes.

Debian is not likely to accept a restriction on modifying glyphs. We consider that Debian (and its downstreams and users) must be free to make changes - even changes that upstreams disapprove of. For fonts, the need to change glyphs is not theoretical: when I was an Ubuntu developer I personally modified a font in order to correct an erroneous glyph in some Georgian character, in response to a bug report from a user.)

So, if you would like Debian to distribute your fonts under names which advertise your project as the origin, then you should grant Debian permission to do so.

I hope this has been a useful perspective.

chrissimpkins commented 7 years ago

@texhex any comments before we make a decision about this?

chrissimpkins commented 7 years ago

Proposed new license (MIT + Bitstream Vera) that will take effect as of the version 3.0 release of Hack:

License

The 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 License

Copyright (c) 2017 Source Foundry Authors

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

BITSTREAM VERA LICENSE

Copyright (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.

chrissimpkins commented 7 years ago

The above license proposal addresses:

The new license does not address:

chrissimpkins commented 7 years ago

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 https://github.com/source-foundry/Hack/issues/271#issuecomment-327044751

davelab6 commented 7 years ago

I don't get it, why not use only the Vera license?

On Sep 5, 2017 2:10 AM, "Chris Simpkins" notifications@github.com 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) https://github.com/source-foundry/Hack/issues/271#issuecomment-327044751

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/source-foundry/Hack/issues/271#issuecomment-327046350, or mute the thread https://github.com/notifications/unsubscribe-auth/AAP9y2miUGiZxyqpr_I7OSPMdmSmC1cMks5sfJ-agaJpZM4O5Mah .

chrissimpkins commented 7 years ago

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?

chrissimpkins commented 7 years ago

@davelab6 I think that the definitions contained in the Bitstream license are going to be the issue Dave.

From the Bitstream license:

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 ...

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?

davelab6 commented 7 years ago

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.

chrissimpkins commented 7 years ago

Got it! Thanks again for weighing in. This conversation has been really helpful!

chrissimpkins commented 7 years ago

License updated in source, LICENSE.md, and README.md files as of https://github.com/source-foundry/Hack/commit/0f109a294a4edb40060ac0089bd85cfb68d56eee

chrissimpkins commented 6 years ago

@paride Paride, any updates on where things stand with the Debian package for Hack? Are there still outstanding build dependencies that remain under review?

paride commented 6 years ago

@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.