Werner LEMBERG | 13 Jan 2012 20:13
Picon

[ft] FreeType License and patents


Folks,

I've recently stumbled across the following paragraph from the Apache
license 2.0 (http://www.apache.org/licenses/LICENSE-2.0.html):

  3. Grant of Patent License.

  Subject to the terms and conditions of this License, each
  Contributor hereby grants to You a perpetual, worldwide,
  non-exclusive, no-charge, royalty-free, irrevocable (except as
  stated in this section) patent license to make, have made, use,
  offer to sell, sell, import, and otherwise transfer the Work, where
  such license applies only to those patent claims licensable by such
  Contributor that are necessarily infringed by their Contribution(s)
  alone or by combination of their Contribution(s) with the Work to
  which such Contribution(s) was submitted.  If You institute patent
  litigation against any entity (including a cross-claim or
  counterclaim in a lawsuit) alleging that the Work or a Contribution
  incorporated within the Work constitutes direct or contributory
  patent infringement, then any patent licenses granted to You under
  this License for that Work shall terminate as of the date such
  litigation is filed.

Looking up the FreeType License I've found out that we don't have such
a clause...

I would like to add something similar, with the exception that code
especially marked as patented within the FreeType source code is not
covered.
(Continue reading)

Antoine Leca | 16 Jan 2012 18:51

Re: [ft] FreeType License and patents

Eric Rannaud écrivit :
> On Fri, Jan 13, 2012 at 11:16 AM, Dave Crossland <dave <at> lab6.com> wrote:
>> On 13 January 2012 20:13, Werner LEMBERG <wl <at> gnu.org> wrote:
>>> I would like to add something similar, with the exception that code
>>> especially marked as patented within the FreeType source code is not
>>> covered.
>>>
>>> Comments?
>> Why not just switch to Apache?
> Apache2 is not compatible with GPLv2
... neither is the FreeType License (FTL), which is the very reason for
the complex licensing if I understand correctly (docs/LICENSE.TXT)

> However, by switching to Apache2, or by adding such a clause, you will
> likely make Freetype harder to use for some projects that may have
> liked the current license better. (e.g. OpenBSD: they don't like
> Apache2, and maybe would reject Freetype license + patent grant.)
Are you sure OpenBSD is using the Freetype library under the FreeType
License (i.e., with explicit attribution a.k.a "advertising")?

Antoine
Werner LEMBERG | 17 Jan 2012 09:26
Picon

Re: [ft] [ft-devel] FreeType License and patents


> Are you willing to do the work to make sure no FreeType contributor
> currently has a patent on code they have contributed?

This should be doable, given that there are just a handful of
contributors who added longer, non-trivial stuff.

     Werner
Werner LEMBERG | 17 Jan 2012 09:28
Picon

Re: [ft] FreeType License and patents

>>>> Comments?
>>>
>>> Why not just switch to Apache?

Well, we have our special advertisement clause, and I would like to
stay with it.

>> However, by switching to Apache2, or by adding such a clause, you
>> will likely make Freetype harder to use for some projects that may
>> have liked the current license better. (e.g. OpenBSD: they don't
>> like Apache2, and maybe would reject Freetype license + patent
>> grant.)

This is life.  To please everyone, we have to make it public domain,
probably.  But I definitely don't do this.

     Werner
David Turner | 17 Jan 2012 10:25
Picon
Favicon
Gravatar

Re: [ft] [ft-devel] FreeType License and patents

Hello,


Just to make it clear, I'm too in favor of adding an Apache2-like patent clause to the license.
And for the sake of full-disclosure, my employer does releases quite a large amount of Apache-2 licensed code.

On Fri, Jan 13, 2012 at 8:34 PM, Eric Rannaud <eric.rannaud <at> gmail.com> wrote:
On Fri, Jan 13, 2012 at 11:16 AM, Dave Crossland <dave <at> lab6.com> wrote:
> On 13 January 2012 20:13, Werner LEMBERG <wl <at> gnu.org> wrote:
>> I would like to add something similar, with the exception that code
>> especially marked as patented within the FreeType source code is not
>> covered.
>>
>> Comments?
>
> Why not just switch to Apache?

Switching to Apache2 is an interesting possibility, but such a license change means getting the approval of all contributors to the project. Given FreeType's age, that might be challenging and/or time-consuming (e.g. what are the chances that all email addresses in our copyright disclaimers are still valid).

An easier approach would be to ask for all future contributions to be covered by "FreeType License 1.1", which would be equal to the actual one, plus a patent clause. This allows us to keep the existing code just as-is in case we don't have a contact or agreement with the original author of some piece of code. Also makes explaining the change easier.

We can still continue to contact contributors to ask them their opinion/agreement on switching their existing code to Apache 2 though, and maybe later switch to it.
 
Apache2 is not compatible with GPLv2 notably because of this
particular patent clause (that's the general agreement anyway -- some
see GPLv2 as already having an equivalent clause, albeit less
explicit). Apache2 is compatible with GPLv3, however.


GPL is already not an issue since the original FreeType license is not compatible either (due to the credit clause). That's why we dual-license the library by the way. I don't see why anything would change with the proposed license update.
 
So you want to be careful adding that kind of exception, you may
create a number of new license compatibility questions.

If you want such a patent grant clause, you might as well have
Freetype released under Apache2 and continue to make it available
under GPLv2. At least license compatibility is then clear.

However, by switching to Apache2, or by adding such a clause, you will
likely make Freetype harder to use for some projects that may have
liked the current license better. (e.g. OpenBSD: they don't like
Apache2, and maybe would reject Freetype license + patent grant.)

I'm ok with OpenBSD rejecting an updated license (you can't please all people in the world after all). I still can't find any official reason why they're opposed to Apache2, but they can still use the existing FreeType code and back-port security fixes manually if they want. They've been doing it with Apache 1 for years and nobody's been greatly impacted by it as far as I understand.

It might be a good thing to bump the library's minor version number for the license change to make this back-tracking easier.

- David

_______________________________________________
Freetype mailing list
Freetype <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype
Jochen Jägers | 17 Jan 2012 14:27
Picon

[ft] ugly output with freetype and gtk

Hello,

i'm developing an embedded system for home automation based on
gnu/linux.

The userinterface is build in HTML/Javascript displayed in a fullscreen
browser based on webkit-gtk with freetype as font-backend.

I get ugly output on some glyphs. I've made a screenshot to illustrate
this ugly output. 

http://tinypic.com/r/4uwbkl/5

Look at "Standort" for example. The "d" has two pixels in the top left
corner. I get this ugly output with different types and different file
formats. The text in other gtk-based applications look ugly too.

I've tryed many things i found on the internet like different settings
for hinting, lcdfilter and subpixels but nothing worked.

I've also tryed different versions of freetype (2.4.4 and 2.4.8) with
the same ugly result.

At the moment I've no idea to solve this problem.
Do you have any idea what i can try?

Greetings
Jochen Jägers

_______________________________________________
Freetype mailing list
Freetype <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype
Werner LEMBERG | 17 Jan 2012 14:49
Picon

Re: [ft] ugly output with freetype and gtk


> I get ugly output on some glyphs.  [...]
>
> Look at "Standort" for example.  The "d" has two pixels in the top
> left corner.  I get this ugly output with different types and
> different file formats.  The text in other gtk-based applications
> look ugly too.

This is not sufficient information.  First of all, what font?  If you
try the ftview demo program, do you get the same bad rendering
behaviour?  You could also try KDE to check whether this makes a
difference.

    Werner
suzuki toshiya | 17 Jan 2012 14:57
Picon

Re: [ft] ugly output with freetype and gtk

Hi,

Thank you for reporting with illustrative screenshot.

Your screenshot does not seem to be hinting issue, rather,
it looks like something wrong in the rasterization itself,
forced to say, integer overflow etc. The noise pixel on
glyph "d" seem to lack reasonable cause in hinting.

I want to know if any smallest rasterization program, like,
ftview (a demo program in freetype2-demos) can show same
issue or not. If you cannot execute such program on your
embedded system, please let me know what kind of testing
progam can be executed on your system.

Also I'm interested in the noise pixels are exactly
reproduceable, or, they appear at different positions
when you reboot the system.

Talking about my personal experience, some old rogue
FreeType2 client breaks the cached glyph bitmap, so
same glyphs shown in one execution have constant noises
(in your screenshot, "e", "g", "n", "u" have constant
noise pixels), but when I terminate/restart the program,
the noise pixels appear differently.

Regards,
mpsuzuki

Jochen Jägers wrote:
> Hello,
> 
> i'm developing an embedded system for home automation based on
> gnu/linux.
> 
> The userinterface is build in HTML/Javascript displayed in a fullscreen
> browser based on webkit-gtk with freetype as font-backend.
> 
> I get ugly output on some glyphs. I've made a screenshot to illustrate
> this ugly output. 
> 
> http://tinypic.com/r/4uwbkl/5
> 
> Look at "Standort" for example. The "d" has two pixels in the top left
> corner. I get this ugly output with different types and different file
> formats. The text in other gtk-based applications look ugly too.
> 
> I've tryed many things i found on the internet like different settings
> for hinting, lcdfilter and subpixels but nothing worked.
> 
> I've also tryed different versions of freetype (2.4.4 and 2.4.8) with
> the same ugly result.
> 
> At the moment I've no idea to solve this problem.
> Do you have any idea what i can try?
> 
> Greetings
> Jochen Jägers
> 
> 
> _______________________________________________
> Freetype mailing list
> Freetype <at> nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype

_______________________________________________
Freetype mailing list
Freetype <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype
Jochen Jägers | 17 Jan 2012 16:46
Picon

Re: [ft] ugly output with freetype and gtk

Hi,
thank your for your fast answer.

With ftview everthing looks fine so it seems to be a gtk problem.

The noise pixels are exactly reproduceable. After reboot and also after
reinstalling the whole system the noise pixels are at the same position.
only by changing fontconfig parameters like hinting the pixels change
their positions.

Are there any ideas where to look for more information or where to ask
for further help?

Greetings,
Jochen Jägers

Am Dienstag, den 17.01.2012, 14:57 +0100 schrieb suzuki toshiya:
> Hi,
> 
> Thank you for reporting with illustrative screenshot.
> 
> Your screenshot does not seem to be hinting issue, rather,
> it looks like something wrong in the rasterization itself,
> forced to say, integer overflow etc. The noise pixel on
> glyph "d" seem to lack reasonable cause in hinting.
> 
> I want to know if any smallest rasterization program, like,
> ftview (a demo program in freetype2-demos) can show same
> issue or not. If you cannot execute such program on your
> embedded system, please let me know what kind of testing
> progam can be executed on your system.
> 
> Also I'm interested in the noise pixels are exactly
> reproduceable, or, they appear at different positions
> when you reboot the system.
> 
> Talking about my personal experience, some old rogue
> FreeType2 client breaks the cached glyph bitmap, so
> same glyphs shown in one execution have constant noises
> (in your screenshot, "e", "g", "n", "u" have constant
> noise pixels), but when I terminate/restart the program,
> the noise pixels appear differently.
> 
> Regards,
> mpsuzuki
> 
> Jochen Jägers wrote:
> > Hello,
> > 
> > i'm developing an embedded system for home automation based on
> > gnu/linux.
> > 
> > The userinterface is build in HTML/Javascript displayed in a fullscreen
> > browser based on webkit-gtk with freetype as font-backend.
> > 
> > I get ugly output on some glyphs. I've made a screenshot to illustrate
> > this ugly output. 
> > 
> > http://tinypic.com/r/4uwbkl/5
> > 
> > Look at "Standort" for example. The "d" has two pixels in the top left
> > corner. I get this ugly output with different types and different file
> > formats. The text in other gtk-based applications look ugly too.
> > 
> > I've tryed many things i found on the internet like different settings
> > for hinting, lcdfilter and subpixels but nothing worked.
> > 
> > I've also tryed different versions of freetype (2.4.4 and 2.4.8) with
> > the same ugly result.
> > 
> > At the moment I've no idea to solve this problem.
> > Do you have any idea what i can try?
> > 
> > Greetings
> > Jochen Jägers
> > 
> > 
> > _______________________________________________
> > Freetype mailing list
> > Freetype <at> nongnu.org
> > https://lists.nongnu.org/mailman/listinfo/freetype
> 

_______________________________________________
Freetype mailing list
Freetype <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype
suzuki toshiya | 17 Jan 2012 17:18
Picon

Re: [ft] ugly output with freetype and gtk

Hi,

Hmm, if ftview could not reproduce the noise pixel, the
next library to be checked would be Pango (text rendering
engine of GTK+) or Cairo (the vector graphic engine used
by Pango, under some configuration).

However, yet I don't know which display subsystem is used
in your embedded systems (e.g. X window, DirectFB, or anything
else?), I cannot give detailed comments.

Regards,
mpsuzuki

Jochen Jägers wrote:
> Hi,
> thank your for your fast answer.
> 
> With ftview everthing looks fine so it seems to be a gtk problem.
> 
> The noise pixels are exactly reproduceable. After reboot and also after
> reinstalling the whole system the noise pixels are at the same position.
> only by changing fontconfig parameters like hinting the pixels change
> their positions.
> 
> Are there any ideas where to look for more information or where to ask
> for further help?
> 
> Greetings,
> Jochen Jägers
> 
> Am Dienstag, den 17.01.2012, 14:57 +0100 schrieb suzuki toshiya:
>> Hi,
>>
>> Thank you for reporting with illustrative screenshot.
>>
>> Your screenshot does not seem to be hinting issue, rather,
>> it looks like something wrong in the rasterization itself,
>> forced to say, integer overflow etc. The noise pixel on
>> glyph "d" seem to lack reasonable cause in hinting.
>>
>> I want to know if any smallest rasterization program, like,
>> ftview (a demo program in freetype2-demos) can show same
>> issue or not. If you cannot execute such program on your
>> embedded system, please let me know what kind of testing
>> progam can be executed on your system.
>>
>> Also I'm interested in the noise pixels are exactly
>> reproduceable, or, they appear at different positions
>> when you reboot the system.
>>
>> Talking about my personal experience, some old rogue
>> FreeType2 client breaks the cached glyph bitmap, so
>> same glyphs shown in one execution have constant noises
>> (in your screenshot, "e", "g", "n", "u" have constant
>> noise pixels), but when I terminate/restart the program,
>> the noise pixels appear differently.
>>
>> Regards,
>> mpsuzuki
>>
>> Jochen Jägers wrote:
>>> Hello,
>>>
>>> i'm developing an embedded system for home automation based on
>>> gnu/linux.
>>>
>>> The userinterface is build in HTML/Javascript displayed in a fullscreen
>>> browser based on webkit-gtk with freetype as font-backend.
>>>
>>> I get ugly output on some glyphs. I've made a screenshot to illustrate
>>> this ugly output. 
>>>
>>> http://tinypic.com/r/4uwbkl/5
>>>
>>> Look at "Standort" for example. The "d" has two pixels in the top left
>>> corner. I get this ugly output with different types and different file
>>> formats. The text in other gtk-based applications look ugly too.
>>>
>>> I've tryed many things i found on the internet like different settings
>>> for hinting, lcdfilter and subpixels but nothing worked.
>>>
>>> I've also tryed different versions of freetype (2.4.4 and 2.4.8) with
>>> the same ugly result.
>>>
>>> At the moment I've no idea to solve this problem.
>>> Do you have any idea what i can try?
>>>
>>> Greetings
>>> Jochen Jägers
>>>
>>>
>>> _______________________________________________
>>> Freetype mailing list
>>> Freetype <at> nongnu.org
>>> https://lists.nongnu.org/mailman/listinfo/freetype
> 

_______________________________________________
Freetype mailing list
Freetype <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Gmane