[gentoo-dev] redistribute intel rpms

[gentoo-dev] redistribute intel rpms

[Sébastien Fabbro]

Hi,

We have a few fetch restricted Intel packages in the main tree (icc,
ifc, mkl, ipp, tbb). All except tbb are closed-source but free with
non-commercial licenses. Lately upstream has repackaged the icc and
ifort (ifc) as a big tar blob containing all of them, but also release
some of them separately. For various reasons we would like to keep
separate ebuilds. The problem is the separate packages have common
libraries, causing duplication and file collisions. So the idea was to
download the tar blob which contain a few binary rpms and base new
ebuilds on these rpms. This means we will have to re-distribute the
rpms on our mirrors. I can't understand from the many licenses if we
are allowed to do it, it surprisingly looks like we can do it.

Anyone with better understanding of the licences could help? Upstream
does not answer.

--
Sebastien

Re: [gentoo-dev] redistribute intel rpms

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 1196 bytes --]

On Fri, Nov 06, 2009 at 04:04:41PM -0800, Sébastien Fabbro wrote:
> We have a few fetch restricted Intel packages in the main tree (icc,
> ifc, mkl, ipp, tbb). All except tbb are closed-source but free with
> non-commercial licenses. Lately upstream has repackaged the icc and
> ifort (ifc) as a big tar blob containing all of them, but also release
> some of them separately. For various reasons we would like to keep
> separate ebuilds. The problem is the separate packages have common
> libraries, causing duplication and file collisions. So the idea was to
> download the tar blob which contain a few binary rpms and base new
> ebuilds on these rpms. This means we will have to re-distribute the
> rpms on our mirrors. I can't understand from the many licenses if we
> are allowed to do it, it surprisingly looks like we can do it.
> 
> Anyone with better understanding of the licences could help? Upstream
> does not answer.
Can you list the license files please? I'll poke at them after that.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --]

Re: [gentoo-dev] redistribute intel rpms

[Sébastien Fabbro]

On Saturday 07 November, Robin H. Johnson wrote:

> On Fri, Nov 06, 2009 at 04:04:41PM -0800, Sébastien Fabbro wrote:
> > We have a few fetch restricted Intel packages in the main tree (icc,
> > ifc, mkl, ipp, tbb). All except tbb are closed-source but free with
> > non-commercial licenses. Lately upstream has repackaged the icc and
> > ifort (ifc) as a big tar blob containing all of them, but also
> > release some of them separately. For various reasons we would like
> > to keep separate ebuilds. The problem is the separate packages have
> > common libraries, causing duplication and file collisions. So the
> > idea was to download the tar blob which contain a few binary rpms
> > and base new ebuilds on these rpms. This means we will have to
> > re-distribute the rpms on our mirrors. I can't understand from the
> > many licenses if we are allowed to do it, it surprisingly looks
> > like we can do it.
> > 
> > Anyone with better understanding of the licences could help?
> > Upstream does not answer.
> Can you list the license files please? I'll poke at them after that.
> 

The one in the tree (Intel-SDP) has slightly changed. New one:
http://software.intel.com/en-us/articles/intel-software-development-products-license-agreement/

--
Sebastien

Re: [gentoo-dev] redistribute intel rpms

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 1530 bytes --]

On Fri, Nov 06, 2009 at 04:45:23PM -0800, Sébastien Fabbro wrote:
> > > Anyone with better understanding of the licences could help?
> > > Upstream does not answer.
> > Can you list the license files please? I'll poke at them after that.
Files, plural. If each RPM in the blob has separate licenses, we need to review
all of them.

Additionally, from the base license:
] Subject to all of the terms and conditions of this Agreement and any specific
] restrictions which may appear in the Redistributables text files, Intel grants
] to you a non-exclusive, non-assignable copyright license to distribute (except
] under an Evaluation License as specified below) the Redistributables, or any
] portions thereof, as part of the product or application you developed using the
] Materials.

Thus, we need to review the "any specific restrictions which may appear in the
Redistributables text files" for problems as well.

At a first reading, it smells badly. Do you know of any other distro that is
redistribution the files as-is from upstream or other derivative
distributable?

P.S.,
As I feel it is appropriate here, IANAL, and this should not be construed as
being legal advice. Rather, I feel sufficiently -versed in open source
licensing issues that I can say if something is going to be clear or too grey
to be certain.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --]

Re: [gentoo-dev] redistribute intel rpms

[Sébastien Fabbro]

On Saturday 07 November, Robin H. Johnson wrote:

> On Fri, Nov 06, 2009 at 04:45:23PM -0800, Sébastien Fabbro wrote:
> > > > Anyone with better understanding of the licences could help?
> > > > Upstream does not answer.
> > > Can you list the license files please? I'll poke at them after
> > > that.
> Files, plural. If each RPM in the blob has separate licenses, we need
> to review all of them.

This license is the only one I could find in the "Intel Compiler
Professional Edition" which is the one tar ball we are thinking of
splitting.

> Additionally, from the base license:
> ] Subject to all of the terms and conditions of this Agreement and
> any specific ] restrictions which may appear in the Redistributables
> text files, Intel grants ] to you a non-exclusive, non-assignable
> copyright license to distribute (except ] under an Evaluation License
> as specified below) the Redistributables, or any ] portions thereof,
> as part of the product or application you developed using the ]
> Materials.
> 
> Thus, we need to review the "any specific restrictions which may
> appear in the Redistributables text files" for problems as well.
>

The "Redistributables" seem a bit different in Intel sense, see my
post in [1]. I also put the redist file in [2].

> At a first reading, it smells badly. Do you know of any other distro
> that is redistribution the files as-is from upstream or other
> derivative distributable?
>

We are the only distro having Intel stuff in the repos as far as I know.
Most of the big distros have official support but users need to install
it from Intel.

Thanks for looking at this!

[1] http://software.intel.com/en-us/forums/intel-c-compiler/topic/69175/
[2] http://dev.gentoo.org/~bicatali/
--
Sebastien

Re: [gentoo-dev] redistribute intel rpms

[Robin H. Johnson]

On Fri, Nov 06, 2009 at 05:58:09PM -0800, Sébastien Fabbro wrote:
> > Additionally, from the base license:
> > ] Subject to all of the terms and conditions of this Agreement and
> > any specific ] restrictions which may appear in the Redistributables
> > text files, Intel grants ] to you a non-exclusive, non-assignable
> > copyright license to distribute (except ] under an Evaluation License
> > as specified below) the Redistributables, or any ] portions thereof,
> > as part of the product or application you developed using the ]
> > Materials.
> > 
> > Thus, we need to review the "any specific restrictions which may
> > appear in the Redistributables text files" for problems as well.
> The "Redistributables" seem a bit different in Intel sense, see my
> post in [1]. I also put the redist file in [2].
Can you make a list of files in the giant tarball aren't included in the
credist.txt list?

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Re: [gentoo-dev] redistribute intel rpms

[Sébastien Fabbro]

On Thursday 12 November, Robin H. Johnson wrote:

> > > Thus, we need to review the "any specific restrictions which may
> > > appear in the Redistributables text files" for problems as well.
> > The "Redistributables" seem a bit different in Intel sense, see my
> > post in [1]. I also put the redist file in [2].
> Can you make a list of files in the giant tarball aren't included in
> the credist.txt list?

I put a list in [1] of the files we are thinking of splitting from the
tar balls. We could go further and split the rpms, but it should be
enough to get us working.

[1] http://dev.gentoo.org/~bicatali/intel-distrib.list

--
Sebastien

[gentoo-dev] Re: redistribute intel rpms

[Duncan]

Sébastien Fabbro posted on Fri, 06 Nov 2009 16:04:41 -0800 as excerpted:

> We have a few fetch restricted Intel packages in the main tree (icc,
> ifc, mkl, ipp, tbb). All except tbb are closed-source but free with
> non-commercial licenses. Lately upstream has repackaged the icc and
> ifort (ifc) as a big tar blob containing all of them, but also release
> some of them separately. For various reasons we would like to keep
> separate ebuilds. The problem is the separate packages have common
> libraries, causing duplication and file collisions. So the idea was to
> download the tar blob which contain a few binary rpms and base new
> ebuilds on these rpms.

To here looks reasonable...

> This means we will have to re-distribute the rpms on our mirrors.

This conclusion doesn't necessarily follow from the above, unless you 
summarized-out the important technical issues.  See below.

> I can't understand from the many licenses if we are
> allowed to do it, it surprisingly looks like we can do it.

No position on the legal aspect, except that if we can avoid the question 
by not distributing them at all, much as we do with various other 
restrict=mirror packages, that would seem to me to be the way to go.

What I'm missing is why a combination of the approach used for, say, the 
kde split ebuilds, and the standard restrict=mirror ebuilds, can't be 
used.  It seems to me that the ebuilds could each require the big combo-
tarball, extract only the necessary component rpms, and go from there, 
much as the kde split ebuilds do with the big combo tarballs that kde 
ships except they don't have the rpms step to worry about and I expect 
the kde interdependencies were far more complex to try to work out (you'd 
need to ask the gentoo/kde folks on that to be sure, but from a user who 
followed the experimentals to some degree, that certainly seems to be the 
case).

The big combo tarball could then be restrict=mirror or whatever, with or 
without a specific user click-thru (and restrict=interactive or whatever) 
as necessary and already used on some packages, following existing 
policies.

Of course, there's certainly the complexity of automating the tarball 
unpack of only the specific needed components, but gentoo/kde has a 
**LOT** of experience with that sort of thing by now, and I'm sure they'd 
be happy to share hints and helpful tactical strategies with you, if you 
ask, and there's no way I can conceive it being even half as dependency 
convoluted as kde4 was to figure out, so it should be FAR easier.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: redistribute intel rpms

[Sébastien Fabbro]

On Sat, 7 Nov 2009, Duncan wrote:

> The big combo tarball could then be restrict=mirror or whatever, with
> or without a specific user click-thru (and restrict=interactive or
> whatever) as necessary and already used on some packages, following
> existing policies.
> 
> Of course, there's certainly the complexity of automating the tarball 
> unpack of only the specific needed components, but gentoo/kde has a 
> **LOT** of experience with that sort of thing by now, and I'm sure
> they'd be happy to share hints and helpful tactical strategies with
> you, if you ask, and there's no way I can conceive it being even half
> as dependency convoluted as kde4 was to figure out, so it should be
> FAR easier.

To make myself clearer, the tar ball includes a few binary rpms and a
installer blob. Both icc and ifc tar ball include the mkl, idb and some
common library rpms. If we go for a kde-split with a mirror
restrict approach, users would still have to download the big (~800Mb)
tar balls. Only users with use of all (icc, idb, ifc, mkl, ipp, tbb)
intel software would benefit of downloading them. It is also the fact
Intel has a history of changing their packaging system. Not to
mention that a rpm split seems to me lot simpler to maintain and
quicker to package for me than the kde-split mirror-restricted approach,
and the fact my interest for these packages is limited.

--
Sébastien

[gentoo-dev] Re: redistribute intel rpms

[Duncan]

Sébastien Fabbro posted on Wed, 11 Nov 2009 22:55:20 -0800 as excerpted:

> To make myself clearer, the tar ball includes a few binary rpms and a
> installer blob. Both icc and ifc tar ball include the mkl, idb and some
> common library rpms. If we go for a kde-split with a mirror restrict
> approach, users would still have to download the big (~800Mb) tar balls.
> Only users with use of all (icc, idb, ifc, mkl, ipp, tbb) intel software
> would benefit of downloading them. It is also the fact Intel has a
> history of changing their packaging system. Not to mention that a rpm
> split seems to me lot simpler to maintain and quicker to package for me
> than the kde-split mirror-restricted approach, and the fact my interest
> for these packages is limited.

OK, makes sense... as long as there's legal cover to do it.  If there's 
not, then we're back to doing the split.  And asking about the legal 
cover is what this thread's all about.  Fair enough.

I was simply wondering if the split had been given due consideration as I 
didn't get that from the original post, but it appears so.  Thanks.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman