Is foxyproxy libre?
- Anmelden oder Registrieren um Kommentare zu schreiben
Hi,
I'm searching for a libre proxy switching plugin for my browser. I have
been using foxyproxy for a long time, but I don't know if it's libre. I
found foxyproxy on a Trisquel page:
http://trisquel.info/en/browser/addons/foxyproxy-standard-0
However, I read foxy's FAQ:
https://getfoxyproxy.org/mozilla/faq.html#hidden
and found this:
Under what license is FoxyProxy released?
The FoxyProxy source code is released under the GPL license. The FoxyProxy
name, logo, graphics, art work, website, styles, and documentation are
proprietary works and are NOT open-source.
So I don't think it a 100% free software. What do you think?
Iru
Hi Iru!
There are differing views. The FSF is concerned whether the code and documentation are free, so depending on whether the docu is bundled, they might call it free.
Ironically the Debian project which distributes proprietary software requires that also media be under free licenses to be placed into Debian main repository. (On the other hand anything goes as long as it's legal to distribute in their non-free repo.)
I personally think protecting the name makes sense and I believe there are FSF approved free software licenses which have a clause forbidding the use of the name or another misleading very similar name. Ditto the logo, Mozilla products famously do this, hence e.g. abrowser on Trisquel (and iceweasel on Debian). Not liberating the graphics and especially the documentation are poor choices if you ask me. Perhaps somebody could have a friendly chat with the author. Probably would change nothing however...
> There are differing views. The FSF is concerned whether the code and
> documentation are free, so depending on whether the docu is bundled, they
> might call it free.
Although I use Debian, I actually agree with the FSF line on this issue. It
makes sense that *tools* (software, etc.) be free so that society can control
the functional components that actually have the potential to be used for good
or bad. On the other hand, non-functional components (media, artwork, etc.) I
think the author should be able to distribute however they want- they are just
data that does nothing by itself, but is actually consumed. Software, on the
other hand, is not consumed, it is *used to an end*.
To me, this is a rational extension of my views concerning property in general;
although I respect personal property (commodities to be consumed) I advocate
social ownership of capital- and software is essentially digital capital. It is
important that society control it democratically.
Is there any particular reason why Debian decided to be so finnicky about
insisting on rejecting 'non-free' documentation and media? I'd be interested to
know how that happened.
In the Debian package collection, games like Alien Arena are bundled in
non-free even though the game itself is under the GPL! It's a silly situation
where people have to enable the non-free repository to have access to certain
software that is actually free- in the same way that OpenMW is packaged in
contrib even though it too is GPL- it just requires Morrowind data files, which
are non-free.
It's only because of Debian's insistence on providing non-free software as a
'service' (read dis-service) to its users that this situation even exists. If I
was in charge of Debian, I would have only one repository, which would package
only free software- including free software with non-free non-functional data.
OpenMW, Alien Arena, etc. would be where they rightly belong- in main.
Now we'll see how far this goes: For some reason, Alien Arena existed in
the Free Software Directory. Actually I was the one who sent to to be
reviewed (that is, I didn't approve it, but I was the one who sent it to
be evaluated). And, although I don't like the game that much, I remember
being very happy when Alien Arena was approved as free software, just
like I aways feel when some new free software is approved there (just to
give you an idea, I have the news freed for new entries).
However, some weeks later, the entry for Alien Arena was suddenly
removed. According to what I can recall, the history stated that it was
non-free software.
I'm not saying that I agree or disagree. I'm just saying that we might
as well be careful as to who reviews entries on the Free Software Directory.
For the purposes stated in the previous paragraph, I was going to
suggest something along the lines of "if the reviewer is working on the
Free Software Directory, even if he follows the Debian Free Software
Guidelines personally, he has to follow the GNU Free Systems
Distribution Guidelines when working on the Free Software Directory".
That might seem obvious, but it doesn't really work all the time. Even
we, as simple humans, can't manage to let our personal feelings out of
our daily work. That is, according to my teacher of human resources
management, most researchers usually recommend people to just "wear
masks" to try to separate personal feelings from daily work, but that
doesn't work well, and will probably blow up worse later on.
So, just get the right people that really follow the guidelines we do
follow, and we should be o.k. :D
I am a translator!
The game's engine is libre, the data is proprietary. Hence there is no place for that game in the default Debian installation. And it should be that way. I absolutely don't agree with you that non-free data should be included in main. And mind that I am perfectly fine with and use a lot of non-free data (as all do, some just don't realize it or don't admit it). The mission stated is clearly (it's the first point of the social contract) to keep Debian 100% libre by default:
Debian will remain 100% free
We provide the guidelines that we use to determine if a work is "free" in the document entitled "The Debian Free Software Guidelines". We promise that the Debian system and all its components will be free according to these guidelines. We will support people who create or use both free and non-free works on Debian. We will never make the system require the use of a non-free component.
> Debian will remain 100% free
Debian is a distribution of free *software*. The Debian project should not
concern itself with the issue of free culture, which is an entirely separate
issue -or at least it should not take such precedence that free software is
rejected due to dependency on non-free artwork.
The free software and free culture movements can very well cooperate, but
Debian should retain free software as its one and only goal. As long as the
software is free- the part that actually matters- it should be accepted in main
IMLHO. The rejection of non-free data in main means that in order to access
certain free software, users must enable non-free repositories! I chose rather
to simply eschew using free software unfortunate enough to fall in non-free,
but others might not be so resolute.
Very well. I reconsider my position. In light of the ridiculous situation that
*there is free software in non-free (!!)* there should in fact be four sections
of the Debian repository: main (for free software and free data), fettered (for
free software and non-free data), contrib (for free software which depends on
packages in non-free) and non-free (for non-free software only (but not data)).
This way people who support the FSF line on non-free non-functional data could
enable 'fettered' (or whatever it would be called) and use non-free data
without actually exposing themselves to non-free software. The way things are
currently structured Debian judges non-free non-functional data to be just as
bad as non-free software, which is clearly ridiculous.
I kind of agree that there shouldn't be some arbitrary distinction made for inclusion of non-libre cultural works. What's the problem, anyway? So there are some libre software games that aren't in the main repository because they're not libre culture. (But mind, those games are in contrib, not non-free.) All you have to do is get those games from another source. I haven't had any problem doing this with The Ur-Quan Masters on Trisquel.
I am a translator!
exactly Onpon. Not in non-free but contrib.
Moxalt: "We will never make the system require the use of a non-free component."
It's a matter of philosophy I think - the goal is to make it so that by default Debian stays always libre and free of any proprietary **component** , data included.
Wouldn't there actually be a problem if one wants to, let's say, sell debian dvds?
Maybe it would violate the license of some game data shipped with the dvd.
Besides I think the issue gets exaggerated.
If non-free art is in the free repos or not makes a minor difference.
As long as there is no nonfree _software_ in it..
I personally tend to agree that it's troublesome getting free games plus nonfree data somewhere else.
I think it would be great if the game data was free (i could use and build upon it) but i don't refuse to enjoy nonfree media. And since there are not so many free software games out there to begin with (compared to the proprietary world...) it's not so pleasent if the offer gets limited even more.
> Wouldn't there actually be a problem if one wants to, let's say, sell debian dvds?
Indeed.
> If non-free art is in the free repos or not makes a minor difference.
> As long as there is no nonfree _software_ in it..
One important thing to realize, as Calinou pointed out, is that a lot of games' "data" is actually software. Just to give a few examples:
- SuperTux's levels can have Lua scripts embedded into them.
- Naev has Lua scripts all over its "data" (including missions and events, which are entirely Lua code).
- ReTux's "data" includes "timelines", which are sequences of instructions in a specialized mini-language. In the next version (which is coming out soon), it supports basic "if" statements and even supports directly executing Python code, because I've found that trying to prevent these from being programs is futile.
- Frogatto's "data" includes a bunch of programs of some type in it's "cfg" files (though I don't know what language it is).
- Ren'Py games' "data" include Ren'Py scripts, which are (from my understanding) a superset of Python code.
- All point-and-click adventure games (like Flight of the Amazon Queen and Beneath a Steel Sky) include scripts (programs) by necessity, in various languages, and this is usually not built into the engine, but rather supplied as a part of the games' "data" (so that the engine can be re-used for other games).
This is perhaps because, either the developers or packagers, don't make
a distinction between functional and non-functional data.
I personally think that functional data should have terms like
"font-${font_name}", "${package_name}-doc", "${package_name}-dev",
"${package_name}-mod-${modification_name}",
"${package_name}-addon-${addon_name}",
"${package_name}-${extension_name}",
"${package_name}-plugin-${plugin_name}", "${package_name}-engine" (if
the package needs third party non-functional data to work, but it should
not depend/recommend/suggest non-shareable non-functional data) or
"${package_name}" if it's the main program.
As for non-functional data, I think it should have names like "-models"
(I'm not sure, but I leave this here if 3D models are considered
non-functional data), "-levels" (id. "-models"),
"${package_name}-sounds", "${package_name}-musics", and
"${package_name}-graphics".
If I missed some particular case, please let me know.
Note however, that I didn't use "${package_name}-data" as I find it too
misleading.
It's not because of packagers that this happens, it's because of us game developers. Mostly because making a strong separation between software and non-functional data can sometimes be very difficult or lead to esoteric designs.
Actually, I would try to simplify things a little more:
* "${package_name}-${addon/extension/mod/plugin_name}" (considering only the scripts and executables)
* "${package_name}-${addon/extension/mod/plugin_name}-(graphics|models|musics|sunds)" (for non-functional data related to the above)
* And of course, the corresponding "-dev", "-doc", "-engine", "-help" (that is available for viewing through the "Help" menu of a program), "-locale", "-src", both for "${package_name}" and for the previous three items above.
- Anmelden oder Registrieren um Kommentare zu schreiben