[PETSC #18705] PETSc and Cygwin License (POSIX layer)

[Barry Smith]

On Dec 4, 2008, at 12:51 PM, Matthew Knepley wrote:

> On Thu, Dec 4, 2008 at 12:42 PM, Barry Smith <bsmith at mcs.anl.gov>  
> wrote:
>
>  Make is NOT the problem! (It is just one of several)
>
>  Config/configure.py uses the SHELL constantly for basically  
> everything. Try running config/configure.py
> under Windows without using cygwin.
>
> I disagree with this characterization. The lowest level definitely  
> spawns shell jobs, however at the configure
> level, they are a small set of specific tasks, and it would not be  
> hard to retarget them to a different architecture.

    That just has to be done.
>
> For instance, almost everything comes down to a compile, link, or  
> execution. I will now say "toolbox", or maybe
> "toolbag" (buildstuff?).

    In the HPC, world the most accurate term is "bunch of crappy  
software I use".

    Barry

>
>
>   Matt
>
>
>  I hate the term "toolchain"
>
>
>   Barry
>
>
> On Dec 4, 2008, at 12:04 PM, Matthew Knepley wrote:
>
> I for one think it should be possible to remove 'make' from the
> toolchain, leaving us with only win32fe, which we distribute. Thus
> I think we could abandon cygwin once and for all. I would even be
> willing to write a \emph{make clone} to accomplish this, even though
> I am a committed enemy of make (which once TP'ed my house).
>
>   Matt
>
> ---------- Forwarded message ----------
> From: Barry Smith <bsmith at mcs.anl.gov>
> Date: Thu, Dec 4, 2008 at 12:00 PM
> Subject: Re: [PETSC #18705] PETSc and Cygwin License (POSIX layer)
> To: Stefan Benkler <benkler at itis.ethz.ch>
> Cc: petsc-maint at mcs.anl.gov
>
>
>  Stefan,
>
>   Here is my understanding of the situation.
>
>   Conjecture: You CAN use an open source compiler (GNU)  to compile  
> proprietary code and then sell
> the binaries without making the proprietary code GNU licensed so  
> long as you just use the
> GNU compilers out of the box and don't change their source code and  
> don't include the compliers
> libraries in your binaries.
>
>  IF this is true then you are safe, the Cygwin environment is only  
> used by PETSc to have
> a system to compile PETSc. None of it is included in the binaries  
> generated.
>
>  On the other hand, if my initial conjecture is wrong, then there  
> could be a problem.
>
>  Barry
>
> We've tried over the years to use Windows "posix" environments to  
> develop a build system
> for PETSc so we don't need cygwin to build PETSc. Unfortunately  
> their stuff is so "un-unix"
> like that it just wasn't practical and using developers studio to  
> build PETSc directly is
> possible but requires some how getting all the PETSc source properly  
> into developers studio
> and as far as I know the only way to do this is manually through the  
> gui which is very painful;
> plus if we change something in the Unix build side later we'd need  
> to change it manually
> on the developers studio side.
>
> If the situation has changed and Windows does provide a reasonable  
> way to build large
> unix codes I'd love to hear about it and use it. We hate cygwin but  
> feel with have no other
> reasonable option.
>
> On Dec 4, 2008, at 3:33 AM, Stefan Benkler wrote:
>
> Dear PETSc developers
>
> Since a while, I successfully use your fantastic library on Windows.  
> Thank you very much!
>
> Lately, I had a discussion about the involved copyrights/licenses  
> with a colleague. The main point was if PETSc requires the POSIX  
> layer of cygwin on Windows (and therefore would need to fulfill  
> cygwin's GPL license).
>
> My standpoint was that cygwin is just used to configure and build  
> the library, but only native Windows libraries (using MS or Intel's  
> Windows compiler, MKL) are finally linked to the PETSc libs.  
> However, I have difficulties to proof this claim, which is the  
> reason for this email.
>
> Please comment/clarify the licensing on a Windows system.
>
> Thanks a lot for your informations.
>
> Best regards
>
>  Stefan Benkler
>
>
>
>
>
>
> -- 
> What most experimenters take for granted before they begin their  
> experiments is infinitely more interesting than any results to which  
> their experiments lead.
> -- Norbert Wiener
>
>
>
>
> -- 
> What most experimenters take for granted before they begin their  
> experiments is infinitely more interesting than any results to which  
> their experiments lead.
> -- Norbert Wiener