Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/
Gaetan Nadon writes: > - The minimum autoconf version should be 2.60. Features above 2.60 > should not be used. Starting v 2.62 there is a license controversy What is that? [The NEWS file doesn't show any license changes in 2.62. Autoconf itself switched to the GPLv3 in 2.65, but I'm not sure why that should be an issue if earlier versions were OK... (the NEWS file says "As with earlier versions, the license includes an exception clause so that you may release a configure script generated by autoconf under the license of your own program").] Thanks, -miles -- Admiration, n. Our polite recognition of another's resemblance to ourselves. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/
On , Matt Turner wrote: > In short, 2.62 is the first version that includes GPLv3 tools to build > autoconf, even though what is installed is GPLv2. > > [1] http://lists.x.org/archives/xorg-devel/2011-June/022724.html Thanks, that explains the significance of 2.62 -- but it doesn't actually explain the problem; it just says "In order to build it, I would have to accept GPLv3 (which is not acceptable)". _Why_ is the GPLv3 "not acceptable", when the GPLv2 was? What does "I would have to accept the GPLv3 [to build it]" even mean? The GPL applies to redistribution, not use. I'm still mystified. Thanks, -Miles -- Cat is power. Cat is peace. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/
2011/9/29 Alan Coopersmith :
>> _Why_ is the GPLv3 "not acceptable", when the GPLv2 was?
>
> Note his employer, which is well known as not accepting the GPLv3,
> possibly due to it being a mobile phone manufacturer, and the GPLv3's
> free patent license grant not fitting well with the current mobile phone
> environment in which every manufacturer is involved in more patent
> infringement lawsuits & countersuits than anyone wants to consider.
Er, sure, but that brings up my second point: the GPL restricts
redistribution, not use, so you are not required to "accept it" to use
GPL tools.
So the original complaint, that he is "forced to accept the GPLv3 to
use autoconf" seems a little confused. [of course certainly it's
possible that _I'm_ confused, or there's a subtlety I'm missing.]
[W/R/T patents in particular, the GPLv3 only seems to affect (1)
contributors to autoconf, and (2) those who redistribute autoconf in a
way that would violate some patent except for a private license
between the two parties. For mere users of autoconf, neither is going
to be an issue.]
> Since most developers on the X & Mesa projects are doing it as part of
> our paid employment, we are subject to the constraints of the licenses
> our employers are willing to accept, and no amount of logic or arguments
> from outsiders can trump company policy.
This is true, but on the other hand, there's a limit to which projects
should be willing to accept arbitrary and unreasonable restrictions
imposed by the employers of contributors. When "company policy" is
due to real issues for the employer, which are likely shared by others
as well, then probably the project should at least tend towards
respecting it; on the other hand, completely _arbitrary_ "company
policies" ("we hate the letter G, so absolutely no source files
containing it are acceptable!") are less defensible.
There's a clear negative impact from restricting autoconf use to old
versions (autoconf has bugs and misfeatures, and these are often fixed
in newer versions), so I don't think it's a decision that should be
taken lightly (short-term restrictions are less of an issue, of
course).
As the GPLv3 is widely used, I think this is an issue that will come
up again, so it's worth some discussion.
-Miles
--
Cat is power. Cat is peace.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/
2011/9/30 Jeremy Huddleston : >> Er, sure, but that brings up my second point: the GPL restricts >> redistribution, not use, so you are not required to "accept it" to use >> GPL tools. > > Again, mirroring Alan's comment. IANAL. I just do what the Lawyers > say. I am told not to touch GLPv3 with a 10 foot poll while I have my > Apple hat on, so I go beyond that and stay 10 miles away from GPLv3 > while I have my Apple hat on. Vague statements like "touch with a 10 foot pole" are not meaningful. [See below for more details] >> So the original complaint, that he is "forced to accept the GPLv3 >> to use autoconf" seems a little confused. > > From the 2.62 release notes at > http://lists.gnu.org/archive/html/autotools-announce/2008-04/msg2.html: > > """ > Meanwhile, several source files within the Autoconf project are under > GPLv3+, as described in COPYINGv3; these files are used for building > and installing Autoconf, but are not present in the installed > programs. The entire Autoconf project will move to GPLv3+ when the > exception statements have been reformulated in terms of the Additional > Permissions as described in section 7 of GPLv3. > """ > > That alone means no 2.62 for me while I'm doing Apple-fu. The GPL only applies to redistribution, not use. _Users_ of autoconf (like you, as a Mesa dev), _projects_ that use autoconf (like Mesa), _restributors_ of autoconf-using projects, and _end-users_ of such projects do not need to "accept" the GPL at all, v3 or otherwise, and are not affected by its terms. So unless you're sending copies of autoconf _itself_ (not Mesa) to other people, the version of GPL used in autoconf simply does not apply to you. [Again, see below for more detail] >> As the GPLv3 is widely used, I think this is an issue that will >> come up again, so it's worth some discussion. > > It's not that simple. We should not thrust acceptance of a new > license down our users throats. The existence of GPLv3 is what > prompted Gentoo to add support to portage to allow users to block > installing packages based on license. Clearly it's not just one or > two companies that are afraid of it. Again, using autoconf _does not require users to "accept" the GPLv3, nor does it place them under any restrictions due to the GPL[v3]_. autoconf-generated files and autoconf boilerplate in Mesa itself are _under the Mesa license_, so one can happily restribute Mesa without having to "accept" the GPL[v3] or incur any restrictions from it.. There is no "forcing down the throat", as they simply aren't affected by it. Here's my argument: (1) Mesa should try to respect corporate restrictions that are based on actual potential harm/consequence to the developer (2) However Mesa should _not_ feel beholden to follow those which have no valid basis (e.g. those based merely on "dislike") (3) There are real negative consequences to not using newer version of autoconf, so it's not something that should be done lightly (4) Merely _using_ autoconf does not imply "acceptance" of the GPL[v3] or incur any restrictions from it (the GPL is about restribution, not use; a user is _not affected_) (5) for autoconf-related files distributed with Mesa itself (which Mesa contributors presumably do want to redistribute), there are three types: (5.1) autoconf-generated files: these are not under the GPL but rather an extremely liberal license: # This file is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, # with or without modifications, as long as this notice is preserved. (5.2) autoconf boilerplate: these use the GPL[v3], but contain a term which allows them to be restributed under the Mesa license as well: # As a special exception to the GNU General Public License, if you # distribute this file as part of a program that contains a # configuration script generated by Autoconf, you may include it under # the same distribution terms that you use for the rest of that program. (5.3) autoconf input files: these are obviously purely Mesa, and are under the Mesa license, and not affected by the license of autoconf => So users, developers, and redistributors of Mesa do not need to "accept" the GPL[v3], nor incur any restrictions from it, based on autoconf-related files in Mesa. (6) Therefore, Mesa developers/users/redistributors are _not affected_ by the GPLv3, even if GPLv3'd versions of autoconf are used. (7) Thus while companies like Apple may not like the GPLv3, they are not actually affected by the use of GPLv3'd autoconf in Mesa, so there's no rational basis for their trying to restrict projects like Mesa from using such tools. (8) ... and therefore, Mesa should judge the harm from avoiding
Re: [Mesa-dev] glsl2: Remove generated files from git
Ian Romanick writes: >> These files generated by bison and flex are different for me than the >> ones checked in to git: >> >> src/glsl/glcpp/glcpp-lex.c >> src/glsl/glcpp/glcpp-parse.c >> src/glsl/glcpp/glcpp-parse.h >> src/glsl/glsl_lexer.cpp >> src/glsl/glsl_parser.cpp >> >> This is causing some annoyances for me when I do commits or switch >> branches. Is there any reason why these files can't be removed from >> git? > > One word: Windows. Welcome to my world. How about putting "generated" files like that into a separate subdirectory (e.g. ".../prebuilt"), which is ignored by the non-windows builds? Then on windows, it can simply do "cp .../prebuilt/foo .../foo" instead of generating the file using bison or whatever. -Miles -- Guilt, n. The condition of one who is known to have committed an indiscretion, as distinguished from the state of him who has covered his tracks. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glsl2: Remove generated files from git
Ian Romanick writes: >> How about putting "generated" files like that into a separate >> subdirectory (e.g. ".../prebuilt"), which is ignored by the non-windows >> builds? >> >> Then on windows, it can simply do "cp .../prebuilt/foo .../foo" instead >> of generating the file using bison or whatever. > > Most (all?) of the people working on the flex and bison files are on > Linux. Because of that, I can almost guarantee the special "for > Windows" copies that aren't used on Linux will lag. In some ways, > that's even worse because we'll likely end up with various types of > spurious bug reports from people trying to build on Windows. Er, but that's no different than the status quo, which apparently already has pre-generated files, albeit with an annoying conflict-generating name. [In fact, you seem to be the person arguing that the pre-generated files are necessary!] If it's decided that it's acceptable to require windows users to have bison etc, installed, and to get rid of the pre-generated files in git, then great, all problems are solved. If that's not acceptable though, and it's decided that pre-generated files should be kept, it seems nice to at least avoid the current annoying conflicts for the vast majority that are using linux ... right? -Miles -- Mayonnaise, n. One of the sauces that serve the French in place of a state religion. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] D3D1x Revert
Jose Fonseca writes: > And to be honest, WINE developers did a disservice to themselves by > openly stating their concerns. They put themselves between the rock > and the wall with that. For future reference, if people have this sort > of doubts, they should contact the project maintainers (e.g Brian, > Keith) privately. I dunno if the WINE devs are being over-cautious or not, but if they have legitimate concerns, why is stating them openly "doing themselves a disservice"? Isn't openness a _good_ thing? Of course, if they do use a public forum they should try to be polite, (but if they're not, then that's the issue, not the act per-se) -Miles -- Somebody has to do something, and it's just incredibly pathetic that it has to be us. -- Jerry Garcia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Building Mesa 7.10 on Windows 7 / Visual Studio 2010
Matt Turner writes: > Although, after cmake, if we just added an imake build system, I think > we'd have everything covered. I'm not sure it's possible to run out of build systems ... pretty much everybody has written one! -miles -- Saa, shall we dance? (from a dance-class advertisement) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] List of OpenGL features/extensions to avoid?
Eric Anholt writes: > That's hard, because floating point framebuffers are so useful (and > obvious). ... and so undeserving of patent protection ... :[ -miles -- Corporation, n. An ingenious device for obtaining individual profit without individual responsibility. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
