Carl Worth wrote:
don't think it is supported in cairo. So I am not sure where these
rasters are coming from, unless cairo is converting all text to
rasters.
Definitely not converting all text to raster, (unless someone's using
an ancient version of cairo).
I don't know the root cause, but FYI I'm definitely getting rasterized text with the Cairo backend for mathtext_demo.py. (I'm using cairo-1.4.10, which I believe is the latest stable release).
Cheers,
Mike
And you are pretty sure it is all the text, not just the mathtext? We
do use special fonts for mathtext (the Backoma cm ttf fonts) and
perhaps something funny is going on with them? But that should not
affect non-mathtext in the same figure.
What about simple_demo.py -- do you get rasters there too?
JDH
On 7/6/07, Michael Droettboom <mdroe@...31...> wrote:
I don't know the root cause, but FYI I'm definitely getting rasterized
text with the Cairo backend for mathtext_demo.py. (I'm using
cairo-1.4.10, which I believe is the latest stable release).
When I set my backend to gtkcairo, and do something like
plot([1,2])
xlabel('0\.0, 0\.1')
it is clear that the ticklabels are not rasters, only the mathtext. My fonts
are the MPL defaults, the search settled on Vera.ttf.
On Friday 06 July 2007 08:35:31 am John Hunter wrote:
On 7/6/07, Michael Droettboom <mdroe@...31...> wrote:
> I don't know the root cause, but FYI I'm definitely getting rasterized
> text with the Cairo backend for mathtext_demo.py. (I'm using
> cairo-1.4.10, which I believe is the latest stable release).And you are pretty sure it is all the text, not just the mathtext? We
do use special fonts for mathtext (the Backoma cm ttf fonts) and
perhaps something funny is going on with them? But that should not
affect non-mathtext in the same figure.
John Hunter wrote:
I don't know the root cause, but FYI I'm definitely getting rasterized
text with the Cairo backend for mathtext_demo.py. (I'm using
cairo-1.4.10, which I believe is the latest stable release).And you are pretty sure it is all the text, not just the mathtext? We
do use special fonts for mathtext (the Backoma cm ttf fonts) and
perhaps something funny is going on with them? But that should not
affect non-mathtext in the same figure.
Yes, all text is rasterized (in this case the math as well as the tick labels). Looking in the file it doesn't appear that any vector fonts have been included at all.
I have posted the file here for the curious:
ftp://ftp.stsci.edu/tmp/mdroe/mathtext_demo_cairo.ps
I'm running cairo-1.4.10, pycairo-1.4.0, python-2.5.1. Any other relevant details?
Cheers,
Mike
On 7/6/07, Michael Droettboom <mdroe@...31...> wrote:
John Hunter wrote:
What about simple_demo.py -- do you get rasters there too?
No. I get vectors there.
I noticed that using the backend "GtkCairo" seems to use backend_ps.py for Postscript output. Using backend "Cairo" uses cairo. Maybe probably explains the difference between Darren and my results.
Cheers,
Mike
Thanks, John, for sharing this essay. Please allow me to respond to a
few points:
Hey Carl -- thanks for the response. You have definitely made me
reconsider some of my arguments, though my conclusion mostly remains
intact. At the end of the day, it is a fact that almost all of the
significant software for scientific computing in python is BSD
compatible and GPL averse. This in part stems from the position of
enthought, who make very substantial contributions to scientific
computing in python (scipy, chaco, traits, envisage, tvtk, the annual
conference...) and it is my understanding that they do need to release
closed source applications built on top of their open source
libraries. In the past I have had similar ambitions, and one day may
again, so I too am GPL averse.
I have no objection to proprietary, closed source software in the
commercial domain as many in the free software world do, with the
notable exception that I think scientific computing should be done
with open source software. I wrote mpl as part of a suite of tools to
replace proprietary EEG software (dongle and all) because work done
with that software is only reproducible if you have the 50 thousand
dollar dongle. There is a particular ideology with the free software
foundation that all software must be free that many in the scientific
computing community in python do not support. In this community, I
think most people prefer open source software because they like to
build their own tools, see what is going on under the hood, and fix it
if it is broken. There is also the compelling argument, in principle
though not in practice, that open algorithms and code is required by
peer review. And as coding science geeks who might actually do
something one day that will also pay off in dollar terms, I think many
of us want to leave open the possibility of building a proprietary
product built on these tools, and the GPL is somewhat incompatible
with these ambitions.
I would guess you'll find that quite difficult in many cases,
(I don't agree that the GPL is most often chosen without intention
just because it is "famous").
Well, we certainly have had some success with it and we have had
people respond, "you're right, I just picked it because it was the
only thing I'd heard of". The target audience here is a grad student
releasing some technical suite of algorithms that they happen to be
world experts in -- they are more scientists than coders -- and are
not nearly as deep into this world as we are. This is their first
significant coding project and they want to share their algorithms,
and often they release it as GPL. We pounce on them and say, "What
about BSD, so it will play more nicely with scipy and friends?". And
by and large that is successful. This is not a pitch aimed at mature
projects with multiple contributors, where you are certainly right,
getting a switch would be almost impossible.
You only bring the LGPL up at the end of your essay as almost an
afterthought and dismiss it with a very vague, "but many companies are
still loath to use it out of legal concerns". Do you have actual
evidence to point to for that?
I think LGPL is a perfectly good license which satisfies most of my
objections. Eric Jones of enthought has said he is reluctant to use
LGPL code. I get the general sense that he simply doesn't want to
risk a legal battle with the FSF, which may not be entirely rational,
but their zealotry on some of these issues may simply scare some of
the people in the commercial space. Perhaps you are right that the
better answer for the scientific computing community in python is to
reconsider the LGPL stance in scipy, but until that happens, and it is
not my decision and I view it as unlikely, the best thing for this
community is to use a set of compatible licenses in which we can share
code, and the fact remains that we cannot include any LGPL code in our
code unless we want our code to be LGPL as well. Sometimes I just
want to rip out a small algorithm from a library and insert it into
mpl, without having to bring in the entire library as a dependency.
Unless I want my code to be LGPL, I can't do that.
When I get some time, I'll update my essay, which was really just an
email posted on the scipy site but is now an essay <wink>, and
incorporate some of your other very good arguments as well.
Thanks,
JDH
On 7/5/07, Carl Worth <cworth@...528...> wrote:
Sorry to spam this list with this, but it came up here...
Carl Worth wrote:
Thanks, John, for sharing this essay. Please allow me to respond to a
few points:
Carl, you have clearly thought this out a lot, and have a real experience with this, so I have a issue that you may have some insights into:
I work for the US federal government, and we are not allowed to copyright our work, so be definition, any code we write is in the public domain. This means that we can not release code under the GPL, as you have to hold copyright to do that. This makes our managers nervous about using GPL'd libs (LGPL is fine, I'm a big fan of LGPL)
The FSF has unfortunately only ALMOST addressed these issues in their FAQ:
http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLUSGov
From the answers to these FAQs, it's clear that we can release our code into the public domain, and it can then be combined with GPL code in a GPL project, so we can contribute to GPL and LGPL projects.
However, it still looks like we can't actually release a program ourselves under the GPL, and if a given program contains GPL code, then IIUC, it MUST be released under the GPL, so we've got a problem.
We could probably get around all this by developing the code, but having someone else release it, but the implications of that are still confusing to me.
To repeat: LGPL is OK -- while we might (and have) contribute to a library we use, we have no need to release a version of it ourselves.
Anyway, what all this means is that so far we've avoided GPL code for our projects -- something to keep in mind, the US gov't is a major user of Open Source Projects.
-Chris
PS: Google is remarkably unhelpful to me in figuring all this out. If anyone has useful references about the US Federal gov't developed and released software an the GPL -- please send me the links!
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@...236...
I can’t answer your question about GPL in the gub’ment, but I would really like to know where I can read Carl Worth’s rebuttal to the above URL.
–bb
On 7/7/07, Christopher Barker <Chris.Barker@…236…> wrote:
Sorry to spam this list with this, but it came up here…
Carl Worth wrote:
Thanks, John, for sharing this essay. Please allow me to respond to a
few points:
I sent that in the middle of a matplotlib-devel thread yesterday. It
appears to be archived here:
http://sourceforge.net/mailarchive/message.php?msg_name=87ps36a32z.wl%25cworth%40cworth.org
-Carl
On Sat, 7 Jul 2007 02:16:34 +0900, "Bill Baxter" wrote:
> Carl Worth wrote:
> >> http://www.scipy.org/License_Compatibility
> >
> > Thanks, John, for sharing this essay. Please allow me to respond to a
> > few points:I can't answer your question about GPL in the gub'ment, but I would really
like to know where I can read Carl Worth's rebuttal to the above URL.
Hey Carl -- thanks for the response.
You're quite welcome. Thank you for receiving it as intended---as an
alternate viewpoint based on my experience.
I think LGPL is a perfectly good license which satisfies most of my
objections.
Good. That's the most important point I wanted to get across. It
seemed like an obvious hole in the original essay to me.
Eric Jones of enthought has said he is reluctant to use
LGPL code. I get the general sense that he simply doesn't want to
risk a legal battle with the FSF, which may not be entirely rational,
but their zealotry on some of these issues may simply scare some of
the people in the commercial space.
I won't comment on hearsay, but I'd love to have a conversation with
anyone about merits and risks of the LGPL. As for the FSF and
commercial involvement, I think the last 18 months of the GPLv3
drafting process has shown quite conclusively that the FSF has very
effectively engaged some very significant commercial interests.
Here's one point of evidence of that:
GNU-Linux Software License Revision Praised By SIFMA
http://www.sifma.org/news/47167838.shtml
And much more information on a similar theme is available in this
excellent talk recently given by Eben Moglen:
Groklaw - Moglen: "The Global Software Industry in Transformation: After GPLv3"
Perhaps you are right that the
better answer for the scientific computing community in python is to
reconsider the LGPL stance in scipy, but until that happens, and it is
not my decision and I view it as unlikely, the best thing for this
community is to use a set of compatible licenses in which we can share
code, and the fact remains that we cannot include any LGPL code in our
code unless we want our code to be LGPL as well.
I made the caveat earlier that it's often good to not change licensing
once a community has formed around it. Similarly, it's also often good
to go with the same license as the wider community you're trying to be
a part of. So again, you're probably doing the right thing.
But I can also point to my own experience. When I first started what
later would become cairo, (it was called Xr at the time), I had
expected it to be a library that formed part of the X Window
System. So I chose the MIT license that was the basis of that
community's code.
Later though, as cairo matured, and we realized it had much wider
scope than just an X library, I didn't feel constrained to choose the
MIT license for purpose of compatibility with X. So we floated the
idea of changing the license from MIT to to LGPL and that idea was
extremely well-received in the cairo community and ultimately
successful. Here's the thread that started it for interest:
[Cairo] Possible license change: MIT -> LGPL
[Cairo] Possible license change: MIT -> LGPL
Sometimes I just
want to rip out a small algorithm from a library and insert it into
mpl, without having to bring in the entire library as a dependency.
Unless I want my code to be LGPL, I can't do that.
There are some ironies in free software licensing decisions. You can
choose an MIT/BSD license in order to have the widest possible "fan
out", (that is, the number of projects that can take your code), but
that might also limit your "fan in", (the number of projects from
which you can accept code into your project).
So you're suffering from "limited fan-in" I would say due to having
chosen a BSD-ish license but wanting to benefit from other LGPL code.
-Carl
On Fri, 6 Jul 2007 08:20:59 -0500, "John Hunter" wrote:
On 7/5/07, Carl Worth <cworth@...528...> wrote:
Sorry to spam this list with this, but it came up here...
Carl, you have clearly thought this out a lot, and have a real
experience with this, so I have a issue that you may have some insights
into:
Yes, I have thought about licensing a lot. And I'll gladly share my
opinions, (but no legal advice, of course, etc. etc.).
I work for the US federal government, and we are not allowed to
copyright our work, so be definition, any code we write is in the public
domain.
Fantastic! And that's just as government work should be. (I used to
work for a University research lab doing mostly government-funded
project. Sadly, I saw lots of government funds getting poured down the
drain to fund projects that resulted in proprietary software that wen
nowhere.)
This means that we can not release code under the GPL, as you
have to hold copyright to do that. This makes our managers nervous about
using GPL'd libs (LGPL is fine, I'm a big fan of LGPL)
You don't have to release code under the GPL. As you said, you
can't. Just keep publishing that public domain code.
The FSF has unfortunately only ALMOST addressed these issues in their FAQ:
Frequently Asked Questions about the GNU Licenses - GNU Project - Free Software Foundation
Frequently Asked Questions about the GNU Licenses - GNU Project - Free Software Foundation
The FSF answer looks remarkably clear to me. I don't see the "almost"
at all.
From the answers to these FAQs, it's clear that we can release our code
into the public domain, and it can then be combined with GPL code in a
GPL project, so we can contribute to GPL and LGPL projects.
Yes, definitely.
However, it still looks like we can't actually release a program
ourselves under the GPL, and if a given program contains GPL code, then
IIUC, it MUST be released under the GPL, so we've got a problem.
Oops. I think you made a mistake here. Read the answer from the FSF
again:
Can the US Government release improvements to a GPL-covered
program?
Yes. If the improvements are written by US government employees in
the course of their employment, then the improvements are in
the public domain. However, the improved version, as a whole,
is still covered by the GNU GPL. There is no problem in this
situation.
And keep rereading that until the part that says "There is no problem
in this situation" really sinks in. I don't know how I could word the
reply more clearly than the FSF did.
And if you think there's specific text in the GPL that contradicts
this advice from the FSF, I'd suggest you contact the FSF about it,
(but frankly, I can't find any such text).
So if I were in your situation, I would contribute to GPL projects by
sending public-domain contributions. I would also start any new
projects by releasing public-domain code, (which others could then
take and modify and release their modifications under the GPL if
desired).
Anyway, what all this means is that so far we've avoided GPL code for
our projects -- something to keep in mind, the US gov't is a major user
of Open Source Projects.
Please reconsider this, (or invite your lawyers to, or write to the
Free Software Foundation as needed).
PS: Google is remarkably unhelpful to me in figuring all this out. If
anyone has useful references about the US Federal gov't developed and
released software an the GPL -- please send me the links!
A quick scan through the Linux kernel source code, (obviously one of
the most popular GPL-released projects), shows plenty of contributions
from people with .gov email addresses, (both NSA and LLNL feature
prominently). So you might find some helpful people to contact there
who are more directly in circumstances similar to yours, (feel free to
contact me off-list if you've got any questions about how to track
down some potentially helpful email addresses there).
-Carl
On Fri, 06 Jul 2007 10:05:22 -0700, Christopher Barker wrote:
Carl Worth wrote:
Yes, I have thought about licensing a lot. And I'll gladly share my
opinions, (but no legal advice, of course, etc. etc.).
Thanks for your input.
I work for the US federal government, and we are not allowed to
copyright our work, so be definition, any code we write is in the public
domain.Fantastic! And that's just as government work should be. (I used to
work for a University research lab doing mostly government-funded
project. Sadly, I saw lots of government funds getting poured down the
drain to fund projects that resulted in proprietary software that wen
nowhere.)
Well, what we produce ourselves is public domain, but what we spend taxpayers money on by hiring contractors is a totally different story. All too often contractors are paid to develop something that they keep all the rights too.
You don't have to release code under the GPL. As you said, you
can't. Just keep publishing that public domain code.
Oops. I think you made a mistake here. Read the answer from the FSF
again:Can the US Government release improvements to a GPL-covered
program?Yes. If the improvements are written by US government employees in
the course of their employment, then the improvements are in
the public domain. However, the improved version, as a whole,
is still covered by the GNU GPL. There is no problem in this
situation.
And keep rereading that until the part that says "There is no problem
in this situation" really sinks in. I don't know how I could word the
reply more clearly than the FSF did.
Here is the distinction I (and our lawyers) see, that others don't seem to, so maybe I'm missing something. In essence, I see a distinction between contributing to a project someone else is releasing, and creating a derived work that I release myself. Maybe there is no difference.
Example of the two different situations:
1) I have written a bug fix or new feature to a GPL or LGPL piece of software that I want to contribute back. As it says above, no problem. I send it to an email list, post it in a bug tracker, whatever. It is now in the public domain, and it can be added to the GPL'd project. No problem here.
2) I have written a substantial application that makes some use of some GPL'd code. I want to put that app up on a government-run web site, and let people use it at their will. As I understand it, I am now "releasing" the application, and as it includes some GPL code, it MUST be released under the GPL. But I can't do that, because I don't hold copyright over the stuff I've written on the taxpayers time. So what do I do?
I could post all the code I wrote myself (released into the public domain), then post instructions how to combine it with the GPL code, compile it, and viola, you have your app, but that's not exactly making things as accessible as I'd like.
The work around is to find someone else to do the combining, compiling and releasing for us.
And here is the text of the GPL FAQ that I refer to:
"""
Can the US Government release a program under the GNU GPL?
If the program is written by US federal government employees in the course of their employment, it is in the public domain, which means it is not copyrighted. Since the GNU GPL is based on copyright, such a program cannot be released under the GNU GPL.
"""
And I have written the FSF, and not gotten a reply.
So if I were in your situation, I would contribute to GPL projects by
sending public-domain contributions.
Done and doing that.
Anyway, what all this means is that so far we've avoided GPL code for
our projects -- something to keep in mind, the US gov't is a major user
of Open Source Projects.Please reconsider this, (or invite your lawyers to, or write to the
Free Software Foundation as needed).
Honestly, it hasn't been difficult yet. As John has referred to, most Scientific code seems to not be GPL. We came close when we were going to use MySQL in a product, but we ended up going with a non-GPL Python Object DB instead.
A quick scan through the Linux kernel source code, (obviously one of
the most popular GPL-released projects), shows plenty of contributions
from people with .gov email addresses,
Sure, contributing is no problem, it's the releasing of derived works that has me concerned.
Feel free to
contact me off-list if you've got any questions about how to track
down some potentially helpful email addresses there).
I do know NASA has released some stuff under the GPL, but I haven't tracked down how or why yet. Any contacts would be appreciated.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@...236...
to, so maybe I'm missing something. In essence, I see a distinction
between contributing to a project someone else is releasing, and
creating a derived work that I release myself. Maybe there is no
difference.
I'll reply only to the problematic case. (And we're definitely
off-topic for the matplotlib-devel list, so I suggest we take any
further discussion privately unless someone steps up and says "please,
continue here").
2) I have written a substantial application that makes some use of some
GPL'd code. I want to put that app up on a government-run web site, and
let people use it at their will. As I understand it, I am now
"releasing" the application, and as it includes some GPL code, it MUST
be released under the GPL. But I can't do that, because I don't hold
copyright over the stuff I've written on the taxpayers time. So what do
I do?
From what authority do you derive the "I can't do that" part? Think
about that.
You say "because I don't hold copyright", but what does that mean?
Copyright would give you the ability to impose limits on the
recipients, (specifically with respect to activities such as copying,
creating derived works, public performance, etc.). You don't have any
right to impose such limits, but you also don't need any rights.
I would suggest that all of the parts that you have written by
annotated with appropriate statements indicating their public-domain
status.
The question is, can you combine these public-domain files with other
files that you obtained via the GPL? That's a question of creating a
derived work which is something that requires the copyright holder's
permission. And the copyright holder has given you that permission as
long as the derived work is made available under the terms of the GPL.
So, yes, you have permission to release the combined work under the
terms of the GPL. Recipients can then modify and redistribute the
combined work under the terms of the GPL. Recipients can _also_
extract any public-domain portions of the work and use those in any
way whatsoever, since they are public-domain.
I could post all the code I wrote myself (released into the public
domain), then post instructions how to combine it with the GPL code,
compile it, and viola, you have your app, but that's not exactly making
things as accessible as I'd like.
Does such a person have an ability that you do not? Your only unique
position is that you cannot assert any copyright in the things you
created. Nor can your hypothetical third party doing the combining,
right? So I see no problem with you being the party doing the
combining.
"""
Can the US Government release a program under the GNU GPL?If the program is written by US federal government employees in the
course of their employment, it is in the public domain, which means it
is not copyrighted. Since the GNU GPL is based on copyright, such a
program cannot be released under the GNU GPL.
"""
That wasn't what you asked though. You asked if you could combine
original software written by the government with software available
under the GPL and release the combination. And that's exactly what the
FSF answers in the next question:
Sure, contributing is no problem, it's the releasing of derived works
that has me concerned.
But what's the distinction there? Releasing a derived work is
certainly an action that requires the copyright holder's permission,
but you have that permission explicitly in the GPL.
There's never any relicensing. The parts that are public-domain are
still public-domain. The parts that are available only under the terms
of the GPL are still available only under the terms of the GPL. You
cannot relicense at all unless you are the copyright holder.
The only question is in the case of a combined work whether there is a
set of permissions that doesn't violate the terms of any of the
pieces. (This is the general "license compatibility" question.) And in
the case of GPL+public domain, the answer is yes, and the set of
permissions is the GPL.
I think one possible point of confusion is the wording of
"improvements" in the FSF GPL FAQ explaining that the government can
"release improvements to a GPL-covered program". This might be
interpreted as somehow implying that its only legitimate if the
improvements are somehow less significant than the GPL program.
A more clear answer might just say that the government, (or anyone
else for that matter), can legitimately combine GPL software with
public domain software and release the result under the GPL.
But you certainly don't need the FSF FAQ to give you that permission
explicitly. The GPL itself gives you all the permission you need.
So again, I'll go back to my original question, by what authority do
you see any problem? Would you be violating anybody's copyright by
releasing a program combining GPL components and government-written
public-domain components? That is, would you be taking any action that
required a copyright holder or copyright holder's permission that you
don't have? I certainly can't see any.
-Carl
On Fri, 06 Jul 2007 14:03:30 -0700, Christopher Barker wrote: