Windows-Packaging

[Patrick Spendrin]

Bernhard Reiter schrieb:
> On Freitag, 16. Januar 2009, Bernhard Reiter wrote:
>>>> - We need to ship the exact source code, scripts and tools to build each
>>>>  specific binary shipped for GNU (L)GPL licensing.
>>> As far as i know does the gpl licensing means only to provide the source
>>> for a related binary, but it does not make the binary releaser
>>> responsible to provide  all required 3rdparty tools.
>>>
>>> Think about msvc builds  -  We build kde software on windows with msvc
>>> express editions, but we don't provide the ide or the platform sdk - in
>>> fact ms probably will do not like this
>> You happen to ask a licensing expert about. In short terms the license
>> does require to deliver source for tools and libraries, except when they
>> are generally shipped with the operating system. (See below.)
> 
> Forgot to attach it, so here we go. I am quoting GNU GPL v2 to show that this 
> has been in there for years, GNU LGPLv2, and the v3s have similiar 
> conditions.
> 
> http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
> Section 3 is about that you must make available the "complete corresponding 
> machine-readable source code".
> 
> | complete source code means all the source code for all modules it contains, 
> | plus any associated interface definition files, plus the scripts used to 
> | control compilation and installation of the executable. 
> 
> Note that the simplified view from 1991 was that most operating system
> bring their tools with them.
> 
> | However, as a  
> | special exception, the source code distributed need not include anything 
> | that is normally distributed (in either source or binary form) with the 
> | major components (compiler, kernel, and so on) of the operating system on 
> | which the executable runs, unless that component itself accompanies the 
> | executable.       
> 
> So I think not shipping msvc express matches the spirit of this license.
> 
> The point why we want the tools to be available: 
> 
>> But we also want to make it fairly easy for people
>> to rebuild the exact version they are using, so they can only change
>> a small thing if they like.
> 
> And of course we need to control the tool chain, e.g. for security reasons.
Sorry, I can't resist with this one:
Independent of the compiler's redistribution/source code,
How is it easier to install a complete cross compile stack (given that
you even want to provide one!) than to rebuild on windows?

"however you call it, we are lacking enough information for some point.
Some things we could only know after trying as there are no experiences
with this yet."

I have heard this sentence more than half a year ago @Linux-Tag in 
Berlin from you - and no result yet. Why not write down a list what you 
want to know? It should be definitely possible to write down what you 
want to compare and what you want to know at all.

"Currently emerge does not fetch nor secure the source for all of the
binaries used for a regular build. Of course you could enhance it to do
so, but this would be a major effort."

I just looked at the kolab "Debug" package yesterday and you even ship
the complete emerge directory with it (besides some other obvious
strange things). You are not forced to use such insecure technology. 
Just to remind you, it should be easy to build kdepimlibs and kdepim 
without emerge using the standard way.

The discussions about kontact/kdepim annoy me a bit.
There is not to much sense if we can't find any compromise. Dropping all 
our efforts and fixing the way you want it to be (namely trying to fix 
cross compiling) is not an option. As I am one of the packagers I can 
say that I will not compile kdepim as long as we haven't found a 
solution for it.

Patrick

-- 
web:                 http://windows.kde.org
mailing list:        kde-windows at kde.org
irc:                 #kde-windows (irc.freenode.net)