[Haskell-cafe] Using stringize and string concatenation in ghc preprocessing
Harendra Kumar
To reduce boilerplate code in an FFI implementation file I am trying to use the stringizing and string concatenation features of the C preprocessor. Since ghc passes '-traditional' to the preprocessor which disables these features I thought I can pass my own flags to the preprocessor like this:
{-# OPTIONS_GHC -optP -E -optP -undef #-}
But "-optP" seems to only append to the flags that GHC already passes and gcc has no "-no-traditional" option to undo the effect of the "-traditional" that GHC has already passed. I think "-optP" should override the flags passed by ghc rather than appending to them. Is there a reason not to do that?
-harendra
Brandon Allbery
I ran into this very problem recently. Turns out -traditional knows string concatenation too. I seem to remember learning this by browsing the GHC source code, but now I can't find any occurrence of this pattern. But here's an example of how to do string concatenation with CPP in -traditional mode: https://github.com/tweag/sparkle/blob/a4e481aa5180b6ec93c219f827aefe932b66a953/inline-java/src/Foreign/JNI.hs#L274.
That's the hacky K&R way I mentioned earlier.
Harendra Kumar
I ran into this very problem recently. Turns out -traditional knows string concatenation too. I seem to remember learning this by browsing the GHC source code, but now I can't find any occurrence of this pattern. But here's an example of how to do string concatenation with CPP in -traditional mode: https://github.com/tweag/sparkle/blob/a4e481aa5180b6ec93c219f827aefe932b66a953/inline-java/src/Foreign/JNI.hs#L274.
HTH,
On Sat, Aug 20, 2016 at 2:27 PM, Harendra Kumar <harendr...@gmail.com> wrote:But "-optP" seems to only append to the flags that GHC already passes and gcc has no "-no-traditional" option to undo the effect of the "-traditional" that GHC has already passed. I think "-optP" should override the flags passed by ghc rather than appending to them. Is there a reason not to do that?Is there any other better way to achieve this? What is the standard way of doing this if any?
Removing -traditional will break much Haskell source. Go look at the history of clang with ghc (clang doesn't do -traditional) to see what happens. (tl;dr: without -traditional, cpp knows too much about what constitutes valid C, and mangles and/or throws errors on valid Haskell that doesn't lex the way C does.)You might want to look at cpphs as an alternative preprocessor. There are some ancient K&R-era hacks that could be used if absolutely necessary, but cpphs should be a much simpler and cleaner solution.
--brandon s allbery kf8nh sine nomine associatesunix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
_______________________________________________
ghc-devs mailing list
ghc-...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Ben Franksen
> You might want to look at cpphs as an alternative preprocessor. There are
> some ancient K&R-era hacks that could be used if absolutely necessary, but
> cpphs should be a much simpler and cleaner solution.
Is there any reason /not/ to prefer cpphs over cpp? If not, why does
anyone still use cpp for Haskell?
Cheers
Ben
--
"Make it so they have to reboot after every typo." ― Scott Adams
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Brandon Allbery
Am 20.08.2016 um 20:33 schrieb Brandon Allbery:
> You might want to look at cpphs as an alternative preprocessor. There are
> some ancient K&R-era hacks that could be used if absolutely necessary, but
> cpphs should be a much simpler and cleaner solution.
Is there any reason /not/ to prefer cpphs over cpp? If not, why does
anyone still use cpp for Haskell?
Ben Franksen
> On Wed, Jan 18, 2017 at 5:39 PM, Ben Franksen <ben.fr...@online.de>
> wrote:
>
>> Am 20.08.2016 um 20:33 schrieb Brandon Allbery:
>>> You might want to look at cpphs as an alternative preprocessor. There are
>>> some ancient K&R-era hacks that could be used if absolutely necessary,
>> but
>>> cpphs should be a much simpler and cleaner solution.
>>
>> Is there any reason /not/ to prefer cpphs over cpp? If not, why does
>> anyone still use cpp for Haskell?
>>
>
> Licensing.
http://projects.haskell.org/cpphs/ says:
"""
License: The library modules in cpphs are distributed under the terms of
the LGPL (see file LICENCE-LGPL for more details). If that's a problem
for you, contact me to make other arrangements. The application module
'cpphs.hs' itself is GPL (see file LICENCE-GPL). If you have a
commercial use for cpphs and find the terms of the (L)GPL too onerous,
you can instead choose to distribute unmodified binaries (not source),
under the terms of LICENCE-commercial
"""
I can't see how this would inconvenience anyone.
Besides, GNU's cpp is certainly GPL licensed; I wonder why different
standards are applied here.
Richard A. O'Keefe
On 19/01/17 12:04 PM, Ben Franksen wrote:
> Besides, GNU's cpp is certainly GPL licensed; I wonder why different
> standards are applied here.
GNU's cpp is not the only one around.
I have the Sun/Oracle compilers, which don't use GNU cpp;
I had the Intel compilers, which don't use GNU cpp;
there's the preprocessor that comes with lcc, which isn't GNU cpp;
and I also have mcpp and warp (in D) and jcpp (in Java).
There must be others out there.
Brandon Allbery
On 19/01/17 12:04 PM, Ben Franksen wrote:
Besides, GNU's cpp is certainly GPL licensed; I wonder why different
standards are applied here.
GNU's cpp is not the only one around.
Ben Franksen
> On 19/01/17 12:04 PM, Ben Franksen wrote:
>> Besides, GNU's cpp is certainly GPL licensed; I wonder why different
>> standards are applied here.
>
> GNU's cpp is not the only one around.
I did not mean to suggest that.
> I have the Sun/Oracle compilers, which don't use GNU cpp;
> I had the Intel compilers, which don't use GNU cpp;
> there's the preprocessor that comes with lcc, which isn't GNU cpp;
> and I also have mcpp and warp (in D) and jcpp (in Java).
> There must be others out there.
Fine. What is the point you want to make with that listing?
Cheers
Ben
--
"Make it so they have to reboot after every typo." ― Scott Adams
_______________________________________________
Ben Franksen
> On Wed, Jan 18, 2017 at 8:17 PM, Richard A. O'Keefe <o...@cs.otago.ac.nz>
> wrote:
>
>> On 19/01/17 12:04 PM, Ben Franksen wrote:
>>
>>> Besides, GNU's cpp is certainly GPL licensed; I wonder why different
>>> standards are applied here.
>>>
>>
>> GNU's cpp is not the only one around.
>
> Which gets at the real point: these compilers come with the system or are
> otherwise provided by the vendor for more general purposes. (If someone
> downloaded icc and used its cpp, monitoring license compliance is their
> problem).
> Someone with corporate lawyers to satisfy may well need to avoid
> GPL, so they would use neither gcc nor cpphs
This would be a problem only if they anticipate a need to distibute
modified versions of cpphs or other sorts of work derived from it. How
probable is that? To re-iterate, GPL in no way restricts usage, not even
modification (for whatever purpose), merely the re-distribution of
derived work. The whole argument strikes me as a transparent attempt to
discredit GPL licensed software, brough forward by certain parties that,
for political reasons, dislike GPL and want to spead FUD against it.
Cheers
Ben
--
"Make it so they have to reboot after every typo." ― Scott Adams
_______________________________________________
Brandon Allbery
This would be a problem only if they anticipate a need to distibute
modified versions of cpphs or other sorts of work derived from it.
o...@cs.otago.ac.nz
>> On 19/01/17 12:04 PM, Ben Franksen wrote:
>>> Besides, GNU's cpp is certainly GPL licensed; I wonder why different
>>> standards are applied here.
>>
>> GNU's cpp is not the only one around.
>
> I did not mean to suggest that.
I read you as saying that it was inappropriate to use any
other licence before GCC's preprocessor is GPL-licensed,
and I was making the point that alternatives (including
proprietary and free) with different license are available.
o...@cs.otago.ac.nz
>> On 19/01/17 12:04 PM, Ben Franksen wrote:
>>> Besides, GNU's cpp is certainly GPL licensed; I wonder why different
>>> standards are applied here.
>>
>> GNU's cpp is not the only one around.
>
> I did not mean to suggest that.
I read you as saying that it was inappropriate to use any
other licence before GCC's preprocessor is GPL-licensed,
and I was making the point that alternatives (including
proprietary and free) with different licences are available.
o...@cs.otago.ac.nz
>> On 19/01/17 12:04 PM, Ben Franksen wrote:
>>> Besides, GNU's cpp is certainly GPL licensed; I wonder why different
>>> standards are applied here.
>>
>> GNU's cpp is not the only one around.
>
> I did not mean to suggest that.
I read you as saying that it was inappropriate to use any
other licence because GCC's preprocessor is GPL-licensed,
and I was making the point that alternatives (including
proprietary and free) with different licences are available.
_______________________________________________
Ben Franksen
> On Sun, Jan 22, 2017 at 11:14 AM, Ben Franksen <ben.fr...@online.de>
> wrote:
>
>> This would be a problem only if they anticipate a need to distibute
>> modified versions of cpphs or other sorts of work derived from it.
>>
>
> Corporate lawyers are not interested in *your* interpretation of GPL, only
> their own.
It is not "my" intepretation, rather it is the "official" interpretation
of the GPL according to the people who created it (the FSF).
> And most of them won't touch GPL3 or even LGPL3 with a ten foot
> pole. Shouting your interpretation of it at them won't change anything.
Do you have any evidence to support this statement? I ask because if
what you say is true, most companies willfully and severely restrict
their options. For instance, a company that employs lawyers who "won't
touch GPL3 or even LGPL3 with a ten foot pole" could not use Linux in
any way (the kernel is GPL licensed), nor e.g. Android (based on Linux
kernel).
I have no data on how many companies in the world use Linux. What I do
know is that many companies, even big corporations, actually support the
Linux kernel with code (e.g. drivers), thus triggering the most
restricting clauses in the GPL. For instance, Volkswagen AG has
contributed socketcan to the kernel.
Ben Franksen
>> Am 19.01.2017 um 02:17 schrieb Richard A. O'Keefe:
>>> On 19/01/17 12:04 PM, Ben Franksen wrote:
>>>> Besides, GNU's cpp is certainly GPL licensed; I wonder why different
>>>> standards are applied here.
>>>
>>> GNU's cpp is not the only one around.
>>
>> I did not mean to suggest that.
>> Fine. What is the point you want to make with that listing?
>
> I read you as saying that it was inappropriate to use any
> other licence before GCC's preprocessor is GPL-licensed,
> and I was making the point that alternatives (including
> proprietary and free) with different license are available.
Right. So my argument about GNU cpp was not valid, since, in principle
at least, there are non-GPL alternatives.
How does that work in practice? What are people using on e.g. Windows as
GHC's C-backend to avoid GPL? I venture that the native (Microsoft's) C
compiler does not enter the picture here, it does not even support C90.
Perhaps they use the LLVM backend?
Cheers
Ben
--
"Make it so they have to reboot after every typo." ― Scott Adams
_______________________________________________
Brandon Allbery
Do you have any evidence to support this statement? I ask because if
what you say is true, most companies willfully and severely restrict
their options.
Additionally, it's not hard to find past discussions of integrating cpphs into ghc, which were effectively blocked by many people reporting that corporate lawyers would force them to stop using ghc if it happened.
Sven Panne
It is not "my" intepretation, rather it is the "official" interpretation
of the GPL according to the people who created it (the FSF).
Do you have any evidence to support this statement?
I ask because if what you say is true, most companies willfully and severely restrict
their options.
For instance, a company that employs lawyers who "won't
touch GPL3 or even LGPL3 with a ten foot pole" could not use Linux in
any way (the kernel is GPL licensed), nor e.g. Android (based on Linux
kernel). [...]
Bardur Arantsson
> If you take $$$ and e.g. license your RedHat Enterprise Linux/SLES/...,
> you have a legal entity (RedHat, SuSE, ...) which takes the
> responsibility before court, not *your* company.
This is not true, unless there's some sort of idemnification clause in
your license/contract with RH/SuSE/etc. (Of course you're not liable for
copyright infrement done by RH/SuSE/etc., but you still have to comply
with all licenses of whatever you derive your works from.) Such clauses
are pretty rare and is basically in the realm of insurance.
Regards,
Ben Franksen
> On Mon, Jan 23, 2017 at 2:55 PM, Ben Franksen <ben.fr...@online.de>
> wrote:
>
>> Do you have any evidence to support this statement? I ask because if
>> what you say is true, most companies willfully and severely restrict
>> their options.
>>
>
> I suppose Apple isn't evidence. Perhaps Apple is a figment of my
> imagination? And no, they are not a singleton.
Are you saying that Apple's lawyers are afraid of litigation because of
GPL infringement? I very much doubt that. I think Apple is just opposed
to GPL because their business model is built around proprietary hard-
and software. They are against GPL because they *do* want to just grab
stuff and sell it as closed source.
> Additionally, it's not hard to find past discussions of integrating cpphs
> into ghc, which were effectively blocked by many people reporting that
> corporate lawyers would force them to stop using ghc if it happened.
I have no doubt that there are companies and/or lawyers like that. What
I doubt is that this is the overwhelming majority, as you seemed to
suggest ("...most corporate lawyers..."). All the evidence you and Sven
provided is merely anecdotal.
> GPL3 is *toxic* in the corporate world.
The wording you choose to express this suggests that either you agree
with this point of view or else have listened too much to the wrong
people, adopting their jargon.
> Doesn't matter what RMS and co.
> claim outside the license itself; what decides reality is what lawyers
> determine from the working of the license, and their willingness to face
> court challenges based thereon.
Are there, at least, public statements on the net (by such lawyers),
preferably with some sort of justification?
Brandon Allbery
I have no doubt that there are companies and/or lawyers like that. What
I doubt is that this is the overwhelming majority, as you seemed to
suggest ("...most corporate lawyers..."). All the evidence you and Sven
provided is merely anecdotal.
Ben Franksen
> 2017-01-23 20:55 GMT+01:00 Ben Franksen <ben.fr...@online.de>:
>
>> It is not "my" intepretation, rather it is the "official" interpretation
>> of the GPL according to the people who created it (the FSF).
>
> But "official" is not the same as "is accepted by any court". Of course the
> people who created the license have a biased view, but so do company
> lawyers (and the rest of the management): The "safe mode" for them is to
> say "no", you can't be blamed then and don't do anything wrong, at least
> not immediately. As a lot of things in life, such decisions are not driven
> by desire to improve the well-being of a greater entity
> (company/society/...), but purely personal interests.
I can understand how this works. However, I would think that this is
also a matter of weighing risks against opportunities. I would really
like to talk to such a lawyer (in private) and ask him to explain to me
how he thinks the GPL could cause legal risk for a company that merely
uses the software.
>> Do you have any evidence to support this statement?
>
> Something like this happened to me at least three times in my career, and
> even if it's not direct refusal to accept such licenses, there are quite a
> few companies (especially bigger ones) which require a *lenghty* process to
> get SW with such licenses approved. This doesn't exactly encourage
> engineers to take that route...
Ok, still anecdotal evidence. Yes, there are such companies/lawyers.
Perhaps this is enough to justify caution. I would still like to see
some numbers.
>> I ask because if what you say is true, most companies willfully and
>> severely restrict
>> their options.
>
> There is no such thing as "the company", basically people are acting as
> individuals (see above).
Ah, well. So if the CEO thinks opportunities trump the risks he/she
*could* just overrule whatever the lawyers say.
>> For instance, a company that employs lawyers who "won't
>> touch GPL3 or even LGPL3 with a ten foot pole" could not use Linux in
>> any way (the kernel is GPL licensed), nor e.g. Android (based on Linux
>> kernel). [...]
>>
>
> That's not true: If you take $$$ and e.g. license your RedHat Enterprise
> Linux/SLES/..., you have a legal entity (RedHat, SuSE, ...) which takes the
> responsibility before court, not *your* company. So that's the easy way for
> lawyers. Alas, there is no GHC/cpphs company of sufficient size for this to
> work in our case.
I really don't understand that kind of logic. In particular, how exactly
does getting GPL'd software from a vendor sich as RedHat allow the
client to shift legal risks to that vendor? And what about RedHat
themselves? Wouldn't *their* lawyers warn them against taking on such
risks? This just doesn't make any sense to me.
> Disclaimer: I don't say that this is a perfect situation, but it's just
> what I've experienced. Just shouting "GPL is fine, you can use it!" ignores
> the darker side of company life...
Perhaps. I suspect that whatever corporate lawyers may say against GPL
is simply irrational fear and stupid conservatism.
BTW, are there *any* examples of court decisions against companies
because of GPL infringements that may lend substance to these vague
claims of terrible risks when using GPL licensed software?
Brandon Allbery
Perhaps. I suspect that whatever corporate lawyers may say against GPL
is simply irrational fear and stupid conservatism.
Sven Panne
Am 23.01.2017 um 21:21 schrieb Sven Panne:
> [...] Something like this happened to me at least three times in my career, and
> even if it's not direct refusal to accept such licenses, there are quite a
> few companies (especially bigger ones) which require a *lenghty* process to
> get SW with such licenses approved. This doesn't exactly encourage
> engineers to take that route... [...]
Ok, still anecdotal evidence.
Yes, there are such companies/lawyers. Perhaps this is enough to justify caution. I would still like to see
some numbers.
> There is no such thing as "the company", basically people are acting as
> individuals (see above).
Ah, well. So if the CEO thinks opportunities trump the risks he/she
*could* just overrule whatever the lawyers say. [...]
[...] Perhaps. I suspect that whatever corporate lawyers may say against GPL
is simply irrational fear and stupid conservatism.
Ben Franksen
> On Mon, Jan 23, 2017 at 4:10 PM, Ben Franksen <ben.fr...@online.de>
> wrote:
>
>> I have no doubt that there are companies and/or lawyers like that. What
>> I doubt is that this is the overwhelming majority, as you seemed to
>> suggest ("...most corporate lawyers..."). All the evidence you and Sven
>> provided is merely anecdotal.
>>
>
> Mrrr. I was trying to back that off a bit; the real issue is not that it's
> "most", it's "enough to make ghc problematic". The last thread about cpphs
> (quick search gets me
> https://mail.haskell.org/pipermail/ghc-devs/2015-May/009106.html from the
> middle of it and containing a decent summary) indicated that a significant
> number of high profile Haskell users would be forced to drop Haskell if
> cpphs went into ghc, because they'd have to face the uphill battle of
> getting corporate lawyers to okay it again.
I can accept that.
> "Just do it and fix the fallout afterward" is not a solution; once in,
> those lawyers would think twice about reinstating ghc if it were
> subsequently removed, because that's the safe stance legally speaking.
Ok.
So it is not advisable to integrate cpphs in ghc. I have no problem with
that.
Could we, instead, make it easy to use cpphs as drop-in replacement for
cpp, so that it gets used whenever when the CPP language pragma is in
effect? On platforms where the standard CPP is the one by GNU, cpphs
could even be made the default.
Ben Franksen
> 2017-01-23 22:42 GMT+01:00 Ben Franksen <ben.fr...@online.de>:
> We could talk endlessly about this
Right. I am tired of it, too. I am ready to concede that there are
/enough/ of these people around that it is a real problem for some
Haskell users.
For me things are exactly the opposite: as a Haskell preprocessor, using
cpphs is the much safer option compared to CPP. History has shown that
e.g. the gcc developers change cpp's behaviour in ways that are
incompatible with using cpp for anything other than C or C++, even if
that means interpreting the C standard in quite a liberal way.
I would very much like to be able to use cpphs as a drop-in replacement
for cpp and to be able to change the default cpp in a ghc configuration
file, rather than at compile time (so I can still use a ghc packaged for
my distro).
Richard A. O'Keefe
on their machines, even GCC, due to legal advice. That was a couple
of revisions of the GPL ago, but some scars last.
Andrew Butterfield
(HPP ?)
Andrew Butterfield
School of Computer Science & Statistics
Trinity College
Dublin 2, Ireland
Stefan Monnier
> number of high profile Haskell users would be forced to drop Haskell if
> cpphs went into ghc, because they'd have to face the uphill battle of
> getting corporate lawyers to okay it again.
Self-censorship based on fear.
The power of FUD.
Stefan
Stefan Monnier
> on their machines, even GCC, due to legal advice. That was a couple
> of revisions of the GPL ago, but some scars last.
By "some scars last", do you mean "I'll stay away from that company"?
Stefan
Audun Skaugen
> Do you have any evidence to support this statement? I ask because if
> what you say is true, most companies willfully and severely restrict
> their options. For instance, a company that employs lawyers who
> "won't
> touch GPL3 or even LGPL3 with a ten foot pole" could not use Linux in
> any way (the kernel is GPL licensed), nor e.g. Android (based on
> Linux
> kernel).
>
> I have no data on how many companies in the world use Linux. What I
> do
> know is that many companies, even big corporations, actually support
> the
> Linux kernel with code (e.g. drivers), thus triggering the most
> restricting clauses in the GPL. For instance, Volkswagen AG has
> contributed socketcan to the kernel.
Actually, the Linux kernel is GPLv2 licenced[1]. I believe companies
are more comfortable with version 2 than version 3.
[1]: https://www.kernel.org/category/faq.html
Anthony Cowley
> On Jan 24, 2017, at 3:11 AM, Andrew Butterfield <Andrew.Bu...@scss.tcd.ie> wrote:
>
> Why not write a new Haskell version of CPP with a more corporate-friendly OS license?
>
> (HPP ?)
I already wrote hpp, and it's been on hackage for a while now. Its test suite puts it through the spec conformance portion of the mcpp test suite, so one can be somewhat confident that it does the fiddly things correctly. That said, I did find and fix bugs when running it over lens (a sigil-rich environment, to be sure) during testing, so there may yet be Haskell code it doesn't play well with.
It is fairly fast, memory-efficient, written entirely in Haskell, on GitHub, and BSD-licensed.
Anthony
Ben Franksen
>> On Jan 24, 2017, at 3:11 AM, Andrew Butterfield <Andrew.Bu...@scss.tcd.ie> wrote:
>>
>> Why not write a new Haskell version of CPP with a more corporate-friendly OS license?
>>
>> (HPP ?)
>
> I already wrote hpp, and it's been on hackage for a while now. Its test suite puts it through the spec conformance portion of the mcpp test suite, so one can be somewhat confident that it does the fiddly things correctly. That said, I did find and fix bugs when running it over lens (a sigil-rich environment, to be sure) during testing, so there may yet be Haskell code it doesn't play well with.
>
> It is fairly fast, memory-efficient, written entirely in Haskell, on GitHub, and BSD-licensed.
That's like music (progressive rock, to be specific) in my ears!
Ben Franksen
> ma., 23.01.2017 kl. 20.55 +0100, skrev Ben Franksen:
>> Do you have any evidence to support this statement? I ask because if
>> what you say is true, most companies willfully and severely restrict
>> their options. For instance, a company that employs lawyers who
>> "won't
>> touch GPL3 or even LGPL3 with a ten foot pole" could not use Linux in
>> any way (the kernel is GPL licensed), nor e.g. Android (based on
>> Linux
>> kernel).
>>
>> I have no data on how many companies in the world use Linux. What I
>> do
>> know is that many companies, even big corporations, actually support
>> the
>> Linux kernel with code (e.g. drivers), thus triggering the most
>> restricting clauses in the GPL. For instance, Volkswagen AG has
>> contributed socketcan to the kernel.
>
> Actually, the Linux kernel is GPLv2 licenced[1]. I believe companies
> are more comfortable with version 2 than version 3.
>
> [1]: https://www.kernel.org/category/faq.html
Same with cpphs: GPLv2 for the program, for the library it's LGPLv2, and
there is also LICENCE-commercial which allows unrestricted distribution
of the binary (w/o sources).
Cheers
Ben
--
"Make it so they have to reboot after every typo." ― Scott Adams
_______________________________________________
Richard A. O'Keefe
On 25/01/17 2:44 AM, Stefan Monnier wrote:
>> I note that a company I worked for refused to have any GPL software
>> on their machines, even GCC, due to legal advice. That was a couple
>> of revisions of the GPL ago, but some scars last.
>
> By "some scars last", do you mean "I'll stay away from that company"?
No, of course not. The key point was that we were a small company
and would not have survived a law suit, win or lose. That company
no longer exists, in any case. The venture capitalists whose
lawyers' advice we followed do exist, but I no longer work for a
startup.
Stefan Monnier
>>> on their machines, even GCC, due to legal advice. That was a couple
>>> of revisions of the GPL ago, but some scars last.
>> By "some scars last", do you mean "I'll stay away from that company"?
> No, of course not. The key point was that we were a small company
> and would not have survived a law suit, win or lose.
I don't follow: the "keep away from GPL" stance seems to only make sense
in the context of a very large corporation where the potential benefit
of that one little tool (GHC) is dwarfed by the general risk of using
things whose license can't be controlled via money.
In the context of a small company, rather than a general stance, I'd
expect it is worth looking at each specific case (since that one tool
would likely represent a more significant portion of the overall set of
tools in use), and drop the hysteria.
Reality check: Has anyone ever heard of a company sued because they use
a GPL'd tool? Ever? How 'bout in your wildest dream, maybe?
Stefan
Bryan Richter
> >>> I note that a company I worked for refused to have any GPL
> >>> software on their machines, even GCC, due to legal advice. That
> >>> was a couple of revisions of the GPL ago, but some scars last.
> >> By "some scars last", do you mean "I'll stay away from that
> >> company"?
> > No, of course not. The key point was that we were a small company
> > and would not have survived a law suit, win or lose.
>
> I don't follow: the "keep away from GPL" stance seems to only make
> sense in the context of a very large corporation where the potential
> benefit of that one little tool (GHC) is dwarfed by the general risk
> of using things whose license can't be controlled via money.
In the American legal system (which inherits from the British system),
the rules are defined based on previously-established rules
("precedent"). This contrasts it with, say, the discipline of physics,
which continuously tries to discover first principles. Law just keeps
accreting its principles.
One effect of this is that it is easy to tell if you are on safe ground.
Are you doing something that is exactly like something else that has
already been decided on? Then you can be pretty certain you will know
the legal results of your actions. You can know if it's "safe" or
"risky". Some issue that has not been explored in much detail is
decidedly risky. The act of creating new legal principles is long, very
costly, and entirely uncertain. The act alone will kill most small
organizations, whether or not the result is in their favor.
The GPL still has a very sparse legal history.
Lawyers are rationally conservative. They will warn their clients of the
sparse legal history of the GPL. Thus, if using GPL'd software is not
related to a company's mission, the smart executive will avoid it. Why
open yourself to unnecessary risk? Why not simply using one of the
dozens of other solutions that have less uncertainty? This is
*especially* true for smaller companies!
Please note I'm playing Devil's advocate here. I use the GPL myself, and
think highly of it. I simply understand that antagonizing people who
rationally avoid it will get us nowhere.
> Reality check: Has anyone ever heard of a company sued because they
> use a GPL'd tool? Ever? How 'bout in your wildest dream, maybe?
problem.
Here's a FAQ about one such case:
https://sfconservancy.org/copyleft-compliance/vmware-lawsuit-faq.html
Note that the SFC very carefully chose the venue for this case: Germany,
which apparently does not have a precedent-based legal system. The SFC
are trying to build a base of legal history for the GPL in the safest,
most conservative manner possible.
Stefan Monnier
>> use a GPL'd tool? Ever? How 'bout in your wildest dream, maybe?
> I can list a few, mostly involving Linux.
Notice I said "use a GPL'd tool". The cases such as VMware or
Linksys/Cisco are quite different from using GHC for development.
Joe Hillenbrand
Linux, gcc, Emacs, and many other GPL tools, even if they don't
realize it, including Apple and Microsoft. This whole argument is
dangerous FUD.
Stefan Monnier
>>> use a GPL'd tool? Ever? How 'bout in your wildest dream, maybe?
>> I can list a few, mostly involving Linux.
One more thing: in your list, please include the number of years of
negotiation before the lawsuit was filed.